Volatility Labs

Tuesday, June 6, 2017

As we head into summer, we wanted to let everyone know that for 2017 we only have two remaining public offerings of our highly popular and newly updated Malware and Memory Forensics training course. If you would like to join us, our international course will be in London during the week of September 18th - 22nd, and our US course will be back in Herndon during the week of October 16th - 20th.

Our cutting edge materials are one of the main reasons students value our course. We don't teach the same concepts year after year. Instead, we update our class regularly, to stay in sync with (and in some cases, ahead of) the rapidly changing attack surfaces, advances in defense technologies, malware hiding tricks, and operating system forensics artifacts. A few recent additions include:

Not only only will you be learning these memory forensics topics directly from the authors of the Volatility Framework and the Art of Memory Forensics, but you will also receive Volatility stickers, a branded USB drive, a copy of the Art of Memory Forensics (digital or print), and various opportunities to win SyncStops - all nicely documented by a former student:

One of the most popular class contests is our CTF that pits individuals (or teams of two) against the rest of the class, in a challenge that involves analyzing Windows and Linux memory samples in a scenario resembling events that unfolded during the 2016 U.S. Presidential Election.

Besides the core knowledge needed to perform effective memory forensics, we also teach the latest tools and techniques for reliable memory acquisition. Students will gain experience using Volexity Surge Collect Pro for robust, fast, and secure collection of Windows memory to local and remote/network-based destinations. Students can purchase Surge licenses at a discounted price during course registration (see Memory Forensics Training FAQ) or separately after the class.

In closing this update, we would again like to thank the DFIR community for its continued support of the Volatility project and our associated training course. In particular, all the newcomers who are just starting to explore memory analysis, as well as our alumni and numerous repeat students who just can't get enough!

On a side note, if you are going to be at DFRWS or Black Hat this summer then be sure to come introduce yourself!

Thursday, April 20, 2017

Its that time again, folks! The 2017 Volatility Plugin contest is now live and accepting submissions until October 1st, 2017. Winners of this year's contest will be receiving over $2,250 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 2013, 2014, 2015, and 2016. 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!

Friday, December 30, 2016

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).

Monday, December 5, 2016

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!

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.

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.

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.

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.

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 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 System.map 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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

Thursday, September 29, 2016

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.

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.

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

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.

Motivation

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.

Setup

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.

dlldump

To start, the dlldump plugin will be used to extract the main application executable and all* loaded DLLs inside of each** process:

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.

malfind

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:

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:

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.

moddump

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.

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:

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

Speed

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.

Scalability

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'sblog 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.

Conclusion

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 @@@@ dfir.org - PGP or through Twitter - @attrc - @volatility.