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

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 

45

$ 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

<snip>

> 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

<snip>

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

<snip>

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.

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.

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

Roadmap

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:

• Our new Slack server
• Our existing mailing list - vol-users

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

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:

An awesome training class from @volatility. Lived up to every great review I've read.
Kudos to @attrc and @iMHLv2 pic.twitter.com/xcf4eXfHQT

— Brian Baskin (@bbaskin) October 18, 2019

Learned a ton, won some stuff, got free drinks. Had an excellent week attending @volatility training. 😊 pic.twitter.com/ZK4OioYCiz

— Sarah (@StarSlaughter) April 21, 2018

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.

Swag including coffee mugs, t shirts, and @volatility branded @SyncStop devices for our training CTF winners #dfir #memoryforensics pic.twitter.com/z5kKS4DTnf

— volatility (@volatility) April 20, 2018

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 3, 4, 5, 6, 7, 8, 9). 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

Malware and Memory Forensics Training in 2019!

We are excited to announce that in 2019 we will have 3 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 in September, and our US course will be back in Reston/Herndon, VA, during the week of April 8-12, and also in October. We will announce the specific weeks of the Fall courses soon.

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:

• Updated memory analysis techniques for Windows 10 changes
• Challenges of recent hibernation file analysis
• Incorporating decompression of memory pages and paging files into analysis
• Expanded coverage of memory-only Powershell and .NET based attacks
• Scalable and automated memory acquisition of Linux systems
• Memory acquisition challenges from OS X Mojave 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 recent student:

Learned a ton, won some stuff, got free drinks. Had an excellent week attending @volatility training. 😊 pic.twitter.com/ZK4OioYCiz

— Sarah (@StarSlaughter) April 21, 2018

We also recently started providing students with a foldable copy of our popular cheat sheet:

Students of our @blackhatevents Digital Forensics & Incident Response class this week will be the first to receive the new foldable @volatility cheat sheets!

Thanks to @Volexity for putting these together! pic.twitter.com/hJ5HHfPy5z

— Andrew Case (@attrc) August 4, 2018

 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.

Swag including coffee mugs, t shirts, and @volatility branded @SyncStop devices for our training CTF winners #dfir #memoryforensics pic.twitter.com/z5kKS4DTnf

— volatility (@volatility) April 20, 2018

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, 3, 4, 5, 6, 7). The knowledge gained during these investigation 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 and our associated training course. It was great seeing and meeting so many users around the world this year, particularly at OSDFCon, Black Hat, DFRWS, BSidesNOLA, and in Amsterdam and Herndon.

-- The Volatility Team

Results from the 2018 Volatility Contests are in!

Let’s begin by thanking all of the participants in this year’s contests! This year we hosted the 6th Annual Volatility Plugin Contest, and we introduced the Inaugural Analysis Contest. We were encouraged to see submissions from our community members around the globe. As in previous years of the Plugin Contest, there were a lot of exciting submissions spanning tools created by practitioners in the field to published academic research. Participation in these contests demonstrates the importance of memory analysis and provides a platform for the innovative research being done in the field.

Volatility continues to thrive because of its active community of contributors. These contributors sacrifice their time and resources to make the world’s most advanced memory forensics platform free and open source. You can show your appreciation for the participants hard work and contributions to the community 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 also like to thank our sponsors: Magnet Forensics and Volexity. When looking for a new job or searching for forensics tool vendors, we definitely recommend considering companies that demonstrate continued support for open source forensics!

---

Placements and Prizes for the 2018 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:

Aliz Hammond for Gargoyle

2nd place and $750 USD cash goes to:

Aleksander Østerud for MemoryDecompression

3rd place and $250 USD cash goes to:

Lorenz Liebler et al. for the Volatility Plugin for Approxis

4th place and Volatility swag goes to:

David Quesada for CSV and Splunk Dashboard

5th place and Volatility swag goes to:

Peter Casey for Vivedump

Placements and Prizes for the 2018 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 Decepticon (South Korea) for 2018 VAC Report

2nd place and $750 USD cash goes to:

Team MalGround (South Korea) for 2018 PyeongChang Olympic Destroyer 

---

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!

---

Plugin Contest

1st: Gargoyle by Aliz Hammond

In the author's words, "Gargoyle works by placing malicious code inside a non-executable area of memory. It then creates a system timer, configuring it to execute a ROP chain on expiry. The ROP chain calls VirtualProtectEx, marking the malicious code as executable, calls the malicious code, and then calls VirtualProtectEx a second time – this time, marking the malicious code as non-executable. The timer is then reinitialised and the cycle starts anew." Gargoyle has the potential to evade live memory scanners (such as AVs, EDRs, etc.) if the security tools only look for payloads in executable memory.

This Volatility plugin builds on the existing timers plugin (to which the author also submitted a patch) and inspects timer APCs (instead of just the DPCs). The plugin uses Unicorn to emulate the APC's instructions and detect (and then follow) the ROP chain to the VirtualProtectEx call. The plugin inspects parameters passed to VirtualProtectEx on the stack and can then pivot to the newly executable payload.

Related References:
https://www.countercept.com/blog/hunting-for-gargoyle-memory-scanning-evasion
https://github.com/countercept/volatility-plugins
https://www.linkedin.com/in/aliz-hammond-704b688a/

2nd: MemoryDecompression by Aleksander Østerud

The MemoryDecompression tool submission provides a mechanism for decompressing memory regions that were compressed during memory management. Instead of paging memory directly to disk, the Windows 10 memory manager provides a mechanism to compress private and pagefile backed pages to reduce memory pressure. This improves performance, since writing to disk is more expensive, and reduces the number of disk operations which improves their longevity. The tool leverages a brute-force approach to decompress memory pages and can be used on both memory samples and page files. By preprocessing the data with Volatility's vaddump and memdump, it is also possible to extract the compressed memory and reduce the processing time. The MemoryDecompression tool requires a system running either Windows 8 or Windows 10.

Related References:
https://www.linkedin.com/in/aleksost/

3rd: Volatility Plugin for Approxis by Lorenz Liebler et al.

Lorenz Liebler, Patrick Schmitt, and Harald Baier implemented Approxis, a tool for quickly processing a large number of on-disk binaries and subsequently matching/identifying parts of those binaries, or related code, in physical memory images. The technique combines approximate matching (a.k.a. fuzzy hashing or similarity hashing) with an additional layer of approximate disassembling. The tool is able to distinguish code from data even in light of significant variation between the original binary and the target memory image. Approxis has two components: (1) a C/C++ tool for creating and querying a binary database, and (2) a Volatility plugin for presenting context-specific information about matches.

Related References:
https://www.dasec.h-da.de/staff/lorenz-liebler/
https://github.com/Hardknox

4th: CSV and Splunk Dashboard by David Quesada

The Splunk dashboard presents over 30 prepared searches across the output of various Volatility plugins. After running the desired plugins and ingesting the CSV output into Splunk, a Volatility user can load this dashboard and start looking for anomalous activity within the memory sample. Over time, a dashboard like this could be built up with more queries for finding and alerting on malicious activity in memory samples. David was inspired to create this tool after attending Malware and Memory Forensics Training taught by Andrew Case.

Related References:
https://github.com/DvAu26

5th: Vivedump by Peter Casey

Vivedump is a plugin to extract and recreate visual scene information from virtual reality (VR) device memory captures. The plugin's ability to create 3D still images of VR scenes gives the investigator a precise look at a user's actions inside of the virtual world. This novel research opens many possibilities into the under-explored topic of VR memory forensics. The tool is only a small piece of larger scale research that analysts at University of New Haven have been doing to help users better understand the risks of using VR, and to help investigators learn the associated artifacts.

Related References:

https://www.linkedin.com/in/peter-casey1/
https://twitter.com/UNewHaven/status/1060261903774167045
https://hackablepodcast.com/#/episodes/virtually-vulnerable
https://www.researchgate.net/publication/324224216_Forensic_Analysis_of_Immersive_Virtual_Reality_Social_Applications_A_Primary_Account

Analysis Contest

1st: 2018 VAC Report by Team Decepticon (South Korea)

The authors of this report put together a realistic lab scenario modeled after Korean APT investigations they have performed. We were not only impressed by the number of Volatility plugins represented in the analysis efforts, but also that the infected systems spanned multiple operating systems (Windows and Linux). Memory analysis was leveraged to shed light on the toolkits and methodologies used by the attackers, including Eternal Blue, Dark Comet, Spear Phishing, HWP exploits, DLL injections, MongoDB vulnerabilities, and more. Evidence from Outlook PSTs were reconstructed from RAM and shellcode was explored and identified in memory using Yarascan, Volshell, and various other capabilities provided by Volatility.

2nd: 2018 PyeongChang Olympic Destroyer by Team MalGround (South Korea)

This analysis report, written by the MalGround team from South Korea, describes a scenario based on the Olympic Destroyer events surrounding the 2018 PyeongChang Winter Olympic Games. Before the Olympics officially began, the attackers attempted to disrupt the opening ceremonies by intercepting the event's critical computer systems and infrastructure offline. The cyber attack was initiated with a targeted spear phish and then leveraged a "network worm" to propagate using network shares and stolen passwords. The simulated scenario involved three systems: an Active Directory server running Windows Server 2008 R2 Standard 64-bit, a victim PC running Windows 7 Ultimate K x86, and an attacker PC running Kali Linux 64-bit. In the simulated scenario, a file-less malware attack, leveraging Empire (Mimikatz, BypassUAC), is combined with the actual Olympic Destroyer malware. The authors leveraged memory analysis to find supporting temporal artifacts, identify suspicious characteristics of processes, and extract memory resident strings and executables. This submission includes the analysts’ report and a memory sample from the Windows 7 machine where the Olympic Destroyer malware was executed.

Related References:
https://www.kaspersky.com/blog/olympic-destroyer/21494/
https://securelist.com/olympicdestroyer-is-here-to-trick-the-industry/84295/
https://blog.talosintelligence.com/2018/02/olympic-destroyer.html
https://blog.talosintelligence.com/2018/02/who-wasnt-responsible-for-olympic.html

---

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

---

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

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

Results from the (5th Annual) 2017 Volatility Plugin Contest are in!

Congratulations to all the participants! This year's contest resulted in a ton 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.

After over 10 years of development with the Volatility Framework and 4 years of previous plugin contests, you might think that there's nothing left to do, but the community continuously proves otherwise. This year, in particular, we were super impressed not only with the creativity and quality of the submissions, but the fact that several works were influenced by or in support of submissions from previous contests.   

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.

---

Here is a break down of the placements and prizes

---

1st place and $1500 USD cash or a Free Seat at Malware and Memory Forensics Training by the Volatility Project goes to:

Xabier Ugarte-Pedrero from Cisco Talos for PyREBox

2nd place and $500 USD cash goes to:

KSL Group (Kyle Ness, Shachaf Atun, and Liam Stein) for Threadmap

3rd place and $250 USD cash goes to:

Peter Kálnai and Michel Poslušný from ESET for Browserhooks

4th place and Volatility Swag goes to:

(tie) Michael Brown for SQLite Artifacts and Adam Bridge for Linux (X) Windows

5th place and Volatility Swag goes to:

Frank Block for Linux Glibc Heap Analysis

---

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: Xabier Ugarte-Pedrero (Cisco Talos): PyREBox

PyREBox provides an extensible reverse engineering sandbox that combines debugging capabilities with introspection. The analyst can interact with the whole system emulator, QEMU, guest either manually, using IPython, or by creating Python scripts. Unlike previous reverse engineering platforms, PyREBox, is explicitly designed for modern threat analysts and the tasks they commonly perform. PyREBox also leverages Volatility to help bridge the semantic gap challenges typically associated with virtual machine introspection.

https://www.talosintelligence.com/pyrebox
http://blog.talosintelligence.com/2017/07/pyrebox.html
https://github.com/Cisco-Talos/pyrebox
https://pyrebox.readthedocs.io/en/latest/

2nd: Liam, Shachaf and Kyle (KSL Group): Threadmap

The KSL Group (Kyle Ness, Shachaf Atun, Liam Stein) submitted the threadmap plugin, which is the result of their extensive research comparing and contrasting weaknesses in existing tools for identifying code injection based on process hollowing. The authors found an obvious gap between the prevalence of attacks in the wild that leverage process hollowing and the strength of tools that can perform detection reliably. Based on the documentation provided alongside the Volatility plugin, the authors not only analyzed existing malware samples (i.e. a reactive approach) but also developed their own variations of process hollowing that are likely to be seen in the near future - and included coverage for those types of attacks as well.

https://github.com/kslgroup/threadmap

3rd: Peter Kalnai and Michal Poslusny (ESET): Browserhooks

Something magical happens when reverse engineers write Volatility plugins. Peter and Michal from ESET have been tracking banking trojans and MITB malware for a while now, documenting the methods that malicious authors take to subvert victim systems - in particular, how they find and hook the SSL VMT (virtual method table) even in browsers such as Chromium-based browsers that static link with the SSL libraries, change regularly, and don't export the table locations. Studying the pros/cons of attacker methodologies, learning from them in order to create a more robust detection platform, and immediately transitioning that knowledge into a capability analysts can use (via Volatility) requires a unique skill set. In addition to exploring these previously undetected API hooks, the authors also extended Volatility's apihooks plugin to work on WOW64 processes (32-bit processes on a 64-bit architecture) and integrated their work into VolUtility - a submission to last year's plugin contest.

https://github.com/eset/volatility-browserhooks
https://www.virusbulletin.com/conference/vb2017/abstracts/browser-attack-points-still-abused-banking-trojans
https://www.virusbulletin.com/uploads/pdf/conference_slides/2017/Kalnai-VB2017-browser-attack-points-trojans.pdf

4th (tie): Michael Brown: SQLite Artifacts

Michael Brown wrote a seriously cool set of Volatility plugins to interrogate SQL artifacts in RAM. Influenced by Dave Lassalle's previous work for the 2014 Volatility Plugin Contest, Michael wrote a more generalized version of the SQL tools that can search for any table schema. In his own words, "You can enter your own schema, but Sqlitefind can also automatically find table definitions in the sqlite_master table, so the user doesn't need to know the schema beforehand! You can even discover tables that you didn't know were in memory." Given the number of applications that rely on sqlite3 under the hood, this opens doors to an unexplored world of application artifacts.

https://github.com/mbrown1413/SqliteFind

4th (tie): Adam Bridge: Linux (X) Windows & Atoms

Adam's contribution to this year's contest is the first of its kind - a set of plugins to analyze forensic artifacts of the X Window System environment on Linux. The data structures recovered by the plugins are tied to the X server itself, thus they work independently of the Linux distribution or window manager. Captured information includes details about each window, such as X and Y co-ordinates, width and height dimensions, parent window objects, window IDs, color schemes, and atom associations. Natively, the plugins can be used to determine titles of browser windows (URLs visited), titles of LibreOffice applications (opened documents), and in the future - potentially even a screen shots plugin for Linux!

https://twitter.com/bridgeythegeek
https://github.com/bridgeythegeek

5th: Frank Block: Linux Glibc Heap Analysis

Frank's submission to this year's contest introduces a library to parse the user mode heap of a process using Glibc (currently supports x86/x64 and Glibc versions 2.20 - 2.25), an API for developers to create their own plugins, and two example plugins that demonstrate the forensic value - command shell history (zsh) and password management (keepassx). We are super impressed with the level of effort Frank put into this suite of tools. Not only did he implement a model of multiple Glibc versions, but he documented the library's internals, produced a 60+ page academic technical report and published a condensed 10-page DFRWS paper.

https://authors.elsevier.com/sd/article/S1742287617301895 (DFRWS Paper)
https://opus4.kobv.de/opus4-fau/frontdoor/index/index/docId/8340
https://insinuator.net/author/fblock/

---

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!

---

Mark McKinnon: Volatility Autopsy Modules

Mark's work on integrating Volatility output into the Autopsy GUI will undoubtedly make life easier for many investigators. Whether they're not familiar with using command line tools, they're uncomfortable in a Linux environment, or if they just want to save time and visualize memory artifacts across various different cases in the same interface, this is a huge advantage for Autopsy users. The module includes a generic interface that allows running any Volatility plugin that supports SQLite rendering. It also contains more specialized modules that take the output of Volatility's dumpfiles (extract files from RAM) and imagecopy (convert hiber/crash to raw) plugins and make their results available in Autopsy as well, creating a near full circle of analysis between disk and memory, all captured in the same GUI.

https://twitter.com/markmckinnon
https://github.com/markmckinnon
https://www.linkedin.com/in/mark-mckinnon-9b08715
https://medium.com/@markmckinnon_80619
https://github.com/markmckinnon/Autopsy-Plugins/tree/master/Volatility
https://medium.com/@markmckinnon_80619/volatility-autopsy-plugin-module-8beecea6396

Javier Vicente Vallejo: Symbolizemod

As a malware analyst, Javier starts most of his work with Windbg or Volatility and then pivots to IDA Pro to gain a detailed understanding of the malicious code. In this line of work, having access to symbols for the malware being disassembled or debugged is practically a requirement if you want to be efficient. The symbolizemod plugin lets you extract variables and symbols from a particular memory region and exports them as a DBG file, which is a common format understood by IDA Pro and Windbg. The end goal is similar to Volatility's existing impscan plugin, except impscan only exports in text and IDC formats. In fact, symbolizemod also includes a command line switch to leverage impscan's engine for enumerating symbols. By default, however, symbolizemod uses its own engine (called "raw mode") which in some cases can produce different results.

https://vallejo.cc/
https://github.com/vallejocc
https://twitter.com/vallejocc

Alessandro De Vito: Chrome Ragamuffin

Chrome Ragamuffin is part of a larger research project started by Alessandro over a year ago. Although the research is ongoing, Alessandro's Volatility plugin is already full of features and it's one of the most compelling examples of recovering application level artifacts that we've seen. Overcoming challenges such as incognito mode and the fact that Chrome updates automatically nearly every time you launch it, Alessandro managed to dissect critical in-memory data structures related to the browser's DOM and the user's navigation. Alessandro has presented his work at OSDFC and Bsides Zurich, showing how to analyze memory to detect CSRF, clickjacking, phishing, and malicious redirects.

https://twitter.com/_cube0x8

https://github.com/cube0x8/chrome_ragamuffin

https://bsideszh.ch/wp-content/uploads/2017/10/BSides-Zurich-How_I_Met_Your_Browser.pdf
http://www.osdfcon.org/presentations/2017/Alessandro_DeVito-How-I-Met-Your-Browser.pdf

---

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

---

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

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

Our Newly Updated Memory Forensics and Malware Analysis Course is Headed to Herndon and London!

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:

• Windows 10 security features, such as Device Guard, Credential Guard, Isolated User Mode, Protected Processes, etc.
• Challenges of recent hibernation file analysis, the impact of new sleep modes, and hybrid style hibernations 
• How to analyze RAM backed page files on Windows 10 & memory compression 
• The Linux subsystem of Windows 10 and the associated memory artifacts
• Memory-only Powershell and .NET based attacks
• New event log sources that compliment memory forensics

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:

Loving the swag, particularly the SyncStop. Thanks @volatility team! pic.twitter.com/GEYGcGSN0P

— me (@cyli) February 8, 2016

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.

Another epic memory analysis CTF battle between @volatility training students. Congrats to the winners! #DFIR pic.twitter.com/1caH6oGMy9

— volatility (@volatility) April 7, 2017

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, 3, 4, 5). The knowledge gained during these investigation is immediately transitioned into content and labs for our training courses:

Extracting&analyzing this log file from memory is required to complete 1 of our memory forensics labs. Has been crucial in many real cases https://t.co/YU1hOzIITr

— Andrew Case (@attrc) March 17, 2017

Detecting each of these with memory forensics is covered in full detail in our @volatility training #dfir https://t.co/UOcMRBDhaL

— Andrew Case (@attrc) May 28, 2017

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!

-- The Volatility Team