In my day job doing incident response, I find myself looking at a lot of Windows event logs. And I don’t know about the rest of you, but I do not find eventvwr.msc to be very user friendly to navigate and filter large files. If you are a XPATH master then sure, it’s probably just fine for you. I, however, am not.
I instead prefer to use the best incident response tool ever created – Microsoft Excel. Sorting, filtering, and searching is a snap!
The problem is in converting the binary XML .evtx files to csv. All the existing libraries and tools I have ever tried only break out the major fields in the event logs, leaving all the fields in the “Message” part of the events lumped together. All the good stuff I want to filter and search on is in locked away in there!
So I create a little script that breaks out every field in an event log into its own column. It iterates over the whole file to pull out the unique fields names from the sum of all events. So you end up with a column for every single field.
The script is on my github here: https://github.com/dewoodruff/evtx_to_csv
If you find it works for you please leave a comment. Or if there are improvements to be made, please submit a pull request!
This script does not appear to be working against Windows 10 “C:\Windows\System32\winevt\Logs\OAlerts.evtx” files. The error message I’m getting (“Key cannot be null.”) seems to indicate that the problem is due to the fact that some of the Message fields in the event log are not labeled with any name by Microsoft. Probably need to shove in a generic label (e.g., DATA1, DATA2, etc..) for any unlabeled fields.
Hi Clint, thanks for the comments. Give it a try now. I added placeholders as you suggested.
-Dan
Many thanks Dan! This new version doesn’t crash anymore while attempting to process the event log I’m feeding it.
However, the outputted csv file is turning out a little bit odd for me…
Some (but not all) of the rows appear to have been split into more “unlabeled” columns than one would expect.
In addition, although its really not that big of a deal, for some reason newline characters in the data text and actually being displayed as explicit “\n” chars in the output of the “unlabeled” fields.
FYI, I’m getting these results when attempting to process an “C:\Windows\System32\winevt\Logs\OAudits.evtx” file. This file should be present on just about any modern Windows system with MS Office installed. So recommend you try it out on your own to see what results you get. Thanks again!
Clint, I used that exact file from my Win10 system for testing, however it only had one event to work with. I did notice it parsed a little strangely, but I think that’s because each line is being considered a separate field since the fields aren’t actually labeled. Not sure there is much I can do about that that!
And the \n is needed and will appear in any of the logs that you parse with the script. CSV doesn’t handle the newlines from the raw messages well, so I have explicitly replaced them with the \n.
Dan
Hello
Nice script ! You saved a lot of my time
I like the comment in your script 🙂
# Note: this script is pretty slow
That’s true, unfortunately it’s pretty slow : step “Reading in the evtx” with cmdlet get-winevent last few minutes for a pretty small evtx file (5MB). Something I have to analyze 100MB, I don’t imagine time it will last.
Any idea to improve speed ?
Marc
Glad the script is helpful. I never was able to speed this script up, but I’ve moved on to using other tools like https://www.eventlogxp.com/ and KAPE EvtxEcmd – https://www.kroll.com/-/media/kroll/pdfs/webinars/event-log-analysis-evtxecmd-using-kape.pdf?la=en&hash=104DF6E511FFB26B71A40132904B32E80CE24E66
You might be able to accomplish something similar with EvtxEcmd.