Volatility 2.3 and FireEye’s diskless, memory

Volatility 2.3 and FireEye’s diskless, memory: If you needed more any more evidence as to why your DFIR practice should evolve to a heavy focus on memory analysis, let me offer you some real impetus.

FireEye’s Operation Ephemeral Hydra: IE Zero-Day Linked to DeputyDog Uses Diskless Method, posted 10 NOV 2013 is specific to an attack that “loaded the payload  directly into memory without first writing to disk.” As such, this “will further complicate network defenders’ ability to triage compromised systems, using traditional forensics methods.” Again, what is described is a malware sample (payload) that ” does not write itself to disk, leaving little to no artifacts that can be used to identify infected endpoints.” This FireEye analysis is obviously getting its share of attention, but folks are likely wondering “how the hell are we supposed to detect that on compromised systems?”

Question: Why does Volatility rule?

Answer: Because we don’t need no stinking file system artifacts.

In preparation for a Memory Analysis with Volatility presentation I gave at SecureWorld Expo Seattle last evening, I had grabbed the malware sample described in great length by FireEye from VirusShare (MD5 104130d666ab3f640255140007f0b12d), executed it on a Windows 7 32-bit virtual machine, used DumpIt to grab memory, and imported the memory image to my SIFT 2.14 VM running Volatility 2.3 (had to upgrade as 2.2 is native to SIFT 2.14).

I had intended to simply use a very contemporary issue (3 days old) to highlight some of the features  new to the just released stable Volatility 2.3, but what resulted was the realization that “hey, this is basically one of the only ways to analyze this sort of malware.”

So here’s the breakdown.