Honeynet Memory Forensics Challenge

Posted by Bagpuss on May 13, 2010
Tags: honeynet, digital forensics, volatility

Using a modified version of the Volatility framework (see http://github.com/carlpulley/volatility and look at the honeynet tag on the main development branch) I've managed to attain third place in the Honeynet Forensics Challenge 2010/3 (Banking Troubles).

In order to achieve this, I found it useful to write python code for the Volatility framework that:

  • extracted cached data associated with file objects
  • extracted stack related data for each process thread
  • performed some basic heap data extraction (this code didn't really turn up anything useful for the challenge though!).

Here are some ways in which my answer could have been improved:

  • My extraction of the PDF is incomplete (at the time I thought it strange that no understandable URL was visible within the shellcode!).
    • Using JSUnpack (as Mario Pascucci does in his answer) clearly allows one to easily extract and then further analyse the shellcode with libemu.
    • Looking at the javascript code that I've manually extracted, it's clear that this agrees precisely with that automatically extracted by JSUnpack. With my original solution I've only extracted every other byte from the Javascript shellcode string! This appears to be myself blindly believing that simply unescaping the Javascript shellcode string would be enough to capture the actual shellcode binary - Tyler Hudak's answer appears to have followed the same extraction path here but with the correct results (I'll have to dig a little deeper to work out precisely why there's a difference in results here!).
    Once the shellcode binary has been extracted I'm then able to provide physical evidence to support why I believe that the collectEmailInfo (CVE-2007-5659) vulnerability was used to exploit the target machine and am able to say which file on the target system the payload was downloaded to.
  • My answer to question 4 failed to analyse the memory for PID 888 (Firefox.exe) sufficiently. If I'd been more thorough here, I'd have been able to say something about what javascript code injection was occurring on the target machine.
  • The other entrants used foremost to carve process memory and extract any files that they could. Obviously, as part of a triage process, this is a nice quick way of extracting files from process address space (I should have realised this at the time - duh!). However, when comparing the malicious PDF file extracted by foremost against that extracted from the shared cache maps of the underlying file object, we clearly have that the latter process is more forensically sound and able to deal with high degrees of fragmentation.
  • My analysis of the e.exe and sdra64.exe binaries (as extracted using malfind2) is pretty poor compared to Tyler Hudak's answer.

Another absolutely fascinating and engaging challenge set by the Honeynet group. Many thanks to all those involved with these challenges.