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.