Ingesting EVTX exports during an incident response
How I got a client's raw Windows event logs searchable during a major security incident.
In plain terms
Windows computers keep a record of what happens on them: logins, errors, changes and more. These are Windows event logs, and an export of them is saved as an EVTX file.
When a security incident happens, the people responding need to search those logs to work out what went on. Normally a client's logs flow into our systems on their own and are searchable right away. In this case the logs the team needed weren't coming in, so the team got EVTX exports from the client instead, and those had to be loaded another way.
It also had to happen without getting in the way of the live systems that process every other client's logs.
The problem
A large healthcare client had a major security incident, and the logs the response team needed weren't being ingested. The team got raw Windows event log (EVTX) exports from the client, and I had only a high-level overview to go on.
What I did
I set up a Windows VM and used Winlogbeat to read the EVTX files. They went to my machine, where a custom parser I wrote shaped the events, and then on to the production Logstash server.
There I ran a custom pipeline in a separate, isolated Logstash instance, with memory limits set in its command-line arguments so it couldn't starve live client ingest. I worked out the rest myself.
The outcome
The response team could search the client's logs, and I was recognised by Nclose's CEO and senior management.
Ethan Creamer-Houghton you have set a precedent