Windows AutoRun feature

Oh, how I love this...in order to address the issue with the Windows AutoRun capability, which malware such as Conficker (no, NOT 'Conflicker'!!!) can use to spread, Microsoft is taking measures to protect users from themselves...but only if you're running Windows 7.

Niiiiiiiice.

Data and Context

I receive questions from time to time regarding various bits of information, some of which is presented in my book. I recently received some questions regarding differences in run counts for applications derived from Prefetch files and UserAssist key entries, the latter being displayed via RegRipper.

What needs to be kept in mind when looking at data as it is being presented by any extraction technique or utility is the context with respect to how the data is created or modified.

For example, application Prefetch files are created by default for XP and Vista systems and are not user specific. However, UserAssist key/subkey entries are found in the NTUSER.DAT files and are user-specific.

Also, UserAssist key entries are most often created through a user's interaction with the shell; entries can be created or modified by double-clicking a shortcut on the Desktop or in Windows Explorer, by clicking through Start, the Programs, etc. However, application Prefetch files can be created/modified by double-clicking a shortcut to a file on the Desktop, as well.

I know that this is only one example, but the key here is to understand that just because two sources apparently include information about applications being launched, the analyst needs to understand the nature of the event or events that create/modify artifacts on a Windows system. Otherwise, you're going to be facing apparent contradictions where in truth, there isn't one.

CaptainForensics

Hey, be sure to check out the the latest CaptainForensics comic...wow, very cool!!

In this comic, the MergeStreams utility is mentioned...ah, and oldie but a goodie! I can't say that I've ever actually seen this tool used in the wild, but it is pretty neat.

Just out of curiosity, who do you think the picture in the back of the book in the second panel looks more like?

A. me
B. Ovie Carroll
C. Richard Bejtlich
D. Robert Englund
E. Rob Lee

Just kidding, guys! Check out the comic, though...it's pretty entertaining!

Tools

I like to be open to different tools that can be used to assist in analysis, and for those of you who know me, sometimes I write my own. However, I wanted to take a moment to point out some tools that I've found recently that appear to be and have been very useful...

From Claus, I learned about a little tool called DiskDigger from Dymitry Bryant which reportedly allows you to recover deleted files from drives. I thought, wow, this is pretty cool...something to try out with respect to recovering deleted files. So I downloaded a copy and fired it up, and with the first version, saw that it only identified the two physical disks on my system. I had mounted an image file as a read-only drive letter via SmartMount and wondered why this "drive" hadn't been detected. I reached out to Dmitry, expecting to maybe hear back within a couple of days...instead, within relatively short order, Dmitry returned my email with a link to an updated version of DiskDigger, as well as to another tool I'd looked at, NTFSWalker. Now, both tools will recognize drives and volumes, and there is a separate tab for pointing the tool to an image file. Very cool! I thanked Dmitry for his quick response, and he pointed out that he's a one-man shop (wow, THAT sounds familiar...) and that if you find something amiss with a tool or if you have a question, his turn-around time is pretty quick...which is something I can personally attest to.

From JADSoftware comes Internet Evidence Finder, a nice little tool that searches for Facebook chat messages and page fragments, Yahoo chat, and MSN chat messages on drives and within memory dumps. I found my initial reference to this tool on the Forensics from the Sausage Factory blog, where the DC1743 says that he ran the tool against a mounted drive image.

If you're interested in extracting MSOffice OLE document metadata, take a look at OLEDeconstruct from Sanderson Forensics. The sample used to demonstrate the tool is the ever popular Blair document from the ComputerBytesMan. The wmd.pl and oledmp.pl Perl scripts I wrote are still freely available and provided on the DVD accompanying Windows Forensic Analysis, both the first and second editions.

Timeline Analysis - XP Restore Points

So, MS says that XP's going to be supported at least through 2014...nice. So this means great things for examiners and analysts...great things because there's no reason to give up the tools and research you've done on XP!

One of the unique things about XP is its use of System Restore Points. For users, these take up drive space and allow you to recover from issues, but for an analyst, Restore Points are a veritable treasure trove of historical data!

So, one of the challenges (albeit minor) presented to analysts is how to extract information about (and from) Restore Points from an acquired image. Well, this is actually pretty easy. A while back, I wrote a ProScript for ProDiscover that would run through an image and extract data about Restore Points to include when and why they had been created. This ProScript is called SysRestore.pl and is located on the DVD that accompanies the Windows Forensic Analysis book (both the currently available edition, as well as the second edition, due out in early June 2009).

As an alternative, I came up with another method for extracting the same data, one that does not require a commercial forensic analysis application. So, the first thing you do is mount the acquired image via SmartMount or ImDisk, as a read-only drive letter (in this case, G:\).

Next, get a copy of PSExec and put it on your analysis system. Go to the directory where you saved it and type:

D:\tools>psexec -s cmd

This will open the command prompt to your C:\Windows\system32 directory with the prompt now running with System privileges. Now, cd to the G:\ drive, and type the following commands:

G:\>cd syst*

G:\System Volume Information>cd _resto*

G:\System Volume Information\_restore{GUID}>

At this point, you should be "in" the directory that contains the restore point directories (ie, RP0, RP1, etc.). Select the directory path in the command prompt, right-click to save it to the clipboard, and then cd to the directory where you have your tools.

Note: By default, ACLs on the system only allow access to the System Volume Information directory to System, which is why we use PSExec.

The acquired image I'm using (see the above SmartMount graphic) is one of Lance Mueller's practicals. So at this point, I type in the following command:

C:\tools>rp.pl -d "G:\System Volume Information\_restore{}"

The path to the RP directory has to be in quotes due to the spaces; the output appears as follows:

RP1 Thu Jan 31 04:33:11 2008 Z System Checkpoint
RP2 Thu Jan 31 04:43:38 2008 Z Installed VMware Tools
RP3 Wed Jan 30 14:09:49 2008 Z Installed WinZip 11.1

Pretty neat! Now, we know when the RP was created, and why. If I want to have output that i can add to an event file for my timeline analysis, I add the '-t' switch and I get:

1201753991|RP|||Restore Point created - System Checkpoint
1201754618|RP|||Restore Point created - Installed VMware Tools
1201702189|RP|||Restore Point created - Installed WinZip 11.1

Once again, for timeline analysis, we see our familiar five field format. Note that the system/host and user name fields are blank. Rp.pl does have '-s' and '-u' switches for adding that information (respectively), although only the system name really applies, as Restore Points aren't specific to a user. Use of the '-s' switch will automatically populate the third field with whatever system name you enter.

This code was pretty easy for me to work up last night because I simply extracted it from ripXP, the tool I demo'd at the first SANS Forensic Summit. I'll be demonstrating that same tool again at the next Summit, in July of this year.

Linkfest

Taking a page from Claus's book...

I was reading the latest print edition of Hackin9, and in the In Brief section, there is a small inset that talks about some research conducted by Stephan Chenette of WebSense, in which Javascript can be used to download segments of malware code to be downloaded via different streams, allowing it to bypass gateways and AV scans. Back in the day, I'd performed some network exploitation research and written some code that would (a) download an EXE from a web site, which had been renamed to .gif, (b) break it into segments and store it in the Registry, and (c) at a specified date and time, reassemble the segments into a complete executable within the System Volume Information directory, and (d) launch it...Stephan's technique is definitely a twist on things and very interesting, in that Javascript can be used to download the EXE segments from multiple locations, as if they were .gifs on different web pages, and then reassemble them on the system. This is one of those techniques that will be difficult to address, as it doesn't really take advantage of a vulnerability that can be patched, per se. However, it may force the AV industry to evolve.

The SANS Internet Storm Center posted a link to information about the Verizon Business RISK Team's 2009 Data Breach Investigation Report, and pulled out some of the interesting statistics developed and provided in the Verizon report. You can find some additional information about the report at the Verizon Business Security Blog. Overall, like many, I think that the information provided in these reports is very useful and insightful, as the numbers are based on actual case work, NOT on questionnaires. As such, you have responders building tables of numbers and developing the percentages, rather than the victims...more accurate numbers will only help us with these issues in the long run.

Timeline Sources - Let's not forget that using Pasco, you can parse the resulting output and incorporate the contents of a user's index.dat (ForensicWiki IE history fil format page) into your timeline analysis. You can also incorporate Keith Jones' whitepaper that is the foundation of Pasco into your own timeline development process, either to parse the index.dat files directly to your timeline format, or to provide additional detail to the events that you do find. This is not to say that histories from other browsers aren't important, as well.

ForensicWiki - Firefox 3 history file format
BelkaSoft Browser Analyzer
Mandiant's WebHistorian

Also, there may be sources of timeline data that are not easily defined or automatically parseable; for example, I have often looked to Dr Watson log files for indications that malware or other processes were (or were not) running at a specific point in time, as each entry in the log includes a list of the active processes at the time of the application crash. All I really have at that point is point in time and a non-specific statement. Sounds like I need to write up that GUI for entering such events...oh, wait... ;-) So this is a nice little app that lets me enter the date (numbers for the month instead of the letters...'8' instead of 'Aug'), the time (already converted to GMT) and other info, and then tell it which event file to add the information to...the five field format is used that the information is added right to the event file. At that point, all you do is re-run the event file parsing script and your new event appears in the proper location within your timeline.

Event Log Analysis

I caught a very interesting blog post on the ISC the other day that had to do with Windows Event Logs. In short, the post illustrates a failed logon attempt by "a worm that spread via MS08-067 (not conficker)". The event ID is 529 (failed logon attempt) and a type 3 logon attempt, indicating that the attempt is from the network.

I'd had an opportunity recently to do some timeline analysis, and I was seeing event ID 540, type 3 records immediately prior to the suspicious activity in question. These events are network-based logons, but the Logon Process and Authentication Package identified within the event record were both "Kerberos". I did some additional research in conjunction with the timeline analysis, as well as some testing, and found that successful network logons (event ID 540, type 3) with the Logon Process and Authentication Package of "Kerberos" indicate that the account successfully authenticated to the domain or Active Directory in order to access resources on the system...in my case, the logon events were immediately followed by the use of PSExec, and were then accessing the Service Control Manager, etc.

On the other hand, however, testing illustrated that logon events with a Logon Process of NtLmSsp and an Authentication Package of NTLM were seen when accessing shares, such as C$. I didn't see any of these in my timeline.

Resources
Tracking Logon and Logoff Activity
MS KB 326985 (contains explanation of event record strings fields)
Fitz - Tracking User Logon Activity Using Logon Events
MS - Vista/2008 Security Events
MS - Events and Errors Message Center (Event Lookup)
MS - 2003 Security Events

Timeline - Sources

I saw an interesting Twitter from Rob Lee other day which led me to the MS site, where they said:

We plan to provide support for Windows XP until 2014.

Excellent.

I like this because a lot of the code that I've written specifically for Windows XP will continue to remain useful. Now, I'm sure that the code will still be useful beyond 2014...even now, responders still deal with NT 4.0 and Windows 2000 systems.

What I'm referring to is the ProDiscover ProScript code that I wrote and included on the DVD with the first edition of Windows Forensic Analysis. ProScript is Perl, which was implemented as the scripting language for ProDiscover...kind of neat idea, eh? Some of the ProScripts that I've written and still use allow you to parse through Restore Points, collecting data about each one. It's pretty easy to go back and update those scripts, based on the latest version of ProDiscover (we're up to 5.5 now), and add the necessary code to extract some of this data in the five field timeline format, and then incorporate the resulting data in your timeline.

Don't have ProDiscover? No problem. Take the same basic code, mount your image file using SmartMount, and use Perl to extract the same data from your mounted file system. Don't have SmartMount? You can use ImDisk, or you can use Linux, either on your own or through something like SIFT.

Why Perl? Don't really know about using Perl? Well, don't listen to me...take a look at what Mike Worman has to say about it.

Obtaining file system timeline data

One of the things I've run across regarding generating timeline data from the file system is that there has to be more than one way to do this.

For example, what happens if you have an image that you can open in FTK Imager, but for some reason, you cannot get any meaningful data from the TSK tools mmls and fls? Or, what happens if you don't have an image, but are instead accessing a live system? While you can use tools like FTK Imager to extract Registry hive files, and use the copy command to get copies of the EVT (and other) files, you may have to find an alternative method by which to obtain file system data.

Well, that's no problem at all, really. First off, if you have an image and you can open that image in FTK Imager, you can export the directory listing. Simply right-click on the image and choose Export Directory Listing. You can also do this from the command line, via the /CreateDirListing=filename switch, as described in the user manual. The resulting output is tab-delimited and goes to a .csv file which you can easily open in Excel...although that isn't entirely useful, really. Instead, you'll want to parse it in Perl (of course). The format of the directory listing output by FTK Imager includes the filename, full path, size, created, modified and accessed dates (no "entry modified" date), and if the file "is deleted". As it's tab-delimited it can be easily parsed and placed in the necessary format for use in our timeline.

Another thing we'll need to do, though, is translate the time format output by FTK Imager into a Unix epoch time...which is pretty simple with the proper application of the split() function and the use of the DateTime module. Through repeated tests, I've found this module to be more accurate than Time::Local, which has actually had several of my converted timestamps off by a month. Installing the DateTime module is as easy as ppm install datetime, if you're running ActiveState Perl.

Okay, that's one way, how about some others?

You can probably just extract the MFT from an image and use Mark Menz's MFTRipper (discussed in the 22 March CyberSpeak podcast) to extract the data you need.

If you're accessing a live system, you can use Perl (or Python...that's what the illustrious Don Weber prefers) and the stat() funtion to get data from each file on the system, without having to actually access the file itself. However, this will just get the live file system...you won't get things like entry modified times and deleted files, and you will be prevented from accessing some directories by default. You can use this same code to do the exact same thing with an image mounted via Andy Rosen's SmartMount, but you may want to first open a command prompt via psexec -s cmd, so that you can run the Perl script from that command prompt, with System-level privileges. This will be particularly important if you want to get not only file system data from Windows XP System Restore Points, but also if you want to parse the rp.log file in each Restore Point for when and why the RP was created, or run tools such as ripXP.

Finally, if you're read my book, you'll know that I've written a number ProScripts for use with ProDiscover. Writing one to create a timeline bodyfile shouldn't be too difficult, although at this point, I'm not sure why you'd need to with the other methods listed.

A couple of things to remember when creating these timelines...

First, the output of fls.exe is pipe-delimited, and includes the fields:

MD5|name|inode|mode_as_string|UID|GID|size|atime|mtime|ctime|crtime

In most instances, the "MD5" entry is 0, although if you're writing your own code, you can definitely populate it. Populating this field can let you do all sorts of analysis besides just looking at the timeline, such as determining if Windows File Protection was subverted to modify "protected" files.

The timestamps are in Unix epoch time, and consist of the last access time, the last modified time, the "entry modified" (ie, ctime), and the creation date (ie, crtime) of the file. This order is important, not only when parsing the bodyfile, but also when creating a tool to assemble your own bodyfile; putting these various times in the wrong locations can throw off your timeline analysis.

Finally, an interesting side effect of conducting this analysis is that timeline assembly and analysis can be run in parallel to other activities, particularly those that consume a great deal of time, such as scanning for PCI data. Also, as the output is largely text based and in most instances the filenames and other necessary files (INFO2, EVT, AV logs, etc.) do not themselves contain sensitive data, this information can be extracted from an image, compressed and protected as necessary, and sent to another analyst to conduct the assembly and analysis. What this leads to is a faster response time, answers delivered to the customer faster, and much quicker resolution of an incident.

F-Response 3G is out!

Check out this post over on the F-Response site...Matt's released the lastest and greatest 3rd generation F-Response! I've got it and I have to tell you...it's pretty awesome! Check out the new features listed on the page.

The very first, most coolest thing I found about 3.09 was the installation...it was smooth and fast. Put iSCSI on your system, and then run the installer. It's that easy! Getting up and running is fast, too. Once you're ready, launching the F-Response Enterprise Management Console (FEMC) allows you to quickly and easily connect to systems and access physical memory (32-bit Windows), as well as physical disks and logical volumes. And, F-Response isn't just for Windows (including 32- and 64-bit for disks)...you can use it with multiple Linux distros, as well as MacOSX.

If you have any questions at all about how useful F-Response will be in your organization, check out the training videos. Honestly...this is quick look into how simply yet powerful F-Response is, and you can run through these during lunch, or while you're having a beer after a long day at work.

Folks, F-Response has quite literally changed the face of incident response! Where once was the day that systems would sit compromised until someone could get to them and acquire data, that data can now be acquired and analyzed quickly and efficiently, even from remote locations. This means that not only can consultants carry around an enterprise capability in their pockets, but on-site IT staff can begin staging collected data, even while management is on the phone getting the help they need. Hit with malware that AV doesn't recognize? What's your response time in getting someone on-site now...24 hours? 72? How about if when the issue occurs, you reach out with F-Response EE and grab the contents of RAM from a couple of systems, and when management gets some responders on the line, you already have a RAM dump available for analysis. If you already have a transfer mechanism set up, you could literally have answers WHILE YOU'RE ON THE PHONE, not 72 hrs later!

Timeline Analysis - RegRipper

In my last post on timeline analysis, I described using file system data (via TSK's fls.exe), Event Log data (via a custom Perl script) and Recycle Bin/INFO2 file data (also via a custom Perl script) to generate a timeline of activity on the system. One of the sources that is missing is, well, Registry hive file data...but that's changing.

The Registry contains a great deal of timestamped data that can be extremely useful when added to a comprehensive timeline.

First, here's the output of the acmru plugin as is currently seen by RegRipper (or more appropriately, rip.pl/.exe):
C:\Perl\forensics\rr>rip.pl -r d:\cases\ntuser.dat -p acmru
ACMru - Search Assistant
Software\Microsoft\Search Assistant\ACMru LastWrite Time Mon Sep 26 23:02:08 2005 (UTC) 5603 [Mon Sep 26 23:32:56 2005 (UTC)]
000 -> port*
001 -> sol.exe
002 -> hacker*
003 -> hack*
004 -> lad*

5604 [Mon Sep 26 23:33:30 2005 (UTC)]
000 -> disk
001 -> ha*

What the above output tells us is that this particular user ran searches (via Start->Search->For Files and Folders...) on 26 Sept 2005, looking for "port*" and "disk", at 23:32 and 23:33 UTC, respectively. I've bolded the most recent searches, as those are on the searches that correlate to the LastWrite times of the keys (seen directly above the bolded text). The other searches were run at some other time, and like most MRUs, do not have a specific time associated with them; therefore, for the purposes of generating a timeline, they will most likely be of little use...although there's no doubt that overall, they'd be useful.

Now, here's what the timeline information looks like:

C:\Perl\forensics\rr>rip.pl -r d:\cases\ntuser.dat -p acmru -t 1127775728|REG||jdoe|M... Software\Microsoft\Search Assistant\ACMru 1127777576|REG||jdoe|M... Software\Microsoft\Search Assistant\ACMru\5603 (000 = port*) 1127777610|REG||jdoe|M... Software\Microsoft\Search Assistant\ACMru\5604 (000 = disk)

You can see here that I've output the information in the familiar five field (time, type, server, user, description) format. Redirecting this information (and all other timeline information) to the overall event file will allow you to parse this data right along with the file system and Event Log timeline data, as well as data from any other source (such as the Recycle Bin INFO2 files, etc.). This can be extremely important, as a user launching an application will be visible near the file system activity associated with the results of that application. In the case of the example above, a recent search can account for a number of files all having last accessed times relatively close together.

Part of what these updates to RegRipper/rip allow the code to do is 'guess' which hive file is being accessed. If the hive file is a user's hive, the code will attempt to extract the username and SID for later use (as with the timeline information above...the 'jdoe' username was automatically populated). Similarly, if the hive is a System hive file, the code will extract the ComputerName value from the hive file for use in the timeline information. However, the server and username values will not be able to be populated for every hive file; for example, the Software, Security and SAM hives do not contain an easily-referenced value for the system or server they're on, and do not apply to a specific user. The way around this is to allow the user to enter this information via the '-s' and '-u' switches to rip.pl.

Adding this capability to ripXP will allow a plugin to be run across all of the hive files within the System Restore Points, extracting historical data for inclusion in the timeline. Very, very sweet.

SANS Summit Updates

Rob Lee has updated the SANS Forensic/IR Summit information, as well as the agenda. Chris Pogue of TrustWave will be joining us in the IR panel, the first panel of the summit. Chris is a co-author of Unix and Linux Forensic Analysis, so be sure to bring your copy to get it signed!

If you've got only one chance to go to a conference, the Summit is THE one to attend in 2009!

New Volatility Plugins

Andreas has posted a couple of new Volatility plugins recently that look really interesting, in that he provided the capability to link file objects to processes, as well as scanning a memory dump for driver objects.

Someone uses RegRipper

I was pleasantly surprised the other day to receive a forwarded post from a list that I don't have access to where someone had successfully used RegRipper. I don't get a lot of these, so when I do, I like to see if the author would be willing to post their comments publicly, or grant me permission to do so. In this case, the author has said that I can post this, so here it is, in its entirety (and completely unsolicited)...

I thought the group might benefit from some interesting observations I have had with a Vista Home Basic edition machine.

#1 regarding user account Windows logon passwords: Three apps were used to evaluate logon passwords: 1) latest version of Ophcrack with Vista rainbow tables, 2) AccessData Registry Viewer, and 3) Harlan Carvey's Regripper. Ophcrack found 3 SIDs, each with NT passwords. 2 of the 3 shared the same password (the family last name followed by the digit "3"). The 3rd user's PW was "not found" in the rainbow table.

PRTK was used to attempt to recover the 3rd PW, but I stopped it after 5 days when nothing was recovered using a custom dictionary and profile constructed from the exported word list from FTK. Registry Viewer displays the date on which all user PW were changed, and lists the NT PW as "True" for all 3 users. Viewer also displays the "hint" for each user's PW, and
for all 3 it is "name + number." Hmmm......the plot thickens. :)

PRTK used again, this time to extract IE7 Intelliforms data. No success using PW supplied by Ophcrack. Multiple sessions with AccessData proved PRTK does extract this stuff EASILY, so I assumed I had a bad image, a bad export, the wrong index.dat files, etc. Days of retrying proved fruitless.

Ran Regripper against the SAM file, and it says the 2 accounts for which Ophcrack supplied a PW, don't require a PW. Remember, Viewer also said the PW was set to "True." For the 3rd user, Regripper said "Password does not expire." Okay, so I rerun PRTK to extract the IE7 Intelliforms data, and this time I leave the logon PW field blank (meaning no PW). Bingo! I get
it all.

So, Ophcrack says PW, Registry Viewer says PW, Regripper says PW not required, PRTK extracts Intelliforms data only when no PW is supplied. So, it look like Regripper wins! Go Harlan!! As for the 3rd user, I've tried the name + number PW and no PW, but still no success. It's not absolutely necessary for the case, so I'm not pursuing it any further.

#2 regarding groups to which SIDs are assigned: A few weeks back I posted to the listserv asking about how to tell if a user had Admin privileges. Several responses said to examine the "groups" key in the SAM file. I looked at these keys with AccessData Registry Viewer. Viewer listed the different groups available on the machine, but not which users were in each
group. I responded to the listserv with this result, but nobody came back at me with an answer. Well, Regripper lists the available groups on the machine, the number of users in each group, and the terminal segment of the SID for each user in the group. Wow! Harlan wins again!! Perhaps Viewer does provide this information, but it is not readily available or visible to
the user. So, if I am falsely accusing Viewer of not providing this information, please set me straight.

Okay, I think I've taken enough of your time. Hope all have a Happy Easter and a good Passover.

Regards,

Louis M. Schlesinger,PI,CCE,CFC,CIFI,WCSI,ACE
CyForensics, LLC
A Licensed Investigative Agency
Macon, Georgia
Voice: 478-731-0752
Fax: 478-922-9020
Email: cyforensics@cyforensics.com
Website: www.cyforensics.com

Addressing the need to evolve

Been watching the 'net recently to see what's new? I have. Saw the MMPC write-up on Conficker.E recently, and it occurred to me that the authors of this bit of malware are really going out of their way to "protect" the systems they infect. After all, look at the list of process names that it terminates if found. Now, from that list, how many of those tools do YOU use when troubleshooting a system or performing incident response? How about dynamic malware analysis?

Okay, so this is nothing new is it? By "new", I mean the need to adapt our tools and techniques to the current environment and climate. Back in the day (or in the "Old Corps", as the case may be...), malware would maintain persistence by writing to the Registry, in particular, to the Run key. Once enough folks became familiar with that technique, then there was a move to maintain persistence via other Registry keys, including the Services keys. Then, to make things even more fun, the Services were added as randomly-named DLLs, loaded as part of SvcHost. We're even seeing WFP subverted or disabled, or bypassed completely by modifying "protected" files in memory only (as with Conficker.E, apparently). Oh, yeah, and while I'm off looking in the Registry for a persistence mechanism, some malware author is using Scheduled Tasks, instead.

This is all the continuing evolution of (cyber)warfare. Students of military history have seen this throughout the ages. Build a tank, then build an armament or weapon to take it out. Add armor to the tank, someone builds a missile. Reactive armor is added to the tank, and then a probe is added to the missile...and back and forth we go. The IR/CF world is really no different, as the same sorts of tactics are used.

It's never a good time to rest on your laurels. Just when you think you've got it licked and all wrapped up, that's when you know its time to change how you're doing things again.

SANS Forensic Summit Agenda

Rob Lee has posted the agenda for the SANS Forensics and Incident Response Summit, to be held 7-9 July 2009 in Washington, DC.

I attended the first summit in Oct, 2008 and I have to tell you, it was one of the best conferences I've been to! It was extremely well organized with a lot of great speakers and great information, and provided ample opportunity for folks to mingle, ask questions, etc. My hope is that this year's summit will surpass the first one by orders of magnitude, as this kind of summit/conference/gathering is sorely needed.

This year's line up includes a keynote from Richard Bejtlich, followed by a presentation by Kris Harms, and then an IR panel discussion. This year, Rob's following a similar agenda (different content) as he did with the first summit, which IMHO was very successful.

I'll be presenting on the topic of Registry analysis, and with only about 50 minutes, I'll be ripping through the basics to get to the guts of why we need to do Registry analysis in the first place. Of course, I'll be talking about RegRipper, JT's regslack.pl (which has been HUGELY beneficial in a number of engagements) as well as how to run RegRipper plugins against the hive files stored in Windows XP System Restore Points...automatically!

There are also going to be presentations and panels addressing forensic tools and techniques, given by some of the folks who have developed and use them on a regular basis.

Also, look for Bret and Ovie to record their CyberSpeak podcast live at the Summit!

Hey, if you've got to be in DC on 7 July 2009, THIS is where you need to be! ;-)

New Edition of Captain Forensics is up!

The latest edition of CaptainForensics has been posted, check it out!

Keep your eyes open for future editions...at the end of this edition, there are two important clues...

First, "...the images were within a Word document..."

Second, "I was reading about this in a forensics book..."

Stay tuned!

Timeline Analysis, pt VI - Taking Another Step

In my last post on timeline analysis, I illustrated how you could use some freely available tools to get started in developing a detailed timeline of activity from a system. Using TSK tools, we can extract file system timeline information from an acquired image, creating what Brian refers to as a bodyfile. This gives us the beginning of a more complete timeline...in order to take our timeline to the next level, we need to look at other sources of timestamped data...for right now, from the system being examined; for this example, we'll look to the Event Log as a source of timeline information.

As a reminder, we're using the 5 field timeline format that I described earlier. I'm referring to this as a "TLN" format, or timeline format, and includes the time (normalized to Unix epoch time), the source of the event (ie, where we got it, such as from an EVT file, INFO2 file, or some other log or source), the host or system on which the event occurred, the user associated with the event (if available), and a description of the event.

So, we have the file system bodyfile (courtesy of the TSK tools), but we need to translate that into the 5 field format; this is really simple to do using a script I call bodyfile.pl. Now, we have to stop for a second, because two of the fields we'd normally include...the server or host name, and the username...are not available in a TSK bodyfile. I opted to use RegRipper on the hive files extracted from the image to get the server name, and bodyfile.pl has a switch that lets me enter the server or host name so that the script can populate that field. This can be very important if you're correlating events across multiple systems.

Note: If you're dealing with live systems, you may opt to use another means, such as Perl or Python, to collect a file system bodyfile that is similar to the output of fls.exe.

Then I used a Perl script for parsing EVT files to parse through the Application, System, and Security Event Logs extracted from the image and add those events to the overall events file that we started with bodyfile.pl. This can add some very interesting correlating information to your timeline file, and the EVT parsing script can be (has been) adapted to parse event records out of a memory dump (which is all kinds of way cool!).

Now, if you've looked at the image that we're using (ie, the NIST hacking case image), you'll know that there's at least one Recycle Bin on the system with "deleted files" in it, as well as a nice INFO2 file. So I extracted the INFO2 file from the image, and used recbin.pl to parse the contents into our TLN format, adding those events to the timeline data.

Okay, at this point, we have a total of three sources for our timeline data: the file system itself, via fls.exe; the Event Logs; a Recycle Bin INFO2 file. Now what we have is a file full of events, and we need some way to make it useful. I wrote a simple script called parse.pl to read in all of the events, then sort them by the most recent time first, and print all of the events associated with each timestamp. Below is an excerpt from the resulting timeline file, illustrating what appears to be a shutdown of the system (some color-coding done for clarity):

Fri Aug 27 15:46:28 2004 Z
FILE N-1A9ODN6ZXK4LQ - MA.E c:/WINDOWS/Tasks/SA.DAT
EVT N-1A9ODN6ZXK4LQ N/A - EventLog/6006;Info;

Fri Aug 27 15:46:27 2004 Z
FILE N-1A9ODN6ZXK4LQ - MA.E c:/WINDOWS/Prefetch/LOGONUI.EXE-0AF22957.pf

Fri Aug 27 15:46:23 2004 Z
FILE N-1A9ODN6ZXK4LQ - MA.. c:/Documents and Settings/Mr. Evil/Local
Settings/Application Data/Microsoft/Windows/UsrClass.dat
FILE N-1A9ODN6ZXK4LQ - MA.. c:/Documents and Settings/Mr. Evil/NTUSER.DAT
FILE N-1A9ODN6ZXK4LQ - MA.E c:/Documents and Settings/Mr. Evil/ntuser.dat.LOG
FILE N-1A9ODN6ZXK4LQ - MA.E c:/Documents and Settings/Mr. Evil/ntuser.ini

Fri Aug 27 15:46:19 2004 Z
FILE N-1A9ODN6ZXK4LQ - .A.. c:/WINDOWS/Media/Windows XP Shutdown.wav
EVT N-1A9ODN6ZXK4LQ N/A - BROWSER/8033;Info;\Device
\NetBT_Tcpip_{86FC0C96-3FF2-4D59-9ABA-C602F213B5D2}

Pretty cool stuff, eh? Well, here's something else that's very cool...from the output of RegRipper, I collected the last shutdown time from the System hive:

ControlSet001\Control\Windows key, ShutdownTime value
ControlSet001\Control\Windows
LastWrite Time Fri Aug 27 15:46:33 2004 (UTC)
ShutdownTime = Fri Aug 27 15:46:33 2004 (UTC)

As you can see, we did indeed observe a shutdown in the timeline data illustrated above!

Now, this timeline information may not necessarily allow you to answer all of the questions in the challenge, but it can be very useful information, particularly when investigating an intrusion.

Don't forget...others have seen the importance of timeline development, as well. Next steps for this process are to include timeline data extraction in RegRipper, so that this data can be added to the timeline, as well. So stay tuned!

Addendum: I uploaded the complete output of parse.pl to the Files section of the Win4n6 group, under the Timeline Data folder. That way, you can look at ALL of the data...let me know if you have any questions.

Extending Your Reach

As a consultant, one of the things I have always struggled with is an enterprise capability. Often, I'll go on-site for an organization, and the systems that are in-scope for the incident may potentially be the entire infrastructure, ranging from several hundred systems in a data center to several thousand systems across a city, state, or country.

In such instances, tools such as F-Response EE are lifesavers!

However, a full forensic capability isn't always what's necessary. Take the CommandLine Kungfu blog for example...episode 16 has the infamous Ed Skoudis showing us an excellent example of how to use tools inherent to Windows systems to check to see if the patch for MS08-067 has been installed. Ed's WMIC command line is:

C:\>wmic qfe where hotfixid="KB958644" list full

Run that on your own system and see what you get. WMIC makes use of the WMI classes, in this case, the QuickFixEngineering class.

As a sidenote, if you're a Perl freak (like me), or if you just want to add some error checking or nice formating to the output you get from the WMI class query, be sure to look at the MS Script Center repository of sample Perl code. This is a great place to start...for the most part, getting the code working is simply a matter of cut-and-paste. Also, there's a good deal of code on the Windows Forensic Analysis DVD that uses WMI, so you've got another resource available.

I ran a search for the KB958644 patch on my XP system via RegEdit and found it referenced in several locations, including:

HKLM\SOFTWARE\Microsoft\Updates\Windows XP\SP4\KB958644
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\App Management\ARPCache\KB958644
...and...
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\

Another very cool thing is that RegRipper includes a plugin for the Uninstall key...which means that not only can you check for the patch while examining an acquired image, but you can also check live systems via F-Response EE and RegRipper!

Okay...but so what? Well, these approaches (WMIC, Perl, F-Response, RegRipper) give you (as a consultant or as an admin) an enterprise reach, and at a fraction of the cost (in dollars) of some of the big commercial products. Sometimes you don't need a commercial product to reach out and, say, check critical systems in your domain to see if they've been infected with Conficker...