In face of Conficker, the crowd...

...rushes to lynch MS.

Ugh. My inbox was hammered today (okay, truth be told...I got like 2 emails...) with the news that USCERT had found that MS's recommendations for disabling AutoRun/AutoPlay functionality, to protect systems in the face of Conficker infections, fell short and just didn't work.

So I was reading USCERT Alert TA09-020A this morning, and the first thing I noticed was that it was dated 20 Jan 2009. Interestingly enough, I'd blogged about this on 5 Dec 2008.

The next thing I noticed was that the Overview statement clearly said that MS's recommendations were "not fully effective", and then went on to describe why...and then buried way down at the bottom of the alert was the update (presumably from 21 Jan 2009) that mentions MS KB953252.

What's funny is that ComputerWorld jumped on the bandwagon...but the absence of any mention of the update to the USCERT alert was glaringly obvious.

This must be that Fog of War that my instructors always talked about...it looks to me as if in the battle against Conficker/Downadup, a bunch of the folks that should be helping and working together are content to point out each others faults. It's also interesting to me that while USCERT and ComputerWorld are busy pointing out MS's flaws, who's helping customers who should've patched against MS08-067 back in October or November? Oh, wait...that's folks like me... ;-)

Windows 7 Beta Registry

I've seen recently how folks have gotten access to the Windows 7 Beta for download from Microsoft, and being interested, I jumped right up on that bandwagon. I mean, from a forensic perspective, this "Jump List" thing is just going to be a gold mine for an analyst, much like RecentDocs and UserAssist keys have been since Windows 2000. Wikipedia has a nice write-up, and I look at all the great usability stuff that's talked about and all I can think of is "artifacts". ;-)

So, I took a look around to see if anyone was trying to install Windows 7 Beta into VMWare, and I ran across a Windows 7 Beta VM at TuxDistro. I fired up BitTorrent and downloaded the zipped archive, and then unzipped the VMDK file, and opened it in FTK Imager. Now, I saw a "Documents and Settings" directory, and a "Users" directory...so was this REALLY Windows 7?

Well, one question I heard a LOT when Vista came out was "what changed?" Was the Registry different enough that all of our current tools no longer worked? So, there's one way to find out! I dumped the hive files out of the VMDK file from their usual locations, including one called "Components". So I wanted to see if my tools worked, so I fired up rip.pl to see what I was working with:

C:\Perl\forensics\rr>rip.pl -r d:\cases\win7\software -p winnt_cv
Plugins Dir = C:\Perl\forensics\rr\plugins/
Launching winnt_cv v.20080609
WinNT_CV
Microsoft\Windows NT\CurrentVersion
LastWrite Time Fri Dec 12 18:26:31 2008 (UTC)

RegisteredOrganization :
CurrentVersion : 6.1
CurrentBuild : 6956
CurrentBuildNumber : 6956
SoftwareType : System
InstallationType : Client
EditionID : Ultimate
SystemRoot : C:\Windows
PathName : C:\Windows
ProductName : Windows 7 Ultimate
CurrentType : Multiprocessor Free
ProductId : 00428-015-8630506-70665
BuildLab : 6956.winmain.081122-1150
InstallDate : Fri Dec 12 20:52:50 2008 (UTC)
BuildLabEx : 6956.0.x86fre.winmain.081122-1150

Very cool! Not only do the tools seem to work just fine, but it looks as if the VMDK is a Windows 7 Beta VM. Very nice. Other plugins, such as samparse, seemed to work just fine, but parsing the UserAssist key in the NTUSER.DAT file was problematic...the "normal" GUID key didn't seem to be in the hive.

So, it would seem that the binary format of the Windows 7 (the Beta, anyway) Registry hive files has not changed. I'm sure that the content has, as keys have changed names and functionality, and values and ways of recording data have changed. However, as with the move from Windows 2000 to XP, there may simply be more opportunities for forensic analysts. I'll be interested to see who writes some of the first RegRipper plugins specific to Windows 7.

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.

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.