The Importance of Memory Forensics
Information security practitioners know the benefits of examining multiple sources of system data. This is one of the corner stones of the SIEM. By accumulating multiple sources of log data a richer and fuller picture can be developed. I like to break down sources of security data into four categories:
- system state including memory contents, registry entries, logged on users and more
- system disk including stored files and their locations, system or event logs and more
- recorded network traffic and network IDS events/alerts and more
- third party logs from systems providing services such as DHCP, firewall logs, and more
Incident response often involves directly investigating a compromised system which typically focuses on the first two above categories. An investigation is typically started when an indicator of compromise is seen associated with a system within a network. Good responders don’t just wait for alerts to come to their inboxes, however. Forensics scanning frameworks are often used, similar to but differently scoped than vulnerability scanners and similar to but broader than antivirus scanners, to identify systems with suspicious configurations or states.
As much system data is volatile, many forensics examiners will prefer investigating a “live” system or one that has not ben powered off since the compromise. This is because malware is not running, network connections are not open, and attackers are not logged in when the system is off. All of these indicators can be collected from “live” systems and can be found within the system’s memory. Analyzing the memory of a system is most fruitful for determining current system state.
An Open Source Memory Analysis Framework
Enter Rekall, a cross platform open source framework for analyzing system memory (from both “live” systems and memory dumps). Written in Python, Rekall came out of branch of the Volatility project. It scans system memory for specific kernel structures and parses them. Structures include:
- system registry
- running processes
- open network sockets
- arp table entries
- mounted disks
It is incorporated into Google Rapid Response (GRR) a framework for deploying scalable forensics scanning of large environments. Rekall has an extensible plugin architecture and comes with many useful plugins including Yara scanning of memory. The plugin architecture also allows for custom plugins.
Investigate Your Memory
One plugin that grabbed my interests was the dns_cache plugin for Windows systems. It scans the memory image loaded into Rekall for Microsoft’s dnsrslvr.dll library which is loaded by the svchost process. This DLL provides the DNS Caching Resolver Service which acts as a local DNS cache for the operating system.
I added some logic to this dns_cache plugin to allow Rekall to send the domain names identified in the system’s DNS cache to OpenDNS’s Investigate API and display the categorization of the domain name from within Rekall. To use this new functionality download this fork of Rekall, drop in an Investigate API key, and install Rekall as shown here. For capturing an image of live memory from a running system, you’ll also need the winpmem kernel driver for accessing physical memory as a file (the SANS Internet Storm Center has a nice write up about it here).
An example of the results displayed by this DNS cache option are shown below: