Event Logs

I've discussed Windows Event Log analysis in this blog before (here, and here), but it's been a while, and I've recently been involved in some analysis that has led me to believe that it might be a good idea to bring up the topic again.

Formats
I've said time and again...to the point that many of you are very likely tired of hearing me say it...that the version of Windows that you're analyzing matters.  The available artifacts and their formats differ significantly between versions of Windows, and any discussion of (Windows) Event Logs is a great example of this fact.

Windows XP and 2003 use (I say "use" because I'm still seeing these systems in my analysis; in the past month alone I've analyzed a small handful of Windows 2003 server images) a logging format referred to as "Event Logs".  MS does a great job in documenting the structure of the Event Log/*.evt file format, header, records, and even the EOF record structure.  In short, these Event Logs are a "circular buffer" to which individual records are written.  The limiting factor for these Event Logs is the file size; as new records are written, older records will simply be overwritten.  These systems have three main Event Logs; Security (secevent.evt), System (sysevent.evt), and Application (appevent.evt).  There may be others but they are often application specific.

Windows Vista systems and beyond use a "binary XML" format for the Windows Event Log/*.evtx files.  Besides the different format structure for event records and the files themselves, perhaps one of the most notable aspects of Windows Event Logs is the number of log files available.  On a default installation of Windows 7, I counted 140+ *.evtx files; on a Windows 10 system, I counted 289 files.  Now, this does not mean that records are written to these logs all the time; in fact, some of the Windows Event Log files may never be written to, based on the configuration and use of the system.  However, it's often likely that if you're following clusters of indicators as part of your analysis process (i.e., looking for groups of indicators close together, rather than one single indicator or event, that indicate a particular action) it's likely that you'll find more indications of the event in question.

Tools
Of the tools I use (and provide along with the book materials) in my daily work, there are two specifically related to (Windows Event) Logs.

First, there is evtparse.exe.  This tool does not use the Windows API to parse Event Logs/*.evt files on a binary basis, bypassing the header information and basically "carving" *.evt files for valid records.

The ability to parse individual event records from *.evt files, regardless of what the file header says with respect the number of event records, etc., is valuable.  I originally wrote this tool after I ran into a case where the Event Logs had been cleared.  When this occurred, the "current" *.evt files were deleted (sectors comprising the files became part of unallocated space) and "new" *.evt files were created from available sectors within unallocated space.  What happened was that one of the *.evt files contained header information that indicated that there were no event records in the file, but there was clearly something there.  I was able to recover or "carve" valid event records from the file.  I've also used evtparse.pl as the basis for a tool that would carve unstructured data (pagefile, unallocated space, even a memory dump) for *.evt records.

The other tool I use is evtxparse.exe.  Note the "" in the name.  This is NOT the same thing as evtparse.exe.  Evtxparse.exe is part of a set of tools, used with wevtx.bat, LogParser (a free tool from MS), and eventmap.txt to parse either an individual *.evtx file or multiple *.evtx files into the timeline/TLN format I use for my analysis.  The wevtx.bat file launches LogParser to parse the file(s), writing the parsed records to a temporary file, which is then parsed by evtxparse.exe.  During that parsing, the eventmap.txt file is used to apply a modicum of "threat intel" (in short, stuff I've learned from previous engagements...) to the entries being included in the timeline events file, so that its easier for me to identify pivot points for analysis.

A major caveat to this is that LogParser relies on the native DLLs/API of the system on which it's being run.  This means that you can't successfully run LogParser on Windows XP while trying to parse *.evtx files, nor can you successfully run LogParser on Windows 10 to parse Windows 2003 *.evt files (without first running wevtutil to change the format of the *.evt files to *.evtx).

Both tools are provided as Windows executables, along with the Perl source code.

When I run across *.evtx files that LogParser has difficulty parsing, my go-to tool is Willi Ballenthin's EVTXtract.  There have been several instances where this tool set has worked extremely well, particularly when the Windows Event Logs that I'm interested in are reported by other tools as being "corrupt".  In one particular instance, we'd found that the Windows Event Logs had been cleared, and we were able to not only retrieve a number of valid event records from unallocated space, but we were able to locate THE smoking gun record that we were looking for.

Gaps
Not long ago, I was asked a question about gaps in Windows Event Logs; specifically, is there something out there that allows someone to remove specific records from an active Windows Event Log on a live machine?  Actually, this question has come up twice since the beginning of this year alone, in two different contexts.

There has been talk about there being, or that there have been, tools for removing specific records from Windows Event Logs on live systems, but all the talk comes back to the same thing...no one I've even spoken to has any actual data showing that this actually happened.  There's been mention of a tool called "WinZapper" likely having been used, but when I've asked if the records were parsed and sorted by record number to confirm this, no one has any explicit data to support the fact that the tool had been used; it all comes back to speculation, and "it could have been used".

As I mentioned, this is pretty trivial to check.  Wevtx.bat, for example, contains a LopParser command line that includes printing the record number for each event.  You can run this command line on a Windows 7 (or 10) system to parse *.evtx files, or on a Windows XP system to parse *.evt files, and get similar results.

Evtparse.exe (note that there is no "x" in the tool name...) includes a switch for listing event records sequentially, displaying only the record number and time generated value for each event record.  This output can then easily be sorted to look for gaps, or parsed via a script to do the same thing.  For example, using either tool, you can then simply import the output into Excel and sort based on the record numbers and search it manually/visually, or write a script that looks for gaps in the record numbers.

So, when someone asks me if it's possible that specific event records were removed from a log, the first question I would ask in response would be, were records removed from the log?  After all, this is pretty trivial to check, and if there are no gaps, then the question itself becomes academic.

Creating Event Records
There are a number of ways to create event records on live systems, should you be inclined to do so.  For example, MS includes the eventcreate.exe tool, which allows you to create event records (with limitations; be sure to read the documentation).

Visual Basic can be used to write to the Event Log; for an example, see this StackOverflow post.  Note that the post also links to this MSDN page, but as is often the case on the InterWebs, the second response goes off-topic.

You can also use Powershell to create new Windows Event Logs, or create event records.