Friday, December 30, 2016

The Release of Volatility 2.6

This release improves support for Windows 10 and adds support for Windows Server 2016, Mac OS Sierra 10.12, and Linux with KASLR kernels. A lot of bug fixes went into this release as well as performance enhancements (especially related to page table parsing and virtual address space scanning).

Here's the TL;DR:

The release page, with standalone binary downloads for 64-bit Windows, Linux, and Mac:

Information on new Volatility 2.6 profiles:

Python source code packages:

We look forward to working with you all in the new year!
The Volatility Team

Monday, December 5, 2016

Results from the 2016 Volatility Plugin Contest are in!

Congratulations to all the participants! This year we received more submissions than ever before (21 to be exact, from 16 different authors), so judging took longer than we expected. Sorry about that! The good news is...there's a LOT of new and exciting functionality available to law enforcement agents, DF/IR practitioners, malware analysts, and researchers around the globe, which can immediately be transitioned into their workflows. That's the whole spirit of open source memory forensics with Volatility, and we're once again very proud to sponsor a contest with such impressive results.

It may sound cheesy, but everyone is a winner in this contest. Although a few developers will walk away with prizes, they all solved a problem that they (and inevitably others) faced, gained experience writing Python plugins, and learned some intricacies of memory analysis internals. The capability to program around technical issues and design/implement solutions is a gift. You can applaud by following the authors on Twitter/GitHub/LinkedIn, providing feedback on their ideas, and helping to improve their code with testing, documentation, or contributing patches.

We also want to thank Airbnb for donating $999 to the cash prizes! When looking for a new job, we definitely recommend considering employers that support open source forensics and value the importance of memory analysis. Maybe you can be their next Security CSIRT Engineer!

Here is a break down of the placements and prizes

1st place and $1800 USD cash or a Free Seat at Malware and Memory Forensics Training by the Volatility Project goes to:
Monnappa for Hollow Process Detection and Analysis. Monnappa also participated in the 2015, so this is his second consecutive contest. Aside from the code itself, Monnappa's corresponding documentation was very impressive. Given Monnappa has already taken our training class, he'll likely take the cash prize!
2nd place and $800 USD cash goes to:
Kevin Breen for VolUtility and LastPass Credential Recovery. Although we've seen web interfaces in the past, Kevin's take on it has a lot of unique and helpful features. He's already integrated quite a number of new capabilities since the contest closed in October and he's showing no signs of slowing down. He's got Volatility plugin fever! 
3rd place and $450 USD cash goes to:
Dima Pshoul for Advanced Malware Hunter's Kit. Dima designed several creative ways to detect memory-only injected code, which is one of the major reasons why analysts rely on memory forensics. Say hello to malfind's two new best friends! 
4th place and $100 USD cash and Volatility Swag goes to:
Mariano Graziano for ROP Payload Analysis and Linux Kernel Symbol Finder. This is Mariano's second plugin contest - he previously won first place for Actaeon. Its great to see Mariano continuing to implement powerful capabilities like ROPMEMU. Likewise, the Linux kernel symbol finder preemptively solves issues that analysts will face in the absence of Linux profiles.
5th place and $100 USD cash and Volatility Swag goes to:
Bart Inglot for RDP Key Extraction and Replay. This is Bart's second plugin contest, but the first time he's made it to the top 5. We met Bart a few years ago when he attended one of our training classes in Amsterdam, and since then, he's been rapidly improving his memory forensics skills. Bart's submission highlights some really cool capabilities related to offline DPAPI data decryption and extraction of key data from RAM. 
Thomas White for Mac FileVault2 and Microsoft Bitlocker Key Extraction. Together with Volatility's existing plugins for Truecrypt and dm-crypt on Linux, investigators not only have quite thorough support for pulling FDE keys from RAM, but they can understand where and how the keys are stored in virtual memory. 

Here is a detailed summary of the submissions. If you have feedback for the authors, we're sure they'd love to hear your thoughts.

1st: Monnappa: Hollow Process Detection and Analysis

Monnappa's hollowfind is a Volatility plugin to detect different types of process hollowing techniques used in the wild to bypass, confuse, deflect and divert forensic analysis techniques. The plugin detects such attacks by finding discrepancies in the VAD, PEB, and other OS meta-data structures. The plugin also disassembles the address of entry point to detect any redirection attempts and also reports any suspicious memory regions which should help in detecting the injected code.

Monnappa's research on the process hollowing technique in general is very impressive. To design the plugins, he needed to reverse engineer various real-world malware samples that performed process hollowing, intimately study their subtle differences, and write code to handle each case. His blog below is complete with commented IDA screen shots and Volatility plugin output produced after executing the described malware.

Monnappa's Blog on Process Hollowing: detecting-deceptive-hollowing-techniques
Monnappa's GitHub:
Monnappa's Twitter: @monnappa22

2nd: Kevin Breen: VolUtility Web Interface

VolUtility is a web interface (written in Django) for Volatility. It runs plugins and stores the output, derived directly from the plugin's JSON rendering APIs, in a Mongo database. It extracts files from plugins (that support --dump-dir) and stores the binary content in the database as well, allowing searches across all plugins and file content with string search and Yara rules. In comparison with other web interfaces that we've seen in the past, VolUtility stands out due to its extensions, which allow integration with Cuckoo Sandbox, Exif, Floss, and VirusTotal. It also features a hex viewer, PST and SQLite viewers, registry hive browser, volshell-like input controls, etc. We found the documentation very thorough and installation/configuration on Linux was a breeze.

Kevin's Twitter: @kevthehermit
Kevin's Website:

2nd: Kevin Breen: LastPass Credential Recovery

LastPass is a highly popular and widely used password manager. Its ease of use and direct integration into major browsers allows for even non-technical users to maintain unique, strong passwords across a variety of websites and services. Since many users trust all of their passwords to LastPass, cleartext credentials from its database are highly valuable forensic targets. This newly submitted plugin, named lastpass, allows for targeting of LastPass user credentials that were stored in memory at the time of acquisition, allowing for rapid exploitation by forensic analysts.

Kevin leveraged the process VAD scanner API in Volatility along with custom Yara rules to locate signatures related to the cached LastPass credentials. Currently the plugin focuses on IE, Chrome, and FireFox, however Kevin plans to test additional browsers, extend support to additional password managers, and implement unified output so the data can be consumed/post-processed by other applications easily.

Kevin's Twitter: @kevthehermit
Kevin's Website:

3rd: Dima Pshoul: Advanced Malware Hunter's Kit

In Dima's own words, he is a "long time Volatility user who wanted to contribute to the framework and also improve it by writing unique and powerful plugins." Mission accomplished! The "Advanced Malware Hunter's Kit" includes plugins for reconstructing call stacks, detecting hollowed processes, finding malicious threads via code executed from dynamically allocated addresses, and locating injected code regions by analyzing return addresses on the stack.

Dima did a great job analyzing the current plugins in the Volatility Framework (namely malfind) and the associated weaknesses that malware can exploit to trick investigators. Conceptually, the techniques Dima introduced in his plugins will be invaluable supplements for detection of malware hiding in memory.

Dima's GitHub:

4th: Mariano Graziano: ROPEMU (ROP Payload Analysis)

ROPMEMU is a framework for analyzing return-oriented programming (ROP) payloads. It includes two Volatility plugins. The first plugin, ropemu, emulates a ROP payload gadget-by-gadget and produces a JSON trace of the affected machine state. The second plugin, unchain, transforms ROP gadget sequences into simplified non-ROP code for easier analysis and understanding. The plugins leverage the Unicorn emulator and the Capstone disassembler. In addition to the Volatility plugins, several interesting "helper" utilities are also included.

In addition to the Volatility plugins, Mariano also published an academic paper on his work and has presented it at conferences, undoubtedly inspiring countless other researches.

Mariano's AsiaCCS Slides: ROPMEMU_final.pdf
Mariano's Twitter: @emd3l
Mariano's Blog Post at Cisco Talos:
The Project's GitHub:
Mariano's GitHub:

4th: Mariano Graziano: Linux Kernel Symbol Finder

Mariano's ksfinder is a standalone Python script to retrieve exported kernel symbols from Linux physical memory dumps. The script is useful in a scenario in which the analyst does not have a Linux profile and cannot create it (for example, the suspect system was reformatted after memory collection, you simply no longer have access to it, you couldn't obtain the kernel headers, etc). In those cases, ksfinder recreates (or partially recreates) the file by parsing the __ksymtab_strings and __ksymtab of the Linux kernel image (aka vmlinux) solely from the memory sample.

Although the script is not technically a Volatility plugin, it can easily be imported or integrated with Volatility plugins to alleviate one of the biggest issues analysts face with regards to memory forensics of Linux systems.

Mariano's Twitter: @emd3l

5th (tie): Bart Inglot: RDP Key Extraction and Replay

The rdpkeys plugin extracts RC4 and SSL keys from a memory image that can be used for RDP replay. The keys are automatically converted into PEM format, but can be also saved in the native format (referred to as PVK). Bart also included instructions to decode an RDP session with WireShark using the SSL key extracted by the plugin, and examples of when the extraction works and when it can fail.

Bart's plugin makes excellent use of Volatility's APIs. For example, he leveraged the Registry API to recover LSA Secrets, and on platforms that require it - he used the Cached File APIs to recover the DPAPI Master Keys and SSL Private Keys. We also found it very valuable to see examples of using the Python DPAPI module to perform decryption based on resources found in memory - this will undoubtedly serve as a template for various other plugins in the future.

Bart's Writeup: BartInglot_RdpKeys.pdf
Bart's submission:
Bart's Twitter: @BartInglot

5th (tie): Thomas White: FileVault2 & Bitlocker Key Recovery

Thomas White's two FVE plugins are aimed at helping investigators recover the necessary keying information for decrypting/unlocking disks. In particular, the Bitlocker plugin targets recent versions of Microsoft Windows and recovers the FVEK, cipher information, and TWEAK key. One of the most impressive aspects of this plugin is the research and documentation that goes along with it. Thomas recorded the steps he took when live debugging the Windows kernel to identify differences in key storage locations starting with Windows 8. This is an extremely valuable tutorial on how Volatility plugins come to life, especially those that access undocumented structures and memory regions.

Likewise, the FileVault2 plugin targets Mac OSX and has even been tested on Sierra (10.12). The write up below includes a short tutorial on mounting the evidence with extracted master keys using fvdemount.

Thomas' Post on FileVault: extracting-filevault-2-keys-with-volatility
Thomas' Twitter: @triblchkn

The following submissions appear in the order they were received. As previously mentioned, these developers deserve huge props. We look forward to seeing future work by these authors!

Aim4r: VolDiff Memory Diffing and Malware Identification

VolDiff is a python script that leverages Volatility to identify malware artifacts in Windows 7 memory samples. It not only helps automate Volatility plugin execution but it also provides numerous built-in checks for suspicious artifacts typically associated with malware. Examples include child/parent process relationships, process sessions, execution paths, interesting imported APIs, suspicious strings, etc. Most of the checks are based on the output of Volatility plugins such as pslist, psscan, dlllist, impscan, and malfind. Analysts can easily extend the heuristics by editing regular expressions in the configuration area of the tool.

VolDiff also provides the ability to highlight the differences between a sample taken before and after malware execution. This can help an analyst rapidly triage the types of changes the malware may have made to the system. VolDiff helps automate common analysis techniques used by malware investigators.

Aim4r's Twitter: @aim4r
Aim4r's GitHub:
Example analysis: Memory-Analysis-of-DarkComet-using-VolDiff

Marcin Ulikowski: Bitlocker Key Recovery

This plugin finds and extracts Full Volume Encryption Key (FVEK) from memory dumps and/or hibernation files. This allows rapid unlocking of systems that had BitLocker encrypted volumes mounted at the time of acquisition. Architecturally, the plugin scans for BitLocker cryptographic allocations (memory pools) in virtual memory, covering both 32- and 64-bit systems running Windows Vista through Windows 8.1 (support for Windows 10 is in progress). Marcin notes that Windows 8 and newer use the Cryptography API: Next Generation (CNG), so the pool tags are different than previous versions. We found Marcin's AES key schedule validation routines particularly useful (to avoid false positives) in addition to his documentation on how to use bdemount to decrypt protected resources.

Marcin's Twitter: @elceef

Hemant Kumar and Sajeev Nair: Windows MemDiff Forensic Tool (WMDF)

This Windows GUI tool provides a front end to extracting memory related artifacts with Volatility. Additionally, analysts can compare those collected artifacts with a whitelisted artifacts database (generated by running the tool against a baseline system) of their choice. This comparison points out the changes made by malware on the system, helps provide analysts with crisp and low level information, and decreases the area of investigation an analyst needs to manually review.

WMDF Submission:
WMDF Documentation: WMDF.pdf
Hemant's Twitter: @hemantxcode
Sajeev's Twitter: @nairsaj

Nichlas Holm: Network Packets, IP/MAC, ARP

This submission, networkpackets, is a Volatility plugin for extracting network packets (IPv4 and ARP) out of memory samples. The plugin provides the ability to quickly identify memory-resident network packets, and based on those packets provides an analyst with context about the network environment. This context includes information about the IP/MAC address of the system, the network gateway, and an overview of other systems in the same network. Extracted packets are exported into PCAP format, which enables analysis with traditional network analysis tools.

Stanislas 'P1kachu' Lejay: Auto-Profile Detection

P1kachu addresses a real problem (OS and profile detection) that Volatility users frequently face with his profilescan plugin. This plugin uses a pattern-matching approach to infer the operating system of a target memory image. It then calls the corresponding OS-specific profile detection plugin. Since Volatility does not provide such a plugin for Linux images, the authors also developed a helpful a uname scanner plugin, linuxgetprofile, which also outputs details on the kernel and compiler versions.

We're confident that P1kachu's plugin and associated methodologies can become a critical piece in many investigators initial workflows, saving them valuable time and avoiding a lot of the typical "guess work" that has traditionally been done.

P1kachu's GitHub:
P1kachu's Website:
Post on ProfileScan: volatility-profile-finder

Martin Korman: VolatilityBot Malware Detonation Framework

VolatilityBot provides a modular malware "detonation" architecture that helps automate many of the manual and repetitive tasks associated with malware analysis. This includes the extraction of malicious binaries and any associated code injections or related artifacts (strings, IP address, etc.) that may be created during execution. Once the suspicious code has been extracted, it also provides numerous post-processing modules to help identify behavior patterns in the code and prepare the extracted code for in-depth static analysis. Finally, VolatilityBot also provides a number of capabilities for automated heuristic analysis and triaging memory samples at scale.

Martin's Twitter: @MartinKorman
Martin's VB 2015 Slides: Korman-VB2015.pdf
Martin's Code Repository:

James Hall and Kevin Breen: USBStor

The USBStor plugin scans registries for values relating to USB devices plugged into the system under investigation. Instead of the analyst needing to manually analyze each registry hive (USBSTOR, USB, MountedDevices etc.) the plugin will return all available information about previously connected USB devices in an easy to digest, collated format. This greatly decreases analysis time and ensures no mistakes are made and no information is overlooked. The plugin's output contains details such as USB serial number, vendor and product info, container ID, mounted volume name, drive letter, USB friendly name, the last connection timestamp, and more.

James' Website:
James' Twitter: @411hall

Tyler Halfpop: FindEvil Malware Analysis Automation 

The FindEvil project, along with its two new Volatility plugins, findevilproc and findevilmem, provide for automated extraction of executables (applications, DLLs, and kernel drivers) from memory as well as calculation of several attributes of interest to investigators – Virus Total scores, entropy calculations, Yara-based detections, and whether the executable is digitally signed or not. Leveraging these plugins, investigators can quickly find the "evil" executables that are active on a system being investigated and immediately focus their analysis on them.

Tyler's Twitter: @tylerph3

Tran Vien Ha: Open Source Intelligence & MISP Integration

The osint plugin submits URLs or IP addresses found in a memory sample to open source intelligence platforms. Data is submitted using a SOCKS proxy, generally Tor, to provide a degree of anonymity. osint currently supports Blue Coat, Virus Total, and MISP. Your data sources and respective API tokens are stored in a configuration file, and a text file allows you to whitelist commonly seen domains.

The author also contributed an HTML plugin using JQuery for rendering tree views (such as pstree), which is quite handy.

Tran's GitHub:

Here are a few additional resources regarding previous contests and community-driven plugins:

Volatility Foundation Contest Home Page:

Volatility 2015 Plugin Contest Results:
Volatility 2014 Plugin Contest Results:
Volatility 2013 Plugin Contest Results:

Volatility Community GitHub Repository:

Thursday, September 29, 2016

Volatility Update: Core team is growing!

Next year marks the 10-year anniversary of the first public release of Volatility! This would not have been possible without the friendship and support of the amazing Volatility Community.  One of the original goals of Volatility was to create a project that would help bring together technical talent in the forensics and incident response communities. We also wanted to create a unifying framework that would bring together academics, practitioners, government, and law enforcement from around the world. A platform where the latest cutting edge research being presented at the top academic security conferences could be immediately transitioned into the hands of digital investigators.  In celebration of the past 10 years, we have a number of exciting things planned for 2017.  Along those lines, you may have noticed on the mailing list or on github that the Volatility Core development team is continuing to expand.

For those who have been part of the Volatility Community since the beginning, I’m excited to say that Dr. Nick Petroni has rejoined the team. Nick’s pioneering academic research laid the groundwork for much of the modern work in memory analysis.  He was also one of the original developers of Volatility and his design decisions continue to provide the foundation upon which most modern tools are based.  Similarly, I’m also excited to introduce Anthony Colatrella.  Anthony is one of the best computer scientists I’ve had the pleasure to work with.  During his career, he has focused his time on operating system and security development, including contributions to SELinux.  Both Nick and Anthony are working on a number of impressive projects and I’m sure you will see more of them in the coming months.

Wednesday, August 10, 2016

Malware and Memory Forensics 2017 Schedule (Now with Linux, Mac, and Surge Collect Pro)

Our most popular training course just got even better! We're happy to announce the curriculum for Malware and Memory Forensics by The Volatility Project now includes the following:
  • Linux and Mac OS X memory analysis
  • Windows memory acquisition with Volexity Surge Collect Pro
  • Several new and challenging hands-on labs based on high profile, real world incidents
We currently have 5 MMF courses open for registration, including our first wave of events in 2017. Registrants of all classes will receive a free copy of The Art of Memory Forensics in hard/paper or electronic (eBook, Mobi, or PDF) format.


August 29th - September 2nd, 2016 in Amsterdam (**nearly sold out)
October 3rd - 7th, 2016 in Herndon, VA (**nearly sold out)


April 3rd - 7th, 2017 in Herndon, VA
September 18th - 22nd, 2017 in London, UK (**our first UK class in 3 years)
October 16th - 20th, 2017 in Herndon, VA

Starting with the 2017 courses, we're offering discounts on Volexity Surge Collect Pro (for Windows) at the time of registration. For more information on this package deal, see our Memory Forensics Training FAQ.

If you're interested in attending, contact us. We look forward to meeting and training with everyone!

Tuesday, August 2, 2016

Automating Detection of Known Malware through Memory Forensics

In this blog post, we will cover how to automate the detection of previously identified malware through the use of three Volatility plugins along with ClamAV. Although this walk-through primarily focuses on Windows memory samples, at the end we explain how to port the approach to Linux and OS X samples.


Although it would make our jobs quite interesting if every investigation involved analyzing new malware samples and families, the reality is that many malware investigations only require analyzing memory samples in order to verify (or hunt for) an infection by malware previously discovered in the wild. In these situations, the ability to quickly leverage existing tools and malware intelligence can lead to rapid identification of infected systems.

In this blog post, we document a methodology that we have successfully used in many investigations to confirm the presence, or absence, of known malware on a system. By following this workflow, you should be able to quickly sort through memory samples in your current investigations and to perform one aspect of proactive threat hunting in a highly efficient manner.


For the purpose of this blog post, we are going to analyze a memory sample that was previously available online. In particular, we are going to look at the stuxnet.vmem file that was produced to accompany The Malware Analyst's Cookbook. As you can likely guess, this memory sample came from a virtual machine infected with Stuxnet.

The real world scenarios where this applies are when you wish to verify if a system is infected, such as after receiving an AV or IDS alert, or when you wish to perform proactive threat hunting in order to stay ahead of potential threats in your environment. In these situations, you will first need to acquire a memory sample of the system you wish to analyze. A full discussion of this process is outside the scope of this blog post, but Chapter 4 of the Art of Memory Forensics provides extensive detail on the topic.

The remainder of this blog post assumes that you have a memory sample that was acquired using a stable tool and/or method.

Plugin Usage

The goal of this section is to showcase how, with only three Volatility plugins, an analyst can quickly extract a majority of the executables loaded into memory at the time of acquisition. 


 To start, the dlldump plugin will be used to extract the main application executable and all* loaded DLLs inside of each** process:
$ python -f stuxnet.vmem --profile=WinXPSP2x86 dlldump —memory -D stuxout/ Volatility Foundation Volatility Framework 2.5 Process(V) Name            Module Base Module Name  Result
---------- --------------------      -------------  ----------------------- 0x820df020 smss.exe      0x048580000 smss.exe       OK: module.376.22df020.48580000.dll 0x820df020 smss.exe      0x07c900000 ntdll.dll      OK: module.376.22df020.7c900000.dll 0x821a2da0 csrss.exe     0x04a680000 csrss.exe      OK: module.600.23a2da0.4a680000.dll 0x821a2da0 csrss.exe     0x07c900000               Error: DllBase is paged 0x821a2da0 csrss.exe     0x075b40000 CSRSRV.dll     OK: module.600.23a2da0.75b40000.dll 0x821a2da0 csrss.exe     0x077f10000  GDI32.dll     Error: DllBase is paged 0x821a2da0 csrss.exe     0x07e720000 sxs.dll        Error: DllBase is paged 0x821a2da0 csrss.exe     0x077e70000 RPCRT4.dll     Error: DllBase is paged 0x821a2da0 csrss.exe     0x077dd0000 ADVAPI32.dll   Error: DllBase is paged 0x821a2da0 csrss.exe     0x077fe0000  Secur32.dll   Error: DllBase is paged 0x821a2da0 csrss.exe     0x075b50000 basesrv.dll   Error: DllBase is paged 0x821a2da0 csrss.exe     0x07c800000 KERNEL32.dll   Error: DllBase is paged 0x821a2da0 csrss.exe     0x07e410000 USER32.dll     OK: module.600.23a2da0.7e410000.dll 0x821a2da0 csrss.exe     0x075b60000 winsrv.dll     OK: module.600.23a2da0.75b60000.dll 0x81da5650 winlogon.exe 0x001000000 winlogon.exe   OK: module.624.1fa5650.1000000.dll <snip>
In the above invocation of dlldump, we set two options. The first, -D, specifies the directory in which to extract the executables. We will have each extraction plugin write to the same directory in order make running ClamScan easier. The second option, --memory, is likely only familiar to power Volatility users. The purpose of this flag is to instruct Volatility to extract all regions of memory around PE files instead of just relying on the file metadata in the PE header that specifies the original size of each section. This helps substantially when extracting packed executables from memory as you can get data both from the original file as well as the unpacked executable.

* There can be hidden DLLs. The next plugin, malfind, will take care of that.

** If a process is hidden from the active process list, then dlldump will not, by default, find it. This means the hidden executable and any DLLs it loaded will not be extracted using the above invocation. In this situation, you would want to use psxview to find the hidden process - but realize that the fact that a process is hidden already mean its malicious, and you do not need ClamScan to re-verify this for you.


The next plugin that we will use is malfind, which is a plugin that searches for malicious executables (usually DLLs) and shellcode inside of each process. Explaining the precise details of how malfind works is outside the scope of this post and not relevant in a triage situation - but again consult The Art of Memory Forensics if you want all the details. The following shows how to run malfind against the stuxnet sample:
$ python -f stuxnet.vmem --profile=WinXPSP2x86 malfind  -D stuxout/ Volatility Foundation Volatility Framework 2.5
<snip> Process: services.exe Pid: 668 Address: 0x13f0000 Vad Tag: Vad Protection: PAGE_EXECUTE_READWRITE Flags: Protection: 6 0x013f0000 4d 5a 90 00 03 00 00 00 04 00 00 00 ff ff 00 00 MZ.............. 0x013f0010 b8 00 00 00 00 00 00 00 40 00 00 00 00 00 00 00 ........@....... 0x013f0020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0x013f0030 00 00 00 00 00 00 00 00 00 00 00 00 08 01 00 00 ................ 0x013f0000 4d DEC EBP 0x013f0001 5a POP EDX 0x013f0002 90 NOP 0x013f0003 0003 ADD [EBX], AL 0x013f0005 0000 ADD [EAX], AL 0x013f0007 000400 ADD [EAX+EAX], AL 0x013f000a 0000 ADD [EAX], AL 0x013f000c ff DB 0xff <snip>

By default, for each suspicious memory region that malfind encounters, it will print attributes about the region such as which process it is mapped in, the starting and ending address of the region, and a hexdump and disassembly of the bytes at the beginning of the suspicious region. Since we added the -D flag to malfind, it will also extract each suspicious region into a separate file under our specified output directory.

By running the file command on just the files that malfind extracted, we have a good idea that we have already found the malware:
$ file stuxout/* stuxout/process.0x81c47c00.0x1000000.dmp:  PE32 executable (GUI) Intel 80386, for MS Windows stuxout/process.0x81c47c00.0x680000.dmp:   data stuxout/process.0x81c47c00.0x6f0000.dmp:   data stuxout/process.0x81c47c00.0x80000.dmp:    PE32 executable (DLL) (GUI) Intel 80386, for MS Windows, UPX compressed stuxout/process.0x81c47c00.0x870000.dmp:   PE32 executable (DLL) (GUI) Intel 80386, for MS Windows, UPX compressed stuxout/process.0x81c498c8.0x1000000.dmp:  PE32 executable (GUI) Intel 80386, for MS Windows stuxout/process.0x81c498c8.0x80000.dmp:    PE32 executable (DLL) (GUI) Intel 80386, for MS Windows, UPX compressed stuxout/process.0x81e61da0.0xb70000.dmp:   data stuxout/process.0x81e61da0.0xbf0000.dmp:   data stuxout/process.0x81e61da0.0xd00000.dmp:   PE32 executable (DLL) (GUI) Intel 80386, for MS Windows, UPX compressed stuxout/process.0x82073020.0x13f0000.dmp:  PE32 executable (DLL) (GUI) Intel 80386, for MS Windows, UPX compressed stuxout/process.0x82073020.0x940000.dmp:   data stuxout/process.0x820ec7e8.0x2550000.dmp:  data stuxout/process.0x821a2da0.0x7f6f0000.dmp: data

In particular, we see multiple files whose file type is listed as a Windows executable. We also see several extracted regions whose file type was unknown (data), which means the region was either a false positive flagged by malfind or injected shellcode. Fortunately, since we are just using these plugins for automated triage, we can safely move on without examining each region individually.


By using dlldump and malfind, we have extracted every executable that Volatility will give us from userland (process memory) without having to manually dig ourselves. For the last plugin invocation, we will turn to moddump in order to extract all* the executables (drivers) from kernel memory as well.

$ python -f stuxnet.vmem --profile=WinXPSP2x86 moddump —memory -D stuxout/ Volatility Foundation Volatility Framework 2.5 Module Base Module Name Result ----------- -------------------- ------ 0x0804d7000 ntoskrnl.exe OK: driver.804d7000.sys 0x0806d0000 hal.dll OK: driver.806d0000.sys 0x0f7470000 update.sys OK: driver.f7470000.sys 0x0f89ba000 usbehci.sys OK: driver.f89ba000.sys 0x0f8a1a000 HIDPARSE.SYS OK: driver.f8a1a000.sys 0x0f8b5a000 CmBatt.sys OK: driver.f8b5a000.sys 0x0f855a000 pci.sys OK: driver.f855a000.sys 0x0f89aa000 usbuhci.sys OK: driver.f89aa000.sys 0x0bf800000 win32k.sys OK: driver.bf800000.sys 0x0f87fa000 raspptp.sys OK: driver.f87fa000.sys 0x0f89c2000 TDI.SYS OK: driver.f89c2000.sys 0x0b2c23000 ipnat.sys OK: driver.b2c23000.sys 0x0b23ce000 wdmaud.sys OK: driver.b23ce000.sys 0x0f84e5000 SCSIPORT.SYS OK: driver.f84e5000.sys

In this invocation, we have instructed Volatility to locate and extract all* kernel drivers from kernel memory into our output folder.

* moddump relies on the linked list of kernel modules in order to locate each extracted module. This list is susceptible to manipulation by malware and kernel-level malware can certainly run without being present in this list - in fact, it can even run without having any driver file associated with the malware at all (these are known as 'orphan threads' in Volatility terminology). We will avoid that rabbit hole in this blog post though.

Detection with ClamScan

So far we have leveraged dlldump, malfind, and moddump to automatically locate and extract a wide variety of executables from memory.  At this point, we want to check to see if any known malware is on the system, and to do so we will use ClamAV. For those unaware, ClamAV is an open source anti-virus engine with millions of signatures for known malware. It is command-line based and very easy to automate.

The following invocation of clamscan shows running it against all the files in the stuxout directory, which is the directory that contains every executable extracted by the previous three plugins:
$ clamscan stuxout/ | grep -v ": OK$" stuxout/process.0x81c47c00.0x1000000.dmp: Win.Trojan.5873027-1 FOUND stuxout/process.0x81c47c00.0x6f0000.dmp:      Win.Worm.Stuxnet-49 FOUND stuxout/process.0x81c498c8.0x1000000.dmp: Win.Trojan.5873027-1 FOUND stuxout/driver.f895a000.sys: Win.Trojan.Rootkit-8720 FOUND stuxout/process.0x81e61da0.0xb70000.dmp:   Win.Worm.Stuxnet-49 FOUND stuxout/process.0x81c47c00.0x80000.dmp: Win.Worm.Stuxnet-49 FOUND stuxout/process.0x81c498c8.0x80000.dmp: Win.Worm.Stuxnet-49 FOUND ----------- SCAN SUMMARY ----------- Known viruses: 4514519 Engine version: 0.98.7 Scanned directories: 1 Scanned files: 1262 Infected files: 7 Data scanned: 614.46 MB Data read: 631.82 MB (ratio 0.97:1) Time: 196.320 sec (3 m 16 s)

In this output it is immediately obvious that we have a problem as 6 process (userland) files matched AV signatures. Furthermore, one of the drivers extracted from kernel memory matched a signature as well. While ClamScan will occasionally throw a false positive, the fact that multiple signatures matched multiple extracted files very likely means that we have an actual infection. In this example, we can see that ClamAV correctly identifies several of the malicious regions as being associated with Stuxnet.

Advantages to this approach


The fact that we only need to run three Volatility plugins, all with static command line options,  makes this a very fast process. Since none of the plugins require scanning the entire memory sample, each individual plugin should finish in less than one minute.

ClamAV can take anywhere from 1 minute to 10 minutes to scan all files extracted from memory samples that we regularly encounter.


Since the entire triage process described in the writeup can be scripted and will almost always be finished in less than 15 minutes, this approach to detecting known malware is highly scalable.

Defeating Packers

One of the main advantages to extracting malware through memory forensics is that the malware will be in its unpacked form (ignoring VM-based and other advanced packers). This means that the anti-virus engine will be able to scan the actual contents of the malicious files and not just its obfuscated, outer shell. This really helps when scanning with Yara rules as well.

Memory-Only Malware & Injected Code

Through the use of malfind, we are able to find code injected into memory that may never exist on disk and that may have been injected in ways that traditional endpoint security tools would have missed.

No Need to Upload Samples

By running your testing local, you bypass the need to upload potential targeted malware to services such as VirusTotal or to your anti-virus vendor.

No OS Internals Needed

Performing this type of triage requires no advanced memory forensics or operating systems internals knowledge - all you have to do is run the plugins followed by clamscan.

Disadvantages to this approach

While highly useful, this approach is not 100% effective. The following sections describe some of the drawbacks.

Known Only

As made clear in the post title, this approach will only detect known malware. If the organizations originally targeted by Stuxnet had applied this approach to their systems, they would not have detected it as there would be no signatures for it.

This is an example of where deep memory forensics comes into play as it can detect malware in a generic fashion - without the need for any signatures or malware-specific knowledge. MHL's blog post does a great job of showing how effective Volatility's generic anomaly detection plugins are against Stuxnet.

Not everything will be mapped

A second downfall to this approach is that the malicious code might not be resident in memory at the time of the acquisition - it will either in a file on disk or scattered throughout the page file. This situation requires deeper analysis beyond simple triage in order to verify the malware's presence.

ClamAV isn't Perfect

No security tool is perfect, and ClamAV is no exception to this rule. Just because ClamAV does not flag any executables does NOT mean that they are all actually legitimate. In general, we use ClamAV for quick, positive identification of known malware - not to gain confidence that no malware is on the system.

Warnings / Caution Points

Before testing this approach in your own environment, there are two precautions to be aware of:

ClamAV bugs

Unfortunately, ClamAV is not written in a type-safe programming language, and, as a result, has had many vulnerabilities. These vulnerabilities allow for malicious executables to exploit the ClamAV scanning engine in order to take over systems on which the malware is being analyzed. For this reason, we only perform this triage process on systems without critical data and almost always non-networked virtual machines. In general, you should take the same approach with all major anti-virus engines as they all have had numerous exploitable bugs reported in them.

Analysis on Windows systems / Shared VM folders

If you perform this triage process on native Windows systems with AV installed or write your output files to a virtual machine shared folder where the host has AV installed, then it is very likely that the host AV will delete/quarantine any malicious files that you extract. This can cause you to miss infections as, by the time you get to run clamscan, the host AV has already deleted the files, which will prevent clamscan from alerting them to you.

What about dumpfiles?

An experienced Volatility user may be wondering why we did not include dumpfiles into this triage process as dumpfiles can reconstruct cached files, including executables, directly from memory. The answer is that you can certainly include dumpfiles-based extraction into your triage process ---- but be aware of a few points first:

  • This can make your output folder quite large
  • One of the caches that dumpfiles examines contains a file contents as they appear on disk. This means that you will likely be scanning over packed files instead of the unpacked versions from memory
  • dumpfiles can be considerably slower than the three plugins listed

This doesn't mean that you should always avoid dumpfiles, but instead just be cautious of its drawbacks in this particular situation.

Linux & OS X 

This same process can be accomplished with the Linux and OS X counterpart plugins to the plugins used against the Windows stuxnet sample. Please see the official Volatility Cheat Sheet (or the Art of Memory Forensics) for information on these plugins.


Hopefully this blog post has shown you a method that you can bring to your organization and immediately start triaging memory samples. If you have any questions on this process or the post itself, then please feel free to reach out - andrew @@@ AT @@@@  - PGP or through Twitter - @attrc - @volatility.

Monday, July 18, 2016

Memory Forensics Across the Enterprise - *Beta*

I would like to let you know about a *Beta* course opportunity that I’m hosting this summer. The Beta course, Memory Forensics Across the Enterprise - Beta, is offered at a discounted rate exclusively to those who have completed our first course, Windows Malware and Memory Forensics. This course will test some new material focused on performing IR across multiple machines involving different operating systems; and how to maximize efficiency of analysis on a large scale.

I realize that this is rather short notice for this announcement and that this is new un-evaluated content. I am therefore lowering the training price to help offset the overall cost. I hope that you will be able to take advantage of this unique offering and that you will provide valuable feedback regarding its execution.

Ultimately, the target audience for this Beta content would be junior and beginning analysts. The material is designed to get them up to speed in the world of memory forensics and performing IR on a large scale.

*NOTE*: This course is being offered as a “Beta Pop-up course”. As a “Pop-up” course, it is only being offered for a limited time.  The course and its material may not be offered again in the future. As a “Beta” course, it will be used to trial new material and it is being offered at a discounted rate in exchange for feedback

If you are a Volatility Memory Forensics alumni and are interested in taking this course, I am offering it next month in NYC. See our website for details:!beta-memory-forensics-course/kgwzu

Monday, April 25, 2016

Windows Malware and Memory Forensics Training coming to NYC, Amsterdam, and Reston!

We're excited to announce the dates and locations for three new public offerings of Windows Malware and Memory Forensics Training by The Volatility Project.

The following courses are now open for registration:
  • June 27th - July 1st in NYC
  • August 29th - September 2nd in Amsterdam
  • October 3rd - 7th in Reston/Herndon, VA
You can request an invite through our web form or contact us via voltraining @ memoryanalysis [dot] net (pgp). All three of these locations have sold out early in the past, so please contact us ASAP if you wish to attend.

Also, students in our recent Reston course wanted to share some of their feedback with you:
I thought I understood Windows internals until I attended this course. Attend if at all possible! Troy A. (Malware Analyst)

Thanks for a great training. Its one of the best (if not the best) I've been to.  Billy M. 
The course is put together in a way that all skill levels and experience will get valuable information.  Jeremy S. (Senior Research Analyst)

It is one of the greatest forensics classes I ever attended.  Ali K. (IT Security Consultant)
We look forward to meeting all the talented analysis and investigators that attend our classes!

Friday, April 8, 2016

Airbnb Donates $999 to the 2016 Volatility Plugin Contest!

Thank you to Airbnb for donating $999 to the 2016 Volatility Plugin Contest and their continued support for open source memory forensics development.

When we announced the contest a couple days ago, the cash prizes for the top three contest winners were $1500, $500, and $250. In light of Airbnb's donation, we decided to augment the values for the top three and extend the cash prizes for the 4th and 5th place contributors, resulting in not only higher rewards but more cash winners.

1st: $1800 or a free seat at Windows Malware and Memory Forensics
2nd: $800
3rd: $450
4th: $100
5th: $100

Participants who place will still receive the designated shwag (t-shirts, stickers, sync stops, books, etc). Thanks again to Airbnb for their generous donation and support!

Monday, April 4, 2016

The 2016 Volatility Plugin Contest is now live!

This is a quick update to announce that the 2016 Volatility Plugin contest is now live and accepting submissions until October 1st. Winners of this year's contest will be receiving over $2,000 in cash prizes as well as plenty of Volatility swag (t-shirts, stickers, mugs, sync stops, etc).

The purpose of the contest is to encourage open memory forensics research and development. It is a great opportunity for students to become familiar with memory forensics, develop a master's thesis or PhD project, as well as gain experience that will be very desirable by future employers. For those already in the field, submitting to the contest is a great way to gain experience and visibility in the memory forensics community. After the contest is over we promote the work in our conference presentations, blogs, and social media.

If you are looking for inspiration or to see the past winners, please check out the pages from 20132014, and 2015. You will find projects that allow for inspection of virtual machines guests from the view of the host, recovery of in-memory browser artifacts, methods to detect stealthy rootkits, and much more.

If you have any questions please feel free to reach out to us. 

We are looking forward to another year of innovative open source research!