Interesting Analysis
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.
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.