Forensics Blogs/Podcasts

Does anyone know of any other purely forensics blogs and/or podcasts out there? I know that there're several neat, not-specifically-forensics sites, but I'm looking for just forensics; hardware or software, Windows, Mac, Linux, Atari, Commodore...anything specifically related to computer forensics.

Updates - Code and such

I updated some code recently and thought I'd post a quick note about it...

First off, if you're using kern.pl from the OS Detection package on my SF.net site, I've updated the code to actually tell you which OS is running. The output is a little cleaner, and provides arguments so you can get a verbose output if you need it. Also, the script has been renamed to "osid.pl", replacing kern.pl.

In the simplest form, you simply pass the name of the RAM dump file to the script, and get the output:

C:\memory>osid.pl d:\hacking\boomer-win2003.img
2003

Or, you could use the arguments (use '-h' to see the syntax info) to get more info:

C:\memory>osid.pl -f d:\hacking\boomer-win2003.img -v
OS : 2003
Product : Microsoft« Windows« Operating System ver 5.2.3790.0

I posted yesterday about the updates to the disk documenting script, which I thought was pretty neat. Thanks again to Jon Evans for pointing out the Win23_PhysicalMedia class for getting the serial number. My thought is that something like this is extremely useful, and easy to use (i.e., just cut-and-paste the output into your acquisition worksheet after you've imaged a drive). The "Signature" helps you tie the drive to the image because that's the same value listed in the first DWORD of some of the MountedDevices entries.

Shifting gears, the e-Evidence site was updated yesterday. Every month, Christine puts up new stuff and it's great to see what's out there. For example, I wonder how many folks have taken the time to reflect on their first incident the way Brian did. Also, check out the presentation about the anatomy of a hard drive. There's always some interesting stuff on this site.

Documenting Disk Information

One of the things that computer forensics nerds (present company included, of course) need to do a lot of is documentation...something they, uh, I mean "we" are notoriously bad at. Come on, face it, most nerds don't like to document what they do...it just gets in the way of doing the fun stuff.

What about documenting information about disks you image? You know...hook up a write-blocker, fire up the acquisition software...what about documenting the disk information for your acquisition worksheet, or your chain-of-custody forms?

One way to do this is with DiskID. Another way is to use WMI. By correlating data from the Win32_DiskDrive, Win32_DiskPartition, and (thanks to Jon Evans for pointing this one out) Win32_PhysicalMedia, you can get the same info as with other tools (on Windows). For example, correlating the data from the three Win32 classes mentioned give me the following - first, for my local hard drive:

DeviceID : \\.\PHYSICALDRIVE0
Model : ST910021AS
Interface : IDE
Media : Fixed hard disk media
Capabilities :
Random Access
Supports Writing
Signature : 0x41ab2316
Serial No : 3MH0B9G3

\\.\PHYSICALDRIVE0 Partition Info :
Disk #0, Partition #0
Installable File System
Bootable
Boot Partition
Primary Partition

Disk #0, Partition #1
Extended w/Extended Int 13

Then for a USB thumb drive (gelded of the U3 utilities):

DeviceID : \\.\PHYSICALDRIVE2
Model : Best Buy Geek Squad U3 USB Device
Interface : USB
Media : Removable media other than floppy
Capabilities :
Random Access
Supports Writing
Supports Removable Media
Signature : 0x0
Serial No :

\\.\PHYSICALDRIVE2 Partition Info :
Disk #2, Partition #0
Win95 w/Extended Int 13
Bootable
Boot Partition
Primary Partition

See? Pretty cool. In some cases, you won't get a serial number, but for the ones I tested, I wasn't able to get a serial number via DiskID32, either.

Now, the cool thing is the "Signature". This is the DWORD value located at offset 0x1b8 in the MBR of a hard drive, and appears in the MountedDevices key entry for that drive (the data entry should be 12 bytes in length).

Using the Win32_LogicalDrive class, you can get the following:

Drive Type File System Path Free Space
----- ----- ----------- ----- ----------
C:\ Fixed NTFS 21.52 GB
D:\ Fixed NTFS 41.99 GB
E:\ CD-ROM 0.00
F:\ Removable FAT 846.70 MB
G:\ Fixed NTFS 46.91 GB

Not bad, eh? And the cool thing is that not only can these tools (which were written in Perl and can be 'compiled' using Perl2Exe) be used with the FSP, but they can also be used by administrators to query systems remotely.

Addendum, 3 Nov: I hooked up an old HDD to a write blocker today and ran the tools against it...here's what I got from di.pl:

DeviceID : \\.\PHYSICALDRIVE1
Model : Tableau FireWire-to-IDE IEEE 1394 SBP2 Device
Interface : 1394
Media : Fixed hard disk media
Capabilities :
Random Access
Supports Writing
Signature : 0x210f210e
Serial No : 01cc0e00003105e0

\\.\PHYSICALDRIVE1 Partition Info :
Disk #1, Partition #0
Installable File System
Primary Partition

I verified the signature by previewing the drive in ProDiscover, and locating the DWORD at offset 0x1b8...it checked out. The Windows Device Manager shows the Tableau write-blocker to be the HDD controller.

Here's what I got from ldi.pl:

F:\ Fixed NTFS 9.39 GB

The Disk Manager also reports an NTFS partition on the drive. Still looks pretty useful to me. DiskID32 reported some weird info, probably due to the write-blocker.

New Today

New Perl module on CPAN

I received an email this morning that directed me to a "new" Perl module called Parse::Win32Registry. From the description, the module allows you to read the keys and values of a registry file without going through the Windows API. Very cool! This goes a step or two beyond my own Perl code for doing this, as it uses an Object Oriented approach (it also covers the Win95 Registry files, as well).

Even though this one isn't up on the ActiveState site yet, it looks like a great option, and will be extremely useful. The install went really easy for me...I downloaded the .tar.gz file, extracted everything, and just copied the contents of the \lib directory into my C:\Perl\site\lib directory. From there, I began running tests with the sample file, and things went really well.

Some of you are probably looking at this thinking, "yeah...whatever." Well, something like this can make parsing through Registry files to get all sorts of data much, much easier. I can also see this being used to parse through the Registry files in XP's System Restore points much easier, even to the point of running 'diffs'.

New CyberSpeak show
Brett's got a new CyberSpeak podcast out...it's a short one this time, folks. Brett mentioned feedback and encouragement in the show - I don't know what kind of feedback he and Ovie get, but like everyone else, I can see the comments on the LibSyn site. These guys are putting forth a great effort, and it can't be easy to parse out the kind of time it takes every week to put the show together. I tend to wonder if the show could be used as a focal point to a sort of extended e-zine for the community. I've thought before about how useful a digital forensics e-zine would be...something practical, useful, hands-on...not at an academic level, but more on the level of "here's what you can do, and here's how you do it". Since there's a wide range of subjects out there (I'm interested in Windows systems, Brett mentioned Macs in today's show...) I don't think that it would be too hard to put something together each week...folks sending in links to articles, etc. Using the LibSyn site, or some other site (like what the Hak5 guys do with their show notes in a Wiki format), a neat little e-zine can be put together each week/month, with lots of folks contributing. Just a thought...

Desktop Capture Software
Oh, and if anyone has any input or thoughts on some good, free desktop capture software, drop me a line. I want to capture my desktop while I speak into the mic on my laptop, so I can record HOW-TOs for my next book. I think that following along visually is better for some folks (and probably much more interesting) that reading a bunch of steps. Right now, I'm considering WebEx Recorder, but would like to get some input on other options. The requirements are simple...good quality output (with regards to video and audio), and the recorder and player should both be freely available. I know that the IronGeek uses CamStudio...anyone have any thoughts or input on that?

It Bears Repeating

There are just somethings that you can't say often enough. For example, tell the ones you love that you love them. Also, tell them that when they suspect an incident, do NOT shut the system off!

Think of Brad Pitt and Ed Norton (no, not that way!!) in Fight Club, but paraphrase..."the first rule of incident response is...don't panic. The second rule of incident response is...DO NOT PANIC!!"

Okay, let's go back to the beginning...well, maybe not that far. Let's go back to an InformationWeek article published in Aug, 2006, in which Kevin Mandia was quoted...here's one interesting quote:

One of the worst things users can do if they think their systems have been compromised by a hacker is to shut off their PCs, because doing so prevents an investigator from analyzing the contents of the machine's RAM, which often contains useful forensic evidence, Mandia said.

So, what do you think? Is he right? Don't say, "well, yeah, he must be...he's Kevin Mandia!" Think about it. While you're doing that, let me give you a scenario...you're an admin, and you detect anomalous traffic on your network. First, you see entries in firewall or IDS logs. You may even turn on a sniffer to capture network traffic information. So let's say that at that point, you determine that a specific system is connecting to a server on the Internet on an extremely high port, and the traffic appears to be IRC traffic. What do you do? More importantly, what do you want to know?

The usual scenario continues like this...the system is taken offline and shutdown, and stored in an office someplace. An outside third party may be contacted to provide assistance. At this point, once the incident is reported to management, the questions become...what is our risk or exposure? Was sensitive information taken? Were other machines affected? If so, how many?

This is where panic ensues, because not only do most organizations not know the answers to the questions, but they don't know how to get the answers themselves, either. Here's another quote from the article:

...Mandia said rumors of a kernel level rootkits always arise within the company that's being analyzed.

You'll see this in the public lists a lot..."I don't know what this issue is, and I really haven't done any sort of investigation...it's just easier to assume that it's a rootkit, because at the very least, that says the attacker is a lot smarter than me." Just the term rootkit implies a certain sexiness to the incident, doesn't it? After all, it implies that you've got something someone else wants, and an incredibly sophisticated attacker, a cyberninja, is coming after you. In some cases, it ends up being just a rumor.

The point of all this is that many times, the questions that management has about an incident cannot be answered, at least not definitively, if the first step is to shut down the system. At the very least, if you have detected anomalous traffic on your network, and traced it back to a specific system, rather than shutting the system off, take that additional step to collect process and process-to-port mapping info (for a list of tools, see chapter 5 of my first book) from the system. That way, you've closed the loop...you've not only tied the traffic to a system, but you've also tied it to a specific process on the system.

Of course, if you're going to go that far, you might was well use something like the Forensic Server Project to gather even more information.

Windows Memory Updates

Andreas recently released a new tool called poolgrep.pl. This lets you run searches across memory pools, looking for things such as timestamps, IP addresses, etc. You need to start by using poolfinder.pl to develop an index, and from there you can search through various pools for specific items.

This is definitely a start in the right direction. As Andreas has pointed out, the pool header contains a size value, so we know how many bytes the pool occupies. He has also shown that some pool contents can reveal network connections. From here, IMHO, we should focus on "interesting" pooltags, and attempt to understand their structure. Once we do, then this can be added to tools such as poolfinder.pl, and the data parsed and presented accordingly. In addition to network connections, for example, the contents of the clipboard (pool tag = Uscb) may be interesting, as well. MS provides a listing of pooltags in the pooltags.txt file that's part of the Debugger Tools. You can see an online version of the file here.

Also, there's been an update to the SANS ISC Malware Analysis: Tools of the Trade toolkit listing...and it looks like I'd better get cracking on finishing up the tools I've been putting together to address not just Windows 2000 RAM dumps! ;-)

ForensicZone.com

For those who haven't seen it, you should check out ForensicZone.com, home of PTFinderFE and SSDeepFE. There's also a number of links on the site to cell phone stuff, particularly for forensics. Very cool stuff.

Vista, RAM dumps, and OS detection (oh, my!!)

I received an email from Andreas today, and one of the things he mentioned is that the offset for the Vista kernel in memory is 0x81800000...this could be added to my os detection script. So I made the change to my script and ran it against a memory dump that I had from a Vista machine. Nothing. Nada. No impact, no idea. I opened up the memory dump in UltraEdit and saw that there was nothing at the offset...well, at least no PE header.

I then fired up my Vista RC1 VMWare session, and ran LiveKD to see what it reported the kernel base address as (0x81800000), and then I suspended the session. I opened up the resulting .vmem file and ran the script against it...and saw the following:

File Description : NT Kernel & System
File Version : 6.0.5600.16384 (vista_rc1.060829-2230)
Internal Name : ntkrpamp.exe
Original File Name :
Product Name : Microsoft« Windows« Operating System
Product Version : 6.0.5600.16384
File Description : Boot Man╕╝ ç(╝ ç
File Version : 6.0.5600.16384╜ çp╝ çsta_rc1.060829-2230)
Internal Name :
Original File Name :
Product Name : Microsoft« Winh╛ ç╪╜ ç« Operating System
Product Version :

Very cool. To make this change yourself, just add '0x81800000 => "VistaRC1"' to the %kb hash.

Addendum 24 Oct: Sent by Andreas, and confirmed this morning...add '0x82000000 => "VistaBeta2"' (remove outer single quotes) to the %kb hash in kern.pl.

Pool tag finder

Andreas released his poolfinder tool the other day, a Perl script for locating pool tags in a memory dump. This script accompanies a paper he wrote for IMF 2006 (here's his paper from DFRWS 2006).

So, what's a pool tag, and why is it important? According to Andreas, the kernel allocates what's referred to as a "pool" of memory, so that if an application requests some memory that is less than a 4K page, rather than wasting all of that space, only what is required will be allocated. The pool tag header is a way of keeping track of this pool.

The pool header specifies the size of the pool, but there isn't any publicly available method for parsing that pool into something usable. I've used this technique to locate the contents of the Clipboard in the DFRWS 2005 memory challenge dumps, and Andreas has used this to locate network socket activity. Perhaps someone with experience in developing drivers for Windows can assist in developing a methodology for revealing the format of the various structures.

Additional Resources:
Who's using the pool?
How to use PoolMon.exe

Addendum, 23 Oct: I've made some comments to Andreas's blog, and we've gone back and forth a bit. What I'd like to try to do is identify various pool tags that are of interest to forensic examiners (ie, TCPA for network connections, clipboard, etc.). Thanks to Andreas's work, finding the pool tags and their sizes is relatively easy...deciphering them into something readable is something else entirely.

Restore Point Forensics

I was doing some digging around the other day, researching System Restore points in XP...they're only in XP (and ME, but we're only concerned with the NT-style Windows OSs), and not something you'll find in 2000 or 2003.

So, what is "System Restore"? SR is a function of XP that creates "restore points" or limited backups of certain important files, depending upon certain triggers. For example, by default, a restore point will be created every calendar day. Also, restore points are created whenever the user installs software. This, of course, means that you could technically have multiple restore points created during a single day. Restore points can be used in case something goes wrong with the installation and the system is affected...the user can select a previous restore point, and "roll back" the system to that point. This is a very cool thing, and I've used it more than once myself. Keep in mind, though, restore points do not affect certain things, such as login passwords or a user's data, so don't be afraid to select a restore point from 3 days ago because you think you might loose that spreadsheet you built yesterday.

So what do restore points mean to us? Well, they're full of a wealth of information about the system. I've presented on the topic of "the Registry as a logfile" in the past, and this is a great example of that. Important files are backed up, but so are portions of the Registry, such as the System and Software files, the user's profile(s), and portions of the SAM. These Registry files have keys in them, and the keys have LastWrite times.

Where do these come into play? I've seen several questions in some of the lists lately, asking about things like "was this user account on the system", or "did the user change their name", as well as other questions where, on the face, would best be answered if there were some way to take a glimpse into the past. Restore points let you do that.

The structure of the restore points is pretty simple. On the root of the system drive, you'll find a "System Volume Information" directory, and beneath that a directory named "_restore{GUID}". Beneath that, you'll have numbered restore points...RP35, RP36, RP37, etc. You get the idea. Within each of these "RP**" directories, you'll have some backed up files (depends on the nature of the restore point), and a file called 'rp.log'. This is a binary file that contains the description string (null terminated string starting at offset 0x10) for the restore point, as well as the FILETIME object of when it was created (QWORD starting at offset 0x210). Finally, there is a snapshot directory holding all of the Registry file backups.

If you're interested in peering into these restore points, but don't have an image available, you can look at them on your own XP system. One way to get some information is through WMI. Using the SystemRestore and SystemRestoreConfig objects, you can get information about each restore point, as well as configuration settings about the System Restore, respectively. I wrote a Perl script to do this...here's an excerpt of what I got on my system:

64 13:28:07 09/27/2006 Installed Windows Live Messenger
65 15:07:48 09/28/2006 System Checkpoint
.
.
.
73 12:45:41 10/09/2006 System Checkpoint
74 14:03:53 10/09/2006 Installed QuickTime
75 19:25:09 10/09/2006 Installed Microsoft .NET Framework 1.1
76 20:21:54 10/10/2006 System Checkpoint
77 20:52:59 10/11/2006 System Checkpoint
78 22:00:48 10/12/2006 System Checkpoint
79 22:20:18 10/12/2006 Installed Windows Media Player 11
80 22:20:41 10/12/2006 Installed Windows XP Wudf01000.
81 10:45:08 10/14/2006 Software Distribution Service 2.0
82 12:35:54 10/18/2006 System Checkpoint
83 18:29:09 10/19/2006 System Checkpoint
84 20:38:49 10/19/2006 Removed ProDiscover IR 4.8a
85 20:43:48 10/19/2006 Installed ProDiscover IR 4.84

Kind of cool. This gives me something of a view of the activity of the system, not only when it was online, but also what was going on. Notice that on 19 Oct, three restore points were created. Not only was the normal System Checkpoint created, but there was a software removal and an installation. This script is very useful, not only for incident response (include it with the FRU and FSP), but also for general system administration. It works remotely as well as locally, and gives the admin some good visibility into the system.

The other interesting thing about this is the order of the restore points. Notice that as the restore point indexes increase, so do the timestamps. If I were to have modified my system time several days ago, things might not appear to be in order...so this is a good little sanity check to see if maybe the system time was modified. It's not definitive, mind you, but a good check.

If you just want to take a look around, go to SysInternals and get a copy of psexec. Once it's on your system, type:

psexec -s cmd

and a command prompt will open, but you'll have SYSTEM level privileges. Then type:

cd \Sys*
cd _restor*

Now, select one of the restore points and cd to that directory, then to the snapshot directory. If you do a 'dir' at this point, you'll see all of the various Registry files that are backed up, each one beginning with "_REGISTRY_MACHINE_*". At this point, you can copy any of these files out to a "normal" directory, and either open the file in a hex editor, or run it through the Offline Registry Parser and see the contents in ASCII. I tried this and dumped out one of the SAM files I found, and saw that I could see the C values that hold group membership information, as well as the F and V values for user's account information. One of the things I've got in the works is a set of scripts that will parse through these files (and the "normal" Registry files), reporting on what it finds...but in a way that's readable to an investigator. So, rather than spewing out binary data for the F and V values for a user account, translate that into something readable, like my UserDump ProScript. Something like this could be used to 'diff' the various files from restore points.

I've developed a ProDiscover ProScript for sorting through the restore points on an XP system, and I'll make it available when the next version is released.

Additional Resources:
Steve Bunting's site (he uses EnCase)
Bobbie Harder's site (links to KB articles)
Windows XP System Restore
Wang's Blog (tells you how to open the RP** Registry files in RegEdit)
Restore Point Log Format

New HaxDoor variant

I picked this one up from the Securiteam blog this evening...it seems there's a new HaxDoor variant out. Symantec's technical write-up contains a lot of detail (useful to forensic analysts...the guys on the FIRST list should take note), and even though they do classify this one as a "backdoor", they do actually use the word "rootkit". For further reading:

• Trend Micro
• Sophos (probably the least useful)
  
• McAfee (click on "Symptoms")

This variant captures keystrokes, steals passwords, allows the attacker to download files, in addition to hiding itself, installing itself as a service, attempting to disable the Windows Security Center, and maintaining additional persistence by adding an entry to the following Registry key:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\Notify\

Here's some info from MS on that Winlogon\Notify entry.

One thing I think that's needed is an understanding of how clear, detailed write-ups on things like this are important to the IR/CF community. This sort of thing is very helpful when you're trying to ascertain the sophistication of an intrusion, and perhaps even develop some next steps. Remember, things such as NTFS ADSs and esoteric Registry key entries may be ho-hum boring to a lot of folks, but they're all pieces of the puzzle if you're doing IR/CF.

If you think you may have a rootkit, check out one of these tools.

PTFinder Front End

Andreas posted this on his blog, and I took a look at it...very cool. This is a front-end for running PTFinder, and even allows you to choose which operating system you want to run it against. This makes things a little easier to use.

If you have a RAM dump and don't remember which OS it is, as long as it's between Win2k and Win2K3SP1, you can use my OS detection script.

The neat thing is that you can get output that looks like this. Very cool!

Are you a Spider man?

I found an announcement on another list today for Spider, a tool from Cornell University for locating sensitive personal information (SSN, credit card numbers, etc.) on a system.

I'm told that the intended use is to run it against the system after you've acquired an image, which makes sense. Either image the system live, and then run the tool on the rebooted system, or remove the hard drive, image it, replace it, boot it, and then run the tool. I wouldn't recommend it as an initial step in IR, as it will change the MAC times on all of the files, but it is a great idea for IT admins. Many times during an engagement, one of the questions that will be asked is, "Is/was there any sensitive data on the system, and if so, was it accessed/copied?" Well, IT admins can run a tool like this as part of their SOP...after all, if an incident does occur, you're going to be asking that question anyway, right?

Also, through in something like LiveView, particularly if all you have is an image. Boot the image, and run Spider against it. Unfortunately, you're going to have to install .Net on the booted image, but VMWare is great with snapshots.

So, for the Windows version, you need to install the .Net framework first. Note that the documentation for downloading and installing Spider refers to the install file as "spider_nsis.exe", and the Windows version (2.19a) comes as 'setup.exe'. The configuration of the tool is a bit outside the 'norm'...you don't just launch Spider from the command line with switches.

Interesting capabilities include the ability to add regex's, scanning of ADSs, and logging to the Event Log or to syslog.

A great tool, but I really see it being more of an IT admin's SOP than a response tool, 'though it does have it's uses. Keep in mind that the documentation states that you can have a high incident of false positives, but that's the case even with regex searches in EnCase, and just something you have to deal with for now.

Parsing Registry files

Last week, I mentioned making adaptations to a tool to perform specific tasks. Specifically, adapting the Offline Registry Parser so that instead of dumping all of the stuff in a Registry file, dump specific keys, values and their data, and translate that data into something human-readable (and parsable), rather than simply spewing it to STDOUT.

Where I thought this might be useful is with the SAM file, to start. Run through the file and pull out all of the user information, group membership info, and even the audit policy (translated into something similar to auditpol.exe's output). A side benefit of this is that you could run it against the current SAM file, as well as any located in System Restore points, and get a rough timeline of when changes occurred.

This could also be done for the NTUSER.DAT files.

Another benefit of this is data reduction. Rather than dumping the entire contents of the Software hive, you could extract only those keys, values, and data that you would most usually be interested. From there, you'd have less to analyze, and still have the original data.

Innovation

This post is likely to be the first of several, as it's something I've been thinking about for quite a while, and it takes new form and shape every time it pops into my head. So...please bear with me...

We see all the time that cybercrime is increasing in sophistication. We see this in reports and surveys, as well as in quotes. From this, we can assume (correctly) that there is a widening gap in abilities and resources between those committing the crimes, and those investigating the crimes. This gap is created when innovation occurs on one side of the equation, and not on the other.

I guess we need to start with the question, is there a need for innovation in the field of incident response (IR), and consequently computer forensic (CF) analysis?

I know that this is going to open up a whole can of worms, because not everyone who reads this is going to interpret it the same way. Even though I get this question running around inside my brain housing group from time to time, I don't think I really have a solid grasp of the concept yet. I see things and I think to myself, "Hey, we could really use some innovation here", or as in the case of Jesse Kornblum's ssdeep, "Hey, THAT'S an innovation!!"

I know what isn't an innovation, though...hash lists are not an innovation. Not any more. Sorry. 'nuff said.

Let's look at it this way...right now, Windows systems are being investigated all the time. I'm on several public and member-only forums, so I see the questions...some of the same ones appear all the time. There are just some things that folks don't know about yet, or don't have a clear understanding of, and simply don't have the time to research it themselves. From a more general perspective, there are areas of a Windows system that are not investigated on a wide basis, simply due to lack of understanding (of what data is available and how it could affect the investigation). I firmly believe that if there were more of an understanding and more knowledge of these areas, some investigations reap significant benefits.

So, is the innovation need in the area of knowledge, communication, or both?

Vista is bringing about innovations in technology. Un- or under-documented file formats require application-specific innovations (and these include Registry entries, not just binary format).

See what I mean? It's kind of hard to put your finger on, even though it's there...just outside your direct line of vision, like trying to see someone at a distance, at night. On the one hand, cybercrime has a motivation to innovate...money. Innovations are made out of necessity. But what about other cases or issues, such as missing childern? Business innovations in technology and applications (MySpace, Xanga, IM applications, etc.) just naturally require innovations in the areas of understanding, investigations, and subsequently communications. Outside innovations in storage media have led to different (albiet, not new) means of committing information theft and fraud.

Thoughts?

d00d, you can do it on Windows, too!

Jesse Kornblum had a couple of interesting posts recently on his blog, both relating to ssdeep. Yes, Jesse, I found the ssdeep stuff to be more interesting than the cat stuff. Sorry! One post was about using ssdeep to discover code re-use by comparing files in directories, and the other one was about using ssdeep to tie a portion of a file to the original. Very cool stuff.

I've gotta say that ssdeep is one of the true innovations in incident response and computer forensics. This isn't a new/different implementation of something that's already there...this is truly something new.

VMWare Converter (beta)

I received an email this morning that mentioned the release of VMWare's Converter tool, which is still in beta. Clicking on the "Registry Now" button lets you register for the beta.

The Converter is a tool that allows you to convert between formats. From the web page:

• Supports cloning a wide variety of Windows OS platforms including Windows XP, Windows Server 2003, Windows 2000, Windows NT 4 (SP4 +) and 64-bit Windows Support (Windows XP and Windows Server 2003).
• Supports conversion of standalone VMware virtual machine disk formats (VMware Player, VMware Workstation, VMware GSX Server and VMware Server) across all VMware virtual machine platforms (including ESX 3.0 server and VC 2.0 managed servers as target host).
• Supports conversion of 3rd party disk image formats such as Microsoft Virtual PC, Microsoft Virtual Server, Symantec Backup Exec System Recovery (formerly LiveState Recovery) and Norton Ghost9 (or higher) to VMware virtual machine disk format.

Pretty cool. Looks like additional functionality to what you get from LiveView. BTW, the latest CyberSpeak podcast has an interview of the author of LiveView.

Rootkits revisted

I was browsing the F-Secure blog this morning and found something interesting...from last Friday, there was this post about reselling stolen information. Now, this is nothing new...this is just part of how organized online crime is becoming. Rather than one person doing everything, someone will purchase malware and use it to infect systems, then collect the data from Protected Storage, keystroke loggers, etc. This information is then sold to others for use...in fraud, identity theft, etc.

For a good example of this, take a look at Brian Krebs' story from 19 Feb 06.

What I thought was most interesting about the F-Secure blog entry was this:

These changing Haxdoor variants are generated with a toolkit known as "A-311 Death".

The toolkit itself is sold on the Internet by its author, known as "Corpse" or "Korpsov".

Okay, this is nothing new, either. Selling malware toolkits or custom rootkits is nothing new, either. This toolkit is based on Haxdoor. I started taking a look around and I found some interesting links. One was from the nmap-dev list...it's a discussion of a service detection signature for rootkits produced from this toolkit.

My post on Gromozon has some links to rootkit detection software.

Additional Resources:
AusCERT
McAfee Rootkits: The Growing Threat paper
Symantec C variant, D variant

FSP/FRU File Copy Client posted

I posted the File Copy Client (FCli) that was mentioned in Windows Forensics and Incident Recovery. After getting enough questions about it, I thought that it was about time that I uploaded it to the SourceForge site.

The FCli is a GUI client that the investigator can use to select files to be copied from the 'victim' system, over to the FSP server. Here's how you use it (I am going to create webinar/movie files for this stuff for the book)...download the archive from the SF site, and keep all of the files (EXE and associated DLLs) together in the same directory. For initial testing, you may want to have them separate from other tools and files. Launch FCli, and choose File -> Config...enter the IP address and port of the FSP server. Then choose File -> Open and use the dialog to select the files that you want to copy (web server log files, etc.). Once you've selected the files that you want, click OK to close the dialog and the file names will be added to the FCli ListView (you can go back and open the File -> Open dialog again, if you wish).

Once you have selected the files you want to copy, click "OK" in the main FCli window. The status bar on the bottom of the window will show you your progress...it may go fairly quickly. Once all the files are copied over, simply close the window.

What FCli does is first collect metadata about the file...size, MAC times, and MD5/SHA-1 hashes. This data is sent to the FSP server and archived. The file itself is then copied over to the server, at which point the server verifies the hashes. Here's an extract from the case log file:

Mon Oct 2 21:26:14 2006;DATA command received: bho2.dat
Mon Oct 2 21:26:14 2006;HASH bho2.dat:885f60ff031496a3fe37aa15454c6a46:bf402abbbe76e417105d18ad9193436315dd7343
Mon Oct 2 21:26:14 2006;FILE command received: bho2.pl
Mon Oct 2 21:26:14 2006;bho2.pl created and opened.
Mon Oct 2 21:26:14 2006;bho2.pl closed. Size 1522
Mon Oct 2 21:26:14 2006;MD5 hashes confirmed for bho2.pl.
Mon Oct 2 21:26:14 2006;SHA-1 hashes confirmed for bho2.pl.

First, the metadata is sent to the server and saved in a file with the .dat extension (next version needs to change this, in case of a conflict with a file with a .dat extension), and the hashes are pulled out of the file and logged. Then the file is copied over and the size of the file on the server, after it's been written, is logged (you can verify this later with the size recorded in the metadata). Then the file hashes are computed for the file that is now on the server, and confirmed against the metadata.

The archive you want from the SF site is fcli_20061003.zip. This archive contains the executable file and all supporting DLLs, as well as the Perl source code for the FCli.

Thanks, and enjoy!

Addendum: It seems that WinRAR-compressed files don't always play well with other compression utilities, so I updated the archive and uploaded it...look for fcli_20061003a.zip

E-Evidence.info site updated

The E-Evidence site was updated earlier today...as always, lots of interesting stuff! Thanks, Christine!

When did a user's access change?

I saw a question today on the Windows Forensic Analysis group on Yahoo that I thought was definitely worth repeating here. One of the members said that he was investigation a situation in which a limited helpdesk account was found to have Administrator-level rights on a system; his question was, how could he go about determining when the access level had changed.

Well, he never mentioned the version of Windows he was faced with, but if he were working with Windows XP or above, he could make use of the System Restore Points to answer that question.

How? Well, I wrote a ProScript to use with ProDiscover that parses through the SAM file of the Registry to extract things such as user information, and group membership information. Andreas posted some really good info on the specifics of parsing the Registry values, so I won't repeat it here. So...the ProScript works with the regular Registry files, but what to do about the Registry files located in the Restore points? Well, that's where the Offline Registry Parser comes in. By adapting regp.pl (from the SourceForge site) to include some code from my ProScript, one can then go back and parse through each of the SAM files in the Restore Points, until you find a point where the helpdesk account is no longer included in the Administrators account. Note that this will only work for accounts local on the system.

Not sure about the scripting but have a need for a tool that does something like this? Regp.pl will parse through the SAM file, dumping it all out to ASCII text, but it currently does not translate the specific values, particularly those that are REG_BINARY or REG_NONE types. However, a modicum of modification is all that's necessary to dump a report of just the information you want from that file. If this is something you'd be interested in, let me know, and maybe we can discuss some custom Perl coding. Need an EXE instead of a script? I can help with that, too.

New issue of the IJDE

The lastest edition of the International Journal of Digital Evidence (IJDE) is out, and the most interesting article (for me, anyway) is Jesse Kornblum's Exploiting the Rootkit Paradox with Windows Memory Analysis.
In the paper, Jesse makes some very simple, yet very important points that most folks probably don't think about when they're doing IR and decide that they've been infected with a rootkit; in particular, that rootkits want to remain hidden, and want to run.

Very interesting, and well worth the time it takes to read it. Enjoy!

Something old, something new...with USB

It really amazes me sometimes how a journalist "covering the security scene" will wake up one day and come to the relevation that something is "new". The thing is that most kids in junior high school today know enough about how to use Google to find out that these things really aren't all that "new". Ugh. Maybe now that we've redefined "is", we have to work our way through the dictionary and redefine "new", as well.

Case in point...this ComputerWorld article. Take a look at this excerpt from the first paragraph:

Now, the emergence of USB flash drives that can store and automatically run applications straight off the device could soon make the drives even more of a security headache.

Yeah, okay, this is essentially a true statement...and there's more to it. It's that extra bit of informaiton that needs to be understood to effectively address this threat.

The ComputerWorld article makes repeated references to Hak.5, a video podcast version of MAKE. It's not a podcast I've seen before, but it does look pretty interesting. Anyway, the article refers to something called "Switchblade", described in the episode Wiki as "a custom USB key that will retrieve vital information from a target computer, necessary for auditing password strength".

Okay, so what's really going on here? Well, the issue is the use of the U3-enabled thumb drives. In a nutshell, the U3 utilities create a small CDFS partition at the beginning of the thumb drive, with the intention of providing the user with mobility...anyone owning a U3-enabled thumb drive can take their desktop (well, a limited desktop) anywhere with them, and plug the thumb drive into any workstation and use their applications. Nice, convenient...and a security nightmare.

Like I said, the core issue is the CDFS partition and how Windows systems treat these partitions. Windows has an autorun feature that allows for the "load=" and "run=" lines from autorun.inf files located in the root of the partition to be parsed and executed, but only for certain types of media. Removable (ie, USB) drives don't allow this by default, but CDs and DVDs do. The default value for the NoDriveTypeAutoRun key is 0x95, which means that CD-Rom drives allow the functionality by default.

For more information, MS KB article Q155217 describes how to disable this functionality for CD-Rom drives. Additional information about the Cdrom\AutoRun key is here, and there's an explanation of the AutoRunAlwaysDisable key here. Also, from MS's USB FAQ:

Q: What must I do to trigger Autorun on my USB storage device?
The Autorun capabilities are restricted to CD-ROM drives and fixed disk drives. If you need to make a USB storage device perform Autorun, the device must not be marked as a removable media device and the device must contain an Autorun.inf file and a startup application.

The U3 utility essentially marks a portion of the device as a CDFS partition (...must not be marked as a removable media device...). Please note...regardless of what one thinks it should be, "removable media" != "CD-Rom")

For myself, I purchased a Geek Squad 1GB USB thumb drive when I saw them on sale at Best Buy a while ago. I was shocked when I plugged the device in...not only did I not get 1GB of removable storage, but I also got a bunch of applications...this isn't what I wanted! Digging around the Registry in the USBStor key, I found two entries:

CdRom&Ven_Best_Buy&Prod_Geek_Squad_U3&Rev_6.15

and

Disk&Ven_Best_Buy&Prod_Geek_Squad_U3&Rev_6.15

Hhhmmm...two almost identical entries for the same device, both under the Enum\USBStor key. Beneath both entries, the serial number for the USB device was the same. So we've now got a way of detecting the use of such devices within the infrastructure. For information on tracking USB removable storage devices across Windows systems, check out my GMU2006 presentation slides.

You can go here to download a utility to remove that pesky U3 partition, or just go to U3's Launchpad Removal site.

Okay, so why isn't this 'new'? Back in June, DarkReading had an interesting article on the same subject, from a social engineering perspective. Also, there's a Hacking U3 site that discusses creating your own custom ISO to replace the utilities loaded (scroll down to "The Sting" section).

Finally (as if that weren't enough), there's a nasty little utility called USBDumper that is installed on a PC and silently dumps all files from any USB removable storage device that's plugged into the system. Wow! Copying files is one thing...how about automatically imaging the device and recovering deleted files?!

A brief word on Windows Event Logs: it seems that Windows 2000 will report when USB removable storage devices are plugged into and removed from a system. Event ID 134 would be generated (source = Removable Storage) as the arrival notice and Event ID 160 as the removal notice. However, this seems to have been removed as of XP SP2, according to this KB article:

After you install the hotfix, Netshell no longer listens for Plug and Play device arrival notifications. Therefore, you are not notified about new devices.

Additional Resources/Reading:
Schneier On Security
WikiPedia entry for AutoRun
SecuriTeam Blog entry by Gadi
USBSnoop (2002)
USBSnoop (2001)
USBSnoopy (2001)
USB Monitor

Perl Programming on Win32

Back in the day ('round about '99 or so), I was struggling to learn Perl programming on the Windows platform...I could do the simple stuff that comes as part of the core Perl distribution (ActiveState's distro), but I was having some trouble leveraging the power of Win32-specific modules. Fortunately, Dave Roth was very helpful, and even got me to put together a paper for presentation at the Usenix LISA-NT '00 conference. In fact, it was with Dave's help that I was able to see and use the power of Perl on Windows systems, and write a tool to replace the use of commercial vulnerability scanners, a tool that was extremely successful.

I've purchased Dave's books in the past, and learned a lot from his advice and programming style. It turns out that this year, Dave's turned to blogging, as well. He's updated his forums, as well. His site provides a veritable cornicopia of information for leveraging the power of Perl on Windows, whether you're using the core functionality of Perl, or you're exploiting any number of Windows-specific modules.

MetaData and eDiscovery

In yesterday's CyberSpeak podcast, mention was made of issues with Office document metadata and eDiscovery. Several commercially available tools were mentioned, and I wanted to mention that there are freeware tools available.

First off, let me say that the tool I'll mention is one of my own...I'll be up front about that. It's a Perl module that I posted on CPAN, and it ships with a sample script called "testwd.pl". On Windows, if you're using ActiveState's ActivePerl, installation of the module is simple. Download the archive and extract the MSWord.pm file to \perl\site\lib\File. To install the necessary modules to support this module, use the following commands:

ppm install OLE-Storage
ppm install Startup
ppm install Unicode-Map

The sample script pulls out the data in a crude format...the original script that I based this module on (wmd.pl) did a better job of extracting the information in a pretty format. As an example, I'll use the Blair document:

C:\Perl>wmd.pl d:\cd\blair.doc
--------------------
Statistics
--------------------
File = d:\cd\blair.doc
Size = 65024 bytes
Magic = 0xa5ec (Word 8.0)
Version = 193
LangID = English (US)

Document was created on Windows.

Magic Created : MS Word 97
Magic Revised : MS Word 97

--------------------
Last Author(s) Info
--------------------
1 : cic22 : C:\DOCUME~1\phamill\LOCALS~1\Temp\AutoRecovery save of Iraq - securi
ty.asd
2 : cic22 : C:\DOCUME~1\phamill\LOCALS~1\Temp\AutoRecovery save of Iraq - securi
ty.asd
3 : cic22 : C:\DOCUME~1\phamill\LOCALS~1\Temp\AutoRecovery save of Iraq - securi
ty.asd
4 : JPratt : C:\TEMP\Iraq - security.doc
5 : JPratt : A:\Iraq - security.doc
6 : ablackshaw : C:\ABlackshaw\Iraq - security.doc
7 : ablackshaw : C:\ABlackshaw\A;Iraq - security.doc
8 : ablackshaw : A:\Iraq - security.doc
9 : MKhan : C:\TEMP\Iraq - security.doc
10 : MKhan : C:\WINNT\Profiles\mkhan\Desktop\Iraq.doc

--------------------
Summary Information
--------------------
Title : Iraq- ITS INFRASTRUCTURE OF CONCEALMENT, DECEPTION AND INTIMIDATION
Subject :
Authress : default
LastAuth : MKhan
RevNum : 4
AppName : Microsoft Word 8.0
Created : 03.02.2003, 09:31:00
Last Saved : 03.02.2003, 11:18:00
Last Printed : 30.01.2003, 21:33:00

--------------------
Document Summary Information
--------------------
Organization : default

Notice the bolded line above...this is extracted from the binary data of the file.

The module extracts the information, it just needs to be prettied up a bit. Another benefit of the module is that it extracts additional information from the OLE contents of the file. First off, it extracts information about the OLE "trash bins", where useful data could be hidden:

Trash Bin Size
BigBlocks 0
SystemSpace 940
SmallBlocks 0
FileEndSpace 1450

Also, the module collects information about the OLE streams within the file:

Stream : ☺CompObj
Stream : WordDocument
Stream : ♣DocumentSummaryInformation
Stream : ObjectPool
Stream : 1Table
Stream : ♣SummaryInformation

At this point, you're probably thinking, "yeah...so?" Well, there's a freeware utility available called MergeStreams that allows you to merge an Excel spreadsheet into a Word document. The resulting file is slightly smaller than the sum of both file sizes, and the file extension is ".doc"...so if you double click the file, it will open in Word and all of the word data will be visible. However, if you change the file extension to ".xls" and double-click the file, it will open in Excel, with none of the Word data/information visible. It's still there...it's just not being parsed by Excel.

Why is this important? Well, if I wanted to smuggle information out of an organization, I might put the information in a spreadsheet for easy access and searching and then merge it into an innocuous Word document and copy it to my thumb drive (or laptop hard drive). If on the off chance anyone was to search me or my devices, they'd see the Word document. If the double-clicked it, they'd see the innocuous, boring content I'd put there...and wave me on my merry way. The same could be true for email attachments.

The example that I use that gets the LEOs sitting up in their seats is to take three illicit images and paste them into a Word document. Merge the document with an Excel spreadsheet that may be widely circulated throughtout the company...financial forecasts, etc. Only those folks who know that the images are there will know to change the file extension to ".doc" so that they can view the images.

Interesting stuff. Like I said before, if you have a situation like what was mentioned in the podcast (i.e., you have to search a lot of files for specific metadata, such as the last author, or one of the last 10 authors), then something like the Perl module provides the necessary framework; combine it with any number of ways to enumerate the files in question (read the contents of a directory, read the file list from a file, etc.), Perl's regular expressions, and you can output to any format you like (HTML, XML, spreadsheet, database, text file, etc.).

FIRST Conf '07 CfP

FIRST opened their call for papers (CfP) for the 19th Annual FIRST Conference, to be held in Seville, Spain, in June, 2007.

The CfP page looks interesting with several options available with regards to not only subject matter, but also the types of talks. The Geek Zone talks look like they may be the way things are going, at least for the conferences I'd like to attend. For some strange reason, I'm drawn to the "beer 'n gear" talks, and I hope that they're not all gear.

Hopefully, we'll see some really interesting presentations come out of this conference.

CERT is a platinum sponsor of the conference.

Vista RC1 Install

The other night, I installed Vista RC1 via VMWare. Before doing so, I made sure to read up on any issues identified in the VMWare Knowledge Base. It turns out that there were a couple of issues discovered in some of the beta versions, and most seem to have been addressed. KB 5805328 has some advice that I had to follow to get RC1 to install, that also worked for Didier.

After the install was complete, things were up and running for the most part. However, I was having a problem at shut down...whenever I tried to shut down cleanly, I'd get a BSOD referring to BUGCODE_USB_DRIVER, and then a restart. Hhhhmmm...not a good way to go. I got in touch with Robert Hensing, and he suggested that I install the MS debugging tools and analyze the minidumps (by default, Vista creates minidumps during a BSOD) to see what happened. MS hasn't received many messages about the issue I was having, so there was no update available.

I got the tools installed, but to view the dumps, you have to launch both Windows Explorer and WinDbg using the right-click -> "Run as Administrator" functionality, due to the permissions set on the files, and the user access control (UAC) put in place on Vista. What a pain! Every atomic action you do requires additional privileges, and if you have to do something with more than one step in it (such as open a file in a debugger), then you're going to have problems when you try to figure some of this stuff out on your own.

Anyway, it came down to the usbhub.sys driver as what was causing the problem. I shut down the VM, removed the "USB Controller" from the VM profile, and restarted. Since then, I've had clean shut downs.

So far, so good...

ProDiscover 4.8 is out!

Last week, I received an early announcement from Chris Brown about the release of ProDiscover 4.8, so I downloaded it to check it out.

I've already used it successfully in a preview case. I hooked up the hard drive to a write-blocker, and accessed it with ProDiscover, and it worked just fine.

There are some neat new features to 4.8, most of which will be extremely useful. For instance, you can now use ProDiscover to image the physical BIOS of the system (did anyone see the Blackhat presentation on BIOS rootkits?). Also, you can convert your .eve or .dd files to ISO format.

Finally, similar to LiveView, you can use PD to create the necessary files to launch an image in VMWare. Just so you know, though, it takes more than simply clicking an "OK" button. But to see how simple it is, check out the webinar on where Alex walks you through going from a dd image to a guest running in VMWare (go grab the WebEx Player to watch it). The webinar is instructive and very useful.

OS Detection, Explained

Okay...the code's been posted to SF.net, so I thought I'd describe what it does...

The archive listed under "OS Detection" is called "ostest_0.1". This archive contains two Perl scripts, ostest.pl and kern.pl. Ostest.pl performs OS detection of a Windows RAM dump (dd-style or .vmem file) by locating the SYSTEM process EPROCESS block. This is based on a paper by Jesse Kornblum. I added a check for the Idle process, as well.

Kern.pl uses a method of OS identification that Andreas told me about...if you can locate the kernel base address in the RAM dump, and the first two bytes are "MZ", then you parse the PE header and locate the ResourceTable (or the .rsrc section) , and parse the VS_VERSIONINFO structure(s) to get the various string elements. I started by looking at the various VMWare guests I have, and opened up LiveKd on each one to see what the kernel base values would be. I then posted asking for others to provide the values they saw (I got about half a dozen responses, all for XPSP2), and I even did a search for folks who were doing debugging. From all of this, I created a simple table of the various values for the kernel base for Windows 2000 through Windows 2003 SP1 (I found NT4.0, as well, but that's commented out in the code).

Here's what the output of kern.pl looks like when run against one of the DFRWS 2005 Memory Challenge dumps:

C:\Perl\memory>kern.pl d:\hacking\dfrws-mem1.dmp
kern - Determine OS from a Windows RAM Dump (v.0.1_20060914)
Ex: kern

File Description : NT Kernel & System
File Version : 5.00.2195.1620
Internal Name : ntoskrnl.exe
Original File Name :
Product Name : Microsoft(R) Windows (R) 2000 Operating System
Product Version : 5.00.2195.1620

So, at this point, consider this code an initial, alpha release. I've got some clean up and documenting to do, as well as adding functionality (verbose/debugging output, etc.). But it works, so give it a shot, and let me know what you think.

OS Detection from a RAM Dump, part deux

Okay, here's where I'm at on this so far...

I'm implementing a method of OS detection from a RAM dump by going to the kernel base address in the dump (thanks to Andreas for pointing this method out) and determining if there is an executable there. If there is, I'm using PE parsing code that I've already developed to locate the ResourceTable and parse through it to get the file version information.

For those of you who don't know, the ResourceTable is a "simple" multi-level directory structure. I'm using Matt Pietrek's description of the ResourceTable as a basis, and then using other resources to located the RT_VERSION identifier so I can traverse the directory structure in the right direction.

So, I locate the first/root level easy enough, and locate a pointer to the RT_VERSION resources (skipping bitmaps and dialogs). I get to the second level and locate a pointer to the third level, which gives me a pointer to the resources:

ID = 0x409, PTR = 0x228

What this tells me is that the ID is pointing to a particular language (English) and since the high bit of the PTR isn't set, it points directly to a resource. Only at this point, I don't know which resource, as it's still 24 bytes from the beginning of the VS_VERSIONINFO structure.

I've been searching on Google, and if anyone out there has a resource (link, URL, text file, etc.) that breaks down how to traverse the ResourceTable, I'd appreciate it, as it will save me some time and let me finish this code. Thanks.

Addendum, 14 Sept: Ugh. I figured it out. Finally. I'll have code working soon.

OS Detection from a RAM Dump

I mentioned earlier that I'm working on a script that will help with OS detection from a RAM dump, either dd-style or a VMWare .vmem file. Thanks to some really excellent input from Andreas, I'm looking to add another detection method to the script and in order to do that, I'd like to get some input from you, the readers.

Here's what I need...if you have the MS Debugging Tools installed on a Windows system (2000 and up), go grab a copy of LiveKd, and copy it to your system. Go to the directory where you put LiveKd, and type "livekd -w" to open WinDbg. Once you get the prompt, look at the output from the tool, and copy what the operating system is identified as, and the "kernel base" value.

Once you do that, comment here or send me an email with the information. What I'm trying to do is use as wide a sample as possible to determine if this value is dynamic or not.

Thanks.

Addendum 11 Sept: First off, God bless anyone and everyone involved in the 9/11 attacks. This goes for victims, their families, the rescuers and workers, and all who've pushed forward and continued the mission. God bless you all.

On topic, I've gotten a couple of responses to my request so far, but they've both been for XPSP2. I spent a few minutes online this morning searching for posts about crash dumps, and found a ton of information. What I've seen is that the values I'm looking for seem to be pretty consistent...there're a couple of variations with regards to checked builds on Windows XP, but only a few that I've found. So, at this point, I'm working parsing the resource table, the RVA of which is found the PE header...the IMAGE_RESOURCE_DIRECTORY structures simply lack elegance (yes, that means they're ugly and difficult to deal with).

Gromozon Rootkit

I received a link to an SCMagazine article about the Gromozon rootkit this morning, and I found some interesting tidbits in the writeup.

The most thorough analysis of this bit of malware can be found in this PDF document. It's interesting the capabilities this thing packs:

• User-mode rootkit
• Hiding code in EFS files as well as NTFS ADSs
• Hiding in the AppInit_DLLs Registry key
• Removal of the SeDebugPrivilege setting from user accounts to prevent rootkit detection tools from executing properly
• Creates a new/fake user account
• Creates a Windows service
  
• The PDF document even mentions the use of a checksum scanner to prevent other anti-rootkit tools from running

Here's Symantec's blog entry on the issue.

From a post-mortem perspective, finding the ADSs and Registry contents (AppInit_DLLs key, BHO entry, ControlSet00x\Services) as well as the added user account would all be useful artifacts, as well provide multiple points for identifying a timeline for the infection.

This brings us to the philosophical discussion of "to wipe or not to wipe, that is the question; whether tis nobler in the mind to suffer the slings and arrows of being repeatedly p0wned, or to take up arms against a sea of vulnerabilities and by patching end them". While I do agree that the only way to be sure that you're free of an infection is to wipe the drive and reinstall the OS and data from clean, uninfected media, I also firmly believe that doing so blindly is simply the wrong way to go. Too many times, a rootkit will be the assumed culprit, and the system will be taken offline, wiped, reinstalled and up back into service...and a root cause investigation will never be done. Putting the box back into service is likely to get it p0wned all over again. Remember, folks, not every compromise is due to the successful exploit of a vulnerability...0 day or otherwise. There are plenty of other ways to get in...weak or no passwords (Administrator, sa, etc.), SQL injection, etc. That's the whole point of incident response...to find out what happened, so you can protect against it happening again.

Gromozon Removal Tools:

• PrevX's removal tool
• Instructions from 2-Spyware.com
• SWZone
  

Rootkit Detection/Anti-Rootkit Tools (no particular order):

• RootkitRevealer
• BlackLight (also, info on the Poker Rootkit)
  
• GMER
• Helios
• BitDefender
  
• ProDiscover IR (agent allows you to detect "hidden" processes/files)
• Resplendence Rootkit Hook Analyzer
• RAIDE
• RKDetector
• SOPHOS
  

Of course, the definitive site for information on rootkits for Windows systems is Rootkit.com. A good list of anti-rootkit software is at AntiRootkit.com.

Extracting and authenticating files from RAM dumps

Andreas had an interesting post a while back regarding authenticating executable files reconstructed from RAM dumps (Andreas, can you enable comments in your blog?). In the post, Andreas talks about hashing only certain sections of an executable file, as when an executable file is reconstructed from a RAM dump, there are differences between it and the original file...but those differences only occur in certain sections.

Perhaps the easiest way to reach a concensus with regards to which sections to hash is to read the PE header, and locate the DWORD for the Characteristics for each section. If the section is writeable, don't hash it.

Has anyone tried using ssdeep to compare a reconstructed binary to the original? I ran it against the copy of dd.exe pulled from the first DFRWS 2005 Memory Challenge RAM dump file, and compared it to the original file, and got a 97% match.

Win2003SP1 and RAM dump parsing

The saga of memory analysis continues...

Okay, so the other night I was working on some OO Perl code for parsing RAM dumps, and I decided to put together a table of important value/offset pairs for EPROCESS blocks for the different OSs. Andreas already has a good one started, but it stops at Win2003, then jumps to the Vista betas (also, the link for the EPROCESS for XPSP2 is wrong...go to the one for XP, and replace the "0" before ".html" with "2180"). I fired up a Win2003SP1 VMWare session, launched LiveKd, and dumped the EPROCESS structure. So filling out my table, I find a lot of differences in the structure, going from Win2003 to Win2003SP1...there weren't this many differences going from XP to XPSP2. Oddly enough, the offsets that remain constant throughout, from 2000 all the way to 2003SP1, are for the DirectoryTableBase (0x018), and the ThreadListHead Flink and Blink values (0x050 and 0x054, respectively).

Oh, yeah, one other thing...the Size value for the Dispatcher Header for Win2003SP1 changed, too...the new value is 0xle. I found this by opening up the .vmem file in UltraEdit and searching for the ImageFileName for the System process, which is "System" followed by 10 "\00"s. From there, I backed up 356 bytes (the ImageFileName is a 16 character string located at offset 0x164 within the EPROCESS structure), and as the 356th byte was aligned on a page, I checked the values. As Andreas pointed out, the Absolute and Inserted values are 0x00, but without more to go on, don't use these as part of your "magic number" when looking for EPROCESS structures in a memory dump.

Looking at my table, and looking at a draft paper I was reading, I figured that I could write a tool that would take a dd-style RAM dump or a .vmem file and figure out what OS it was. I mean, after all, now many times does someone tell you that their Windows box has a problem (or got p0wned) and when you ask which version of the OS they were running, you just get a blank stare? Yeah, that never happens to me, either. Anyway, I was looking at some of the "rules" mentioned in the paper, and I started organizing things in my mind...and then started implementing what I was thinking about in code. So, the end result is a pretty decent OS identification script that works for Win2000 through Win2003SP1. The script works, and I'll need to incorporate that functionality into the OO framework I'm putting together.

Here's a sample output from the script:

C:\Perl>ostest.pl g:\vmware\vmware2k3\winNetStandard-Snapshot2.vmem
ostest - parse dd-style RAM Dump to determine OS (v.0.1_20060906)
Ex: ostest

..
Idle check : 2K3SP1
..........................
System check : 2K3SP1

OS guess based on System and Idle checks:
2K3SP1

I incorporated checks for the Idle process, in addition to the System process. The dots printed to STDOUT indicate possible EPROCESS structures that need to be checked...they provide a visual status, nothing more.

If this is something you'd be interested in, please let me know, by comment or by email. I'm not sure if this is entirely useful, and if it isn't, I won't bother posting it with the other tools.

What's new

Thought I'd take a moment to post some new items that I've run across, just this morning...

First, I was checking email this morning and I found that I had a comment to an older post to my blog about Brian Carrier's The Sleuth Kit...a while back I'd mentioned that I had it running on my XP system. I did that by following the instructions listed here (at the very bottom). Well, it turns out that as of 1 Sept, there are Windows executables of the tools available. This is something I definitely need to try out! Thanks to Brian for providing these. If you're going to run it, though, make sure to read the readme files that come with the archive, so that you understand the limitations of the tools.

You might also want to check out Zeitline, a forensic timeline editor from CERIAS. Zeitline is based on Java/Swing.

The listing over at E-Evidence.info was updated yesterday, and there's a lot of neat stuff listed. I love checking this site out every month, as it takes me about a month to get completely through everything.

Addendum 6 Sept: A couple of sites have picked up on the new TSK tools compiled for Windows (Andreas, SANS). I emailed Brian yesterday because after looking at Autopsy, it's clear that I would still need to compile Autopsy via Cygwin. So, for now, installing the entire thing via Cygwin is probably the way to go.

Using Perl in the Enterprise

This post isn't specifically about IR and forensics, but it is sorta...tangentially.

I was reading on a blog entry today how to use PowerShell to determine the type of battery in your Dell computer. I thought this was pretty cool...after all, though my systems aren't susceptible, I'm sure there are folks out there, IT admins in enterprise environments, who are wondering how in the world they're going to check all of their systems. Well, the code looks like a pretty good solution, but it's PowerShell. The same thing could be done with Perl or VBScript, particularly if you have access to the MS Scripting Repository.

Anyway, being a Perl kind of guy, I cobbled together a quick script to get my battery type. Then I started thinking...how many times have I been preparing to go on-site, and wanted to know some specifics about the system(s) in question, and received either "I don't know" or incorrect information. What if I had a simple script (CScript) or program (even compiled Perl) that I could send to an Administrator, and they could run and get the answers? So then I added some things to the code and got it up and running. Here's what it looks like when run against my local system:

WinterMute:Win32_Processor
Name = Intel(R) Pentium(R) M processor 2.13GHz
Manufacturer = GenuineIntel
ProcessorId = AFE9FBFF000006D8

WinterMute:Win32_Battery
Name = DELL D55056
Chemistry = 6

WinterMute:Win32_BIOS
Name = Phoenix ROM BIOS PLUS Version 1.10 A04
SerialNumber = 3PYQJ91
Version = DELL - 27d5091e

WinterMute:Win32_DiskDrive
Name = \\.\PHYSICALDRIVE0
Manufacturer = (Standard disk drives)
Model = ST9808211A
InterfaceType = IDE

I then ran it against a VMWare Windows 2000 session:

192.168.1.22:Win32_Processor
Name = Genuine Intel(R) CPU T2600 @ 2.16GHz
Manufacturer = GenuineIntel
ProcessorId = 0FE9FBFF000006E8

192.168.1.22:Win32_BIOS
Name = Default System BIOS
SerialNumber = VMware-56 4d 3a 85 4a bd 0a d6-09 07 50 66 47 ec 6b 96
Version = PhoenixBIOS 4.0 Release 6.0

192.168.1.22:Win32_DiskDrive
Name = \\.\PHYSICALDRIVE0
Manufacturer = (Standard disk drives)
Model = VMware, VMware Virtual S SCSI Disk Device
InterfaceType = SCSI

I guess the VMWare guest OS doesn't think it has a battery. Oh, well.

The code I wrote implements WMI in order to collect its information. Now, I simply wrote a quick script that would collect string values from the various WMI Win32 Classes. There's no limit to what you can do with to collect information from managed systems, and manipulate that information (store it in a database or spreadsheet, sort on it, compare it to previous runs, etc.). It's also an excellent way to perform hardware or software inventories. Say you'd like to check all machines with certain patches installed...there's a class you can use to collect all of the installed patches, and if the one you're interested in isn't on that list, flag the machine.

Okay, so how does this relate to IR? Well, patched machines are generally more secure. Also, I would think that a battery bursting into flames would constitute a "security incident" of some kind. Finally, you can use WMI or other tools to manage your configurations...is that system's audit policy out of compliance? With remote tools you can reach out, collect the Event Logs currently on the system, and then update the audit policy. You can also use WMI to determine how much RAM and HDD space is on a system, as first steps in performing live response.