After having some stability issues with earlier editions of HBGary REcon, I tried the latest REcon version available with HBGary Responder 2.0.0.0354 with a piece of malware that I needed to analyze and that worked like a champ for me.
This piece of malware was found spreading via USB media. There was nothing unusual about this malware sample other than it was over 30MB in size and thus not uploadable to a number of free online malware analysis sites. It also was packed with MPRESS and not easily unraveled in IDA. What I already knew through other means was that the malware sample persisted and spread through an autorun.inf file in the root of the infected USB media and an EXE buried in a fake recycle bin entry. On infected Windows endpoint machines this particular variant persists in a bogus iexplore.exe file in %WINDIR% and started itself through 3 rogue autoruns entries in the Windows registry.
The malware sample appeared to run OK under REcon's control in a VMware instance of Windows XP SP3. I imported the resulting REcon .FBJ file into HBGary Responder. The first screenshot below shows how HBGary Responder reported a possible issue with the imported REcon data - correctly identifying the child iexplore.exe process created by the autorunme.exe sample as doing something worth of attention (see the red circled call the WSAStartup on the Report tab). (Please click the image to make it larger and easier to view).
The next screenshot shows the Responder Timeline tab "process and thread" view of the REcon forensic journal data collected while running the malware. The entries circled in red show that I ran the malware sample - autorunme.exe - under REcon, and that spawned process iexplore.exe PID 296 with one thread TID 1716, and then another iexplore.exe instance with a PID of 264 with two threads TID 332 and TID 308. (Please click the image to make it larger and easier to view).
The next screenshot shows the Responder Timeline tab's Sample Group track view of the same REcon data. REcon uses a samplepoints.ini file to map API calls into each of these tracks. I used the default samplepoints.ini file for this run of REcon. (Please click the image to make it larger and easier to view).
And this final screenshot shows Responder's ability to graph the REcon data for analysis. What I did to get here was click the eye icon on the tracks that I didn't want to see in the graph. I deselected everything except for the Network track. The I selected portion of the Network track's timeline that I wanted to view (the portion you see in yellow). The you right click the yellow portion of the timeline and select "Send to new graph". In that graph you can see where the malware tried to resolve DNS name sopa.mine.nu to begin the next phase of the infection process. (Please click the image to make it larger and easier to view).
I already use HBGary Responder Professional alongside Memoryze and Volatility as part of my normal Windows RAM dump analysis process and am very satisfied with the results. My experience with HBGary REcon recently tells me that REcon is mature enough to incorporate into my normal malware analysis procedures.
If you need any assistance with malware RE/analysis or Windows RAM dump analysis for incident response for Windows Server 2003/2003/2008 or Windows 2000/XP/Vista/7 on the client side please contact me at sales @ sharpesecurity.com. A routine Windows RAM dump triage and full report normally costs around $500-1000 USD per dump analyzed. Malware RE and basic capabilities analysis is normally roughly in the same price range and takes around 1-2 days to turn around for a quick triage. Deeper dive analysis is available, but takes a bit longer and costs more.
email: david @ sharpesecurity.com
website: http://www.sharpesecurity.com/
Twitter: twitter.com/sharpesecurity
Posts
