NIST Methodology of Incident Response — Illustrated

In this article, we will act as a network defender and apply our expertise in intrusion detection and response skills to help identify and stop the current attack as well as mitigate and deter future intrusions. We will be applying the response tactics, techniques, and procedures (TTPs) regarding the campaign that we created in Part I of this sequel (Lockheed Martin Cyber Kill Chain — Illustrated).

I will be utilizing the standard NIST Incident response methodology for this project since it helps in getting organized during analyzing security incidents.

NIST methodology

Preparation

After the incident has already happened, the first thing we need to do is prepare for the response program. This includes compiling the complete list of IT assets present onsite like servers, IDS/IPS, network segmentation, and endpoints. It’s now time to set up the monitoring by baselining the activities i.e, what a normal network flow will look like. Anything that may seem abnormal or above this baseline will need further deep analysis.

Detection and Analysis

Firstly, it’s important to assemble all the employees and query them if any abnormal activities have been suspected recently. This may include installing new applications inside the host, downloading from insecure websites, plugging unauthorized USB devices, clicking mail attachments, or anything that is above baseline. Since almost all of the employees had received that malicious mail, this issue will surely be raised in this meeting which will give our analysis a direction and a place to start.

One of the faults with Evil Corp is not giving attention to the alerts and triages made by the security tools in place. Moreover, the IPS/IDS systems are not being frequently updated with the signatures of new prevailing malware so the malicious things can lurk freely.

In the meantime, we will collect all the logs and data from the IT systems, security tools like IPS/IDS, people inside the organization, and the indicators (events suspected by the IT team as malicious). Then the analysis of the incident is started.

Since the malware on the endpoints will talk to each other using SMB, this level of interaction is above the baseline and require further analysis. Moreover, the router logs show up interesting domains to which data is being sent that the company even doesn’t know about.

The actual exploit that was used can be harvested from the malicious email that is present in all employee’s mailboxes. The exploit needs to be reverse-engineered for code analysis and detecting the endpoints with which it’s been communicating. And all the privilege escalations methods should be analyzed to exactly know which process the malware has actually transplanted itself. Sometimes it can be a rootkit that will go deep down the kernel which is really tough to get rid of.

Hashes of common services can be compared with the original to accurately determine which service was modified. Process owner, start time, OS, and network resources it is using, all helps in pinpointing where the malware actually resides.

Containment, Eradication and Recovery

It’s necessary to contain the network and take down the whole infrastructure for some limited time so that further damages and data exfiltration can be stopped right away. From the analysis, it should be clear now that this malware is using a domain generation algorithm to connect with the C2 servers. Since we have already blocked all the outgoing traffic there should be no data leakage from now on.

Sometimes taking down the whole business infrastructure is not possible, so we need to perform domain blacklisting to stop every network communication with the threat actor. We can make use of reactionary detection techniques that rely on non-supervised clustering techniques and contextual information like network NXDOMAIN responses, WHOIS information, and passive DNS to make an assessment of domain name legitimacy. Since it is not 100% reliable, we will quickly need to move to the Eradication and Recovery phase.

Post-incident Activity

This is also an important part of NIST incident response methodology which focuses on learning from the previous incidents to improve the process. The motto is to limit the chances of the incident happening again and to identify ways of boosting future incident response activities.