Friday, November 6, 2015

PlugX: Memory Forensics Lifecycle with Volatility

At OSDFCon last week, we discussed a case study showing how we identified manipulated memory artifacts in an infected environment. We were then able to rapidly introduce new capabilities to Volatility that could be used proactively in other environments.

The presentation (hosted on prezi) takes you on a tour of this activity, using a series of videos. Unfortunately, there's no audio (you should have attended the conference!) but it should be fairly self explanatory what's going on. Here's a short description of what the presentation covers:

  • A recent PlugX variant penetrated the target's network. It installed a service named RasTls for persistence and then hid the service from all live tools (WMI, Power Shell, services.msc, sc query, etc). 
  • It injected code into a process and then erased its PE header to evade detection and make dumping the PE file out of memory a bit more complicated. 
  • We identified the injected region with malfind, extracted it with Volatility, then used a hex editor and PE editor to reconstruct the PE file format. 
  • We leveraged the impscan plugin to label API calls inside IDA Pro, then reverse engineered the binary to figure out how it's rootkit component was working. It was clearly targeting the double-linked list of services in usermode space of services.exe. 
  • Next we wrote a new Volatility plugin to automatically detect unlinked services, by comparing the records in memory with the memory-resident registry hives. 

The second part of our talk covered the new features in Volatility 2.5 (including the unified output, community integration, and support for Windows 10, Mac El Capitan, and Linux kernels up to 4.2.3) and all of the submissions to this year's Volatility Plugin Contest.

You can find the slide deck for our talk here (pdf).


  1. What were the host-based indicators for this malware? It must have remained persistent on the system somehow...

  2. It persisted in the registry as a service (even visible via regedit on a live machine). It just hid the service entry from APIs and tools like services.msc, wmi, powershell, etc because those don't query the registry directly, they consult the list in memory. And although you can clearly see RasTls in the registry of a live machine, you wouldn't know it was hidden unless you compared it with the list in memory.