Indicators of Compromise

Indicators of compromise are artifacts and evidence observed inside information systems confirming the existence of attacker actions. These indicators of compromise (IOCs) include virus signatures, changes to file systems and registries and outbound and inbound connections to and from known malicious URLs and domains, to name a few. Threat intelligence documenting indicators from known threat groups adds context to investigations. When indicators point to potential threat actors as the source of an attack, the response team may be able to quickly ascertain the systems affected, by searching for the known indicators of that group.

Containment Fundamentals

After the systems are isolated, images should be taken for use during the investigation. As those images are analyzed, identification and imaging of other affected systems are completed as well. As more and more systems are taken offline, productivity issues will ensue, and communication with the business is vital. Several open source and commercial solutions are available, such as Volatility, Rekal, and EnCase. File system and memory images are key here.

Once all identified systems are imaged, the response team correlates the data from each to further identify IOCs not yet investigated. The response team’s goal is to identify as comprehensive a list of affected systems as possible. Attribution is not always necessary. In fact, for most entities, it is the last thing the response team should focus on. The focus should first be to contain the event and prepare for eradication.

Choosing a Containment Strategy

If incident response objectives are to identify, contain, and eradicate incidents as quickly as possible before any damage is done to sensitive data assets, what is the strategy for doing this? First, entities must assess the capabilities for containing events and incidents once they are identified. Small and medium-size organizations possess limited resources for responding properly to events, identifying indicators, uncovering them in information systems, and taking forensic images. These are specialized skills not often possessed internally. The strategy discussed in Chapter 5 engages outside entities to monitor detective capabilities such as data loss prevention, log correlation and security event management solutions. The strategy starts with identifying the event, working in concert with the third parties providing support to identify the IOCs and searching through the environment to locate other end points at which these indicators are present. The strategy then dictates eradicating the event and restoring systems, topics covered in Chapter 9.

The examples below outline specific types of containment but are not all-encompassing. Not every attack requires its own playbook, for example, attacks against a web application or server. The threat actor may exploit a vulnerability and gain access to the application or server. During the attack, the adversary may use rootkits, malware, and other tools to move laterally, elevate privileges, and maintain persistence. Playbooks may exist for the malware, rootkits, and unauthorized use of elevated privileges, but documentation about responding to web attacks or specific web vulnerabilities may not exist. A forensic investigation would lead to the web vulnerability as the source of the attack, with remediation occurring during the recovery phase.

Malware and Ransomware Outbreaks

Examples of containment activities specific to malware and ransomware outbreaks are highlighted in Figure 8-1.

When notification of malware or ransomware is received, the incident response team must verify if a threat really exists. This could be a false positive, older malware not posing a threat to the entity, or malware from an active threat actor meant to be malicious. If the incident responders have the sample available, there are several ways to determine if a threat may exist. Databases such as VirusTotal allow users to upload attachments, hashes, and Universal Resource Locators (URLs) to get results based on others’ experiences. Figures 8-2 through 8-7 display sample results of a file uploaded to VirusTotal for the Locky Ransomware strain. The images show the initial report on the file uploaded and an analysis of Locky behavior.

Figure 8-2 shows the results of the Locky Ransomware analysis. These results , based on the last analysis of Locky on May 15, 2018, show that 54 of 66 virus engines detected this as malicious. The results for the first 26 engines are shown in Figure 8-2, and the remaining 44 are displayed in Figure 8-3.

Figures 8-4 to 8-7 show the results of the behavior analysis tab. Figure 8-4 displays network connections using HTTP, TCP, and UDP connections.

VirusTotal shows Locky connections to 149.154.68.190 using HTTP and 149.154.68.190:80 on TCP. The UDP connection attempts to connect to the DNS server on port 53.

Figure 8-5 displays the files opened and files read by Locky .

Locky opens several files, notably systems files. It also reads several systems files and several in the Python library. These are indicators the incident response team can use.

Figure 8-6 shows snippets of files written and files moved by Locky . Because the ransomware is Python-based, these files are all Python as well.

Figure 8-7 shows the process and service actions executed by Locky and the modules loaded by the ransomware.

Locky opened the SERVICES_ACTIVE_DATABASE - localhost service manager and the RASMAN, WebClient, and LanmanWorkstation services.

Caution

Attachments uploaded to VirusTotal for scanning are kept in the database. Be careful of what is uploaded, because the contents of the documents uploaded are publicly available.

Uploading the file or executable normally allows VirusTotal to provide associated domain names or IP addresses, if available. VirusTotal also lets you upload domain names and IP addresses for analysis. Learning the domain where the malware originated might lead to detecting command and control (C2) traffic, or, at least, equip the entity to block those domains and IPs from further communication inside the organization. Malware often communicates externally to C2 servers. These servers deliver instructions to the malware at specific intervals, based on call-backs to the C2 server. Detecting the history of calls to C2 sites by the malware is possible with packet capture software such as WireShark. WireShark is an open source tool with many features for capturing and analyzing traffic for investigative purposes. The key to detecting C2 communication is knowing what to look for, based on the initial analysis of the malware. In its article “Detecting and Analyzing Locky Ransomware,” Digital Guardian displayed the malicious domain and IP used by the ransomware to download the malicious executable file 765f46vb.exe.¹ Once initiated, Locky connected to 177.185.194.115, http://comprecaldas.com . No matter the tool utilized, tying these indicators back to machines making connections helps the incident response team detect other infected machines on the network.

Entities with a sandbox environment can also detonate the malware and document its behaviors. Some well-crafted samples sense when a virtual environment is being used and will not execute, preventing incident response teams from learning the characteristics of the sample. If successful, dynamically analyzing the malware sample elicits real-time indicators of events when end points are affected, including

• Are files created and deleted?

• Are registry changes made?

• Does the malware attempt to connect outside the network?

Microsoft Sysinternals RegShot, ProcMon, and Process Monitor dynamically analyze malware behavior. Each is available as an open source solution, and all are common tools available to individuals requiring low-cost ways to conduct dynamic malware analysis. Table 8-1 outlines the purpose of each tool.

Table 8-1

Four Tools Commonly Used to Conduct Dynamic Analysis of Malware

Tool	Purpose
ProcMon	A.k.a. Process Monitor, this tool is available through Microsoft Sysinternals and monitors file system and service behavior, noting any changes made by the malware.
RegShot	In Windows environments, RegShot takes before and after snapshots of the registry. Once the malware is detonated in the sandbox, a second snapshot is taken.
Process Explorer	Another free Microsoft tool, Process Explorer displays services and the associated dynamic link libraries (DLLs) attached.

Detonating malware in a sandbox running ProcMon captures file system changes made by the malware and the starting and stopping of services. RegShot highlights changes made to registry settings by the malware, and Process Explorer shows services running, such as those captured by ProcMon. However, there is one exception, analysts can review the DLLs attached to those services. DLLs are libraries used to share code among applications and programs in Windows. Malware uses DLLs the same way, and threat hunters identify DLLs used by malware can search for DLLs attached to the processes run by malware as additional means for confirming that a machine or system is affected by the attack.

Figure 8-8 shows an image with the information Process Monitor provides. Analysts see the process name, process ID (PID), operation, path, result, and details.

If the malware is an executable, analysts observe the details for later use, searching for other instances of the malware in the environment. The processes in this example highlight numerous activities affecting the registry and one initiating a file read. The details lead analysts to further sources of investigation.

Commercial sandboxes are offered by several entities. Solutions often execute the malware in the sandbox and report the IOCs to the team. Teams do this manually or, when suspicious files traverse the network, they can be automatically detonated in the sandbox, with results sent to analysts.

Once the malware is examined and all indicators of compromise are documented, the incident response team can get down to finding all affected end points. If available, end point detection and response (EDR) SIEM and packet capture sources are used to inventory all affected devices.

Data Theft

One of the worst situations an incident response team can find itself in is containing data theft. These events are newsworthy and require the team to catch up in a hurry. Indicators of data theft are obvious; others are subtler. Figure 8-9 highlights examples of each.

The context of these warning signs is key to understanding the impact of the situation. Attacks on databases housing sensitive information, PII, ePHI, intellectual property, and trade secrets are serious. The same goes for alerts resulting from full disk space. If this situation occurs on infrastructure hosting sensitive data types, impact could be more significant. Further investigation is required because data can be moved from sensitive locations to less sensitive locations before exfiltration outside the entity boundaries.

User-based alerts, e-mails returned for size, working outside normal hours, and use of removable storage, which should be restricted to a select few, necessitate investigation of the user’s access rights. Immediately understanding the class of assets at risk is important. Users with access to the data types previously mentioned pose the biggest threat to the entity.

Retaining Forensic Investigators

Throughout the response, the team must gather digital evidence, to understand what happened. Some of this evidence is used to identify other compromised systems, and some is used to understand how the attack occurred. Images of systems in question are obtained by the incident response team. There are numerous commercial and open source tools to conduct these tasks, but, as discussed earlier in this chapter, the skills are not often found internally.

Retaining an incident response firm prior to an incident is ideal when you know the capabilities to respond do not exist on the team. These experts have experience containing incidents and collecting forensic evidence in response to cyberattacks. Depending on the agreement, the expected level of service might place the team on-site within 24 hours, or it could be that experts promise best efforts to place a team on-site as soon as possible. During large outbreaks, such as WannaCry, best efforts may mean days or weeks before response help arrives. Attention to these details is necessary, to make sure the required response times are built into the agreement.

Once a firm is engaged, on-site workshops and walkthroughs teach the entity’s local IR team what to expect when calling the firm for assistance, expectations for deploying forensic tools in the environment, and opportunities for improvement that the forensic firm identified during these discussions. IR teams must be prepared to rapidly deploy forensic tools used by these firms and plan to gather the necessary approvals to do so.

Executive Expectations

One obstacle the incident response team will face during the containment phase results from executives and members of the business wanting rapid answers and conclusions. This is understandable. Business repercussions may be looming, and leaders want to get in front of any negative situations. The incident response team must stay focused on the task at hand, sharing relevant information when possible, updating leaders on the steps taken and planned, but resisting incomplete or speculative information just to appease the audience. Doing the latter can cause more harm later.

Summary

Containment requires an organization to collect indicators of compromise. Indicators are attributions and artifacts left behind during events. Threat actors have specific attributes, based on tools, techniques, and procedures used. Specific types of malware or ransomware make changes to systems the incident response team uses to search the remaining information systems and assets. When matches to the indicators hit, the incident response team can quarantine these systems, taking them offline for further analysis.

The process of gathering an initial set of indicators and searching for signs of each in the remaining systems are documented in playbooks used by the response team. Playbooks are specific to event types: malware/ransomware, denial of service, lost assets, data theft and unauthorized use or misuse of company assets. This is not a complete list, but very common scenarios seen by incident response teams.

During the containment phase, forensic evidence used to determine the root cause and how the event unfolded is also gathered. Images of the systems are captured for complete analysis of all system characteristics as part of containment.

During this time, incident response teams deal with contact from members of the business and company leadership seeking answers. This is to be expected. The organization could be impacted, depending on the severity of the events in question, and these groups have a need to know. The key is to give facts and not speculate. Speculation causes more harm than good.