How To...
...Parse Windows Event Logs
I caught a really interesting tweet the other day that pointed to the DFIR blog, one that discussed how to parse Windows Event Logs. I thought the approach was interesting, so I thought I'd share the process I use for parsing Windows Event Logs (*.evtx files).
So, I'm not saying that there's anything wrong with the process laid out in the DFIR blog post...not at all. In fact, I'm grateful that the author took the time to write it up and share it with others. It's a fantastic resource, but there's more than one way to accomplish a great many tasks in the DFIR world, aren't there? As Dan said, there are some great examples in the post.
When I create timelines, I use a batch file (wevtx.bat) that runs LogParser, and as the *.evtx logs are parsed, runs them through eventmap.txt to "tag" interesting events. The batch file takes two arguments, the path to a file or directory with *.evtx files (LogParser understands wild cards), and the output event file (events are appended to the file if the file already exists).
Now, I did say, "...when I create timelines...", but this method works very well with just *.evtx files, or even just a few, or even one, *.evtx file.
The methodology in the DFIR blog post includes looking for specific events IDs, which is great. The way I do it in my methodology is that when I parse all of the *.evtx files that I'm going to parse, I have an "events file"; from there, I can parse out event source/ID pairs pretty easily using "type" and "find". It's pretty easy, like so:
type events.txt | find "Security/4624" > logon_events.txt
You can then add to that file using the append redirection operator (i.e., ">>"), or search for other source/ID pairs and create other output files. I've used this method to create micro- or nano-timelines of just specific events, so that I can get a view of things that I wouldn't be able to see in a complete timeline.
Okay, why am I talking about event source/ID "pairs"? Well, in the DFIR blog post, they're looking in the Security Event Log file (Security.evtx) for specific event IDs, but when you start looking across other *.evtx files and incorporating them into your analysis, you may start to see that some event records may have different sources, but the same event ID, depending upon what's installed on the system. For example, event ID 6001 can have sources of WinLogon, DNS, and Wlclntfy.
So, for the sake of clarity, I use event source/ID pairs in eventmap.txt; I haven't seen every possible event ID, and therefore, don't want to have something incorrectly tagged. There's no reason to draw the analyst's attention to something if it's not necessary to do so.
Wait...What?
Okay, there are times when Windows Event Logs are not Windows Event Logs...that's when they're Event Logs. Get it?
Okay, stand by...this is the part where the version of Windows matters. I've gotten myself in trouble over the years for asking stoopit questions (after someone takes the time to write out their request), like, "What's the version of Windows you're examining?" I get it. Bad Harlan. But you know what...it matters. And I know you're going to say, "yeah, dude...but no one uses XP any more." Uh...yeah...no. During the summer of 2017, I was assisting with analyzing some systems that had been hit with NotPetya, and another analyst was examining Windows XP and 2003 systems from another client.
The reason this is important is that, in addition to there being many more log files available on Vista+ systems, the binary format of the log files themselves is different. For example, I wrote evtparse.exe (NOTE: there is NO "x" in the file name! Evtxparse.exe is a completely different tool!) specifically to parse Event Log files from XP and Win2003 systems. The great thing is that it does so on a binary basis, without using the MS API. This means that if the header information says that there are 400 event records in the file, but there are actually 4004, you will get 4004 records parsed.
I also wrote lfle.pl to parse Event Log records from unstructured data (pagefile, memory dump, unallocated space, etc.). I originally wrote this code to assist a friend of mine who'd been working on a way to carve Event Log records from unallocated space from a Win2003 server for about 3 months. Since I wrote it, I've used it successfully to parse records myself. Lots of fun!
I caught a really interesting tweet the other day that pointed to the DFIR blog, one that discussed how to parse Windows Event Logs. I thought the approach was interesting, so I thought I'd share the process I use for parsing Windows Event Logs (*.evtx files).
So, I'm not saying that there's anything wrong with the process laid out in the DFIR blog post...not at all. In fact, I'm grateful that the author took the time to write it up and share it with others. It's a fantastic resource, but there's more than one way to accomplish a great many tasks in the DFIR world, aren't there? As Dan said, there are some great examples in the post.
When I create timelines, I use a batch file (wevtx.bat) that runs LogParser, and as the *.evtx logs are parsed, runs them through eventmap.txt to "tag" interesting events. The batch file takes two arguments, the path to a file or directory with *.evtx files (LogParser understands wild cards), and the output event file (events are appended to the file if the file already exists).
Now, I did say, "...when I create timelines...", but this method works very well with just *.evtx files, or even just a few, or even one, *.evtx file.
The methodology in the DFIR blog post includes looking for specific events IDs, which is great. The way I do it in my methodology is that when I parse all of the *.evtx files that I'm going to parse, I have an "events file"; from there, I can parse out event source/ID pairs pretty easily using "type" and "find". It's pretty easy, like so:
type events.txt | find "Security/4624" > logon_events.txt
You can then add to that file using the append redirection operator (i.e., ">>"), or search for other source/ID pairs and create other output files. I've used this method to create micro- or nano-timelines of just specific events, so that I can get a view of things that I wouldn't be able to see in a complete timeline.
Okay, why am I talking about event source/ID "pairs"? Well, in the DFIR blog post, they're looking in the Security Event Log file (Security.evtx) for specific event IDs, but when you start looking across other *.evtx files and incorporating them into your analysis, you may start to see that some event records may have different sources, but the same event ID, depending upon what's installed on the system. For example, event ID 6001 can have sources of WinLogon, DNS, and Wlclntfy.
So, for the sake of clarity, I use event source/ID pairs in eventmap.txt; I haven't seen every possible event ID, and therefore, don't want to have something incorrectly tagged. There's no reason to draw the analyst's attention to something if it's not necessary to do so.
Wait...What?
Okay, there are times when Windows Event Logs are not Windows Event Logs...that's when they're Event Logs. Get it?
Okay, stand by...this is the part where the version of Windows matters. I've gotten myself in trouble over the years for asking stoopit questions (after someone takes the time to write out their request), like, "What's the version of Windows you're examining?" I get it. Bad Harlan. But you know what...it matters. And I know you're going to say, "yeah, dude...but no one uses XP any more." Uh...yeah...no. During the summer of 2017, I was assisting with analyzing some systems that had been hit with NotPetya, and another analyst was examining Windows XP and 2003 systems from another client.
The reason this is important is that, in addition to there being many more log files available on Vista+ systems, the binary format of the log files themselves is different. For example, I wrote evtparse.exe (NOTE: there is NO "x" in the file name! Evtxparse.exe is a completely different tool!) specifically to parse Event Log files from XP and Win2003 systems. The great thing is that it does so on a binary basis, without using the MS API. This means that if the header information says that there are 400 event records in the file, but there are actually 4004, you will get 4004 records parsed.
I also wrote lfle.pl to parse Event Log records from unstructured data (pagefile, memory dump, unallocated space, etc.). I originally wrote this code to assist a friend of mine who'd been working on a way to carve Event Log records from unallocated space from a Win2003 server for about 3 months. Since I wrote it, I've used it successfully to parse records myself. Lots of fun!