From EVTX Logs to MITRE‑Mapped Threats: Building a Lightweight UEBA Pipeline for LOLBins

The Problem: Too Much Noise

In cybersecurity, Windows computers create “mountains” of data called logs. Inside these logs are “LOLBins” — programs that are part of Windows but can be used by hackers to hide. Because these programs are “normal,” most security tools ignore them or create too many fake alerts.

I wanted to build a way to find the real threats without the noise.

Step 1: Finding the Clues (Parsing)

I started with raw Windows “EVTX” logs. These files are hard for humans to read. I wrote a Python tool to open these files and find “Process Creation” events. I focused on the Command Line — this is where a hacker’s “fingerprints” are usually left.

|   | EventID | TimeCreated         |
|---|---------|---------------------|
| 0 | 4688    | 2026-01-25 14:20:01 |
| 1 | 4688    | 2026-01-25 14:21:15 |
| 2 | 4688    | 2026-01-25 14:22:30 |

Step 2: Thinking Like a Researcher (MITRE Mapping)

I didn’t just look for random bad stuff. I focused on a specific technique called T1218. This is a method where attackers use a trusted Windows program (like rundll32.exe) to run malicious code. By focusing on a real-world technique used by professional hackers, the project became much more practical.

MITRE threat research:
|    | MITRE_ID   | Technique          |   Events_Parsed | Parser_Status   |
|---:|:-----------|:-------------------|----------------:|:----------------|
|  0| T1218.001  | Rundll32 Execution |               30 | Success         |

Step 3: Using AI to Find the “Weird” Stuff

Instead of writing thousands of brittle rules, I used Machine Learning — specifically an Isolation Forest. Imagine a room full of people wearing white shirts. If someone walks in wearing a bright red shirt, they stand out. My AI does the same thing: it learns what “normal” commands look like and flags the “weird” ones as threats.

In the notebook, I start with a small set of realistic T1218‑style commands:

Then I vectorize them using TF‑IDF and run an Isolation Forest:

After vectorizing, the model correctly flags the first line as anomalous (anomaly_score = -1) while treating benign GUI apps as normal. This mimics what you’d see in a real UEBA‑style system: rare, parameter‑heavy LOLBin commands stand out from everyday activity.

Step 4: Making it Useful for the Team

A project is only good if a security team can use it. I turned my findings into a Sigma Rule. This is a standard format that companies use to set up their security alerts. It takes the “brain” of my AI and turns it into a simple alert that a security analyst can understand.

To make this easier to interpret, I also generated a pipeline visualization that shows:

1. Events processed
2. Command lines extracted
3. MITRE‑coverage pie chart
4. Overall pipeline status

The plot turns the notebook into something an analyst or manager can glance at and immediately understand: where the data comes from, what’s being analyzed, and how complete the pipeline is. It also bridges the gap between the “AI‑magic” in Step 3 and the operational alerts that a SOC would actually use.

The Results

By the end of the project, my system was able to catch 86% of the test attacks. Why 86%? — The remaining 14% were false negatives due to a high ‘contamination’ setting in the model, which can be tuned based on the specific network environment.

Scalability: The parser can be swapped for a real-time collector (like Velociraptor), and the ML can be moved to a cloud function.

This shows that we don’t need giant, expensive tools to catch hackers — sometimes a smart, lightweight pipeline is all you need.

Check out the full implementation and sample logs on my GitHub Repo: https://github.com/suvinmajithia/Endpoint-behaviour-detection