No, that’s not a misprint. Your next APT threat could very well come from the corporate parking lot that sits outside your otherwise (hopefully) well-secured facility. The updated scheme goes something like this:

The Caper

The bad guy visits his local office supply store and purchases 3-5 cheap USB thumb drives, paying cash in all likelihood. Later after arriving back at his volcano lair, the villain fires up his favorite exploit framework and, in under a minute, he's built a custom IF_FOUND_PLEASE_OPEN_ME.exe payload that, when executed, will compromise the victim’s machine and automatically create a network tunnel out of the victim’s network and back to the villain’s lair for complete control.

Then, as a final step he places a copy of the malicious IF_FOUND_PLEASE_OPEN_ME.exe on each of the thumb drives he's purchased and his preparations are complete!

All that’s left to for the villain to do then is catch a bus over to any one of your well-known corporate locations. You say you have armed guards working the gate 24/7 controlling access to the parking lots? This is of little concern to our friend as he nonchalantly starts hurling these infected pieces of plastic over the well-placed razor wire. Once he's placed/dropped all of his infected thumb drives he'll head back to the volcano lair and wait.. usually only until lunchtime or, at worst, the end of the business day in most instances.

Later that day at around 1:15pm in the afternoon or so he gets his first successful hit. A machine named JANACCOUNTING1 initiates a connection from our victim’s network back to the villain. Our villain barely has enough time to determine he's on the internal financial network before luck favors him again and a 2nd connection is initiated this time from PRODENGINEERING06. From this point forward it’s gameover. The attacker has multiple established points of presence behind your firewall on the internal network and will begin to move laterally. He's just circumvented millions of dollars in security investment by exploiting the weakest link the security chain - People. This attacker has just pulled off a successful, targeted attack against his intended victim at a cost of less than $50 USD. Wow.

Sound far-fetched? I wish it was. In reality, this attack vector is becoming much more popular and seems to be here to stay. Even folks who ordinarily wouldn’t be fooled into opening a conspicuous PDF or EXE in an email attachment have been known to fall for this style of attack primarily do to their unfamiliarity with it. This attack is very cheap and easy to execute and carries very little risk for the attacker in most instances --even when they're distributing the infected thumb drivess. (referred to as "Moose Apples" in some circles)

Countermeasures

Unfortunately, much like all classic hacks that exploit humans, this is a difficult vulnerability to defend against completely. Employee education is obviously key. I find that while lots of companies have done internal trainings or bulletins about not opening suspicious attachments or PDFS in email, only a small percentage of organizations are currently warning their employees about the dangers of encountering and opening unexpected media. In the example I listed above, we used USB thumb drives, but in reality any storage medium could be used to execute this attack ranging from a malicious.exe placed on a cheap CDR, or MICRO-SD flash card all the way up to leaving free/expensive consumer devices around (Free iPods/iPhones anyone?). We also used the example of a parking lot since that seems to be quite popular, but snail-mail has been used just as effectively as a delivery mechanism.

It is critical that every organization make the time to brief new employees and refresh existing employees on the procedures for reporting suspicious, possibly malicious content no matter what the delivery mechanism is. DHS's anti-terrorism mantra of "If you see something, say something" feels especially appropriate in this context. It is also of critical importance to try to create a constructive environment of open-reporting between the employees and IT organizations. Many incidents each year are caused or exacerbated by underreporting by employees of accidental misclicks. Employees are typically much more forthcoming about accidental infections when there has been open dialogue regarding threats of this type and how they are handled. Too often it seems employees underreport these types of issues for fear of embarrassment or misconceptions about losing their jobs.

Forensic Get:

HBGary is very pleased to announce of the availability of FGET.exe to the general public. FGET which is short for “Forensic Get” is a network-capable forensic data acquisition tool. It's primary function is collecting sets of forensicly interesting files from one or more remote windows machines. FGET starts off by creating a local repository folder @ C:\FGETREPOSITORY\ and from there it will automatically create named sub-folders, one for each machine you run FGET against. By default, FGET is able to obtain a forensicly sound copy of any file on the system, including those that are locked and in use (pagefiles, registry hives, etc). FGET can also be used to fetch NTFS special files that aren’t normally accessible thru the live operating system such as the $MFT, and system restore point data. FGET is also fully capable of bringing back a copy of a deleted file, assuming the file In questions FILERECORD data hasn’t been overwritten or reused.

Before FGET most investigators were forced to pay multiple thousands of dollars on a commercial product to remotely get at these files on a live running machine. Alternatively there are a number of great freeware tools out there but most of these tools seem to be focused on dead/offline analysis.

Default Captured Dataset

BY Default FGET collects the following set of data for each machine you target:

• Full user list - complete with NTUSER.dat file copies
• Complete contents of the windows prefetch directory
• Complete contents of the windows\system32\config\ directory including registry hives, event logs, and the system SAM database.
• BONUS: HBGARY ActiveDefense Customers can also fetch a copy of the last physical memory image taken of the remote machine by appending the “+mem” option to the command line.

All of the above data is collected automatically by simply targeting a machine using “FGET.exe –scan serverbox1”. You can also get a file from a range or list of machines by utilizing the “-range” and “-list” features of FGET.

Remote File Retrieval:

In addition to the default captured dataset, the user can also collect singular remote files on the fly by using FGET. For example if you wanted to make a copy of the remote machines MFT all you need to do is:

FGET.exe –scan SERVERBOX1 –extract C:\$MFT mylocalmftcopy.bin”

Finally, if you’re interested in say collecting a specific file from a range of boxes you would use the command line:

FGET.exe –range 192.168.0.1 192.168.0.5 –extract C:\$MFT

Notice that in the multi-machine usage of the –extract option you don’t specify a local output path. That is because in multi-mode the local

Copies will show up automatically in the named fget repository folder for this machine. So after running this scan we’d find our file at:

C:\FGETREPOSITORY\192.168.0.1\$MFT

Summary

As you can hopefully see FGET.exe is a very powerful tool to have in the forensic investigators tool bag.  It is HBGary’s hope that FGET will allow forensic investigators in the field to work faster, and more efficiently in their investigations thereby reducing potential damage and losses caused by the attacker. Please feel free to contact support@hbgary.com if you have any issues using the tool.

Download FGET v1.0 HERE

Today I took a look at the free physical memory acquisition tool called windd. The authors have touted windd as fully supporting acquisition of memory images on 4GB and greater machines on both 32-bit and 64-bit windows platforms.  They also claimed to be the first to image Windows 7, which of course attracted my attention since FDPro has supported Windows 7 since last year. As one of the primary authors of HBGary's commercial physical memory acquisition tool FDPro, I was interested to see how windd stacked up. As I have written and maintained the commerical verison of FDPro, I had a number of difficult hurdles to overcome. I was curious to see if others had solved these challenges yet. 

Specifically I was interested to see:

• Is windd acquiring all of the available physical memory on the system?
• Would a "raw format" image dump of a 64-bit vista machine load properly into HBGary's Responder?
• Should windd memory images that contain greater than 4GB of ram be considered admissible in court?
• Was windd really the first tool to support physical memory acquisition on Windows 7? (as claimed by the author)

In my evaluation I found the answer to all of these questions was "no". To be honest I wasn't completely surprised to see that many of these challenges had not yet been overcome. It has taken HBGary many, many hours of research and development in addition to a significant time investment performing rigorous QA to insure the accuracy and integrity of the RAM images acquired with FDPro. I guess this is why HBGary charges a hundred bucks for FDPro.

windd vs FDPro.exe bake-off

To evaluate windd versus FDPro I used each tool independently to acquire a "raw format" image on the same 6GB ram, Vista x64 bit machine. To start with I ran two windd images of the machine in question using the following command line options (as recommended in windd's usage):

1) win64dd.exe /m 0 /r /f c:\users\smb\desktop\WINDDx64.bin
and I also tried
2) win64dd.exe /c 2 /m 0 /r /f c:\users\smb\desktop\WINDDx642.bin

Both runs produced a set of output like this:
 
Finally I ran an FDPro.exe image of the same machine using the following command line:

1) FDpro.exe c:\users\smb\fdpro-x64.bin

A quick DIR of all 3 images reveals something quite troubling:
 
As you can see by comparing the two screens above, FDPro is the only tool that actually acquires the entire range of physical memory. It's not clear why the authors of windd decided not to capture the entire physical memory range.  It's clear that windd is aware of the full range of memory in use since the accurate acquisition size is printed in the output of every dump on the "Address space size" line. Returning to my initial set of questions, you can quickly see this failure to acquire all of the memory has severe trickle down effects:

A) Does windd.exe acquire all of the physical memory?

Answer:No it doesn't appear too. It is important to understand that physical memory is translated over the bus of the computer - it does not directly correlate to the RAM - in other words, if you have 4GB of ram, that DOESN'T mean you have memory addressable from 0-4GB. In fact, a 4GB machine will have 0-5GB addressable RAM, with a large section of that mapped into other devices that are attached to the bus.  All 4GB of RAM is represented in that 5GB range, but there is quite a bit more from other mapped devices.  In fact on my 6GB of ram machine, the full addressable physical memory is just over 7GB.  But, on my 6GB machine, the actual converted size of the windd captured image is only 5.99 GB.  This is a big problem for windd. windd is very likely missing over 1GB of actual RAM in my test machine.  Its theoretically possible that windd may be rebasing some of the higher memory in use down to a lower address - but if this is the case this would break any deep forensic memory analysis from occurring. You can't rebase the offsets of physical memory because you won't be able to accurately reconstruct/resolve the virtual memory to physical memory page mappings which is one of the first things done in any automated memory analysis

B) Would a "raw format" image dump of a 64-bit vista machine load properly into HBGary's Responder?

Answer:No it won't successfully load/analyze - This has to do with the fact that not all of the memory is acquired or its being improperly rebased away from its original zero-based physical memory offset.  A tremendous amount of critical kernel structures are located in high memory, the region which windd is not properly capturing.  While the rest of the image may be accurate, this missing data prevents reconstruction of the operating system state.  windd is not currently creating a true/valid RAW image because it's not a complete zero-based memory image. Loading a windd image into Responder was actually the first thing I tried to do since HBGary's responder already supports RAW, zero-based addressed dump formats for multiple external vendors.

C) Should windd memory images that contain greater than 4GB of ram be considered admissible in court?

Answer:Recommendation is no - not presently. Any physical memory image that is incomplete or remapped/modified could easily be thrown out in court. The fact that windd doesn't capture all of the physical memory on the system opens the door for a savvy defense attorney to speculate that perhaps there might have been something in the missing/non-acquired range that would have exonerated their client from whatever crime they're being accused of, and then it's all downhill from there.

D)  Was windd really the first tool to support physical memory acquisition on Windows 7? (as claimed by the author)

Answer:This was just personal - I take pride in my work and want to make it clear that windd was not the first. Besides the identified issues in this post, its noteworthy that the current shipping version of FDPro has supported acquisition Windows 7 since the OS was made available in a pre-release format from Microsoft. FDPro has been capable of acquiring full, accurate, greater than 4GB images of Windows 7 as of last year. NOTE: HBGary's Responder does not yet fully support the automatic analysis of Windows 7 which is why HBGary had elected to not publicly advertise Windows 7 acquisition support. Any timestamped copy of FDPro.exe from as long ago as last year can successfully acquire an accurate/complete image of both 32 and 64-bit Windows 7 systems.

While using HBGary's REcon technology, I discovered a potential new variant of the Agent.BTZ malware. As many know, the Agent.BTZ malware package hit the Pentagon last year. Multiple write-ups and assessments have already covered the internals of this package. Curiously though, not one person or organization has mentioned Agent.BTZ's additional capability of cross-launching the malware packages MSNET.exe (W32.Mockbot.A) and MSNET32.EXE (W32.Spybot.Worm) which are two separate, additional worm packages. Using REcon, I picked up a new relationship between Agent.BTZ and these other botnets.

First a little background on REcon... REcon is a new feature we are shipping with Responder PRO. Essentially, REcon is malware recording tool - it took us about 4 months of solid development work to bring REcon to market. A big thanks goes to the USAF and Wright Paterson AFB for supporting the development. REcon offers a very low level recording capability - something not possible with other malware recording solutions. REcon is not a debugger and doesn't use debugging API's, instead it operates entirely at the kernel level. Every control flow block can be traced along with data samples while a malware executes. Because so much is recorded, you can essentially re-play a malware's behavior post-execution. This recorded data has been integrated into Responder PRO in the form of a "track view" - the recorded data is split into tracks which can be managed individually. The runtraces can even be replayed onto the graph, like a live graph of the malware execution. Samples can be searched, both encrypted and decrypted buffers are captured, packets, filesystem calls, registry, etc. If the malware launches another secondary program, injects a DLL, or even writes code into the thread of another process, every step is tracked, every process and thread involved is traced.

(above) the track view showing recorded information (a few hundred thousand samples)

Agent.BTZ has been covered by other practitioners. The following blog post mentions 2 other files that Agent.BTZ attempts to launch when a thumbdrive or removable drive is inserted: http://blog.threatexpert.com/2008/11/agentbtz-threat-that-hit-pentagon.html

Quoted:

File mswmpdat.tlb The original thread will then attempt to start 2 processes: tapi32d.exe and typecli.exe – these attempts are logged. Whenever Agent.btz detects a newly connected removable disk, it will also log the device details into the same log file %system%\mswmpdat.tlb. The contents of this log file is encrypted the same way – here is the decrypted fragment of it:

18:44:45 29.11.2008 Log begin:

18:44:45 Creating ps C:\WINDOWS\system32\tapi32d.exe (2)

18:44:45 Creating ps C:\WINDOWS\system32\typecli.exe (2)

18:44:45 Log end.

19:02:48 29.11.2008

Log begin: 19:02:49 Media arrived: "D:" Label:""" FS:FAT SN:00000000

19:02:49 Log end.

It is not clear what these 2 files are: tapi32d.exe and typecli.exe - the analyzed code does not create them. It is possible however that the missing link is in the unknown code it injects into Internet Explorer which can potentially download those files.

End Quote

What is interesting is that REcon picked up some new cross-malware relationships that haven't been publicly researched (to the best of my knowledge). While recording Agent.BTZ's behavior for 10 minutes, HBGary's Recon.exe discovered a 3rd and 4th malware package that Agent.BTZ attempts to launch by the name of “msnet.exe” and "msnet32.exe". A quick search on google reveals msnet.exe is the W32.Mockbot.A worm, and msnet32.exe is identified as W32.Spybot.Worm

W32.Mockbot.A details can be found here: http://www.symantec.com/security_response/writeup.jsp?docid=2004-022608-5242-99&tabid=2

W32.Spybot.Worm details can be found here: http://www.symantec.com/security_response/writeup.jsp?docid=2003-053013-5943-99

(above) Responder viewing the 10 ReconBTZ.fbj journal file - Recorded in under 10 minutes

(above) Agent.BTZ wsprintfing process launch log data into its encrypted logfile

(above) The Actual sampled calls to CreateProcessA() that attempt to spawn the additional malware packages

Coupled with VMWare on your laptop, REcon is a powerful tool to take into the field - it answers so many questions and almost eliminates the need for code-level RE work.