Lately, we have been doing a lot of work around physical memory forensics. Recently, we released the free, community edition of our Responder™ product and plan to release the fourth generation of our memory analysis engine later this year. During this work, I have been reflecting on the origins and advancements in the field of physical memory forensics over the last 10 years.
In the early 2000’s, two headline-making malware infections, Code Red and SQL Slammer, demonstrated the possibility that malware could reside only in memory and never leave a file on disk. In the world of incident response, the evidence challenged the traditional notion of dead-box forensics. It meant that critical data would not be obtained by the traditional forensic methodology. It also set the stage for future malware that would subvert API calls, forcing live response scripts to rely on the OS as little as possible.
Physical memory analysis started as crash dump analysis for debugging, but it soon became apparent that volatile data in memory could contain encryption keys, passwords, and other critical information about recent user activity. From a tools perspective, the well-known dd utility has been able to acquire memory from the start, simply by reading /dev/mem or /device/physicalmemory. Other memory tools also emerged. In 2002, Eoghan Casey documented how Arne Vidstrom’s PMDump tool could be used to dump virtual memory and defeat PGPTray.
Rootkits helped drive development of memory forensics –more for malware detection than evidence collection. In 2003, Jamie Butler demonstrated the DKOM (Direct Kernel Object Manipulation) method for hiding processes by removing items from a linked list directly in memory. This was a data-only attack and didn’t involve any kernel hooking. It would be a few years before researchers like Andreas Schuster and Chris Betz developed memory-forensics methods for finding hidden processes that countered Butler’s DKOM . Things took another significant step forward in 2005 when Sherri Sparks released Shadow Walker, a rootkit that was able to hide sections of virtual memory from scanning tools. This lead to the notion of physical memory acquisition – using a raw dump of RAM instead of using OS- supplied virtual memory reads – as a means for rootkit detection.
Attempts at OS reconstructions didn’t really start until the DFRWS memory analysis challenge in 2005, where George Garner [kntlist] and Chris Betz [memparser] developed process and thread reconstruction for Windows®. Everything changed after this – instead of searching for binary patterns and strings, the memory image was seen as a complex snapshot of interrelated structures and data arrays. A keystone development was the ability to discover the page tables in physical RAM and thus translate virtual addresses to their physical offset. In February 2006, I wrote the first version of this technology for HBGary using the self-referencing physical address pointer trick (AFAIK first publically documented by Joe Stewart w/ the TRUMAN project), and we soon added PAE support. Physical memory forensics had become a hot new area of research. Later that year Mariusz Burdach presented on physical memory forensics at the Blackhat conference. Jamie continued his research as well and presented numerous advances in physical memory analysis to detect rootkits at the Blackhat 2007 conference. Shortly after Jamie’s talk, AAron Walters released Volatility. It were these initial advances with page table translation and OS reconstruction that lead to ”modern” physical memory analysis.
By this time, Brian Carrier and Joe Grand had already released Tribble, a PCI card that could monitor and analyze physical memory. It was later that several commercial attempts were made to build a rootkit protection solution in the form of a PCI card. Via a DHS grant, HBGary was subcontracted to work on a similar project and this lead to a prototype PCI card that could analyze Windows XP and detect kernel hooks. Jamie Butler joined Komoku, which had already built a similar device, around that time. Joanna Rutkowska was quick to respond to all of this and developed an extremely low level software-only rootkit for Windows that could defeat even a PCI-based physical memory read – by reprogramming microchips that are part of the bus controller and I/O chipset. In the end, a hardware solution for rootkit detection was not economically feasible and these projects were never successfully commercialized.
HBGary’s work on the hardware PCI card was the genesis for more R&D memory forensics work to come. We abandoned the hardware approach and developed a software library called WPMA (Windows Physical Memory Assessment) - written in C++ and core to Responder’s memory parser. We later developed a second-generation parser and started reverse engineering all the different memory footprints left by every conceivable version of Windows and service pack (we didn’t analyze NT 4.0 – only Win2K and newer). It took about two years to get the Windows platform complete. This work led to the development of our flagship product, Responder™, and the library that performs the physical memory parsing is integrated into our enterprise product’s Active Defense™ agent as well.
I’ve highlighted only a few of the researchers in this important field of physical memory forensics – there are many others who have also made significant contributions. At HBGary, as I mentioned, we will soon release a completely rewritten version of our physical memory analysis engine marking the fourth generation of the technology. Recently, I was watching the performance testing in the lab and I have yet to see it cap 150 MB memory usage while analyzing a 10-gig snapshot, and it is about 30% faster than our current generation. I will post more details on this work as we progress, as the new engine has many additional features that extend our Digital DNA™ technology.
-Greg Hoglund
