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.