Case Closed: Memory-Only Analysis
I recently presented the SANS@Night “Have No Fear, DFIR is Here” with Rob Lee, Chad Tilbury & Lenny Zeltser at SANS CDI. The premise of the four-examiner presentation was to analyze and properly scope the involvement in the Stark Research Labs(SRL) intrusion of the “Natasha Romanoff” Windows 7 x86 system. This scenario is known quite well by FOR508 alumni who have served as members of the SRL CIRT during the Day 6 Challenge. In FOR526: Windows Memory Forensics In-Depth, we take memory analysis a step deeper, diving into Windows Memory Structures in order to understand how the tools work and how to extract smoking guns from a system memory image. My goal during my 20 minutes of presenting with the “All-Star Forensics Team” was to prove to my fellow instructors (and @Night attendees) that I didn’t need their file system forensic analysis at all. In fact, all of the questions pertaining to the intrusion and this system’s involvement could be answered through the analysis of the memory image.
Our mission: Determine the initial vector of infection for the Romanoff system, find all malicious code present on the system and show signs of execution. In addition, we were asked to answer the typical questions customers asked in an incident response scenario, “What credentials were compromised?” “How did they get in and how long have they been here?” and of course, “What did they take?”.
Most digital forensic examiners know of the Volatility Framework, an open source python project supported by a forward-leaning team of developers. Yet, there are other tools we can bring to bear while performing memory analysis. I included Mandiant’s Redline, Simson Garfinkel’s Bulk Extractor and page_brute in my tool arsenal, as I unraveled the story of the Romanoff machine in the SRL intrusion.
Process Enumeration
We cover a six-step process in malicious process identification in our FOR526 Windows Memory Forensics In-Depth class that begins with process enumeration. By running through a couple of Volatility plugins “pslist” and “psscan”, I identified some curious processes.
love pslist output purely for the reason that it is chronological – great for doing fast timeline analysis of what took place on the system since that last reboot. We can see from this pslist output that:
1.) Based on the “Start Time” for the System/SMSS.exe Processes, the system last rebooted at 2012-04-04 11:47:29 UTC.
2.) With two csrss.exe processes (PIDs 412 & 2132) seen in this output, we can ascertain there were two active sessions at the time the image was created (specific to Windows 7 & later).
3.) With the start of the explorer.exe process (PID 296), we know a user logged into the system at 2012-04-04 14:45:45 UTC.
4.) With the presence of rdpclip.exe (PID 2408), we know that this logon was a remote desktop session via terminal services.
5.) A quick hierarchical analysis (Parent/Child surveying), we can identify some potentially anomalous processes to include:
a.) svchost.exe processes (PID 3612 & 6404) whose PPID is 2100 – not expected since svchost.exe is typically spawned by services.exe (PID 564).
b.) PSEXESVC.EXE (PID 2100) – notable due to the fact that it is the parent of the late starting svchost.exe, but also typically associated with the execution of psexec, the SysInternals tool used for remote execution.
c.) terminated processes, a.exe (PID 3264 & 5008) & spinlock.exe (3796 & 1208)
Of course, our next step in this analysis, seen in the next blog post, will be to further investigate each notable process, attempting to enumerate the process parameters, to include identifying the command line (how each process was instantiated).
We will continue the domination of the digital forensics world via memory in the next few posts.
