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!