I’ve been doing IR for a long time and I can’t believe I have only now discovered the power of LogParser. Perhaps I was too spoiled by Splunk to actually be forced to learn this awesome tool. But now that I have gotten familiar with it, I see why it is so beloved. It’s powerful and SQL-friendly command line capabilities give it a ton of flexibility and provide lots of opportunity for automation. While getting acquainted with it, and wanting to document my learning, I decided to create some batch files which capture syntax and intent.
LogParser.exe has been around a long time. Version 2.2 was released around 2006 and there are a few GUI front-ends available (e.g. LogParser Lizard and Log Parser Studio). A quick google search suggests it is more popular among IIS log searchers than EVT(X) uses.
Goal 1. Converting EVTX to CSV
I am often handed a set of IR triage artifacts that includes a file system containing event log files in EVTX format. This binary format is truly unfriendly and neither Excel, nor Splunk can work with it. However, LogParser can! If this were all it could do, it woudn’t be worth mentioning since there are Powershell options to do this as well:
get-winevent -path .\files\c\windows\system32\winevt\logs\*.evtx| export-csv FileName.csv -useculture
To quote on Redditor (’13cubed’): “While you can certainly obtain logs with Get-WinEvent, Log Parser can query just about any text-based data source, not just logs. It is more scalable, and allows for fast searches of massive amounts of data allowing you to filter on a wide variety of things, such as event ID’s, usernames, IP addresses, and more.”
Since I wanted to learn LogParser anyway, I figured it would be helpful to figure this out for starters.
LogParser doesn’t work well with pipes (e.g. logparser.exe > eventlog.csv). Instead, since it uses SQL-like syntax. You have to “INSERT INTO” the location you want to export to. The following syntax works well for “point and shoot” batch-file double-clicking at the root of a mounted directory of artifacts.
logparser.exe “select * INTO Security.csv from ‘.\c\windows\system32\winevt\logs\Security.evtx'” -i:EVT -headers:ON
A batch file to pull only to the log files mentioned in the SANS poster and JP Cert paper (see Goal 3) can be found here.
Now that I have CSVs I can use grep, Splunk, ELK or Excel to do further analysis. But I want to be able to do blue-team work even when my fancy analytics tools aren’t available.
Goal 2. Push Button Event Log Triage
We are all busy. Even if we have the appetite to trawl through thousands of logs manually, if we can speed up the identification of weird/suspicious events, we can apply our brain power elsewhere and be more efficient. I wanted a quick way to summarize certain kinds of information in the logs such that an analyst could look at the output and more quickly identify things which may warrant a closer look.
Since LogParser seems to think in T-SQL, it is a great command line option for some simple data stacking (aka frequency analysis and anomaly detection). I created a set of queries which stack things like users, processes, services, scheduled tasks, domains, remote machines. I found a great resource with many examples of these commands at this github page and borrowed a lot of it making small tweaks here and there.
Since “pipes” don’t work, I had to figure out how to export/append the results to a single file for quick review by an analyst. Adding “INTO exportfile.txt” before “FROM” in the SQL gets the export done, but the append operation also requires ” -filemode:0″ at the end of each query. I chose to name my export file “WELDS.txt” as a corny acronym for “Windows Event Log Data Summaries.”
These queries dump numerous histogram-like count summaries of interesting data elements. It may be helpful to search at the lower end of the frequency table to fin things which are relatively rare.
My favorite part of this script is the summary of process execution events where I have paired the parent process with the child process. Typically, Proc2 is the parent and Proc1 is the child.
LogParser.exe -stats:OFF -i:EVT “SELECT COUNT(*) AS CNT, EXTRACT_TOKEN(Strings, 5, ‘|’) AS Proc1, extract_token(strings, 13, ‘|’) as Proc2 INTO WELDS.txt FROM ‘.\files\c\windows\system32\winevt\logs\Security.evtx’ WHERE EventID = 4688 AND (Proc1 LIKE ‘%.%’ AND Proc2 LIKE ‘%.%’) GROUP BY Proc1, Proc2 ORDER BY CNT ASC”
The results are found near the end of the WELDS.txt file. In the absence of EDR or a memory capture, this can be very helpful in determining strange processes relationships (e.g. we would not want to see cmd.exe starting iexplore.exe).
Goal 3. Know Normal, Find Evil
While there are seemingly endless ways to “find evil” SANS has provided us with a “greatest hits” of suspicious event IDs to pay close attention to in the form of the 2018 “Know Normal – Find Evil” poster. This is a quick reference for event logs, registry entries, and prefetch artifacts which incident responders can use to focus their first review of a suspect endpoint.
The Japanese CERT has also provided a wonderful paper on detecting lateral movement with similar artifacts.
The third batch file seeks to capture each of these pearls of wisdom in a “push-button” friendly way to cull the massive number of events in the evtx files down to only those which are highlighted in these two documents as likely to reveal suspicious activity. I made an attempt to ECHO helpful comments about what each query is doing. This script output is very verbose and most likely needs additional tuning to make it worth while. However, it’s a handy quick reference you can copy/paste from to target specific EventIDs of interest when responding to a suspected compromise.
My final batch file was inspired by the SANS DFIR Summit presentation on AppCompatProcessor. Among many other promising things (e.g. advance statistical anomaly detection), this tool uses a list of “recon” strings to identify clusters of commands which are more likely to be indicative of an adversary performing recon on the machine or network in search of additional opportunities. Commands such as net.exe, whoami.exe, ping.exe, etc are collected and displayed in timeline format.
That’s all for now. Hopefully, this shows you the power of LogParser and gives some ideas on how it can be used to quickly triage evidence in incident response.
P.S. this is a small taste of the kind of information I’ll be teaching at the SANS FOR508 Class starting in Richmond, VA on March 6th. Details here: https://www.linkedin.com/feed/update/urn:li:activity:6483781362825392128/