Tuesday, January 26, 2021

Malware and Memory Forensics Training Goes Virtual!

We are very excited to announce that our popular Malware and Memory Forensics with Volatility training is now available in a self-paced, online format!

Brought to you by members of the Volatility Team, this course gives you the opportunity to learn directly from the people behind the research and development of Volatility, and it offers you a chance to support our ongoing efforts.

The Course

Our course provides a deep examination of Windows internals, malware operations, attacker toolkits, DFIR workflows, and how memory forensics can be leveraged throughout all of your investigations. The end result of the lectures on these topics is a complete understanding of how memory analysis tools operate, along with the traces left behind by malicious actors and applications. You will gain knowledge that applies to all memory analysis investigations and frameworks, both now and in the future.

The Labs

You will get significant hands-on experience using Volatility against Windows, Linux, and MacOS samples during the training labs. These labs are mirrored directly to match our real-world investigations (1, 2, 3, 4, 5), and they are constantly updated as new threats emerge. After each lab, there is a pre-recorded walkthrough that shows you the precise steps taken to solve the lab as well as explains the rationale behind the workflow used. A written version of the walkthrough is also provided in the Lab Guide.

The Content

Signing up for the course provides you with 4 months of access to all material, including the pre-recorded lectures, demos, and lab walkthroughs. You will also be given a trial version of Surge Collect Pro, which provides reliable and secure memory acquisition across Windows, Linux, and Mac systems. For support, we have a dedicated channel on our Slack server and periodic office hours via Zoom; students can directly ask us questions about any portion of the course, with optional screen sharing. After the course ends, you may retain access to the written materials (Art of Memory Forensics, course slides, lab guide) and the course virtual machine. You are also welcome to stay in the student-only Slack channel and join our alumni-only mailing list.

For those wondering about Volatility 2 vs Volatility 3, our course currently uses Volatility 2 for demos and labs as it is the stable and fully featured version of The Volatility Framework. As mentioned previously, the skills learned in this course are transferable to any memory analysis framework – even those not based on Volatility. We plan to add training modules specific to Volatility 3 slowly over time as it stabilizes and further approaches feature- and plugin-parity with Volatility 2. In general, if you know how to use Volatility 2, then using Volatility 3 will be very simple in the future. As students of this course, you will be the first to gain access to Volatility 3 training material as it is released.

Sign Up!

You can request access to the course here. We provide discounts for military, law enforcement, and groups of students from the same organization. We also provide significant discounts to course alumni who wish to take the course again, as well as to full-time college students studying in a related field. Please inquire about these discounts if you meet the requirements. We can also accommodate private sessions for large group trainings.

We would like to thank the memory forensics community for their years of continued support. We are excited that our course is now available 24/7/365 for students around the world!

- The Volatility Team

Wednesday, November 18, 2020

The 2020 Volatility Plugin Contest results are in!

We would like to begin by thanking the participants for their hard work and contributions to Volatility. It’s always exciting to see continued innovation in the field of memory forensics from research teams across the globe! Despite the challenges of this unprecedented year, we had 8 submissions, including a number of new plugins, an output renderer, and a new graphical user interface. This year’s participants also had the additional challenge of learning all the new paradigms and interfaces of Volatility 3.

Independent open source projects and communities only remain viable because of contributors who are willing to sacrifice their time and resources. Please show your appreciation for the contestants’ contributions by following them on Twitter/GitHub/LinkedIn, providing feedback on their ideas, and helping to improve their code with testing, documentation, or contributing patches. 

We would like to thank Volexity for being a sustaining sponsor of the Volatility Foundation and, in particular, for contributing to this year’s contest. We would also like to thank Paessler AG for their donation toward the contest prizes!

Placements and Prizes for the 2020 Volatility Plugin Contest:

1st place and $2000 USD cash or One Free Seat at Malware and Memory Forensics Training by the Volatility Team goes to:

Gustavo Moreira for Netfilter  

2nd place and $1000 USD cash goes to:

Jelle Vergeer for SSHKeys 

3rd place and $750 USD cash goes to:

Aviel Zohar for Volatility Explorer, StructAnalyzer, WinObjGUI, FileScanGUI, P2V, PFNInfo, RAMMap, Winobj

Below is a detailed summary of all submissions, ordered alphabetically by first name. If you have feedback for the participants, we're sure they'd love to hear your thoughts! As previously mentioned, these developers deserve huge props. We look forward to seeing future work by these authors! 

Aviel Zohar: Volatility Explorer, StructAnalyzer, WinObjGUI, FileScanGUI, P2V, PFNInfo, RAMMap, Winobj

This contest submission includes a number of components intended to make Volatility more approachable and user-friendly to investigators. Volatility Explorer is a graphical user interface that provides a user experience similar to Sysinternal’s Process Explorer but only leveraging the information extracted from volatile memory. The Struct Analyzer plugin allows an analyst to parse memory resident data structures in a graphical hierarchy. WinObjGUI provides a capability to view kernel objects with a similar user experience provided by Sysinternal’s WinObj tool. FileScanGui allows an analyst to view files by providing a Window’s Explorer user interface experience. The submission also includes tools for mapping physical to virtual addresses, extracting the provenance of memory regions, and exploring forensics artifacts in physical memory: P2V and PFNInfo. The submission leverages these capabilities to create a tool that provides a similar user experience to Sysinternal’s RAMMap. Finally, the submission also includes an updated version of WinObj.

Related References:

Bjorn Stelte:  EvtxLogs Plugin

This submission provides the capability to extract evtx entries from physical memory of Windows systems. The EvtxLogs plugin leverages the work done by Willi Ballenthin's python-evtx/evtxtract libraries. By focusing on memory samples, it allows a forensics analyst to get insights into events that were happening at the time of acquisition, and events that happened in the past on the suspected system. In particular, this can augment the data used for temporal reconstruction of system events. 

Related References:

Bjorn Stelte:  Syslog Renderer

This submission involved a Volatility 3 renderer for sending Volatility output to a syslog server. The syslog output renderer is intended for situations where a forensics analyst is attempting to analyze a large number of memory samples. An analyst could integrate Volatility into an automated pipeline and send the results to a unified syslog server. Then, the analyst could access the server to triage, using strings and other analysis methods which systems need deeper forensic analysis.

Related References:

Gustavo Moreira: MountInfo Plugin 

The use of containers has seen significant growth in production Linux environments. Previous Volatility file system analysis capabilities did not fully enumerate information related to containers, which left much work on part of the analyst. This plugin closes that gap by replicating the per-process mount information as exported in the /proc/<pid>/mountinfo file on live systems.

Related References:

Gustavo Moreira: Netfilter Plugin

This plugin provides full support for the enumeration of Netfilter hooks for all modern versions of the Linux kernel. The Netfilter subsystem is routinely abused by kernel rootkits to control the network stack, such as the recently disclosed Drovorub and Cloud Snooper malware samples. Abusing Netfilter hooks provides a rootkit with the ability to monitor for 'magic packets' containing command-and-control data; sniff outgoing and incoming network connections; and even silently modify packet data. Properly implemented rootkits will also abuse Netfilter to hide malicious traffic from userland network monitors, such as tcpdump and Wireshark, running on the local system.

Related References:

Jelle Vergeer: SSHKeys Plugin

This submission implemented a Volatility 3 plugin to extract SSH session keys, which are used to encrypt and decrypt network traffic between an SSH client and server. The plugin can extract keys from Linux OpenSSH ssh (client) and sshd (server) processes by locating and parsing a structure that holds the symmetric key cipher name, the keys used for encryption/decryption, and the initialization vectors (IVs) used for encryption/decryption. For each SSH session, two key/IV pairs are recovered, client to server and server to client.  Given the output of the author's Volatility plugin (a JSON containing key and IV) and a PCAP of the network traffic between SSH client and server, users can decrypt and parse the network traffic using another tool the author developed, dissect.network. The result is complete transparency into the entire SSH network session.

Related References:

Or Chechik and Inon Weber: check_parent_spoof Plugin

This submission provides a practical method to detect stealth techniques used by malware in the wild and post-exploitation toolkits, such as Cobalt Strike. Although there are ways to identify parent process spoofing on live machines using ETW and via dead disk forensics by parsing event logs, the check_parent_spoof plugin for Volatility 3 adds this capability to memory analysis. In many cases, after creating a child process with a spoofed parent, code is injected into the child, which warrants analyzing memory anyway. The ability to triage all of these aspects with a single source of evidence provides a powerful capability.

Related References:

Or Chechik and Inon Weber: check_peb_spoof Plugin

In addition to parent process spoofing, another common obfuscation technique is PEB-Spoofing or PEB-Masquerading, which provides a mechanism for bypassing UAC. This plugin provides the ability to detect spoofed process names and detect malware using this technique. This is accomplished by comparing the name in the PEB with the name from the EPROCESS kernel structure. 

Related References:
Here are a few additional resources for previous contests and community-driven plugins:

Volatility Foundation Contest Home Page: http://www.volatilityfoundation.org/contest

Volatility 2019 Plugin Contest Results: https://www.volatilityfoundation.org/2019
Volatility 2018 Plugin Contest Results: https://www.volatilityfoundation.org/2018
Volatility 2017 Plugin Contest Results: http://www.volatilityfoundation.org/2017
Volatility 2016 Plugin Contest Results: http://www.volatilityfoundation.org/2016 
Volatility 2015 Plugin Contest Results: http://www.volatilityfoundation.org/2015
Volatility 2014 Plugin Contest Results: http://www.volatilityfoundation.org/2014-cjpn
Volatility 2013 Plugin Contest Results: http://www.volatilityfoundation.org/2013-c19yz

Volatility Community GitHub Repository: https://github.com/volatilityfoundation/community 


Wednesday, May 27, 2020

When Anti-Virus Engines Look Like Kernel Rootkits

While analyzing real-world systems, memory analysts will often encounter anti-virus (AV) engines, EDRs, and similar products that, at first glance, look suspiciously like malware. This occurs because these security products leverage the same techniques commonly employed by malware—such as API hooking, system call hooking, and registering callbacks—in order to gain the insight they need to detect and analyze threats.

A recent journal publication by members of our team examined this issue for userland API hooks. In this blog post we will show an example of what AV kernel hooks often look like. The sample investigated in this post was sent by a friend who wanted clarification of the behavior, as it was part of a real investigation. In particular, Volatility's ssdt plugin was showing many system call table entries as being hooked, and our friend wanted to know if the hooks were malicious or benign.

System Calls Background

System calls are the common mechanism by which unprivileged code in userland (process) memory requests services through the kernel to access privileged resources, such as the hard drive to create/read/write/delete files, the network stack to send/receive packets, the monitor to display information to the user, and numerous other resources. System calls are also used to enumerate the active system state, such as the list of running processes, active network connections, loaded kernel modules, and nearly everything else that live forensic tools and endpoint agents gather for analysis. This obviously makes the system call table an attractive target for malware to tamper with, as well as a high-value location for security agents to monitor.

To check for signs of rootkits, Volatility's ssdt plugin locates each system call table present in a memory sample and then enumerates each system call table entry. For each entry, it prints either the containing module, if found, or UNKNOWN if the entry points to a memory location not associated with the kernel itself or a module contained within the kernel module list. Several common kernel rootkit methods of hiding code will trigger the classification as UNKNOWN, such as unlinking the malicious module from the module list, or allocating a RWX memory region and then using it to host code after the malicious module is unloaded (see this blog post on analyzing a detached kernel thread).

Unfortunately, the use of system call hooking by AV and EDR engines frequently triggers UNKNOWN entries in ssdt output, as security agents' attempts to "hide" on a system often leverage the same tactics used by malware.

Initial Analysis

To start the analysis, the ssdt plugin was run against the sample:

$ python vol.py -f sample.raw --profile=Win7SP1x86  ssdt > ssdt-output.txt 
Volatility Foundation Volatility Framework 2.6
$ grep -c UNKNOWN ssdt-output.txt 
$ grep UNKNOWN ssdt-output.txt | head -20
  Entry 0x000d: 0x886ea580 (NtAlertResumeThread) owned by UNKNOWN
  Entry 0x000e: 0x881f70b0 (NtAlertThread) owned by UNKNOWN
  Entry 0x0013: 0x886e4d88 (NtAllocateVirtualMemory) owned by UNKNOWN
  Entry 0x0016: 0x88217ca0 (NtAlpcConnectPort) owned by UNKNOWN
  Entry 0x002b: 0x886e9e80 (NtAssignProcessToJobObject) owned by UNKNOWN
  Entry 0x004a: 0x886ea390 (NtCreateMutant) owned by UNKNOWN
  Entry 0x0056: 0x886e9c48 (NtCreateSymbolicLinkObject) owned by UNKNOWN
  Entry 0x0057: 0x88438858 (NtCreateThread) owned by UNKNOWN
  Entry 0x0058: 0x886e9d00 (NtCreateThreadEx) owned by UNKNOWN
  Entry 0x0060: 0x886e9f30 (NtDebugActiveProcess) owned by UNKNOWN
  Entry 0x006f: 0x886e4910 (NtDuplicateObject) owned by UNKNOWN
  Entry 0x0083: 0x886eaba8 (NtFreeVirtualMemory) owned by UNKNOWN
  Entry 0x0091: 0x88436198 (NtImpersonateAnonymousToken) owned by UNKNOWN
  Entry 0x0093: 0x886ea4d0 (NtImpersonateThread) owned by UNKNOWN
  Entry 0x009b: 0x880d3478 (NtLoadDriver) owned by UNKNOWN
  Entry 0x00a8: 0x886eaae0 (NtMapViewOfSection) owned by UNKNOWN
  Entry 0x00b1: 0x886ea2e0 (NtOpenEvent) owned by UNKNOWN
  Entry 0x00be: 0x886e4de0 (NtOpenProcess) owned by UNKNOWN
  Entry 0x00bf: 0x886e4db8 (NtOpenProcessToken) owned by UNKNOWN
  Entry 0x00c2: 0x886ea1a8 (NtOpenSection) owned by UNKNOWN

Looking at the output, it appears that 45 entries are hooked by UNKNOWN module(s). Furthermore, the hooked functions are commonly targeted by both malware and security agents.

Classifying One Hook

To begin the process of determining if the hooks are benign or malicious, volshell was used to examine the code of a few hooks. volshell is a Volatility plugin that allows you to interactively explore a memory sample, including viewing, searching, and disassembling arbitrary addresses in any context (the kernel or a particular process).

To start, volshell was loaded and the hook for Entry 0x000d: 0x886ea580 (NtAlertResumeThread) was disassembled (numbers, dashes, and arrows added for ease of explanation):

$ python vol.py -f sample.raw --profile=Win7SP1x86  volshell
> dis(0x886ea580)
0x886ea580 55                               PUSH EBP                               <----- [1]
0x886ea581 8bec                           MOV EBP, ESP
0x886ea583 ff750c                         PUSH DWORD [EBP+0xc]
0x886ea586 b9fca56e88                MOV ECX, 0x886ea5fc            <-----  [2]
0x886ea58b ff7508                         PUSH DWORD [EBP+0x8]
0x886ea58e 51                               PUSH ECX
0x886ea58f 8b01                            MOV EAX, [ECX]                      <-----  [3]
0x886ea591 ff5004                         CALL DWORD [EAX+0x4]        <-----  [4]
0x886ea594 83c40c                       ADD ESP, 0xc
0x886ea597 5d                               POP EBP
0x886ea598 c20800                       RET 0x8                                    <-----  [5]
0x886ea59b cc                               INT 3
0x886ea59c 0000                           ADD [EAX], AL
0x886ea59e 0000                           ADD [EAX], AL

After reading the disassembly, several things stand out. First, there is a real function prologue with the instructions of "PUSH EBP; MOV EBP, ESP;" [1] and, shortly after, a proper function epilogue [5]. Examining the code in between, a hardcoded address is stored in ECX [2]. That address is dereferenced and stored in EAX [3]. A dereference of EAX + 4 is then used as the target address of a CALL instruction [4].

This code flow can be re-implemented in volshell through the use of its dd (display double word) and dis functions.

> dd(0x886ea5fc, 4)                   
886ea5fc  964c72b4

> dd(0x964c72b4 + 4, 4)          
964c72b8  964ba922

> dis(0x964ba922)
0x964ba922 55                               PUSH EBP
0x964ba923 8bec                           MOV EBP, ESP
0x964ba925 51                               PUSH ECX
0x964ba926 51                               PUSH ECX
0x964ba927 53                               PUSH EBX
0x964ba928 56                               PUSH ESI
0x964ba929 57                               PUSH EDI
0x964ba92a bf010000c0                MOV EDI, 0xc0000001

The first invocation of dd is at the hardcoded address from [2] earlier. As can be seen, the address stored here is 0x964c72b4. The second dd invocation dereferences this address + 4 just as the disassembly in [4] from earlier shows. This gives a CALL target address of 0x964ba922, which the address used in the above dis call.

Looking at the instructions here, there is the beginning of a long function which appears to be the real hook implementation. To determine which, if any, module is hosting the real payload, the drivermodule plugin can be invoked with the address of the function:

$ python vol.py -f sample.raw --profile=Win7SP1x86 drivermodule -a 0x964ba922
Volatility Foundation Volatility Framework 2.6
Module                   Driver          Alt. Name    Service Key
--------------------- ------------- ------------- -----------
SYMEVENT.SYS     SymEvent   SymEvent   \Driver\SymEvent

This output shows that the function is inside of the SYMEVENT.SYS driver, which is part of the Symantec AV/Endpoint protection suite installed on the system.

Classifying All Hooks

So far, it has only been shown that 1 of the 45 hooks belongs to Symantec. To ensure that all of them belong to Symantec, the remaining 44 must be checked. Repeating the volshell steps for two more of the system calls showed the same pattern as before: a hardcoded address (different address for each hook) being dereferenced, followed by the value of the first dereference having 4 added then being dereferenced itself. The consistent result between the hooks of this sample was that the final destination was the same: 0x964ba922. With this in mind, it became clear that the process of checking each hook could be automated to see if they all ended at 0x964ba922. 

To accomplish this, awk was first used to extract just the UNKNOWN addresses from the ssdt output saved earlier:
grep UNKNOWN ssdt-output.txt | awk '{ print $3 }' > unknown-addresses
This placed all of the UNKNOWN addresses in the unknown-addresses file. Next, code was written inside of volshell that repeated the read hardcoded address-> dereference -> dereference+4 pattern. Note: volshell runs inside of the Python shell, so whatever you can do in Python, you can do in volshell as well.  The following shows this code in its entirety, with line numbers added to the beginning of each line.
1.    > for line in open("unknown-addresses", "r").readlines():
2.   ...:    address = int(line.strip(), 16)
3.   ...:    insts = addrspace().zread(address + 6, 5)
4.   ...:    if ord(insts[0]) != 0xb9:
5.   ...:        print "invalid instruction at %x | %x" % (address, ord(insts[0]))
6.   ...:        break
7.   ...:     
8.   ...:    first_addr = struct.unpack("<I", insts[1:])[0]
9.   ...:     
10. ...:   second_addr_str = addrspace().zread(first_addr, 4)
11. ...:   second_addr = struct.unpack("<I", second_addr_str)[0]
12. ...:     
13. ...:   function_addr_str = addrspace().zread(second_addr + 4, 4)
14. ...:   function_addr = struct.unpack("<I", function_addr_str)[0]
15. ...:     
16. ...:   if function_addr != 0x964ba922:
17. ...:        print "incorrect function_address: %x" % function_addr
18. ...:     

This code starts by looping for each line in the file, which contains one line for each UNKNOWN hook address. Next, the address is converted to an integer. On line 3, the hook address plus 6 is read for 5 bytes inside of the kernel address space. This corresponds to reading what should be the MOV ECX, <hardcoded address> instruction at [2] in the first disassembly listing. The first byte of the instruction is verified to be 0xb9, which is the MOV instruction opcode. On line 8, the remaining 4 bytes are then converted to an integer, as they are the hardcoded address in little endian. On lines 10  and 11, the hardcoded address is dereferenced and then converted to an integer. On lines 13 and 14, the dereferenced valued plus 4 is dereferenced and converted to an integer. It is then verified to be the target CALL address of 0x964ba922.

Running this loop over the sample showed that all system call hooks transferred control flow to 0x964ba922, which means that all hooks belonged to the same Symantec driver.

Closing Thoughts

Through a mix of manual reverse engineering and automated comparisons based on knowledge learned, the system call table was automatically verified as clean, and our friend was given a repeatable methodology to apply to other samples in his investigation.

If you like this type of analysis and want to challenge yourself to write plugins that automate memory forensic techniques, then consider a submission to our 2020 Volatility Plugin Contest. This year's contest is based on Volatility 3, and you can learn about the new, exciting features of Volatility 3 in our recently recorded presentation.

If you would like to stay in touch with the Volatility Team and community then consider following us on Twitter, joining our Slack Server, and subscribing to our email list.

Friday, May 15, 2020

The 8th Annual Volatility Plugin Contest!

We are excited to announce that the 8th annual 2020 Volatility Plugin Contest is now accepting submissions until October 1, 2020!

Winners will receive over 3750 USD in cash prizes!

Volatility 3

The 2020 Volatility Plugin Contest encourages research and development in the field of memory analysis. With the announcement of the Volatility 3 Public Beta (blog post and recent presentation), and the current development focus on the Volatility 3 Official Release later this summer, we decided this is an exciting time to shift the Contest to Volatility 3 plugins. As in previous years, the main goal is to encourage innovation in the field of memory analysis.

Submissions provide an opportunity to get industry-wide visibility for your work, put groundbreaking capabilities immediately into the hands of investigators, and contribute back to the open source forensics community. By building on top of Volatility 3, your contributions will help lay the foundation for the next generation of memory forensics! If you are looking for inspiration for the Volatility Plugin Contest, check out the previous results.


We would like to thank Volexity and our other sustaining donors for their continued support.

Friday, November 15, 2019

Results from the 2019 Volatility Contests are in!

We would like to begin by thanking the participants in this year’s contests! This was one of the hardest years for our panel of judges since it had so many outstanding submissions. In the Plugin Contest, there were 11 submissions, which included over 30 new plugins across 3 operating systems. It was also great to see repeat contestants in both the Plugin Contest and the Analysis Contest, and submissions from community members around the globe. Despite the contest going into its 8th year, it’s inspiring to see all the exciting innovation still happening in the field of memory forensics. 

Independent open source projects and communities only remain viable because of contributors who are willing to sacrifice their time and resources. Please show your appreciation for the contestants’ contributions by following them on Twitter/GitHub/LinkedIn, providing feedback on their ideas, and helping to improve their code with testing, documentation, or contributing patches. Looking forward, we are excited to announce that next year’s contest will focus on Volatility 3!

We would also like to thank Volexity for being a sustaining sponsor of the Volatility Foundation and, in particular, for sponsoring this year’s contests.

Placements and Prizes for the 2019 Volatility Plugin Contest:
1st place and $1500 USD cash or One Free Seat at Malware and Memory Forensics Training by the Volatility Team goes to:

Antoine Brodin for FreeBSD Support

2nd place and $750 USD cash goes to:

Blaine Stancill for Windows 10 Memory Compression

3rd place and $250 USD cash goes to:

Shusei Tomonaga for MalConfScan

4th place and Volatility swag goes to:

Shachaf Atun for Winobj and Tokenimp

5th place and Volatility swag goes to:

Fabio Pagani for Linux kallsyms

Placements and Prizes for the 2019 Volatility Analysis Contest:
1st place and $1500 USD cash or One Free Seat at Malware and Memory Forensics Training by the Volatility Team goes to:

TEAM. HSLFL (South Korea) for “Memory Analysis in Data Leakage Cases”

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

Analysis Contest

1st: Memory Analysis in Data Leakage Cases by TEAM. HSLFL (South Korea)

This analysis report, written by TEAM. HSLFL (Hope Seyoung Lee Find Love) from South Korea, focuses on exploring how memory analysis with Volatility can be used during data breach investigations. In particular, they present three scenarios involving a remote administration tool (QuasarRAT), FTP, and cloud storage (Google Drive). The simulated scenarios involved two systems, an attacker machine, and a victim machine. The report authors leveraged memory analysis to find suspicious commands, processes, and network activity. They also used memory analysis techniques to extract memory-resident strings and executables. Finally, they demonstrated how numerous types of memory-resident files, including prefetch, hosts, FTP logs, and browser history, could be extracted and post-processed to reveal valuable insights about the attackers’ activities. The submission includes the analysis report and memory samples from each of the three targeted Windows 7 systems.

Related References:

Plugin Contest

1st: Antoine Brodin: FreeBSD Support

This submission provides a very complete toolkit for performing memory analysis on modern FreeBSD systems. In addition to adding support to Volatility 2.6.1 for a new operating system and writing 13 new plugins, the author has also written a memory acquisition tool for FreeBSD and integrated full profile support. One of the factors that judges consider is the “analysis curve” or the difference in analytical capabilities with and without the author’s work. Prior to this submission, investigations would either not be able to capture RAM or they’d be limited to strings and grep. They now can leverage the full power of Volatility! Amazing and useful!

Related References:
http://distcache.FreeBSD.org/local-distfiles/antoine/2019-vpc/FreeBSD-12.1-PRERELEASE-GENERIC-amd64.lime https://people.freebsd.org/~antoine/2019-vpc/FreeBSD-12.1-PRERELEASE-GENERIC-amd64.zip

2nd: Blaine Stancill (FireEye): Windows 10 Memory Compression

This submission enabled the automatic incorporation of the compressed stores created by Windows 10 to implement in-memory paging. By incorporating analysis of these stores in a new Volatility address space, compressed pages are transparently decompressed as plugins access them. The clever use of inheritance and caching by the authors minimizes the performance impact of the decompression routines and makes the benefits far outweigh the impact. Aleksander Østerud pioneered some of these capabilities in last year’s plugin contest, and it is exciting to see Blaine and the FireEye team dive deeper into what we consider one of the most drastic changes to memory analysis that any OS vendor has made in the past couple years.

Related References:

3rd: Shusei Tomonaga (JPCERT): MalConfScan

This suite of plugins dumps configuration data, decoded strings or DGA domains from over 25 common malware families and red team tool kits. The plugins can be launched individually or in batch mode by the main entry point, malconfscan. Most configurations are identified with yara signatures (which, too, can be leveraged outside of the framework, if desired) and then parsed out of process memory, using freely available decompression libraries (i.e., aPLib), custom decoding functions, or encryption algorithms – using keys hard-coded within the malware or dynamically referenced from elsewhere in the memory sample. The authors also provide a Cuckoo Sandbox integration, which can save analysts a significant amount of time. We'd love to see the broader community submit merge requests to this project and help upkeep the (already extensive) library of decoders.

The authors also thought one step ahead and developed a generic malware string extractor (malstrscan plugin) that works independently of specific malware families. By default, the string extractor searches for injected code regions (similar to how malfind works), disassembles the code, and follows pointers/references to strings. In "full" mode, it extracts strings from bordering memory regions that were possibly allocated contiguously, but that might not appears as injected on their own (for example, if they're RW and not RWX).

Related References:

4th: Shachaf Atun (KSL Group): Winobj and Tokenimp

The winobj and tokenimp plugins introduce some powerful new capabilities. As always, plugins built to satisfy a particular deficiency (amongst existing plugins) during investigations are pretty much guaranteed to be valuable. In this case, the authors wanted to determine which processes elevated via UAC or UAC bypasses, and to hunt instances of token impersonation. Tools such as Mimikatz, Tokenvator, and Invoke-TokenManipulation were used for testing, and pointers were provided in the documentation to threat groups and malware variants that leverage the same techniques. We were impressed by this plugin because it also required analyzing a fair amount of undocumented data structures and flags. The winobj plugin allows extracting artifacts from the object directories. One of the documented use cases is detecting attacks against KnownDlls, which has been exploited heavily in the past. It also provides a valuable alternate method for finding drivers, devices, file systems, mutexes, symbolic links, and various other artifacts relevant to forensics. Allowing interactive browsing of object name spaces was also a nice touch.

Related References:

5th: Fabio Pagani: Linux Kallsyms

This submission provided several new capabilities to Volatility. First, new algorithms for enumerating processes in kernel memory were discussed and implemented as Volatility plugins. What is particularly interesting about these new methods is that they were derived from an automated system that can determine where and how data structures are accessed during runtime and then translate these accesses to memory forensic capabilities. The second part of the submission involved automatically finding and reconstructing the full set of kernel symbols from a memory sample. This also had an interesting twist in that it used the Unicorn emulation engine to perform the decompression of the symbol sets instead of code implemented in Volatility. The use of emulation allowed for the exact algorithm from the kernel to be used.

Related References:

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!

Cesare Pizzi (Sorint.Lab): Powershell

Powershell has become increasingly common as a malicious payload in real malware samples. The goal of this plugin is to assist analysts in finding Powershell processes and narrowing down the amount of related data to focus on for subsequent analysis. The submitted plugin accomplishes this by first using a yara rule, rather than relying on a filename, for finding Powershell processes in memory. Additionally, the plugin provides an advanced scanning option that filters the VADs of found Powershell processes, looking for ones that may contain Powershell-related commands or scripts.

Related References:

Or Chechik and Inon Weber: Ropfind

The ropfind and linux_ropfind plugins find evidence of return oriented programming, or ROP, and stack pivoting in a memory sample. The plugins scan thread stacks for evidence of ROP gadgets and small memory allocations for evidence of stack pivoting. There are a number of checks performed to reduce the number of false positives reported. The plugins additionally provide a means for whitelisting gadgets based on opcodes and make them more specific by whitelisting based on specific symbols.

Related References:

Rolf Govers and Max de Bruijn (Fox IT): Windows Toast Notifications

The ToastPlugin is the first Volatility plugin to extract Windows notification artifacts. In particular, the plugin focuses on a particular type of notification called toast notifications. Toast notifications allow an application to relate relevant information and timely events to users that may require actions. A toast notification can contain text, images, and custom actions. For example, this could include information about connected devices, calendar events, friend requests, or email/messaging notifications. As a result, they can provide investigators with valuable insights into historical user activity and context about how the system was being used. The ToastPlugin searches though memory samples for the toast XML structures. It also lays the groundwork for a lot of future work related to Windows notifications.

Related References:

Elmar Nabigaev: VMware Tools

Virtualization platforms have become exceedingly common and typically provide capabilities to perform various actions on a guest operating system from the host. VMware's vmtools is one example and this plugin can help analysts by finding recently executed commands run on a guest through vmtools. These include operations such as copying files to and from the guest, listing files, running processes, etc. This plugin can also capture credentials an attacker may have used on the guest OS when executing a command.

Related References:

Angelo Mirabella: Linux Coredump

linux_coredump is a new Volatility 2.6.1 plugin that extracts detailed information about individual processes and generates a core dump file for the process. The resulting core file can be loaded into GDB or other debuggers that support the core file format. This plugin is particularly useful for situations where an analyst wants to dig into the details of a particular process found in a Linux memory dump and needs to leverage capabilities provided by debuggers but not memory analysis tools.

Related References:

Ryan D. Maggio, Raphaela Mettig, Sweta Ghimire (LSU): Shemu

shemu (shell + emulator) allows for the emulation of in-memory code directly inside volshell. With current Volatility capabilities, analysts who wish to perform reverse engineering inside of volshell must instead use the dis() function, which simply provides static disassembly listing. Automated emulation of code provides for much deeper, accurate, and efficient analysis of memory resident code and will be a great feature for users of the framework.

Related References:
https://twitter.com/4kb0mb https://twitter.com/rmettig_

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

Volatility Foundation Contest Home Page: http://www.volatilityfoundation.org/contest

Volatility 2018 Plugin Contest Results: https://www.volatilityfoundation.org/2018
Volatility 2017 Plugin Contest Results: http://www.volatilityfoundation.org/2017
Volatility 2016 Plugin Contest Results: http://www.volatilityfoundation.org/2016
Volatility 2015 Plugin Contest Results: http://www.volatilityfoundation.org/2015
Volatility 2014 Plugin Contest Results: http://www.volatilityfoundation.org/2014-cjpn
Volatility 2013 Plugin Contest Results: http://www.volatilityfoundation.org/2013-c19yz

Volatility Community GitHub Repository: https://github.com/volatilityfoundation/community

Tuesday, October 29, 2019

Announcing the Volatility 3 Public Beta!

The Volatility Team is very excited to announce the first public beta release of Volatility 3!

We presented this beta for the first time to OSDFCon attendees and received a very warm reception both during and after our presentation. As always, we are very grateful to our community for the years of support given to our trainings, book, invited speaking engagements, plugin contests, and other activities.

With this blog post, we now want to document the beta release for the entire community.

This beta release is meant to give an early view of the future direction of Volatility along with the ability to experience the new framework well in advance of its first official release next summer.

Since being initially developed in the mid-2000s, Volatility 2 has become the de-facto framework for memory analysis research, development, and real-world analysis. Parallel to this rise in popularity, significant changes have occurred in the memory forensic landscape, including the:
  • Large increases in the size of RAM samples to be analyzed
  • Inclusion of multiple RAM samples in common investigative scenarios
  • Number of analysis tasks (plugins) that are available and utilized in investigations
  • Introduction of rapid kernel development cycles across Windows, Linux, and OS X
These changes, along with others, drove the decision to redesign and reimplement Volatility 3 as a completely new framework - meaning that every line of code has been written from scratch. This decision gave us the full ability to design a framework that not only meets the needs of current analysis, but also of analysis for years to come.

New Features
During the design phase of Volatility 3, it became clear that the choice to design the framework from scratch provided the flexibility to fulfill many of the requests made over the years by members of our community. We are happy to say that a number of these requests have now been satisfied with Volatility 3 and will be fully realized in the first official release.

For users, the highlights of the new features include:
  • Major performance boosts
  • The removal of reliance on --profile in order for the framework to determine which symbol table (profile) is needed to match the operating system version in the memory sample 
  • Proper evaluation of 32bit code on 64bit systems, such as Window's wow64 
  • Automatic evaluation of in-memory code to avoid as much manual reverse engineering on part of the analyst as possible
For developers:
  • Much simpler integration into user 3rd-party interfaces and libraries
  • Extensive API documentation
  • The ability for plugins to directly call other plugins
  • Plugin versioning
  • Direct integration of custom symbol tables and data structures
Code and Documentation

The official repository for Volatility 3 is on Github within the same organization as Volatility 2.

The official documentation can be found on our Read the Docs page.


In order to fully meet the needs of our community, including keeping Volatility 2 stable and up-to-date with the latest operating system versions, along with the rapid development of Volatility 3, we have decided on a dual framework development cycle.

For Volatility 3, our goal is to have the first full release in August 2020. This release is slated to have complete feature parity (plugins, address spaces, etc.) with Volatility 2 as well as a number of completely new analysis features. We then expect official periodic releases to continue for years after.

For Volatility 2, the core development team will keep it fully up-to-date with features and plugins until August 2021.

In August 2021, the core development team will stop work on Volatility 2 and all efforts will be given to Volatility 3. 

This means that, for the roughly next two years, Volatility users can expect a fully featured framework in Volatility 2 while we work to bring Volatility 3 to full realization.

Getting Involved!

By releasing a beta version of Volatility 3 in the middle of the development cycle, we hoped to inspire members of the community to help with our efforts related to development, documentation, testing, and everything else involved with making Volatility 3 become the new de-facto framework of the field. While the core of Volatility 3 is implemented and stable, there is much work to be done in porting plugins and adding the envisioned brand new features.

Whether you are a college student looking to gain real-world development experience or a seasoned professional looking to have a major impact on your field, there are many tasks where help would be appreciated and recognized.

If you would like to discuss these possibilities with us, then please see our community resources, described next.

Community Resources

For the members of our community who wish to engage directly with the core development team as well as other members, we now have two resources available:
Both of these resources can be used to ask questions, get help with analysis or development tasks, keep up with our latest announcements, and for anything else related to Volatility and memory forensics.

Final Thoughts

We would again like to thank our community for the continued support!

The huge, warm reception at OSDFCon made for a very nice experience, and we always enjoy being able to engage directly with Volatility users.

Our 2020 calendars are already packed with trainings, conferences, and other community events. If you see an announcement of us participating at an event that you will also be attending, then please stop by and say hello.

-- The Volatility Team

Tuesday, October 22, 2019

Volatility Malware and Memory Forensics Training in 2020!

We are excited to announce that in 2020 we will have 4 public offerings of our highly popular Malware and Memory Forensics training course. These offerings include:
  • March 9-13, San Diego, CA
  • April 20-24, Herndon, VA
  • September 21-25, Amsterdam, NL 
  • October 19-23, Herndon, VA [Date revised from original announcement]
Our incident-driven, cutting-edge material is 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) rapidly changing attack surfaces, advances in defense technologies, malware hiding tricks, and operating system forensics artifacts. A few recent additions include:
  • Updated memory analysis techniques for ongoing Windows 10 changes
  • Analysis of "stealthy" mechanisms to hide memory-only code
  • Automatic comparisons of live forensics data to memory forensics data for detection of malware
  • Scalable and automated memory acquisition of Linux systems
  • Memory acquisition challenges from OS X Catalina systems
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 few past students:

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.

To continue providing the most up-to-date memory forensics training available anywhere in the world, our instructors constantly perform high-impact, real-world DFIR  (1, 2 3456789). The knowledge gained during these investigations is immediately transitioned into content and labs for our training courses.

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, Linux, and OS X 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, including the recent warm reception at OSDFCon 2019. It was great seeing and meeting so many users around the world this year, particularly at OSDFCon, Black Hat, DFRWS, BSidesNOLA, BSidesAustin, BSidesLV, and in Herndon and London.

-- The Volatility Team