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!