I was analyzing a Windows 2003 R2 SP2 image recently, and I ran across some interesting things that I thought might be a good idea to share.

One of the things I was doing in my analysis was creating a timeline, and saw some Event Log event records that were interesting, so I created a mini-timeline using just the Event Logs. In this case, the system had 5 .evt files...the three usual ones, and Internet Explorer.evt and WindowsPowerShell.evt. I extracted all five files from the image, and began parsing them with my own tools. At first glance, I noticed that there were Security event records dating back to early October, 2009...logins, Event Logs being cleared, etc.

As my analysis progressed, I needed to drill down on something specific, so I created a micro-timeline comprised of just the Security Event Log records, and noticed that the earliest record was from the first couple of days of December, 2009. But wait...how did my other timeline have Security events going back two months before what was apparently in the Security Event Log?

So then I ran evtrpt.pl against the Security Event Log and confirmed the number of records in the log, as well as the date range. I then proceeded to do the same thing across the other Event Logs, as well, just to be sure...and suddenly, from the WindowsPowerShell.evt log, I found 185 Security records! Ah, that's something! So I opened the file in a hex editor and viewed the ELF_LOGFILE_HEADER structure; the StartOffset and EndOffset values were the same...0x0030...indicating that both values pointed to the end of ELF_LOGFILE_HEADER structure (which is 48 bytes long), and that there were NO records in the Event Log. In addition, the CurrentRecordNumber value as set to 1, and the OldestRecordNumber was 0...again, no records. I then opened the Event Log in Event Viewer on my analysis system and was again told, no soup for you! I then went back to the hex editor and after scrolling down past a bunch of zeros, I began to see valid event records, all with "Security" as the source!

So what happened?

Well, apparently when the Event Logs were cleared, and the Event Log files themselves reallocated, at least some of the sectors contained valid event records. Also, there apparently hadn't been any Windows PowerShell events generated, so no event records were written to the log, and the Windows API (via the Event Viewer) duly reported "no records". However, the tools I've written and use do not rely on the Windows API, and instead parse the EVT files on a binary level; they search for the "magic number" for an event record, back up a DWORD to get the size, read that much information into a buffer, and then compare the initial size value to the last DWORD in the buffer. This is just the first check, but allows the analyst to locate event record structures in unstructured data, such as within "unallocated space" within the EVT file. So, not only did the 64K file contain 185 valid event records, but I also found the "smoking gun" that turned supposition (up to that point) into cold, hard fact!

A brief description of the tools (mentioned previously in this blog): evtrpt.pl is a script I use to tell me the total number of event records within a EVT file, as well as the frequency of sources/IDs, and the date range of all records in the file. I use this to get a quick view of how useful the EVT files may be, or to look for specific sources...like McLogEvent, etc.

An example of the frequency of sources and IDs looks as follows (from test data):
Security 528,2 2
Security 528,5 25
Security 538,3 1
Security 540,3 3
Security 540,8 1
Security 551 2

As you might imagine, that can be pretty useful.

I also use evtparse.pl as part of my timeline tools; I can point it at a single file, or at a directory containing EVT files, and it will parse through them, listing the output in the five-field TLN format. From here, I can create a mini-timeline using just the EVT file output, or add the events to an overall event file that also contains file system metadata info (via TSK fls.exe), etc. I also have a switch that will list only the event record numbers, in sequential order, with their corresponding time_generated times...I use this primarily to see if the system clock has been changed.

What this demonstrates is that there can be more sources of data on a Windows system than we're really aware of initially. Because of how the scripts I use were written (i.e., not using the Windows API), with minor modifications, they can also be used to find and extract records from the pagefile, memory, and unallocated space. Evtrpt.pl and an earlier version of evtparse.pl are included in the timeline_tools archive in the Win4n6 Yahoo group, and were mentioned in my second timeline analysis article in the Hakin9 magazine.

As a side note, I also found some pretty cool artifacts in unallocated space within one of the Registry hive files...in this case, the SAM file contained indications of deleted user accounts (and when they had been deleted), which corresponded to other findings in the analysis.

Some of you may have seen (or be using) the timeline tools I released within the Win4n6 Yahoo group and included in my most recent Hakin9 article on Windows Timeline Analysis. If you've taken a look at the tools, you'll notice that I have some tools available for parsing Event Logs from Windows 2000, XP, and 2003 (i.e., .evt files) into the timeline (TLN) format I use. However, there's nothing there, at the moment, for parsing Windows Event Log/.evtx files from Vista, Windows 2008, or Windows 7.

A quick look around showed me that there weren't many free (as in beer) tools for parsing .evtx files. Andreas Schuster has done a good deal of work in this area, has picked apart some of the .evtx data types, and made some tools and an article on the subject available. However, these tools are somewhat limited due to the nature of the new .evtx file format.

Then along came LogParser...freely available from MS and extremely flexible. There are a number of sites available that are dedicated to or include the use of LogParser, and there's even a GUI or two available. However, that's a bit beyond what we're going to talk about at the moment.

You can download the Logparser.msi file from MS and install it, and then copy the files from the installation folder to a thumb drive or CD, making the tool available for live incident response activities. What this means is that you now have a platform-independent means for extracting event records from Windows systems. Using this command:

E:\>logparser -i:evt -o:csv "Select * from System" > %ComputerName%-system.csv

...will do the same thing on Windows XP as it will on Vista or Windows 2008. Now, you have a nice comma-separated value file that you can open in Excel or parse with Perl, and include the entries in a timeline.

Okay, that's live response...what about post-mortem analysis? Well, it turns out that there's a couple of ways you can go on this issue. The first is to have a VM available for each version of Windows, or at least one on the Windows XP/2003 side, and one on the Vista/Windows 7 side. For example, you can mount or access an image of a Windows 2008 system on Windows 7 system, extract the .evtx files, and use the following command:

C:\tools>logparser -i:evt -o:csv "Select * from d:\cases\System.evtx" > system.csv

At this point, all you need to do is parse the resulting .csv file...Perl works quite nicely for this.

The other option is to use just Windows 2008 or Windows 7 as your analysis platform, and convert the .evt files to .evtx format using wevtutil.exe.

C:\tools>wevtutil epl AppEvent.evt AppEvent.evtx /lf:true

This gives you the ability to parse both .evt and .evtx formats on the same platform. However, if you're primarily interested in producing a timeline of events, the timeline tools from the Win4n6 Yahoo group contain a Perl script that parses .evt files into TLN format, without relying on the API. Also, the timeline tools for parsing .evt files will be able to extract event records that aren't "seen" by the API.

Tools
I received an email recently that let me know that the latest version of RevealerToolkit is available, a project from a Barcelona security company. The RVT framework is based on Brian Carrier's TSK tools, and even makes use of some of my code to parse EVT files. More information on RVT is available here. Also, be sure to take a look at the user guide, as well.

Remember when I got p0wned by Intel and MS? Thanks to a blog comment, I was pointed to VMLite, which provides an alternative to MS's XPMode, and without the requirement for hardware virtualization in the CPU. This may definitely be something to take a look at, as virtualization can play pretty important role in forensic analysis in a number of ways. Take a look at packages such as MojoPac and Moka-5, for example.

Rob Lee pointed the GCFA mailing list to RE-Google the other day...this is apparently (quoted) a plugin for the Interactive DisAssembler (IDA) Pro that queries Google Code for information about the functions contained in a disassembled binary. Wow, that sounds pretty cool!

Lance has posted another EnScript, this one to locate Limewire download remnants. This may be pertinent if you're looking at a case involving Limewire or just P2P in general.

Speaking of Lance, I've used the images he has made available for his practicals as examples on a number of occasions; these are excellent resources. However, if you want to work with these practicals as raw dd images (rather than .E0x format), you'll need to convert them using something like FTK Imager. But if you want to mount the EWF/EOx format images and access the files within them, you can use mount_ewf, which Chris has talked about. To do this on Windows, you need to follow these steps (from David Loveall, which Rob Lee so graciously provided to the Win4n6 Yahoo group):

1. Extract the mount_ewf files for Windows into a directory
2. Download and install the Visual Studio runtime files, if you don't already have them
3. Download and install ImDisk

At this point, you should just be able to double-click the E01 file, and tell it Open With... mount_ewf.exe. I'll have to say that I haven't tested this as of yet, but if you've got E0x files you'd like to access, but don't want to have to give up additional space in converting it to raw dd format, this may be an option. P2 Explorer (free) and SmartMount (not free) will also allow you to mount EWF/E0x format images.

Memory Collection and Analysis
An engineer at HBGary recently posted a review of Matthieu's windd tool, based on testing against their own FDPro tool. It's an interesting read...take a look. Here's Matthieu's response, along with some personal notes. I think it's good to see, read, and digest both sides of an issue, and this is definitely worth taking a look at.

On the analysis end of things, Jeff Bryner posted about his FaceBook Memory Forensics tool (ie, pdfbook) on the SANS Forensics Blog recently. Jeff's posted about other tools for parsing memory dumps, and I'm sure that you could use the output of the tool you're using (as opposed to pd.exe, as he mentions in the blog post) to obtain similar results. Looking at the code for pdfbook, as well as the other tools that Jeff's made available, I don't see why they can't be run across unallocated space or the pagefile, for that matter. Another thought might be to give the code the ability to do an EnCase-like preview of X number of bytes on either side of the 'hit' that's been located.

While you're conducting IR or memory analysis activities, Didier's done it again and given us all something new to worry about with SelectMyParent! SMP is a proof-of-concept tool to demonstrate that with the right privileges, you can create a process and designate a parent process for that process. So, instead of running Notepad or Solitaire with your privileges, as a child process of Explorer.exe, you can run it as a child of lsass.exe. And yes, I know what you're thinking...so what? Who's really going to use something like this? Perhaps malware authors...

Print Matter
As a side note from Jeff's post, DFM has it's inaugural issue available...this may be something worth taking a look at. I'd like to see how it compares to Into The Boxes...hopefully, there will be more of a supporting role than competitive.

Along those lines, my second article on timeline analysis is now available in Hakin9 magazine. This one is a hands-on walk-through for using the tools I discuss (and make available via the Win4n6 Yahoo group...go to the Files section) to create a timeline for forensic analysis. I mentioned at an ECTF meeting recently that I have used this technique to great effectiveness. In one instance during a PCI forensic assessment, I was able to narrow down the window of exposure by demonstrating that shortly after the malware was first installed on the system, AV detected and deleted it. In that instance, sources of information included not only the file system metadata and Event Log records, but also AV logs and even information derived from Dr. Watson logs...combining these allowed us to demonstrate that while the malware had been installed, it did not appear to be running at certain times (this malware was not a DLL injected into another process). The two big take-aways from the articles should be that (a) timeline analysis allows you to view events from a system (or several systems) in temporal proximity to each other, and (b) when additional analysis support is required, you can ship off the necessary information for a timeline to another analyst without worrying about exposing sensitive data.

You can also download free Hakin9 articles here.

Correction
I was taken to task by an anonymous poster recently regarding what I've described as a 128-bit timestamp. Apparently, this isn't a timestamp, but rather a SYSTEMTIME structure. I had searched for this, and even been asked by someone from Microsoft about it, but neither of us was able to find a link. So, thanks to Anonymous for sharing this. Apparently, I also stand corrected on how prevalent this structure is within the various versions of Windows, although that's still something of a mystery.

Media
Bret and Ovie have a new CyberSpeak podcast posted...check it out.

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

It's a rainy day here in Northern VA, just the kind of day where you want to sit inside and code. Seriously. One of the things I've had to get back to is tweaking some of the issues I've had with the code for evt2xls.pl. For some reason, on smaller EVT files, it would rip right through them, but on larger files, particularly those around 16MB, it was having...issues.

Rather than try to wade through the mess of code I wrote two years ago, I decided to just rewrite the code from the ground up. Microsoft is nice enough to provide the EVENTLOGRECORD structure format, as well as the ELF_LOGFILE_HEADER structure and ELF_EOF_RECORD structure formats. Using this information, I completely rewrote the code that is the basis of evt2xls.pl. I will also be updating evtrpt.pl, which provides statistics about EVT files, such as the frequency of occurence of various event sources and IDs, as well as the date range of all of the records listed in the EVT file. I plan to add some statistics for SIDs, as well.

So the method for analyzing EVT files from Windows 2000, XP, and 2003 remains the same

1. Run the auditpol plugin from RegRipper (using rip.pl) against the Security hive file to see what's being audited.

2. Run evtrpt.pl (the new one when it's out) against the EVT file(s) to see what you have; for example, if the date range of the EVT records doesn't cover your incident, then there may be little of value.

3. Run evt2xls.pl to extract the event records to XLS, CSV, or a timeline-specific format for analysis.

A basic version of the rewritten evt2xls.pl will be available shortly. A more fully featured version will be available through some other means at a later date.

This is very useful, as the Perl script is platform-independent...it will run on any platform that has Perl, as no special or platform-specific modules are required (with the exception of Spreadsheet::WriteExcel, which can be easily installed on ActiveState Perl using PPM). Also, as the Windows API is not used, there's no worry about extracting event records from EVT files that other tools (particularly the Event Viewer) refer to as "corrupted", so their is not need to "fix" a corrupted EVT file (because it probably isn't corrupted at all).

Addendum: The next step is to create code for locating (and parsing) event records in memory dumps and unallocated space.

Just trying to catch up a bit...

Matt's really clicking along down at F-Response.com...he's posted yet another example of using F-Response to access a running, live Exchange server, this time incorporating Nuix desktop. I've gotta say, if you don't know anything at all about F-Response, you're already late to the party. F-Response has completely changed the face of incident response, and its utility grows by leaps and bounds every day...not because Matt does anything like release an update, but because more people become familiar with it, use it, and see how absolutely fantastic it is as a tool.

Didier found out recently that theVigenere encryption used in the UserAssist keys in Window 7 are only to be used in the beta, and the "encryption" method for the final version is going to go back to good ol' ROT-13!

Lance Mueller posted recently about using a Perl module I wrote for parsing Windows Event Logs (.evt, NOT .evtx). I use this quite often myself, and the version of the module that Lance and Mark McKinnon mentioned is different from what's being included on the DVD that will ship with the second edition of Windows Forensic Analysis. I recently used one of the tools that comes with the evt2xls tools called evtrpt to give me the frequency of event records listing, as well as the date range of the records; this way, I could see if the Event Logs contained records within the date range. I also noticed that the Security Event Log was 512Kb, but there were no records...not surprising since RegRipper told me that auditing had been disabled.

Speaking of RegRipper, over on the ForensicIR blog, Hogfly posted about using RegRipper and some of the things he's used it to extract, such as user/group information, firewall configuration, etc. One of the things I am reminded of each time I use RegRipper is how powerful it really is, in part through its flexibility.

Moyix has posted code updates for the Registry modules he created, and over on ForensicZone, there's a post showing how to use the modules to decrypt the passwords extracted from a memory dump.

Speaking of memory, I ran across Gustavo Duarte's blog recently, and I'm STILL reading some of the posts! I have to say, the pictures drew me to it, but the content keeps me coming back!

For those interested in information about how time stamp data can be and is used in forensics, check out the TimeForensics site for some good papers.

Here's a great PDF that addresses issues with U3 devices.

In keeping with the Getting Started posts, I wanted to include something that may be of interest with regards to finding corroborating artifacts when performing computer forensic analysis.

Many times, when performing CF analysis, we end up trying to find out when a particular user may have logged into a system, or into a Windows domain. There may be other artifacts, as well, that may lead us to the Windows Event Log (right now, I'm just talking about the Windows 2000, XP, and 2003 Event Logs). There are a number of different ways to go about this, using the commercial tools such as EnCase and ProDiscover, but sometimes the analyst may want to extract the .evt files from the acquired image and parse them. In such instances, the Windows API (used by the Event Viewer and a number of other tools) may report that the .evt file is "corrupted".

This has happened enough to others that I don't even bother any longer, and instead resort to tools such as EvtUI, a GUI-enabled Perl script based on the Evt2Xls Perl script that I wrote to parse .evt files on a binary basis, by-passing the MS API and producing something a bit more usable. EvtUI runs against an .evt file and parses out all of the event records into an Excel binary-compatible spreadsheet. The Time_Generated field of the event record structure is formated so that it can be used to sort on in the spreadsheet. EvtUI also produces a report file, which gives the analyst an overview of the .evt records based on the frequency of the various sources and event IDs. I found this particular functionality useful enough that I pulled it out into its own tool (I call it "evtrpt") and added a frequency count for event types (Info, Warning, Error, Success, and Failure). The report file also gives you the date ranges of all of the event records.

Another thing that EvtUI lets the analyst do is enter exceptions. I've seen instances with really large .evt files (when combined with an extremely verbose audit configuration) where .evt file will have more than 65,535 records...and this is the limit of entries for Excel. So, the analyst can run EvtUI once, and then check the report...if there are more than 65,535 records, she can choose event IDs to enter as exceptions and then re-run EvtUI.

Now, once you've gotten this far, the question then becomes, how do you analyze the data you've got? Well, what you look for depends not only on your case, but what's being audited (which you can see very easily by parsing the PolAdtEv value from the Security Registry hive file. This is only a start, though...I suggest that anyone who does or wants to do Event Log analysis check out the following sites:

EventID.net (indispensable and well worth the $24/yr subscription)
Eric Fitzgeralds' blog
Rob "Van" Hensing's Blog
Windows 2000 Security Event Descriptions (pt 1, 2)

Tips
There was an intrusion investigation where the intruder was suspected of having created an account (done in many cases in order to maintain persistence) within the domain. Auditing for logon events was not enabled, but auditing for account management events was...and I was able to quickly find an event ID 624 record showing the creation of the suspicious

Other Resources
EventLogRecord structure
Windows Event Log Reference (Vista, 2008)
GrokEVT (Python-based)
ScreenClean

In my book, I covered the Windows 2000, XP, and 2003 EventLog file header and event record structure in some detail. There's also a Perl script or two on the DVD that accompanies the book that let you parse an Event Log without using the Windows API, so that you avoid that pesky message about the Event Log being corrupted.

I've since updated one of the scripts (changing the name to evt2xls.pl), so that now it writes the information that it parses from the Event Log file directly into an Excel spreadsheet, even going so far as to format the date field to that it "makes sense" to Excel when you want to sort based on the date. I've found that writing the data directly to a spreadsheet makes things a bit easier for me, particularly when I want to sort the data to see just certain event record sources, or perform some other analysis. I've also added some functionality to collect statistics from the Event Log file, and display information such as total counted event records, frequency of event sources and IDs, etc., in a separate report file. I've found these to be very useful and efficient, giving me a quick overview of the contents of the Event Logs, and making my analysis of a system go much smoother, particularly when combined with Registry analysis (such as parsing the Security file for the audit policy...see the Bonus directory on the DVD for the Perl script named poladt.pl and its associated EXE file). One of the things I'm considering adding to this script is reporting of successful and failed login attempts, basing this reporting in part on the type of the login attempt (ie, Service vs Local vs Remote).

Here's something to think about...there is sufficient information in the book, and Perl code on the DVD, such that you can create tools for parsing of event records from other sources, such as RAM dumps, the pagefile, and even unallocated space. I'm considering writing a couple of small tools to do this...not search the files, specifically (I can add that to the code that parses RAM dumps) but to start by simply extracting event records given a file and an offset within the file.

But what about actual Event Log analysis? What about really using the Event Log to get some insight into activity on the system? What can we look for and how can we use it?

Here are some tidbits that I've come across and use...please don't consider this a complete list, as I hope that people will contribute. This is just to get folks started...

Stephen Bunting has a great write-up that explains how to use the Event Log to track time change events, such as when someone alters their system time.

The Application Event Log is a great place to look for events generated by antivirus applications. This will not only tell you if an antivirus application is installed on the system (you can also perform Registry analysis to determine this information), but perhaps the version, when it was active, etc.

In the System Event Log, Event ID 6161 (Source: Print) tells you when a file failed to print. The event message tells you the name of the file that failed to print, the username, and the printer.

Also in the System Event Log, Event ID 35 (Source: W32Time) is an Information event that tells you that your system is sync'ing with a time server, and provides the IP address of your system. This can be very useful in a DHCP environment, as it tells you the IP address assigned to the system (actually, the interface) at a particular date and time.

Windows Defender (Source: WinDefend) will generate an event ID 1007 when it detects malware on a system; the event strings contain specific information about what was found.

Whenever you're doing Event Log analysis, be sure to go to EventID.net for help understanding what you're looking at. Most of the listed event IDs have detailed explanations of what can cause the event, as well as links to information at MS.

Again, this is not a complete list of items that you may find and use in your analysis...these are just somethings that come to mind. And remember, you get a bit more out of Event Log analysis when you combine it with Registry analysis, not only of the audit policy for the system and the settings for the Event Logs, but with other sources, as well.

Links
EventLog Header structure
Event Record structure
EventLog EOF record structure
EventLog File Format

I received an email from a friend recently, asking about finding an Event Log in unallocated (ne "free") space. He mentioned that he'd found it using a hex editor and copied it out of the image to a separate file, but still couldn't open it in the Event Viewer.

That got me thinking about the content of my book, and how that could be useful in a situation like this. On page 201 of Windows Forensic Analysis, table 5.3 lists the event record structure; that is, what an event record "looks like". With this information alone, event records can be retrieved from unallocated space; once you find the "magic number", back up 4 bytes and you've got the size of the event record. From there, you can copy out the entire event record and the rest of the information within the record can be easily parsed from unallocated space, or even from the pagefile or a RAM dump.

A post from another forum got me thinking that the same is true for Registry keys, as well. Figure 4.3 illustrates a hex view of what a Registry key and a Registry value "look like" on disk. Using this information, as well as the code listed on pgs. 133 and 134, Registry keys and values can be extracted and reconstructed from unallocated space, the pagefile, or even a RAM dump.

The great thing is that event records and Registry keys have time stamps associated with them (Registry values do not). This also illustrates what can be retrieved from these other areas through data carving...after all, event records and Registry structures have "magic numbers", similar to file headers, and their data can be carved out just as easily.