This is a post authored by Matt Suiche (Director, Memory, IR & R&D • Product Management, Magnet Forensics & Founder, Comae Technologies & OPCDE Conference) with contributions by Jamey Tubbs (Director of Training, Magnet Forensics).
When analyzing malware and exploits (or troubleshooting issues), you’ll find it in memory—even if it can’t be found on disk. Memory will give you a look at the exact state of a device at a specific time; this is why memory analysis, or memory forensics, is important to DFIR (Digital Forensics and Incident Response). Memory capture and analysis is an important step of DFIR before rebooting a machine or device because implants may not be persistent, as mentioned recently by Sen. Angus King. The National Institute for Standards and Technology (NIST) has authored a Guide to Integrating Forensic Techniques into Incident Response.
In paragraph 220.127.116.11 they profess, “On most systems, it is not possible to avoid alteration of RAM when running a utility that attempts to make a copy of RAM. Instead, the goal is to perform the copying with as small a footprint as possible to minimize the disruption of RAM”. As the NIST has explained in this document, the need to gather memory, and be minimally invasive in obtaining it, is such an important part of DFIR that it cannot be overlooked.
Despite being a critical step, it’s often left out due to poor user experience, the required operating system internals knowledge, and reliance on manual operations because of the lack of automation.
Comae has been developed to help in memory analysis—learn more about how you can use it in incident response, threat hunting, and compromise assessment.
Firstly, when you access the Comae platform, you’ll have the option to download DumpIt which is our memory acquisition tool. One of the specificities of DumpIt is that it will create a full memory crash dump file (.dmp) which is interoperable with Microsoft WinDbg as it is a native Microsoft Windows format.
A lot of legacy memory acquisition tools will do a 1:1 memory copy of the physical address space and fill reserved memory spaces by other devices with null bytes resulting in unnecessary memory usage that has nothing to do with the RAM. On top of that, another sacrifice done by legacy raw memory images is that fact that while they require a driver to access the memory of a live system, they do not leverage this to collect a lot of the information required for analysis which later results in carving memory for key structures required for analysis. When using an existing format such as Microsoft crash dump files, or ELF core dumps – modern acquisition tools leverage structured data required for analysis just like debuggers have been doing for the past decades.
Another option to generate memory dumps as supported by Comae memory analysis platform is to leverage process minidumps which can be generated either by utilities like Microsoft Process Explorer, ProcDump, or even some of the EDR agents like Microsoft ATPs which let you target which suspicious process you want to target for an acquisition. There are also other scenarios where process dumps can
be leveraged, for instance in the case of serverless web jobs on Microsoft Azure App Services (w3wp.exe).
Compact acquisition utilities are very practical as they are easy to deploy by leveraging pre-installed agents to deploy and run DumpIt.
- Cloud Security. Where pre-installed agents are already present in virtual machines such as the AWS Systems Manager Agent (SSM Agent) that runs on Amazon instances and equivalent.
- Enterprise Security. Where EDR/XDR agents are already present on the machines and where security response features such as CarbonBlack LiveResponse, CrowdStrike Real Time Response, and SentinelOne Remote Script Orchestration (RSO), etc.
Memory dumps are very useful for compromise assessments, but also for retro-hunting – especially in scenarios where you historically collect and keep full system images of your critical assets in order to have the option to go back to them whenever you are aware of a new IOC or new threat actor to cover gaps that EDRs and XDRs were not able to cover at the time.
Assuming breach is a mindset but being able to verify breach at a later point in time is the equivalent of having a time machine for compromise assessment. As we know, EDRs are best effort technology in terms of active protection – it is very important for enterprises to have complementary scenarios for when protection fails.
Analysis & Hunting
Having data is great, but the main question for any analyst or security researcher is often, how can I browse and query this data efficiently? As we move forward with a smooth user experience that allows us to get a bird’s eye view perspective on a system, we wanted to focus on having the ability to ask questions to a memory image and to have repeatable operations to selectively and swiftly be able to categorize images while investigating a case.
This is how we started working on SQL-like queries and actionable playbooks allowing us to assign MITRE ATT&CK tags to queries. Mapping events to MITRE aims at providing analysts with more visibility and clarity to results. Here is an example of a playbook for OS Credential Dumping (T1003.002):
name = "OS Credential Dumping with mimikatz"
threat = "malicious"
mitre = ["T1003.002"]
sql_query="select processId, commandLine, imageFileName from `Processes/processObject` where imageFileName = 'mimikatz.exe'"
Here is another one for Obfuscated Files or Information (T1027.002) to identify uncommon section:
name = "Uncommon section names"
[[query]] threat = "suspicious"
mitre = ["T1027.002"]
sql_query=""" select distinct p.processId, p.imageFileName, p.commandLine, s.name from `Processes/processObject` p left join `Processes/processObject.imageFileObject.sections` s on p.identity=s.identity where s.name not in ('.text', '.data', '.rdata', (...), 'RT_DATA', 'RT_CONST')
And another one for Process Injection (T1055.001) by looking at allocated pages in processes:
name = "Executable memory pages"
threat = "malicious"
mitre = ["T1055.011 "]
select distinct p.commandLine as commandLine
from `Processes/vadObject` as v
left join `Processes/processObject` as p
where v.isImage = true and v.protection = 'MM_EXECUTE_READWRITE'
Another way IOCs can be leveraged for threat hunting is to use the hashes of executable sections of binaries in memory, similarly to hashes of files on disk we can use queries to search of memory-based IOCs.
select distinct p.processId, p.imageFileName, p.commandLine, s.name from
`Processes/processObject` p left join
`Processes/processObject.imageFileObject.sections` s on p.identity=s.identity
Another way to use memory queries is also to leverage existing playbooks such as Sigma playbooks used for SIEMs. Let’s take a look at Sigma signatures with the CommandLine keyword such as proc_creation_win_powershell_susp_parameter_variation.yml which aims at detecting suspicious PowerShell invocation with a parameter substring such as exec bypass which corresponds to Command and Scripting Interpreter: PowerShell (T1059.001) from the MITRE ATT&CK techniques.
Here is an example of query to detect the above behavior by querying keywords within the commandLine variable of processObject nodes.
select imageFileName, processId, commandLine from `Processes/processObject` where commandLine like '%exec bypass%'
For additional examples, you can consult our Knowledge Base on our website: Hunting with MemQueries – Comae Knowledge Base.
If you’re interested in trying out Comae to see how you can use it to diagnose cyber-attacks quickly and efficiently through memory analysis—then be sure to join Magnet Idea Lab to take part in a special beta program!
Plus, if you’re looking to join a team that’s focused on producing software that solves the most important problems facing digital forensics and incident response professionals today, take a look at this open role for a Sr. Software Developer – Rust (lever.co).
To learn more about how to use Comae for Incident Response, sign up for our June 15th webinar “Volatile Memory IR With Comae Beta From Magnet Idea Lab“.