New Windows Forensic Group

Based on input from everyone, I've created a new group, specific to the discussion of forensic analysis of Windows systems:

http://groups.yahoo.com/group/windowsforensicanalysis/

Right now, members must be approved, and the group is moderated. As I said, this is based on input I've received with regards to forums for discussing this topic. I'm a member of other groups and lists, and am constantly amazed how someone can post something, and the subsequent responses get so far off track...usually pretty quickly.

I'm not entirely sure at this point what the criteria will be for approval of members. I'm thinking that a review of things the applicant has already written, be they posts in other groups or papers or articles of some kind, endorsements from others, etc.

I will also be moderating the list, but I don't expect that to really be a problem...in fact, I'm really sort of doing this just so I can say that I did. I know that the very fact that membership is limited is going to prevent people from even applying, and will by its very nature limit the number of messages posted.

Anyway, if you're interested and perform some aspect of forensic analysis of Windows systems, please feel free to apply.

GMail Drive footprints

I hope someone finds the following information useful...

As a follow-up to my Registry key spreadsheet, Iwanted to take a look at the 'footprints' created on asystem by installing the GMail drive shell extension. This is a nifty little tool that lets folks w/ GMail accounts install a shell extension and use their storage space like a drive. This could have some interesting repercussions in cases.

The exemplar system in my testing is WinXP Pro, and the testing tool is InControl5.

During installation of this shell extension, several files are added to %WINDIR%\system32\ShellExt (ie,GMailFS.*).

Registry entries that are added or updated include (but are not limited to):

-> HKCU\Software\Niko Mak Computing\WinZip\filemenu(if user has WinZip and uses it to open the archive)

->HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\RecentDocs\.zip

-> HKLM\Software\Classes\.GMailFS (and GMailFS, w/othe preceeding '.') (CLSID ={2B3453E4-49DF-11D3-8229-0080BE509050} and maps to theappropriate HKEY_CLASSES_ROOT subkeys on a livesystem, as well as underHKLM\Software\Microsoft\Windows\CurrentVersion\Explorer\MyComputer\NameSpace\andHKLM\Software\Microsoft\Windows\CurrentVersion\ShellExtensions\Approved).

-> The CLSID can be found underHKLM\Software\Classes\CLSID, along with consecutiveCLSIDs (ie, ending in 51, 52, etc.) for variouscomponents.

-> The user's UserAssist (please refer to the spreadsheet for these paths) entries are updated, based on user activity.

Once a user logins into the Gmail drive, theHKCU\Software\Viksoe.dk\GMailFS key is created, with several values. "Auto Login" is set to 1 if the user chooses "auto login" at the initial GUI. Also, several text files (C:\gmail_*.txt) are created.

Approximate installation dates can be determined by retrieving the LastWrite times from the Registry keys listed above.

Please feel free to direct anycomments/questions to the list, or to me directly.

Thanks.

Registry keys posted on the web

Okay,

I've posted the Excel spreadsheet of Registry keys I've been working on here. Take a look, let me know what you think.

Thanks.

Gaps in Windows forensic analysis

For the past week or so, I've been posting to a couple of lists I'm on, asking about forums or communities where the forensic analysis of Windows systems is discussed. The results have been...well, let's say, less than satisfying.

Most of the responses included, "...go here...", or "...try this site...", without any real consideration for the content of the site. I've received references for sites that may contain anything even tangentially related to security. However, not much of the information at the site really has a great deal to do with forensics analysis of Windows systems?

So...maybe I got what I asked for, and my question was vague. I thought about that, but I don't see how someone can think "forensics analysis of a Windows system" is vague. If you start with the image of a drive, I know some folks mount it on a write-blocker, and then do A/V scans, examine file hashes, etc....all part of data reduction. But who's interested in looking deeper in the Registry? Who wants to correlate Registry information (ie, data and LastWrite times) to log files from the system...and I don't mean just IIS and Event Logs?

Given that a great many systems being examined by law enforcement are Windows systems, I would think that this would be a more popular topic. I can only guess as to why this doesn't seem to be the case...but I'll refrain (that kind of speculation bores me).

So, it would seem that contrary to what Fox Mulder thinks, "the truth" just isn't out there. I'll continue posting my thoughts, musings, and research here...and if anyone comes across a site that discusses these sorts of things, let me know...I'd appreciate it. I'd like to see what kinds of things keep the analyst up at night, and what kinds of things the analyst would like to know more about. I'd also like to have a free-flowing exchange of such information...not just a site where people ask questions that are never answered...

Registry Keys

I've been working on a spreadsheet containing several workbooks of Registry keys. One workbook contains AutoStart locations, another contains keys that track user activity (ie, MRU lists, etc.).

The basic format for the workbooks is to list the key, an explanation or description of the key (ie, when it's accessed, such as at system boot or user login), and references for how the key is used. Right now, my references consist entirely of links to MS web pages.

I've provided it to a couple of people I know for review, and one comment came back that there needs to be a different format. What would be a good format for something like this? HTML? What would be more useful/valuable to the user community? Would one format be more useful to, say, a forensic analyst, while another would be more useful to a Windows sysadmin?

I'll be considering responses as I update the material. Thanks.

FRUC Updates on the way

A user of the FSP emailed me earlier this week with some issues he'd identified when using the FRUC...specifically, the commands in the .ini file were not executed in order, and there seemed (quite rightly) to be no provisions for handling commands that hung.

I've got a couple of modifications to make to the code, but they should be out soon.

Thanks.

What keeps you up at night?

When it comes to performing the technical aspects of incident response and forensics on Windows systems (ie, data collection and analysis), what keeps you up at night? What are your concerns?

I'm sure everyone has a different perspective on this. A LE-based forensic analyst may have one set of concerns that may or may not overlap with those of an admin, or first responder. Does someone in a corporate environment have different concerns from those of someone managing a web hosting environment?

Are you concerned about finding out what happened, what the root cause was? Are you concerned with "bringing the perpetrator to justice?" Are you of the opinion that there are simply too many dark, dusty corners to look in, so better to just re-install the operating system from clean media and move on?

I think your thoughts and opinions would go a long way toward addressing issues such as reference materials, postings, training opportunities, etc. Please free to comment here, or email me. I'd like to provide a summary of the responses I receive (anonymized and sanitized, of course). I'd also like to ask that if you do respond, please indicate your role in some way. Thanks.

Interesting stuff on Windows

I was working on a spreadsheet containing information about Registry AutoStart locations last night and ran across something pretty interesting that I thought I'd pass along...

One of the AutoStart locations used by malware is:

HKLM\Software\Classes\exefile\shell\open\command\

On a live system, this also maps to the HKEY_CLASSES_ROOT hive...

HKCR\exefile\shell\open\command

This entry specifies the command to be launched when an exefile (a file ending with the .exe extension) is run. The Default value for this key is "%1" %*. Some malware writes to this entry, ensuring that the malware is launched whenever an executable is run.

*Note: This same sort of thing applies to other types of executable files, such as cmdfile, comfile, scrfile, piffile, and batfile.

So I wanted to see what else could be done via these sorts of keys, so I navigated to:

HKCR\Drive\shell\cmd\command

I right-clicked on the Default value and chose Modify. The default entry is cmd.exe /k "cd %L", and I added && notepad.exe to the command, and clicked "OK". I then opened My Computer, right-clicked on the C:\ drive, and chose "Open Command Prompt here..." from the context menu. A command prompt AND Notepad opened!

So this adds yet another entry to one of the three classes of AutoStart locations (ie, System boot, User login, User activity). I haven't seen anything on the Internet (yet) about locations like this being used by malware or malicious users, but it does go to show what could be done.

Security Event Log Resource

I received a message from one of the lists I belong to today, pointing out this Windows Security Event Log resource. This looks like an excellent way to get started with parsing scripts, or to simply better understand the messages that appear in the Event Log.

I'd start with psloglist.exe to extract the information from the logs, then parse the output using Perl, and a flat text database with the event information. The db could be used simply to filter the entries, or to add information to the output.

Yet another incident write-up...

Not too long after reading JOAT's blog, I was over on Michael Howard's blog and caught a write-up of how he handled a spyware incident. My comments are as follows:

1. I prefer a nice, oaky Chardonnay, or if I'm in the mood for a red, I tend to prefer a shiraz, perhaps Australian.

2. One of the things Michael mentioned using was Port Reporter...excellent suggestion. This nifty tool from MS fills the gap with much of the IP logging that appears on other systems. If you find it daunting to parse through the logs looking for "suspicioius" or "unusual" entries, I'd strongly recommend installing the Port Reporter Parser tool along with it.

3. I would have strongly recommended that he include SpyBot and AdAware on his thumb drive, along with the other tools he mentioned. Thumb drives are becoming ubiquitous, and you can rewrite information to them, such as new versions of tools whenever they're updated.

4. For learning purposes, I would have liked to know a little more about the connections to Brazil and Russia, and how the son was exonerated for the pr0n on the system. Providing details of the steps used, data collected, and decisions made would have been helpful, as well as entertaining.

5. One of the comments that concerns me is "I also ran RootkitRevealer 1.32 from sysinternals.com, and saw nothing out of the ordinary. So I consider the machine clean." After all the posts we've seen about how easily tools like RootkitRevealer and BlackLight can be fooled, I don't know if I'd consider the system "clean" based on that information alone.

6. I do agree that all it takes is a little education, and most folks will be fine. This time of year, folks really need to be careful, though...it's tax season, and lots of people use TurboTax, TaxCut, and other tax preparation software. That's all good and fine, but these products create files on your machine...files that an intruder can easily steal or copy ("YOINK!")...so be sure to batten down the hatches...

Another Serv-U/FTP compromise

I was reviewing JOAT's blog this morning, and saw a link to a write-up about the response to an FTP compromise. I read through it and thought I'd post a review. I know that hindsight is 20/20 and all that, but I think it would pose an excellent opportunity for questions, comments, and will give everyone a chance to learn a little something.

The initial investigation seems to stem from some unusual network traffic, and the investigation ensued from there. The investigator started by running netstat.exe, then connected to one of the ports to see the FTP service banner, and then ran fport.exe. The investigator identified various files, to include a scanner and what looks like an IRC bot.

While the investigator seems to have taken all necessary steps to solve this issue, my hope is that there are several steps missing for the sake of brevity. Yes, these measures helped him resolve this issue, but a well-planned methodology would prove more useful for a wider range of issues. Some of the things missing include any information about running processes, owners of the processes, installed services, etc., etc.

One thing that I'm curious about is, how did this thing get on the system. According to the investigator, the files he found were in a directory that only allowed the system full access (according to the cacls.exe output). The investigator stated, "...don't even give Administrator access...only the system-level account. Had to edit security permissions to grant access back to Administrator..." So my question is, if the administrator didn't have access, even to change permissions, how did the investigator handle this? This question is intended to be rhetorical, and point out a deficiency in documentation, not necessarily process.

Finally, I found the conclusions to be interesting. Yes, legit apps have been bundled together for some time, allowing attackers to bypass things like anti-virus software b/c the software they're loading (Serv-U, mIRC32, etc.) is not identified as malicious.

Another thing I would point out is the use of a rootkit...or, more specifically, the lack thereof. Take a look at the names of the files...svchost.exe, Explorer.exe, windows.dll, etc. Why bother with a rootkit when hiding in plain sight works just fine?

Finally, the investigator doesn't seem to have addressed the issue of how the compromise occurred at all. How did this stuff get on the box (the operating system was never identified, other than "Windows")? Weak password? Some other compromise, perhaps browser- or email-borne? Could other systems be affected or vulnerable, as well?

All in all, I think these kinds of things are good...posting what you did, and how you handled a situation, for others to see, review, and learn from.

Now, to the reader...what might have you done differently, and why?

Prefetch files posted

I've posted my Prefetch files on my Windows-IR.COM Tools page. Check them out, let me know what you think...

Prefetch files posted

I've posted the prefetch files to my Windows-IR.com site, on the Tools page. Take a look...

Book Update

I received a report of the sales of my book from the publisher last night...from the publishing date (approx 27 July 2004) through the end of 2004, 3055 copies were sold.

I don't know yet if that's good or bad, or what. I've reached out to some folks I know that have also written books, to try and get an idea of what that means, given the market, the book's niche, etc.

I want to thank everyone who's purchased a copy of the book...without you, that number would not have been possible. Thanks!

Is anyone else seeing this???

Not too long ago, I blogged about ADSs and the Prefetch directory...and so far, I've only been able to replicate this behaviour on XP Pro. I've tried XP Home and 2003, with no luck.

Is anyone else seeing this behaviour, or have you been able to replicate this on XP Home/2003?

How good is your Reg-foo?

Yes, I'm still working on the Registry Analysis HOWTO, subtitled "Your Reg-foo is very good..." (remember the old, poorly-dubbed "BlackBelt Theatre"??). I'm using what I've got so far as a stepping off point for a presentation at work, then a similar presentation at a conference in June.

I've got some interesting tidbits so far...detecting deleted user accounts, mapping USB-connected storage devices, etc.

I was wondering that things you guys look for (or want to know more about) in the Registry.

Before you comment or email me...malware stuff is pretty passe. It's well known. We all know about the ubiquitous 'Run' key. So keeping that in mind, send in your tips...

How good is your Reg-foo?

Yes, I'm still working on the Registry Analysis HOWTO, subtitled "Your Reg-foo is very good..." (remember the old, poorly-dubbed "BlackBelt Theatre"??). I'm using what I've got so far as a stepping off point for a presentation at work, then a similar presentation at a conference in June.

I've got some interesting tidbits so far...detecting deleted user accounts, mapping USB-connected storage devices, etc.

I was wondering that things you guys look for (or want to know more about) in the Registry.

Before you comment or email me...malware stuff is pretty passe. It's well known. We all know about the ubiquitous 'Run' key. So keeping that in mind, send in your tips...

Parsing the Prefetch directory

One comment from the previous blog entry asked for a program that would parse through the Prefetch directory and list all files, as well as the date/time that the application was last run. I've got that done...didn't take long at all...and will post the code over on the Windows-IR.com web site...check the Tools page. I'll try to get it posted tonight.

I've also written a Perl script that will parse the layout.ini file and for each executable (based on file extension....exe, .dll, and .sys) listed, will located the file and parse out available file version information. I'll post that script along with it's standalone .exe file to the Windows-IR.com site, as well.

Both programs will make an interesting addition to the FRU...perhaps even adding some code to the above programs to perform data reduction would provide more interesting results. However, I would definitely consider correlating the last access times of the .pf files from the Prefetch directory with things such as the uptime of the system, and any logon/logoff information you can get from the Security Event Log (in a pinch, last access times to the user directories may be useful if the appropriate auditing is not enabled).

More about the Prefetcher

So far, there hasn't been much of a response to my previous Prefetch blog post...though I have heard that some folks have been thinking along those lines. I wanted to add a couple of things I've stumbled across...

First, XP prefetches for the boot process and application launch, by default, while 2003 only prefetches for the boot process. As a system hardening recommendation, I'd suggest modifying the 2003 Registry value to prefetch for application launches, as well. The Prefetch directory shouldn't take up a great deal of space...for servers, pretty much the same applications will be launched over and over, so the predominant changes to the directory will be updates to file access times. However, if any unusual applications are launched, a record (ie, a '.pf' file) will be created in the Prefetch directory.

Second, I thought I mention something about the layout.ini file that you see in the Prefetch directory. This file is used by the system defrag tool to optimize system performance, by placing all of the files and directories listed in the layout.ini file in the same contiguous space. Having all of these files and directories close together in the same place makes the access of those objects more efficient.

So...what I did today was write a Perl script that parses the layout.ini file for executable files (based on .exe, .dll, and .sys file extensions) and then extract file version information from each of these. This script can easily be modified to flag files that aren't Microsoft (or Adobe or Symantec) files, or on files that don't have file version information. I should probably add extracting MAC times, as well, prior to grabbing file version info.

Here's an excerpt from the output of the script:

C:\WINDOWS\SYSTEM32\USERINIT.EXE
File Version : 5.1.2600.2180
Product Version : 5.1.2600.2180
OS : NT/Win32
Type : Application
CompanyName : Microsoft Corporation
FileDescription : Userinit Logon Application
FileVersion : 5.1.2600.2180 (xpsp_sp2_rtm.040803-2158)
InternalName : userinit
Copyright : © Microsoft Corporation. All rights reserved.
Trademarks :
OrigFileName : USERINIT.EXE
ProductName : Microsoft® Windows® Operating System
ProductVersion : 5.1.2600.2180
PrivateBuild :
SpecialBuild :

This sort of thing is extremely useful, allowing for quicker searches of "suspicious" files. The key is in understanding how the Prefetch directory and the layout.ini file are populated, and then determining how they can be used (exploited??) by a forensic analyst.

What is the Prefetcher?

Ever wondered what the Prefetcher is? As of Windows XP, MS added a prefetcher to improve boot and application launch time. Like many other things on Windows systems, this functionality is controlled by a Registry key.

Basically what happens is that when an application is launched, via pretty much any means (there are some methods I haven't tested yet...but even launching an app via a Scheduled Task works...), the system figures that you may want to launch it again at some point, so it creates a file in the %SYSTEMROOT%\Prefetch directory, with a ".pf" extension. This file contains some binary data, as well as some other information in Unicode (more on this in a minute).

The file that is created is given a name based on the following elements:

• The name of the application
• A dash
• A value representing a hash of the path to the application
• The '.pf' extension

As the hash in the filename is based on the absolute path to the executable image file, if you run the same application after copying it to a different location, you'll get a different hash value, hence a different '.pf' file will be created in the Prefetch directory.

Back to the topic of Unicode data within the '.pf' file...if you open the file, near the end you'll see several paths. Most of these are paths to modules used by the application...but the path to the executable image file can also be seen here.

Combining this path with the MAC times on the file itself can provide valuable information to a forensics analyst.

I've test this by running apps from the command prompt, as a Scheduled Task, via Start->Run, etc. Nothing of note happened until I ran an application from within an NTFS alternate data stream. I created the ADS using the following command:

C:\>type c:\windows\notepad.exe > mytest.txt:np.exe

After running this command, I launched the application using the following command:

C:\>start .\mytest.txt:np.exe

Notepad ran just fine (as expected), and when I listed the contents of the Prefetch directory, I found this entry:

... 0 MYTEST.TXT

Hhhmmm...no '.pf' file. Or...is there? I ran LADS.EXE version 4.0 against the Prefetch directory, and found this:

Scanning directory c:\windows\prefetch

size ADS in file

---------- ---------------------------------

7960 c:\windows\prefetch\MYTEST.TXT:NP.EXE-0870E38D.pf

Nice! Very interesting!

So...what's my point? Let's say you want to determine if a user had run an application on a system. Well, there are locations in the Registry that record when a user launches an application in a certain way...via Start->Run, for example (search the Registry for "RunMRU"). While I haven't been able to determine whether or not there's any difference between Prefetch file names based on the user account, you should find a Prefetch file for the application (assuming, of course, the user doesn't know about prefetching and hasn't deleted the contents of the directory).

A forensic analyst can combine the MAC times of the file with the path found within the '.pf' file itself (yes, the absolute path to the ADS is in the '.pf' created in the ADS example I used), and add that to a timeline of system activity.

As I have an opportunity to try other things, I'll post them here. But don't be afraid to try your own things instead of asking me, "what happens if you..."