Industry News

How to Conquer Memory Analysis for Incident Response, Threat Hunting and Compromise Assessment

Matt SuicheThis 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 5.2.1.2 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.

Turn off, turn on: Simple step can thwart top phone hackers | AP News

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.

Acquisition

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"

[[query]]
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"

[[query]]
threat = "malicious"
mitre = ["T1055.011 "]
sql_query="""
select distinct p.commandLine as commandLine
    from `Processes/vadObject` as v
    left join `Processes/processObject` as p
    on v.identity=p.identity
    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.

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 
where s.rawMd5Hash='a371492f16c0940507435909603efe88' 

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%' 
Here is an example of query to detect the above behavior by querying keywords within the commandLine variable of processObject nodes.

For additional examples, you can consult our Knowledge Base on our website: Hunting with MemQueries – Comae Knowledge Base.

Conclusion

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“.

Subscribe today to hear directly from Magnet Forensics on the latest product updates, industry trends, and company news.

Start modernizing your digital investigations today.

Top