The Value of Physical Memory for Incident Response

Physical memory refers to the random access memory (RAM) of the computer. RAM can be added or removed from a computer by adding or removing memory chips. Windows computers typically have anywhere from 256 Megabytes of RAM to over 2 Gigabytes. RAM is volatile memory that is lost when a computer is powered down. While the computer operates, RAM stores all the accumulated data for running applications and network communications. The RAM will contain the contents of application windows, keystrokes, and even email attachments. There is a wealth of information in RAM that exists only when applications are running. Most of this information cannot easily be obtained from a hard drive. Information that can be obtained from RAM includes: All running processes at the time of the memory snapshot All loaded modules and DLL s (dynamic link libraries) including injected malware All running device drivers, including potential rootkits All open files for each process, including path to file on disk All open registry keys for each process All open network sockets for each process, including IP address and port information that is calculated at runtime, such as packet buffers Decrypted versions of otherwise encrypted data Contents of windows Keystrokes Email attachments, file transfers, and other secondary data Cryptographic key material Hard drive encryption keys WEP and WPA wireless keys Usernames and passwords For many years, forensic analysts have known that physical memory is valuable. Tools have been developed to forensically image the contents of RAM, similar to the way a hard drive image is taken. But until very recently, nobody has built tools to analyze the contents of these physical memory images. RAM analysis is hard you have to parse undocumented and esoteric data structures which are unique to each operating system version. Every computer program and activity that is represented in the RAM can only be recovered through many layers of analysis. In the past, this had to be done by hand and thus was error prone and did not scale. Challenges to physical memory analysis include: Identification of the operating system, version, and service pack Use of undocumented internal data structures to the operating system Internal data structures may change between versions and service packs of the OS White Paper: The Value of Physical Memory for Incident Response Page 2 of 7

Physical memory Pages must be sorted and organized to rebuild the memory of the operating system Many sections of memory are paged out and this must be accounted for To extract an EXE or DLL file from memory it must be reconstructed and fixed up to return it to the portable executable (PE) format Traditional MD5/SHA1 filesystem hashing does not work for in memory files, the hashes will not match These reasons and more are why nobody has built a tool to perform analysis. Not only does a tool need to perform complicated and layered analysis, to be deployable as a product it must be able to analyze all the different versions and service packs of an operating system. This is made more difficult when dealing with closed source operating systems such as Microsoft Windows that are patched on a regular basis. Physical memory forensics can be used for a variety of purposes: Augment disk based forensics Detect which files each process had open at the time of seizure Detect if sensitive or proprietary data was being stolen Detect back door programs, spyware and keyloggers Detect advanced attacks, such as in memory only backdoors 1 Obtain unpacked/decrypted versions of programs that are packed/encrypted ondisk Detect hidden processes and drivers, such as rootkits Detect recently used email and web addresses Detect recently edited files Rootkits and other malware pose a serious threat to the Enterprise. Physical memory forensics offers a unique and powerful way to detect and analyze these threats. A rootkit may hide itself by patching the kernel or hooking functions on a running system, but a physical memory snapshot is analyzed offline and thus is not subject to these bypasses. The simple fact is that for code to execute it must exist in RAM, thus it can be found. Automated scans can detect many suspicious behaviors in running software, including potential rootkits. Combinations of factors can be used to narrow the search. For example, if a keyboard driver is accessing the filesystem, this may indicate a keylogger (see Table 1). Although not guaranteed to be malicious, the behavior is suspicious. 1 Metasploit Meterpreter, etc. White Paper: The Value of Physical Memory for Incident Response Page 3 of 7

Table 1 Two suspicious properties found on the "" device driver 2 ZwCreateFile ZwWriteFile ZwCreateFile Import This keyboard driver is accessing the filesystem, check for a keylogger ZwWriteFile Import This keyboard driver is accessing the filesystem, check for a keylogger Multiple factors can contribute to understanding whether software has malicious properties. These can include: Suspicious strings (see table 2) Use of suspicious libraries or functions, such as network or filesystem The combined use of several suspicious functions together Accessing user mode programs from kernel mode Use of protocols such as IRC, SMTP, or POP3 Use of encryption Network capabilities combined with backdoor commands Enumeration of files Use of registry keys to survive reboot Table 2 List of suspicious strings with analyst notes ( rootkit variant) Key logger thread Suspicious string terminated Driver: %s Suspicious string Keyboard hook detached from device... \Device\KeyboardClass0 Keyboard hook detached from device... Successfully created log file... \DosDevices\c:\.txt Scan code '%s' successfully written to file. Suspicious string This is definitely used by rootkits. Searching google revealed that a rootkit called "GMER" may also use this. Looks like it can detach also. Maybe it can be unloaded. Check for log file on system. This looks like a secret log file. Likely keystrokes. Suspicious string 2 MCSI Responder PRO, www.mcsi.mantech.com/responder White Paper: The Value of Physical Memory for Incident Response Page 4 of 7

hiding driver The driver looks like it can hide itself. It might not be detected by system tools. To address new and unknown threats, the human analyst must be involved. Although any factor can be suspicious on its own, the combination of several different factors working together can significantly boost the confidence that something malicious has been found. The human analyst can determine the relative importance of each finding and relate them together. In table 2 we see a list of suspicious strings and the notes made by an analyst. The target is a driver calling itself which turns out to be related to a keylogging rootkit. The terms scan code, hiding driver, and Key logger give away what this rootkit is doing. Table 3 Graph of all IRC commands in a rootkit 3 /Victim=[ vic online: /Ip= ] /Trojan Port=[ is Online IP ADDRESS= From: Subject: Vic: is online from Port: &Name= o vq0 zmd)l`q'dgo 3 Graph generated using MCSI Responder PRO Edition (www.mcsi.mantech.com/responder) White Paper: The Value of Physical Memory for Incident Response Page 5 of 7

%0A data_004b02e8 data_004b01e8 45000 PRIVMSG # Vic: IP ADDRESS= Server Port= is Online Please Open your Client to Chat First! NOT DONE Has logged OUT! Has logged IN! Client Opened to chat! Client Closed to chat! The relationships between suspicious strings can be reinforced further by following control flow and cross references, as shown in table 3. When viewed separately, the strings appear to be related, but when graphed we can see for certain they are related. See the graph below. To obtain these cross references requires the ability to extract EXE s and DLL s from the physical memory and then requires a subsequent disassembly step to obtain code and data cross references. Using graphs to explore string relationships is powerful and easy to grasp for people who have no prior reverse engineering experience. Graph based analysis is relatively new to the industry and is significantly less complex than traditional reverse engineering. White Paper: The Value of Physical Memory for Incident Response Page 6 of 7

Until recently, analysts who wanted these capabilities had to cobble together a variety of separate tools that only provide partial functionality. Because of the lack of commercially supported products, physical memory forensics has been slow to mature. Most research has resulted in free tools that are limited to specific operating system versions, have command line only interfaces, and have minimal parsing and extraction capabilities. White Paper: The Value of Physical Memory for Incident Response Page 7 of 7