Why perform memory forensics? There are a plethora of reasons. What do you do when something happens on a computer and nothing is written to the disk? That is the biggest reason why you want to analyze a computer’s memory. Memory is like a snapshot in time for a computer and can provide some very valuable information. Everything that happens on a computer traverses through memory, enabling you to extract some very valuable information.
Redline is a great memory forensics tool best utilized for a quick triage of RAM. Not only does it provide a faster triage capability, but it also includes options such as MD5 whitelisting and IOC searches.
How do you gather a computer’s memory? There are a multitude of different tools that can gather memory. A few that I utilize are FTK Imager, dd, dumpit.exe and Win32/64dd.exe.
What do you do if the machine you are investigating is a Virtual Machine? VMs have memory as well. Below are a few of the different memory files present for different VM platforms:
- Vmware (Fusion/Workstation/Server/Player) — .vmem = raw memory. (.vmss and .vmsn = contain memory image) (each snapshot will have its own .vmem file)
- Microsoft Hyper-V — .bin = raw memory image
- Parallels — .mem = raw memory image
- VirtualBox — .sav = partial memory image (Memory file only holds memory actively in use, not the entire amount of memory assigned to the virtual machine.
NOTE: Since Virtual Box’s .sav file only contains memory actively in use, it will not be recognized by many memory analysis tools. Volatility has an address space that will pad the memory image and enable analysis.
Are there any artifacts from RAM on the disk? There sure are. The Hiberfil.sys file contains a compressed RAM image on a dead system and can be found in %systemdrive%/hiberfil.sys. This file is created when a laptop lid is closed and the system moves into hibernation mode, NOT when the system goes to sleep.
What does sleep actually do on Win7/8? It stores the current state of memory. Sleep DOES NOT create the hibernation file. It shuts down all power except for one piece, the RAM. A system hibernates when the battery is being depleted, then the computer will go into hibernation mode and create the hibernation file.
There are several tools that can analyze the hiberfil.sys file natively such as Bulk Extractor, Internet Evidence Finder, and Volatility.
If you were given the below screenshot and were told, “find evil”, where would you start? The below screenshot contains all the data that you need to be able to do a quick triage. Some good questions to consider are:
- Does the process have the correct name?
- Is the process running out of the right path?
- Was the process started under the correct parent?
- Were the correct arguments used?
- When was the process started?
- Was the process started under the right Security Identifier (SID)?
Knowing what is “normal” on a windows system is critical in this situation so that you are able to find the “evil”. SANS has a great poster on “Knowing normal to find evil”. http://digital-forensics.sans.org/media/poster_2014_find_evil.pdf
Redline gives you the ability to quickly triage memory processes. The below process indicates that the “Process has a known mutant for “sobig” malware”. Using Redline’s Malware Risk Index (MRI) hits, you are able to quickly tell that this is a malicious process.
Redline uses a term called Least Frequency of Occurrence (LFO) to analyze process objects. Process objects are things such as DLLs, Handles, Threads, Memory Sections, and Sockets. According to the LFO, malware and its associated artifacts should be among the rarest objects in a memory image. Redline will keep a count of each time a process object is referenced. You can sort by occurrences to identify outliers.
NOTE: A process object occurring only once is not de facto malicious, but should be trusted less than one that appears 20+ times.
The above screenshot show a few mutexes pulled from a machine infected with Conficker. Notice that those mutexes only occur once. Also, the “-99” is specific to Conficker. A quick Google search would bring you to that conclusion.
What seems out of place with the above screenshot? Is the process spelled correctly? In fact it is not. The correct spelling should be sVChost.exe NOT sCVhost.exe. The correct svchost.exe should occur more than one time on a windows system.
Beyond Rogue processes, the memory image will provide you with a variety of network artifacts. Below are a few different artifacts to pay attention to while analyzing memory:
- Suspicious ports: Communications via abnormal ports? Indicators of listening ports/backdoors?
- Suspicious Connections: External connections. Connections to known bad IPs. TCP/UDP connections. Creation times (network sockets have creation times. You can look for other related processes/threads initiated near the same time.)
- Suspicious Processes: Why does this process have network capability (open sockets)? Should it?
The screenshot above has some suspicious looking connections. The process looks like a normal svchost.exe process, but should it have a connection via port 4444? It most definitely should not. This is a metasploit meterpreter binary that was injected into svchost.exe. A good thing to pay attention to are pattern based port numbers. Patterns such as 4444, 4567, etc. are typically suspicious. Typically server based ports are below 1024.
Take a look at the below screenshot. Does anything seem suspicious to you? I notice a process that is listening over port 80. What processes listen on port 80? Web browsers listen over port 80, not SYSTEM. If you were to google the IP 126.96.36.199, you would find results for TDSS worms.
Redline also gives you the ability to filter by strings. A lot of the time malware authors will hard code web addresses or IPs into their malware. If you filter for strings such as “http://” , “https:// , or “ftp:// you would typically find some interesting artifacts. Below is a sample of some suspicious strings found in a memory image. You would definitely want to look into those IPs more.
Redline can also be used to Detect a couple different types of Injection. Below we will discuss DLL Injection and Process Hollowing.
DLL injection works by allocating space in a running process, shoving the DLL file into it and then creating a new thread to load the DLL into the running process using the Windows VirtualAllocEx() and CreateRemoteThread() function calls. The attacking process can force a running process to load a malicious DLL by hooking its filter functions using the SetWindowsHookEx() function.
Process image not backed with file on disk = process hollowing. If the process binary is unmapped (not backed with a file on disk), then it is a strong indication that process hollowing has occurred. The malware starts another copy of a legitimate system process. It pauses the process, de-allocates some of the original code and replaces it with malicious code. Items like the process image name, path, and command-lines remain unchanged and serve to camouflage the now malicious process.
An easy thing to look for in Redline are injected memory sections that will be shown as “EXECUTE_READWRITE”. Below are a few processes that indicate DLL Injection:
How many lsass.exe processes are there supposed to be on a Windows system? And what is the parent process supposed to be for lsass? Below is an example of Redline output detecting process hollowing. If you aren’t aware how many lsass processes there are supposed to be, or what the parent process is, Redline’s Malware Risk Index Hits will assist you in identifying process hollowing.
Redline will also assist in rootkit detection. Here are a few things that you can look for to identify rootkits:
- NtEnumerateKey à Hide registry keys
- NtEnumerateValueKey à Hide registry values
- NtQueryDirectoryFile à Hide file or directory
Based off the below screenshot, you won’t necessarily know that this is a rootkit, but the name is very suspicious. Also, the hooked functions field is a good indication that these are possible rootkits.
Putting it all together:
1) Identify Rogue Processes
- Name, path, parent, command line, start time, SID, MRI score
2) Analyze process DLLs and handles
- Digital signatures and LFO helpful
3) Review network artifacts
- Suspicious Ports, connections, and processes
4) Look for evidence of code injection
- Injected memory sections and process hollowing
5) Check for signs of a rootkit
- SSDT, IDT, IRP, and inline hooks
6) Dump Suspicious processes and drivers
- Review strings, anti-virus scan, reverse-engineer