Hot Topics
Security Bloggers Network 
SBN

Malware Analysis Part 3: The phases and roles of incident response

by Tony Robinson on November 11, 2021

In Part 3 of this series, I’m going to cover incident response and the role it plays in malware analysis. If you haven’t had a chance to read the earlier parts of the malware collection, you can find them here:

Data Forensics and Incident Response (DFIR) is, in a word, complex. Before we go any further into this blog post, if you’re not familiar with the Incident Handler’s Handbook from SANS.org, I would highly recommend taking a look at it. You don’t need to read the whole thing if you don’t want to, but you really should. It’s only 19 pages, it defines the phases of a security incident, and it has been a cornerstone of incident response plans for the better part of a decade now. 

Phases of the Incident Response Cycle

The Incident Handler’s Handbook report identifies the following phases of an incident:

  • Preparation – The necessary steps to ensure that a SOC (Security Operations Center) or CIRT (Computer Incident Response Team) can respond to an incident at a moment’s notice. It includes things like:
    • Acceptable Use and/or other system policies
    • Response plans (e.g., prioritizing events by impact)
    • Knowing who to communicate with when issues arise
    • Picking team members to serve as members of the response team who specialize in different roles
    • Documentation on what actions the incident responders are supposed to take and in what order
    • Ensuring responders have proper access to perform their duties
    • Verifying that response team members have the right tools for the job (e.g., a jump bag full of necessary equipment)
    • Proper training for the responders in order for them to fulfill their duties
  • Identification – Knowing when an incident has been triggered or detecting when an asset or system has deviated from normal operations. This could be reports of a system that is behaving abnormally or an alert triggered from network and/or host-based intrusion detection logs.
  • Containment – Knowing how far the threat has spread, stopping the spread, and preventing further damage once the threat has been identified.
  • Eradication – dealing with removal and restoration of affected systems, including patching and/or mitigating vulnerabilities that caused the incident in the first place.
  • Recovery – Bringing affected systems back into production and testing to ensure that the affected systems are clean and fully functioning.
  • Lessons Learned – addressing incomplete documentation or security problems encountered during an incident, and completing additional documentation that may help with future incidents.

The Roles We Play

Malware analysis can play a very important role in the incident response cycle. The points in the cycle in which malware analysis plays an important role are in the Identification, Containment, Eradication, and to some extent, the Recovery and Lessons Learned phase. 

Practice Exercise: z0Miner

Indicators of compromise, AV signatures, IDS/IPS rules, etc. all help to identify known threats. That much is pretty obvious–but then there are actions and capabilities that aren’t easily converted into indicators. 

In part 2 of this series, we covered the MITRE ATT&CK matrix and how capabilities are divided into categories. We also noted that while capabilities don’t necessarily have indicators associated with them, they are important to identify because they identify how threat groups, malware, and implants do what they do. Keep this in mind as we progress through this exercise.

Let’s say your organization runs Atlassian Confluence locally. And for some reason, the recent remote code execution vulnerability against Confluence was not mitigated or patched. Maybe the asset wasn’t being managed properly, maybe nobody knew it was there, or perhaps there was a production change freeze in effect. Regardless of the reason, the server exists, and the vulnerability exists. 

Now bad guys are starting to exploit this vulnerability. In one such example, bad guys are installing “cryptojacking” software. Cryptojacking involves the unauthorized use of a device to mine for cryptocurrency. For more information, check out this article by Kaspersky.

In our case, the cryptojacking malware in question utilizing this vulnerability is called z0Miner. This article by TrendMicro details everything they know about z0Miner. The article shows what vulnerabilities have been used in the past to drop z0Miner in addition to the recent change where they started using CVE 2021-26084. 

This vulnerability is what enables the malware to get installed. It represents something that the malware needs in order to be delivered. The MITRE ATT&CK tactic utilized here is initial access, and the technique would be exploitation of public-facing applications. This use of this vulnerability maps to the Identification, Containment, Eradication AND Recovery phases of the Incident Response cycle. 

We can Identify systems vulnerable to CVE 2021-26084. Check them for signs of compromise and contain them as necessary to prevent possible spread. Remove and recover infected, vulnerable systems. As a part of the recovery phase, ensure the vulnerability is patched and mitigated across vulnerable systems.

Malware utilizes a variety of methods for delivery; one of the most common aside from phishing is utilizing remote code execution vulnerabilities with proof of concept code available to deliver malware–z0Miner is just one such example. Identifying what vulnerabilities are used to deliver malware so that those vulnerabilities can be patched or otherwise mitigated is very important.

Towards the end of the report, they provide a list of MITRE ATT&CK tactics and specific techniques the malware itself utilizes. These techniques may or may not have specific indicators of compromise associated with them, but they nonetheless are important to note because they represent methods for identifying the malware. 

For example, two tactics identified are the installation of a service “Hyper-V Guest Virtualization Service” utilizing the DLL file, “vmicguestvs.dll”. Another method identified involves the installation of a scheduled task “.NET Framework NGEN v4.0.30319 32”, that is actually a powershell command that downloads and executes PowerShell retrieved from a pastebin URL. This URL contains the cryptomining tools. Towards the end of the report, these techniques are represented as:

T1569.002: System Services: Service Execution

T1053.005: Scheduled Task

T1543.003: Create or Modify System Process: Systems Service

T1036.004: Masquerade Task or Service

The creation of services and scheduled tasks aren’t necessarily things that malware analysts can use to produce IoCs.

While the vmicguestvs.dll file is an artifact that is dropped to disk can can be hashed to serve as an indicator of compromise, all of the actions associated with creating a new service or scheduled task aren’t easily hashed. They do, however, represent tactics that the malware uses that can be hunted for, including:

  • Have any new services been installed?
  • Have any new scheduled tasks been installed?
  • Is it normal to observe PowerShell being executed from this host? 
  • Are PowerShell script blocking and/or process execution logs enabled for us to observe executed PowerShell scripts on this host and/or the parent process that spawned them?

If you can define and document the action malware takes on a host, it can be used during the phases of incident response to help bring incidents to a close. 

The tactics and techniques mapped to the MITRE ATT&CK matrix can be used to identify the malware, contain it by identifying systems in which similar/identical services or scheduled tasks have been recently installed and identifying those hosts for removal and restoration. Finally, we can test for proper recovery from this malware by verifying that the restored system no longer exhibits any of the techniques listed above.

However, the creation of new services and scheduled tasks that seek to masquerade as legitimate services and jobs represents tactics and techniques that we can take other actions to detect. See the bulleted list above for examples of some actions that can be taken to help guide incident response against this threat, but not /just/ this particular threat.

Below the table containing the ATT&CK matrix tactics and techniques, we have a score of indicators of compromise–file hashes, URLs, and IP addresses associated with z0Miner. File hashes for artifacts dropped to disk and URLS associated with initial malware delivery, as well as delivery of second stage implants and tools. 

This information is useful for identification of this particular threat, containment, and eradication by identifying other hosts with the same indicators or who visited the same IP addresses, as well as for recovery by re-scanning the hosts for the indicators to confirm they are no longer infected once restored.

File hashes that represent files dropped to disk as part of this malware campaign…

…as well as URLs and IP addresses that represent initial exploitation attempts, initial payload delivery, and delivery of additional stages of malware and/or other tools used by this campaign. These indicators would serve us well in the Identification, Containment, Eradication, and Recovery phases for this particular malware campaign. We could scan for artifacts dropped to disk using endpoint protection tools, check firewall, flow, proxy and/or IDS/IPS logs for any visits to these IP addresses or URLS to identify all systems that may be infected for containment/eradication. Then, for recovery we can re-scan using these indicators to confirm that the threat was properly removed when the infected systems were restored.

Lessons Learned

After we’ve successfully identified the threat, contained it, eradicated it, and recovered from it, The final step is lessons learned from this exercise. While malware analysis doesn’t /directly/ contribute to this phase, our actions taken can be rolled into a lessons learned report that can improve processes and documentation so that this doesn’t happen again.

For example, we know the host was running Confluence and that it was exploited to drop z0Miner. What process or documentation gap led to this happening? Was it due to poor asset management? Was it from a lack of patch management? Vulnerability management? Lack of flexible change control? How do we prevent this from happening again? 

The solution could be a multi-pronged approach, or it may simply be another meeting to discuss the feasibility of retiring your local Confluence instance and re-hosting it in Atlassian’s cloud, where they can handle patch management.

What data sources do you have available for sweeping for the indicators the report identified? What data sources are available for searching for the tactics and techniques identified in the report? How can the gaps in data visibility be addressed? These are all things that your analysis and understanding of the malware indirectly influences in the lessons learned phase.

Conclusion

Malware analysis plays a major role in responding to security incidents. The Incident Handler’s Handbook is a wonderful resource that has been used for well over a decade to define the various phases of a security incident and map malware analysis phases. This helps analysts understand that what a sample does plays a direct role in various phases of the incident response cycle.

If you’re interested in learning more about malware analysis, I have a few recommendations:

  • If you want to play around with malware, triage it, perform static analysis, and/or do any sort of dynamic analysis, you should learn how to build a lab environment with strong security controls so that your experiments don’t escape containment. In 2017, I wrote a book on creating virtual machine labs with strong security controls to help students protect themselves while experimenting as well as to help keep those experiments contained to protect others who share the same network. I’ve since re-written that work. Print copies of this second edition are available on Amazon, and a digital deluxe edition is also available if money is a little tight or if you want to evaluate the book before buying a physical copy. 

The post Malware Analysis Part 3: The phases and roles of incident response appeared first on Hurricane Labs.

*** This is a Security Bloggers Network syndicated blog from Hurricane Labs authored by Tony Robinson. Read the original post at: https://hurricanelabs.com/blog/malware-analysis-part-3-the-phases-and-roles-of-incident-response/?utm_source=rss&utm_medium=rss&utm_campaign=malware-analysis-part-3-the-phases-and-roles-of-incident-response

Tony Robinson , ,