Honeynet Memory Forensics Challenge
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.
- 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.