DEV Community: Jude Hilgendorf

Auditing Windows security from a Python script, no pip install needed

Jude Hilgendorf — Sun, 10 May 2026 09:17:16 +0000

I had a problem. I wanted a Windows security audit script I could drop on any machine, run as admin, and walk away with a readable report. Just a single .py file. No pip install, no virtualenv, no "wait, do you have Python 3.10 or what."

The catch is that "real" Windows auditing tools usually pull in pywin32, wmi, or some chunky vendor SDK. None of that flies on a locked down workstation. So I tried writing the whole thing on the standard library.

That is what WinRecon turned into. 20 checks, single Python module, no dependencies past stdlib.

Here's how the dependency-free constraint shaped the architecture.

For registry reads I went straight to winreg. Anything that needs Windows tooling goes through subprocess with the actual built-in binaries (netstat, net, sc query, wmic, and PowerShell for Defender and audit policy queries). It is not elegant. You end up parsing CLI text output a lot. But it works on a fresh Windows 11 box with nothing installed.

Example. Getting Defender status without pywin32. PowerShell already returns it as JSON, you just have to ask:

def get_defender_status():
    cmd = [
        "powershell", "-NoProfile", "-Command",
        "Get-MpComputerStatus | ConvertTo-Json"
    ]
    result = subprocess.run(cmd, capture_output=True, text=True, timeout=60)
    if result.returncode != 0:
        return None
    return json.loads(result.stdout)

Subprocess plus ConvertTo-Json got me out of a hole on probably half the checks. WMI bindings would have been faster but the trade is dependencies, and I wanted the script to just run.

The 20 checks cover the obvious stuff (firewall state, RDP config, password policy, open ports, BitLocker, Credential Guard, Secure Boot, audit policy, antivirus status) plus the stuff a SOC analyst actually wants to see: suspicious scheduled tasks, sketchy startup entries, weird PowerShell flags. The scheduled task check looks for things like encoded payloads (-enc, frombase64string), LOLBins (certutil, bitsadmin, regsvr32), -windowstyle hidden, IEX, and C2 indicators like ngrok or pastebin URLs. Cheap pattern matching but it catches the lazy stuff.

Output is a self-contained HTML report. All CSS inlined, no external assets. You can email it, drop it on a fileshare, open it on a stripped down server, and it renders. There is also a JSON file for anyone who wants to parse findings into a SIEM later.

Scoring is dumb on purpose. Each finding is CRITICAL (-20), WARNING (-10), or PASS/INFO (0). Start at 100, deduct, end with a letter grade A through F. The point is not "is this CVSS-accurate." The point is that you can hand the HTML to a non-security person and they get it in three seconds.

What broke along the way.

The biggest pain was admin vs standard user. Some checks (BitLocker, audit policy, credential guard, firewall details) just fail or return degraded results without elevation. I wanted them to fail loudly without crashing the whole run, so each check returns a Finding object with status PASS, WARNING, CRITICAL, or INFO, and the runner aggregates them. If one check explodes, the others still finish. Took me a couple iterations to stop having one bad subprocess timeout kill the whole report.

The other thing I underestimated: HTML escaping. All those scheduled task names and registry values go straight into the report. If a malicious task name had <script> in it, my report would happily render it. So I added pytest coverage specifically for the escape path, and a test that drops <img src=x onerror=alert(1)> into a finding to make sure it comes out as text. Coverage is at 80% min, which feels right for a tool you might run on a real machine.

Things I would still fix.

The grading is too coarse. A box with one critical finding and 19 passes lands a C. That is fine for "is this safe" but it overweights single critical findings. I want to weight them by category eventually, so a missing antivirus is not the same as a deprecated SMBv1 enabled.

Subprocess timeouts also have a default of 60s per check, which is fine on a normal machine and miserable on a slow domain-joined one. I should make them adaptive.

The suspicious-pattern detector is regex on strings, which means false positives. A scheduled task named "regsvr32-cleanup" gets flagged. The custom keywords file partially fixes this but I should ship a default trusted-paths list that covers common vendor software.

If you have a Windows machine and 30 seconds:

git clone https://github.com/TiltedLunar123/WinRecon
cd WinRecon
python -m winrecon

It writes the HTML to ./winrecon_reports/. Open it. Tell me which check is wrong on your box. That is actually the most useful feedback I can get right now.

Repo: https://github.com/TiltedLunar123/WinRecon

Testing Sigma Rules Against Local Logs Without a SIEM

Jude Hilgendorf — Wed, 06 May 2026 13:23:48 +0000

I'd written a few Sigma rules for my home lab and wanted to know if they actually fired on real Sysmon events. The standard answer is "deploy to Wazuh and replay logs". That's a lot of overhead when I just want to confirm a regex matches.

So I built SIEMForge. It's a Python CLI that loads Sigma YAML files, parses the detection logic, and matches it against JSON, JSONL, syslog, or CSV log files locally. No SIEM required.

This post is the messy version of how it came together. The final code is on GitHub at github.com/TiltedLunar123/SIEMForge.

The problem

I had ten Sigma rules covering things like LSASS dumps, suspicious PowerShell, and registry persistence. To validate them I'd been:

starting Wazuh in a VM
shipping a Sysmon JSONL via filebeat
SSHing to the manager and tailing alerts.log
realizing the rule didn't fire because I had a typo in the field name

Round trip on a single rule edit was about 4 minutes. For ten rules iterating through false positive checks, the math gets bad.

What I actually wanted: siemforge --scan events.json and a list of which rules fired with which event ID.

First attempt: just regex everything

Naive plan. Sigma rules look simple. They have a detection block with selection, filter, and condition keys. The condition usually says selection and not filter. How hard can it be?

Hard. The condition language allows:

selection
selection and filter
selection or filter
selection and not filter
1 of selection*
all of them

I started with a bare boolean parser that handled and, or, not. About 70% of my rules worked. The 1 of selection* ones broke. So did the wildcards in field values like CommandLine|contains: '*-ep bypass*'.

I rewrote the matcher around a small expression tree instead of regex. Each detection block compiles to a callable: given an event dict, return bool. The condition is parsed once at load and evaluated per event.

def compile_selection(selection: dict) -> Callable[[dict], bool]:
    matchers = []
    for key, value in selection.items():
        field, _, modifier = key.partition("|")
        matcher = build_field_matcher(field, modifier or "equals", value)
        matchers.append(matcher)
    return lambda event: all(m(event) for m in matchers)

build_field_matcher handles contains, startswith, endswith, and re modifiers. Wildcards in raw values (*-ep bypass*) get translated to a contains check at compile time.

The field name problem

Sysmon JSON via Wazuh ships fields as process.command_line. Raw Sysmon EVTX via evtxecmd ships them as CommandLine. Splunk ships them as CommandLine too but inside a _raw blob.

My rules were written against the EVTX naming. When I tested against the Wazuh-formatted JSON, nothing matched. Took me an hour to figure out why.

Two options: rewrite all the rules, or normalize the events. I went with normalize. There's a field_aliases.yml that maps common variants:

CommandLine:
  - process.command_line
  - data.win.eventdata.commandLine
  - winlog.event_data.CommandLine

The scanner tries each alias when the canonical field is missing. Not pretty but it stopped me from owning two copies of every rule.

What actually works

After three rewrites the scanner runs on a 4823-event Sysmon dump in under a second. Output looks like:

[*] Scanning /var/log/sysmon/events.jsonl (jsonl, 4823 events)

[ALERT] Rule: Suspicious PowerShell Download Cradle
        Technique: T1059.001
        Event #312 | 2026-03-14T08:41:02Z
        CommandLine: powershell -ep bypass -c "IEX(New-Object Net.WebClient).DownloadString(...)"

[*] Scan complete: 2 alerts across 4823 events

That's the round trip I wanted. Edit a rule, rerun, see if it fires. About 2 seconds end to end now.

The Sigma to Splunk/Elastic/Kibana converter is a side benefit. Same compiled tree, different emit step.

What's broken

Plenty.

The syslog parser is held together with tape. RFC 3164 vs RFC 5424 timestamp detection works on the obvious cases, but if the host writes a non-standard date format (looking at you, pfSense) fields end up mis-split. I have a TODO to switch to pyparsing instead of my hand-rolled tokenizer.

The MITRE coverage matrix is per-rule, not per-technique. It tells you which rule covers which technique, but not which techniques you have zero coverage on. That's the actually useful direction. v3.2 work.

Sigma's 1 of operator is implemented for selection groups but not for conditions like 1 of selection_*. About 10% of public Sigma rules use that pattern, so the rule loader currently warns and skips them.

What I'd do differently

I should have started with the reference Sigma backend (pySigma) instead of writing a parser from scratch. By the time I realized that, I'd already shipped two converters and ripping it out felt worse than maintaining the homegrown one. If I started today I'd wrap pySigma and add my own scanner on top.

Test data. I waited too long to build sample log files for each technique. Now there's a samples/ directory with process injection, service installation, user creation, CSV examples, and a clean baseline for false positive checks. Should have been there from commit one.

CI. I added it at v3.0 after a regression broke the Splunk converter on Windows. 138 tests run on every push now. Worth the upfront cost.

Use it

git clone https://github.com/TiltedLunar123/SIEMForge.git
cd SIEMForge
pip install pyyaml
python -m siemforge --scan samples/events.jsonl

If you write Sigma rules and hate the deploy-test loop, give it a try. Issues and PRs welcome. There's a CONTRIBUTING file with rule submission guidelines.

Repo: https://github.com/TiltedLunar123/SIEMForge

My Sigma rule was silently failing and the test suite didn't catch it

Jude Hilgendorf — Tue, 05 May 2026 11:14:24 +0000

I'm 18, taking cybersecurity at a community college in Michigan, and most of my detection engineering knowledge comes from reading other people's Sigma rules at like 1am. So when I started building SIEMForge, an open source toolkit that bundles Sigma rules with a Sysmon config and Wazuh custom rules mapped to MITRE ATT&CK, I figured the rules part would be the easy bit. Wrong.

Here's the bug that took me two evenings to actually understand.

The setup

SIEMForge ships with 10 detections in rules/sigma/. They cover the usual suspects: PowerShell download cradles, LSASS dumps, mshta and rundll32 abuse, Run key persistence, scheduled tasks, that kind of thing. There's also a CLI scanner I wrote that loads every rule and runs it against a log file (JSON, JSONL, syslog, or CSV). The point is to test rules locally before you ship them into Splunk or Elastic, so you don't write a rule, deploy it, and then realize three weeks later that it's never fired.

I had one extra rule sitting in a branch called ssh_bruteforce_burst.yml. The intent was simple: if you see N failed ssh logins from the same source IP inside a short window, fire an alert.

I dropped it into the rules folder, ran my sample syslog through the scanner, and got zero alerts. Which would've been fine, except I had also dropped 50 fake "Failed password for root from 198.51.100.4" lines into the syslog sample. Should've been a wall of red.

What I checked first

The dumb stuff first, like always.

Was the rule actually loaded? Yes. The scanner logged [*] Loaded 11 Sigma rules instead of 10.
Was the syslog parser reading the right fields? I added a --verbose flag and dumped the parsed events. Confirmed program=sshd, message="Failed password for root from 198.51.100.4 port 51234 ssh2". Looked fine.
Was the rule selectable in isolation? I ran the converter against just this rule and it spat out valid Splunk SPL. No errors.

So the rule loaded, the events parsed, the conversion worked. And nothing matched.

The actual problem

I went and re-read the Sigma spec for like the third time and noticed something. My detection block looked like this:

detection:
  selection:
    program: sshd
    message: 'Failed password'
  condition: selection | count() by source_ip > 10

The issue is that condition doesn't take an aggregation expression in the form I had written. The correct form puts the aggregation as part of the rule using a separate timeframe field and a condition that references the count. Mine was a frankenstein of old Sigma syntax I'd half-remembered from a blog post.

Worse, my scanner code did the right thing technically. It looked at condition: selection, found the events that matched the selection, and then tried to evaluate | count() by source_ip > 10 as a literal pipeline. My pipeline parser saw something it didn't recognize and bailed silently with a False result, which is exactly the wrong default.

That's the real bug, by the way. The rule file was wrong, but the scanner not telling me it was wrong is what cost the two hours.

The fix

Two changes. First, I rewrote the rule with proper field-condition mapping:

detection:
  selection:
    program: 'sshd'
    message|contains: 'Failed password for'
  timeframe: 5m
  condition: selection | count(source_ip) by source_ip > 10

Second, and more importantly, the scanner now raises on unknown pipeline operators instead of returning False. Here's the relevant chunk in siemforge/scanner.py:

def evaluate_condition(self, condition: str, matches: list) -> bool:
    if "|" in condition:
        base, *pipeline = [p.strip() for p in condition.split("|")]
        result = self._evaluate_base(base, matches)
        for op in pipeline:
            handler = self._pipeline_handlers.get(self._op_name(op))
            if handler is None:
                raise UnknownPipelineOperator(
                    f"unknown pipeline operator '{op}' in condition '{condition}'"
                )
            result = handler(result, op)
        return result
    return self._evaluate_base(condition, matches)

The UnknownPipelineOperator is a custom exception that gets caught one level up and surfaced as a load-time error with the rule filename. So now if a rule is malformed in a way the scanner can't handle, you find out when you load it, not when you wonder why nothing's firing.

Test count went from 137 to 138 because I added one specifically for this case: feed a rule with a garbage pipeline op, assert that loading raises.

What's still broken

Some honest disclosure since this is a portfolio project, not a real product.

The aggregation pipeline in the scanner only supports count() by <field> > N right now. Any other aggregation isn't implemented. It just raises the same exception. That's better than silently passing, but it's not actually doing detection on those rules yet.
The syslog parser is RFC 3164 plus a fallback for RFC 5424. It does not handle vendor-specific formats like Cisco ASA out of the box. You'd need to preprocess.
I don't have a real corpus of malicious vs benign logs to measure false positive rates. The CI just smoke-tests that rules load and the converters produce non-empty output. That's not the same as knowing if a rule is good.

What I'd tell past me

Two things.

One, if you're writing a rule and the test data should match and it doesn't, the bug is in either the rule, the parser, or the matcher. Add print statements to all three before you start theorizing. I wasted an hour assuming it was the syslog parser when it wasn't.

Two, if your detection engine returns False on something it doesn't understand, you've built a system that will lie to you. Always raise. Always.

If you want to look at the code or fork it for your own home lab, the repo is at github.com/TiltedLunar123/SIEMForge. v3.1 has the fix and the expanded test suite. PRs welcome, especially if you've got rules you've tested in the wild.

How I taught a log scanner to tell brute force from credential spray

Jude Hilgendorf — Sat, 02 May 2026 10:14:52 +0000

I've been building a CLI tool called ThreatLens. It parses EVTX, JSON, Syslog, and CEF logs offline, runs detection rules, and spits out alerts mapped to MITRE ATT&CK. One of the first detectors I wrote was for failed logons (Event ID 4625). Easy, right? Count the failures, threshold it, alert if it crosses N in a window.

That worked for about ten minutes.

The problem showed up when I fed it a real-looking dataset with both a brute force attack and a password spray happening at the same time. My detector lit up on the brute force (one IP hammering one account) but completely missed the spray (one account name being tried against 30 hosts from different sources, slowly). They're both T1110 in MITRE land, but operationally they look nothing alike, and lumping them together meant tuning the threshold either let real attacks through or buried analysts in noise.

So I split them.

What I tried first

The naive version groups by source_ip and counts failed events. Something like:

def detect_brute_force(events, threshold=5, window_seconds=60):
    buckets = defaultdict(list)
    for e in events:
        if e.event_id == 4625:
            buckets[e.source_ip].append(e.timestamp)
    alerts = []
    for ip, times in buckets.items():
        times.sort()
        for i in range(len(times) - threshold + 1):
            if (times[i + threshold - 1] - times[i]).seconds <= window_seconds:
                alerts.append(make_alert(ip, times[i:i + threshold]))
                break
    return alerts

Fine for the textbook brute force. Useless for spray.

The thing is, spray doesn't burst from one IP. It rotates targets. A single account hits five hosts, then ten, paced out so no individual host's failed-logon bucket trips. If you're grouping by source, you'll never see it. If you crank the threshold down to compensate, every misconfigured printer in the building becomes a "brute force" alert.

What worked

Two detectors, two grouping keys, two threshold profiles. Brute force groups by (source_ip, target_username) and looks for tight bursts. Spray groups by target_username only and looks for breadth across distinct hosts in a wider window.

# brute-force: tight, narrow, single source
GROUP_BY = ("source_ip", "target_username")
THRESHOLD = 5
WINDOW = 60  # seconds

# spray: wide, slow, single target
GROUP_BY = ("target_username",)
DISTINCT_FIELD = "computer"  # how many hosts did this account hit?
THRESHOLD = 5
WINDOW = 300

The spray detector is basically asking a different question: "did anyone try this account against an unusual number of hosts in a short window?" Counting raw events doesn't help here. What helps is counting distinct hosts touched.

Once I had both, I added a small ranking step. If both fire on the same dataset, the brute force usually fires first (smaller window) and the spray fires on the same account but against different hosts. The output now flags both with separate severity, separate evidence, separate recommendations. An analyst can tell at a glance which one to chase.

The code path that actually ships

It ended up living in threatlens/detections/brute_force.py. Two classes, both subclassing the same DetectionRule base, both producing Alert objects with the same shape. The base class handles time-window grouping so each detector only writes its own correlation logic. You can tune both via rules/default_rules.yaml without editing Python. Service accounts get suppressed with an allowlist that takes a reason field, which sounds dumb but it's been useful for remembering why the line is there six months later:

allowlist:
  - rule_name: "Brute-Force"
    username: "svc_monitor"
    reason: "service account, expected failed auths from health check"

What's still broken

A few things that bug me.

The detection is window-based, not session-aware. If a spray runs slowly enough to fall outside the 5-minute window but completes over 30 minutes, I miss it. I've thought about a sliding global account-watch list with decay, but I haven't written it yet.

The MITRE mapping is correct but coarse. Both detectors emit T1110 with no sub-technique. I want to add T1110.001 (password guessing) and T1110.003 (password spraying) explicitly so downstream tools can tell them apart without parsing my description string.

There's no enrichment for source IP. I don't know if the spray is coming from a known-bad ASN, a Tor exit, or just the marketing intern who forgot a password. The architecture supports a plugin step for this, I just haven't written that plugin.

What I'd do differently

If I started over, I'd build the time-window grouping primitive first and then write detectors on top, instead of writing each detector with its own buckets. I refactored to that shape after the fourth or fifth detector and it would have saved me a lot of duplicated correlation code.

The repo is at github.com/TiltedLunar123/ThreatLens. It's MIT, runs on Python 3.10+, only runtime dep is PyYAML, and there's a Docker image if you don't want to deal with venvs. Sample logs are included so you can run it and see what the output looks like in about 30 seconds.

It works. Not perfect but it works.

After event viewer crashed on a 400mb evtx, i wrote my own log triage cli

Jude Hilgendorf — Fri, 01 May 2026 09:53:27 +0000

last week i was poking through event logs from a home lab vm i suspected had been scanned hard. dropped the evtx into event viewer. it took 90 seconds to load, then crashed the moment i tried to filter by event id 4624.

splunk is overkill for one machine. wazuh wants infra i didn't want to set up just to look at one file. pysigma converts sigma rules to backend queries, but i didn't have a backend. so i wrote threatlens.

it's a cli. point it at a log file or directory, get alerts mapped to mitre att&ck.

threatlens scan logs/ --min-severity high

that's the whole interface for the common case.

what i actually wanted

three things, roughly in priority order.

works on a single laptop with no infra. no daemon. no agent. no message queue. only runtime dep is pyyaml.

reads the formats i actually have. evtx (windows native), json/ndjson (modern stuff), syslog (linux), cef (network gear).

speaks sigma. the community has thousands of detection rules already written. i didn't want to invent another rule format.

what i tried first

python-evtx for parsing, which worked fine. then plyara for sigma (turns out plyara is yara, not sigma, oops). then pysigma, which converts sigma to backend queries. i didn't want a query string, i wanted in-memory matching against parsed events.

the precedence stuff bit me hard. my first parser handled a or b and c left-to-right and got the wrong answer half the time. rewrote it three times before it matched sigma's reference behavior.

the part i'm most proud of

the elasticsearch output. i wanted to push alerts to ES so they'd show up alongside other security data. the official elasticsearch python client is 40mb installed and pulls in dozens of transitive deps i didn't want to audit.

then i remembered: the bulk api is just newline-delimited json over http.

import json, urllib.request

def push_alerts(alerts, url, index, api_key=None):
    lines = []
    for a in alerts:
        lines.append(json.dumps({"index": {"_index": index}}))
        lines.append(json.dumps(a.to_dict()))
    body = ("\n".join(lines) + "\n").encode("utf-8")

    headers = {"Content-Type": "application/x-ndjson"}
    if api_key:
        headers["Authorization"] = f"ApiKey {api_key}"

    req = urllib.request.Request(
        f"{url.rstrip('/')}/_bulk",
        data=body,
        headers=headers,
        method="POST",
    )
    with urllib.request.urlopen(req) as resp:
        return json.loads(resp.read())

stdlib only. works against real ES clusters. saves about 40mb of install size and removes a whole category of supply chain risk.

attack chain correlation

single alerts are noisy. "failed logon" by itself means nothing. "failed logon burst, then privilege escalation, then lateral movement on the same account inside a 10 minute window" is a story.

the chain detector groups alerts by username and timestamp, then walks them through kill chain order. credential access then priv esc then lateral movement then execution. if the order matches and the events sit inside a tunable time window, it fires a single high severity chain alert that links back to the constituent events.

against a 52 event mixed-noise dataset i wrote, it pulls out two distinct chains and produces zero false positives on the benign activity. focused 26 event simulation lights up correctly too.

the 12 detectors

each one is a separate python module subclassing a DetectionRule base. brute force, lateral movement, privilege escalation, suspicious process, defense evasion, persistence, discovery, exfiltration, kerberos attacks (kerberoasting and as-rep roasting), credential access (lsass, sam, dcsync), initial access (external rdp, after-hours logons), and the chain correlator.

custom yaml rules and sigma rules get loaded on top of those. you can also drop a .py file into --plugin-dir and the loader picks it up at scan time.

what's still rough

the html report works but the css is ugly. svg donut chart for severity, expandable evidence per alert, but the typography needs polish.

i haven't tested against a real enterprise dataset. sample data is hand-crafted to exercise specific detectors. there's a synthetic generator for 1000 event datasets, but synthetic isn't real.

sigma loader doesn't handle count() by aggregations yet. doesn't handle cross-rule correlations either. those are the next two things on the list.

native evtx parsing requires python-evtx as an optional extra. without it you have to export to json first. i'd rather auto-detect at runtime and fall back gracefully.

what i'd do differently

write the sigma test corpus before the parser. every fix would have been faster with real test cases in place.

design the alert model around elasticsearch field naming rules from day one. had to rename three fields late because they weren't valid es field names.

decide upfront whether it's a tool or a framework. threatlens is mostly a tool, but the plugin system pushed it toward framework, and the ambiguity cost some design clarity.

links

repo: https://github.com/TiltedLunar123/ThreatLens

if you do detection work and the sigma compat breaks on a real community rule, open an issue. that's the part i most want stress-tested.

I Built a Privacy-First Chrome Extension That Saves Your Forms Locally, Zero Network Requests

Jude Hilgendorf — Fri, 01 May 2026 01:20:11 +0000

I Built a Privacy-First Chrome Extension That Saves Your Forms Locally

You're 800 words deep into a job application. Tab crashes. Refresh. Gone.

We've all been there. Most "form saver" extensions phone home to some SaaS with a freemium tier and a privacy policy nobody reads. I wanted the opposite: something that runs entirely on my machine, never makes a network request, and just works.

So I built FormVault, an open-source Chrome extension that auto-saves form data to local storage, with a one-click restore toast when you come back to the page.

GitHub: https://github.com/TiltedLunar123/FormVault

What it does

Auto-saves any form field you type into, debounced 3 seconds after your last keystroke
Pops a non-intrusive toast when you revisit a page with saved data
Skips passwords, credit card fields, SSNs, never saved, period
Banking sites blocked by default, with a user-configurable domain blocklist
All UI injected via Shadow DOM so it never collides with host page styles
100% local storage. Zero fetch calls. Zero analytics. Zero telemetry. Verifiable in the source.

It's Manifest V3, MIT-licensed, and the entire codebase is small enough to audit in an afternoon.

Why I built it

I'm a cybersecurity student. I spend a lot of my time studying how user data leaks through "convenience" features. Every time I install a browser extension, I read its permissions and skim its code. Most form auto-savers either sync to a cloud (which means your half-finished forms, including stuff that should have been redacted, sit on someone else's server), or they have hidden analytics calls.

I wanted the boring, paranoid version: storage stays on your machine, code is small, nothing exfiltrates. Building it also forced me to learn a few things about the Chrome extension platform that I'd been hand-waving over.

The interesting technical bit: making auto-restore work with React

Here's where it got fun. Saving form values is easy, you addEventListener('input', ...) on every field, debounce, write to chrome.storage.local, done. Restoring is where most extensions fail silently on modern apps.

Set input.value = 'foo' on a React-controlled input and... nothing visible happens. The DOM updates, but React's internal state still has the old value, and the next render snaps it back. Same story with Vue, Svelte, and most reactive frameworks.

The fix is to call the native value setter directly and then dispatch the events React's synthetic event system listens for:

function setReactCompatibleValue(el, value) {
  // Use the native setter from the prototype, not the framework's overridden one
  const proto = el instanceof HTMLTextAreaElement
    ? HTMLTextAreaElement.prototype
    : HTMLInputElement.prototype;
  const nativeSetter = Object.getOwnPropertyDescriptor(proto, 'value')?.set;

  if (nativeSetter) {
    nativeSetter.call(el, value);
  } else {
    el.value = value;
  }

  // React listens to these, bubbling matters
  el.dispatchEvent(new Event('input', { bubbles: true }));
  el.dispatchEvent(new Event('change', { bubbles: true }));
  el.dispatchEvent(new Event('blur', { bubbles: true }));
}

Why this works: React patches the value setter on input elements to track changes through its synthetic event system. When you write el.value = ..., you hit React's patched setter, which marks the value as "set by React" and ignores the subsequent input event as a no-op. By grabbing the native setter from HTMLInputElement.prototype and calling it directly, you bypass the patched version, so when you then fire a synthetic input event with bubbles: true, React picks it up and updates state correctly.

The same technique works for Vue, Preact, and basically any framework that uses synthetic events.

The other thing: identifying fields without owning them

The other rabbit hole was figuring out how to find the same field again on a later page load. SPAs rerender. Element IDs sometimes survive, sometimes don't. CSS selectors that work today may break tomorrow.

FormVault stores three identifiers per field and falls back through them at restore time:

Unique selector, #id if there's an ID, otherwise tag[name="..."] if names are unique, otherwise a nth-of-type path up to the body.
name attribute, used as a secondary lookup if the selector misses.
XPath, last-resort positional path for sites with no useful identifiers.

Three layers of redundancy means restore works on the messy real-world web instead of just on demos.

Privacy guarantees you can actually verify

One of the things I find frustrating about "privacy-focused" tools is that you have to take their word for it. FormVault is small enough that you don't.

The repo is one content script, one service worker, one popup, and a tiny storage helper. Search the codebase for fetch, XMLHttpRequest, WebSocket, or any analytics SDK. You won't find them. The manifest doesn't request host_permissions for any external domain. Network tab will be silent forever.

For sensitive field detection, I check four signals before saving anything:

Input type (passwords and hidden are auto-skipped)
autocomplete attribute (new-password, cc-number, cc-csc, etc.)
Regex against id, name, aria-label, placeholder for password|ssn|cc-num|cvv|routing-number|account-number|pin-code and similar
Domain blocklist (banking sites are blocked out of the box)

False negatives are still possible on weirdly-named fields, but the multi-signal approach catches most real-world cases.

Try it

It's a developer-mode install for now (Chrome Web Store fee is a hurdle for a side project):

git clone https://github.com/TiltedLunar123/FormVault.git

Then chrome://extensions/ → Developer mode on → Load unpacked → pick the folder.

If you find a form that doesn't restore properly, open an issue with the URL and I'll take a look. Bonus points if you can break the sensitive field detection, that's the one thing I want to keep tightening.

If you'd like to support the project, a star on the repo helps with discoverability. And if you have ideas, iframe support, Firefox port, export/import, the roadmap is open.

GitHub: https://github.com/TiltedLunar123/FormVault

I Built a Chrome Extension That Bulk-Cleans Gmail in One Click (and Why You Probably Need It)

Jude Hilgendorf — Thu, 30 Apr 2026 14:15:32 +0000

I Built a Chrome Extension That Bulk-Cleans Gmail in One Click

If you're like me, your Gmail inbox is a graveyard of newsletters you never read, promo emails from 2019, and 40MB attachments from a group project you forgot about. Google gives you 15GB free, and somehow that "free" tier feels like extortion the second you cross it.

So I built Gmail One-Click Cleaner, an open-source, Manifest V3 Chrome extension that bulk-cleans Gmail in one click. No servers, no analytics, no API keys. Everything runs in your browser.

The problem

The "obvious" solution everyone reaches for is one of those services that asks for full Gmail OAuth scope. You hand over your entire mail history to a startup you've never heard of, and they delete some emails for you. That's a wild trade.

I wanted something that:

Runs 100% locally, never touches my email content over the network
Uses Gmail's own UI to do the deletion (so it's basically simulating what I'd do manually)
Has safety rails so I don't accidentally nuke important stuff
Is fast enough to clean tens of thousands of emails without me babysitting it

What it does

It runs configurable cleanup rules against your inbox. Out of the box it ships with categories like:

Promotions older than 6 months
Social updates older than 1 year
Anything with "unsubscribe" older than 1 year
Attachments larger than 10MB older than 6 months

You pick a rule set (Light / Normal / Deep), pick a mode (Live / Review / Dry-Run), and hit go. A live dashboard shows progress, per-rule results, and estimated MB freed.

Architecture (the interesting bit)

The whole thing is a Manifest V3 extension, which forced me into some interesting design decisions:

manifest.json         → MV3 manifest, minimal permissions
background.js         → Service worker (alarms, messaging, stats)
contentScript.js      → Gmail DOM automation (injected into Gmail)
popup.html/js         → Extension popup UI
progress.html/js      → Live progress dashboard
options.html/js       → Rules & settings
shared.css/js         → Design tokens + GCC utility namespace
browser-polyfill.js   → Cross-browser shim (Chrome, Edge, Brave, Firefox)

The cleanup engine lives in contentScript.js. It uses Gmail's existing search syntax, the same thing you'd type into the search bar, to scope each rule:

// Example: pull anything in promotions older than 6 months
const query = "category:promotions older_than:6m";

// Then we drive Gmail's UI: open search, select all matching threads,
// click "Select all conversations that match this search", click Trash.

Sounds simple, but Gmail's UI is a moving target. Every few months the DOM shifts. So I built helpers around MutationObserver to wait for elements rather than setTimeout everywhere, that one change cut flakiness by maybe 80%.

The safety rails

The first version of this thing scared me. So I wired in real guardrails:

Minimum age cutoff. Every rule has a "never touch anything newer than X" floor. Default is 3 months. You'd be amazed how often this saves you.

Global whitelist. Senders or domains you protect from every rule, no matter what. Bank, employer, family, done.

Safe Mode. Skips categories that are statistically dangerous: receipts, order confirmations, shipping updates. Even if a rule matches, Safe Mode will block it.

Skip starred & important. On by default. Gmail's "Important" classifier isn't perfect, but it's good enough as a backstop.

Dry-Run mode. Run any rule set and just count matches. No deletion. This is the mode I always tell new users to start in.

Even with all that, Gmail keeps trashed mail for ~30 days, so worst case you've got a recovery window.

Privacy: this part actually matters

The thing I'm proudest of is the permissions footprint. The whole extension needs:

"permissions": ["activeTab", "scripting", "tabs", "storage"],
"host_permissions": ["https://mail.google.com/*"]

That's it. No <all_urls>. No identity. No webRequest. Storage is local (your settings live in chrome.storage.local, never synced unless you toggle it). There is no backend. There is no analytics SDK. There is no telemetry. The repo's open source, go check manifest.json yourself.

If you've ever installed a "free" extension and felt that creeping suspicion, this should feel different.

Why I built this

I'm a CompTIA-track cybersecurity student who reads a lot of breach reports for fun. Most "free" tools that touch email are not free, you're paying with your data, and the second their startup pivots or gets acquired, the rules change.

I wanted a tool I'd actually trust on my own inbox. So I built it, used it, and shipped it.

Try it

Grab it here: github.com/TiltedLunar123/gmail-one-click-cleaner

If you find it useful, a star helps a ton. PRs welcome, there's a CONTRIBUTING.md with the dev setup and a Jest test suite to keep things honest.

What's the most ridiculous thing your Gmail is hoarding right now? Drop a screenshot in the comments, I'm taking nominations for default rules in v5.

Building ThreatLens: An Offline Threat Hunting CLI That Maps Logs to MITRE ATT&CK

Jude Hilgendorf — Tue, 28 Apr 2026 12:24:17 +0000

Most blue team tooling assumes you have a SIEM, a budget, and a network connection. That's a fine assumption for an enterprise SOC, but it kills the feedback loop for students, home-labbers, IR consultants who land in air-gapped environments, and anyone who just wants to triage a dump of logs without spinning up infrastructure.

That's the gap I built ThreatLens to fill: a single Python CLI that ingests EVTX, JSON, Syslog, and CEF logs, runs Sigma rules plus a set of opinionated detectors, correlates findings across stages of an attack, and produces alerts already mapped to MITRE ATT&CK. No agents, no cloud, no license keys. Just pip install threatlens and point it at a log file.

What it actually does

ThreatLens isn't trying to replace Splunk. It's the layer that runs before a SIEM, or instead of one when you don't have access to one. The detection coverage is what you'd expect a junior analyst to want pre-built:

Brute-force and password spray with logic that distinguishes the two
Lateral movement via rapid network logons across hosts
Privilege escalation by watching sensitive privilege assignments
Suspicious process execution (LOLBins, encoded PowerShell, certutil download cradles, SAM dumping)
Defense evasion (log clearing, Defender disabled, audit policy tampering)
Persistence (services, scheduled tasks, Run keys, startup folders)
Discovery bursts (whoami, ipconfig, net, nltest, dsquery in rapid succession)
Kerberoasting and AS-REP roasting
Credential access including LSASS, SAM, and DCSync
Attack chain correlation that links credential access → priv esc → lateral movement → execution into a single multi-stage alert

Each alert ships with the MITRE technique ID, the matching evidence, and a severity that's actually based on signal density instead of a flat "MEDIUM" stamp.

Why I built it

I'm a cybersecurity student grinding through CompTIA certs and trying to build muscle memory around log-based threat hunting. The problem is, the second you step outside a paid lab, the resources dry up. Hunting in a free Splunk trial means re-uploading data every week. ELK is a weekend of YAML before you see your first alert. Even paid SaaS SIEMs hide the detection logic behind a UI, which is great for production and terrible for learning.

I wanted a tool that made the detection logic the artifact. Open the repo, read detections/brute_force.py, and you can see exactly why a 4625 burst from a single IP becomes a "Brute-Force" alert and why the same IP hitting 30 different usernames becomes "Password Spray" instead. That transparency is the entire point.

A code walkthrough: the brute-force detector

The cleanest example of how the project is structured is the brute-force detector, because it's also the one that taught me the most. The naive version is "5 failed logons in 5 minutes, alert." That misses password spray (one attempt against many users) and over-fires on legitimate failures during outages.

Here's the core of the actual detector (source):

class BruteForceDetector(DetectionRule):
    name = "Brute-Force / Password Spray"
    mitre_tactic = "Credential Access"
    mitre_technique = "T1110 - Brute Force"

    def analyze(self, events: list[LogEvent]) -> list[Alert]:
        failed = [e for e in events if e.event_id in FAILED_LOGON_IDS]
        if not failed:
            return []

        alerts: list[Alert] = []

        # Group by source IP
        by_ip: dict[str, list[LogEvent]] = defaultdict(list)
        for event in failed:
            key = event.source_ip or "unknown"
            by_ip[key].append(event)

        for source, source_events in by_ip.items():
            windows = find_dense_windows(
                source_events, self.window_seconds, self.threshold
            )
            for window in windows:
                if len(window) >= self.threshold:
                    targets = {e.target_username or e.username for e in window}
                    is_spray = len(targets) > 3
                    rule_label = "Password Spray" if is_spray else "Brute-Force"
                    ...

A few things are happening that are worth pulling apart:

1. It groups by source first, not by user. Most beginner tutorials key on the username. That breaks the moment an attacker rotates usernames against the same source. Keying on source IP catches the spray pattern naturally.

2. The window logic is delegated. find_dense_windows is a small utility that finds the densest sub-windows inside a list of events sorted by timestamp. Pulling it into a utility means lateral movement, discovery, and credential access detectors all share the same primitive, the rules stay declarative.

3. Brute-force vs spray is one line. is_spray = len(targets) > 3. If a single source is hammering more than three distinct usernames inside the window, it's almost never a misconfigured client and almost always a spray. The threshold is configurable, but the default is calibrated against the public detection logic in the SOC Prime and Sigma communities.

4. Severity scales with density. The alert isn't just "found something." If the burst is 3x the threshold it ships as HIGH, 2x as MEDIUM, and so on. That keeps the noise floor sane when you point it at a noisy log.

The same shape repeats across the other detectors. Each one is ~100 lines, each one inherits from a tiny DetectionRule base class, and each one is unit tested with synthetic events so you can read the test file and see exactly what the rule fires on.

Multi-stage correlation

The detection that took the longest to get right is the attack chain correlator. Individually, a single 4625, a single privilege assignment, and a single network logon are all noise. Stitched together, credential access → priv esc → lateral movement, on the same actor, inside the same time window, they're a kill chain.

The correlator scans all alerts produced by the per-tactic detectors, groups them by actor (user or source IP), sorts by tactic-stage, and emits a single multi-stage alert when at least two ATT&CK tactics fire in sequence. The output is a timeline a human can actually read, not a wall of unrelated tickets.

That's the part that feels closest to real SOC work. You stop staring at a single event and start asking "what's the story?"

Output formats

ThreatLens ships three:

Terminal, color-coded summary, severity counts, top techniques, exit code = severity tier (so you can chain it in CI)
JSON, full structured alerts, ready to feed into a SIEM, a webhook, or just jq
HTML report, standalone, no JS framework, includes a severity chart and an interactive attack timeline. This is the format I keep open in a tab while I work through a dataset.

What's next

The roadmap I'm actually working on:

More native parsers (currently leaning on python-evtx; eventually want a pure-Python EVTX reader for environments where pip is restricted)
Better Sigma backend coverage so community rules drop in cleanly
A small library of "hunt packs", pre-built configurations targeted at specific scenarios (ransomware aftermath, lateral movement audit, post-phish triage)

Try it

If any of this sounds useful, the repo is here: github.com/TiltedLunar123/ThreatLens. There's a sample log in sample_data/ so you can run threatlens scan sample_data/sample_security_log.json and see real alerts in under 30 seconds.

A star helps the project show up for other students and early-career analysts trying to find tools that aren't locked behind enterprise pricing. PRs welcome, especially new detectors. If there's a tactic you've been wanting to hunt for and the repo doesn't cover it yet, open an issue and we'll talk through the rule design.

I Built an Offline Log Triage CLI That Detects MITRE ATT&CK Techniques in EVTX, Syslog, JSON, and CEF

Jude Hilgendorf — Mon, 20 Apr 2026 14:00:42 +0000

I Built an Offline Log Triage CLI That Detects MITRE ATT&CK Techniques

SOC analysts routinely face thousands of daily events, and most of it is noise. If you're on an incident response engagement with no network access, or you're staring at a zip of EVTX files a client dropped in your lap, spinning up a full SIEM isn't realistic.

That's the gap ThreatLens is trying to fill. It's a single Python CLI that parses log formats SOC analysts actually encounter — JSON/NDJSON, EVTX, Syslog (RFC 3164 and 5424), and CEF — and runs a detection engine mapped to MITRE ATT&CK, entirely offline, with only PyYAML as a hard runtime dependency.

This post walks through what it does, why I built it, and a code walkthrough of how the detection engine works.

What It Actually Does

Point it at a log file or a directory, and it runs 12 built-in detection modules covering tactics like brute force, lateral movement, privilege escalation, and persistence. Output is whatever you need for the workflow:

Color-coded terminal output for quick triage
Self-contained HTML reports with charts and interactive timelines
JSON for piping into a SIEM
CSV for handoffs to analysts who live in spreadsheets
Elasticsearch bulk API format when you want to ingest the findings

A few representative commands:

# Basic scan against a JSON log
threatlens scan logs/security.json

# Native EVTX parsing — no conversion step
threatlens scan evidence/security.evtx

# HTML report, filtered to high severity and above
threatlens scan logs/ -o report.html -f html --min-severity high

# Real-time tailing for live triage
threatlens follow /var/log/events.json

# Use community Sigma rules
threatlens scan logs/ --sigma-rules sigma/rules/windows/

# CI/CD gate — exit non-zero on high-severity findings
threatlens scan logs/ --fail-on high

Why I Built It

I'm a cybersecurity student, and the gap between "read a blog post about MITRE ATT&CK" and "actually recognize T1110 in a pile of Event ID 4625s" is large. The only way I found to close it was to write the detection logic myself.

Existing tools kept tripping on the same pain points:

Chainsaw, EvtxHussar, hayabusa are excellent but Windows-centric. I wanted one tool that chews through EVTX and the Linux syslog a cloud workload dumped.
Full SIEM stacks are overkill for a one-off engagement. I didn't want to stand up Elastic + Kibana + Filebeat to look at 200MB of logs.
Custom scripts get rewritten every engagement. I wanted rule-based logic I could extend without touching parsing code.

So the design goal was: one binary, offline, format-agnostic, rule-driven, zero infra.

Code Walkthrough: The Rule Engine

The most interesting piece architecturally is the rule engine, because it has to be expressive enough to write real detections but simple enough that an analyst can author rules in YAML without writing Python.

A rule looks like this:

rules:
  - name: "After-Hours Logon"
    severity: medium
    conditions:
      - field: event_id
        operator: equals
        value: "4624"
    threshold: 1

That's a toy example. The real power shows up when you combine operators. The engine ships with 12: equals, not_equals, contains, not_contains, startswith, endswith, regex, gt, lt, gte, lte, and in. Conditions AND together by default, and thresholds turn a single-event match into a frequency-based detection (5 failures in 60 seconds, etc.).

The evaluation loop is roughly:

def evaluate_rule(rule, event):
    for condition in rule.conditions:
        field_value = event.get(condition.field)
        if not OPERATORS[condition.operator](field_value, condition.value):
            return False
    return True

Where OPERATORS is a dict mapping operator names to small comparison lambdas. Adding a new operator is a one-line change — no parser work, no AST manipulation. This is deliberate. I wanted rule authoring to feel like writing a conditional, not configuring a parser.

Thresholded rules layer on top. The engine keeps a sliding window per (rule, grouping_key) — typically grouped by source IP or username — and fires the alert only when count >= threshold within the window. Grouping keys are pulled from the event by name, which means a rule author can correlate on any field the parser exposes without modifying code.

The parsing phase normalizes every format into a flat dict with a small set of canonical fields (timestamp, source_ip, username, event_id, process, command_line, etc.) plus the raw original. That normalization is what makes the rule engine format-agnostic — the same "Brute Force" rule works against Windows 4625 events, SSH auth.log failures, and a CEF feed from a firewall, because they all expose username and source_ip after parsing.

Attack Chain Correlation

The feature I'm most proud of is multi-stage correlation. A single brute-force alert is interesting. A brute-force alert followed 30 seconds later by a successful logon from the same IP, followed by a net user /add execution, is an incident. The correlation engine takes a chain definition — an ordered list of rule names with time windows — and fires a higher-severity meta-alert when it sees the full kill chain in order.

That's how low-severity events ladder up to high-severity incidents without drowning analysts in noise.

Allowlist Suppression

Every detection tool dies on false positives. The allowlist layer suppresses known-good activity by rule name plus any combination of event fields:

allowlist:
  - rule_name: "Brute-Force"
    username: "svc_monitor"
    reason: "Expected service account failures"

The reason field is required. It forces the author to document why this exception exists, which is the single most important thing about any suppression rule in production.

Testing

Against the sample datasets in the repo, ThreatLens hit zero false positives on benign activity while detecting 100% of embedded attack techniques with correct MITRE ATT&CK classification. That's on curated data — real-world logs are messier — but it's a useful floor.

Try It

pip install threatlens
threatlens scan /path/to/your/logs

Or clone it and poke at the rule engine: github.com/TiltedLunar123/ThreatLens

If you find it useful, a star helps the repo surface for other analysts. PRs for new detections or log formats are especially welcome — I'd love to see what rules other people write.

Building SIEMForge: A Portable SIEM Detection Toolkit with Sigma, Sysmon, and MITRE ATT&CK

Jude Hilgendorf — Mon, 20 Apr 2026 13:47:45 +0000

If you've ever tried to stand up detection content across more than one SIEM, you already know the pain. Sigma rules live in one repo, Sysmon config lives in another, your Wazuh custom rules are scattered across three local_rules.xml files, and MITRE mapping is an afterthought buried in a spreadsheet. I built SIEMForge to fix that.

SIEMForge is a single Python toolkit that bundles Sigma rules, a Sysmon configuration, and Wazuh custom rules — all mapped to MITRE ATT&CK — with an offline log scanner and a multi-backend rule converter. It runs from a home lab to a production SOC without changing the workflow.

Repo: github.com/TiltedLunar123/SIEMForge

Why I built it

I'm a cybersecurity student, and when I started building detections for a home lab, the tooling gap became obvious fast. Every tutorial assumed you had a Splunk license or a full Elastic stack. The actual Sigma ecosystem is great, but turning a Sigma rule into something that runs against real logs without spinning up a SIEM is friction that kills learning momentum.

I wanted three things:

Write detection logic once in Sigma, deploy it anywhere
Test rules offline against sample logs before pushing anything to production
See MITRE ATT&CK coverage at a glance so I knew where the gaps were

SIEMForge is the tool I wished existed when I started.

What it does

Log Scanner Engine. Point it at a JSON, JSONL, syslog, or CSV log file and it runs your Sigma rules against it — no SIEM required. Human-readable alerts by default, JSON output if you want to pipe it somewhere.

Multi-Backend Rule Conversion. Convert one Sigma rule into Splunk SPL, Elasticsearch Lucene, or Kibana KQL. No vendor lock-in, no rewriting detections when you change platforms.

MITRE ATT&CK Coverage Matrix. Every bundled rule is tagged with techniques. Run one command and see exactly what you cover.

Rule Validation. Catches bad YAML, broken field-condition mappings, and malformed Sigma syntax before you deploy anything.

Sysmon + Wazuh bundled. A production-ready Sysmon config and Wazuh custom rules ship with the project, mapped to the same techniques as the Sigma rules.

Code walkthrough: the log scanner

The piece I'm proudest of is the offline log scanner. It lets you validate detection logic against raw logs without deploying anything. Here's how it works conceptually:

python -m siemforge --scan /var/log/sysmon/events.json

Under the hood, the scanner:

Loads every Sigma rule from rules/sigma/ and parses the YAML into a rule object
Opens the log file and streams records (auto-detects JSON / JSONL / syslog / CSV)
For each record, walks each rule's detection block and evaluates the field-condition logic
On a match, emits an alert with the rule name, MITRE technique, and the matching log line

The tricky part is Sigma's detection syntax — it supports wildcards, regex, contains-all, contains-any, logical AND/OR between selection groups, and negation. Getting the evaluator right is what the 138-test suite is mostly for. If you're building anything similar, test-drive it hard. Edge cases around null, case sensitivity, and list vs scalar matching will eat you alive otherwise.

Here's what a PowerShell detection rule looks like after conversion to Splunk SPL:

index=windows EventCode=1 CommandLine="*powershell*"
AND (CommandLine="*-ep bypass*" OR CommandLine="*DownloadString*")

That SPL query came from a Sigma YAML that looks roughly like:

detection:
  selection:
    EventID: 1
    CommandLine|contains: 'powershell'
  suspicious:
    CommandLine|contains:
      - '-ep bypass'
      - 'DownloadString'
  condition: selection and suspicious

One source of truth, three SIEM backends. That's the whole point.

Install and try it

git clone https://github.com/TiltedLunar123/SIEMForge.git
cd SIEMForge
pip install pyyaml

Scan a log file:

python -m siemforge --scan samples/suspicious_powershell.json

Convert a rule:

python -m siemforge --convert splunk rules/sigma/proc_creation_suspicious_powershell.yml

Print MITRE coverage:

python -m siemforge --mitre rules/sigma/

What's next

v3.1 expanded the test suite, added Windows CI matrix testing, and fixed a Sigma spec edge case around SSH bruteforce detection. Next up: more rules covering cloud attack paths (T1078.004, T1580), a proper detection-as-code pipeline example, and maybe a web UI for the coverage matrix if there's demand.

Call to action

If you're studying blue team, running a home lab, or just want a way to prototype detections without spinning up a full SIEM — clone it, break it, open an issue. Stars help the project surface to more people who'd benefit.

Star SIEMForge on GitHub →

If you'd build something with it, tell me what rule you'd write first.

I Built an Offline Threat-Hunting CLI in Python — Here's How ThreatLens Catches Real Attacks

Jude Hilgendorf — Fri, 17 Apr 2026 15:53:01 +0000

If you've ever stared down thousands of EVTX, Syslog, or JSON log events after a suspected incident, you already know the pain: the signal-to-noise ratio is brutal, and most "SIEM-lite" tools either want a cloud subscription or a 20-step install.

I wanted something different — a single CLI I could drop on an air-gapped workstation, point at a folder of logs, and get a ranked list of attack patterns mapped to MITRE ATT&CK within seconds.

That's ThreatLens — an offline log analysis and threat hunting CLI written in Python. No agents, no cloud, no license server. Just pip install, scan, read the report.

What it actually does

ThreatLens parses security logs and runs them through a detection engine that covers 12 attack categories mapped to MITRE ATT&CK tactics:

Brute-force and password spray attacks (T1110)
Lateral movement via rapid multi-host authentication (T1021)
Privilege escalation through sensitive permission assignments (T1134)
Suspicious process execution including LOLBins and encoded PowerShell (T1059)
Defense evasion patterns like log clearing and audit policy changes (T1070, T1562)
Persistence mechanisms via services, scheduled tasks, and registry modifications (T1543, T1053, T1547)

It ingests JSON/NDJSON, native EVTX, RFC 3164/5424 Syslog, and CEF — with auto-detection, so you don't have to flag formats manually.

Exports: color-coded terminal, JSON, CSV, self-contained HTML reports with SVG charts and an interactive attack timeline, or direct Elasticsearch ingestion if you already have a stack.

Why I built it

I'm a cybersecurity student who spends a lot of lab time on blue-team exercises. Every time I finished a scenario, I'd end up with a mountain of Windows Event Logs and no fast way to confirm what actually happened. Commercial tools were overkill for a lab, and open-source options usually needed a full ELK stack before they'd tell me anything useful.

I wanted a tool that answered one question fast: "Is there anything interesting in this pile of logs?" — without spinning up infrastructure.

Code walkthrough: the detection engine

The core idea is a three-layer detection model:

Built-in detections tuned via rules/default_rules.yaml
Custom YAML rules — 12 operators (equals, contains, regex, gt/lt, etc.) with grouping and time windows
Sigma rules — natively compatible with community Sigma repos, with field modifiers and compound conditions

Here's a custom rule that detects 5+ failed logons from the same source in under 60 seconds — classic brute-force:

name: brute_force_failed_logons
description: Multiple failed logon attempts from single source
severity: high
mitre: T1110
match:
  all:
    - field: event_id
      op: equals
      value: 4625
  group_by: source_ip
  window: 60s
  threshold:
    op: gt
    count: 5

The rule engine normalizes incoming events (EVTX → dict, Syslog → dict, etc.), pipes them through each loaded rule, and any match pushes an alert into a correlation stage that links multi-stage kill chains. So a brute-force hit followed by a privileged logon from the same IP a minute later gets stitched into one chain, not two disconnected alerts.

That correlation step is what makes the output usable — instead of 400 alerts you get 8 attack chains ranked by severity.

Using it

Quick install from source:

git clone https://github.com/TiltedLunar123/ThreatLens.git
cd ThreatLens
python -m venv .venv
pip install -e ".[dev]"

Or Docker if you want zero local install:

docker build -t threatlens .
docker run --rm -v $(pwd)/logs:/data threatlens scan /data/

Then scan:

threatlens scan sample_data/sample_security_log.json
threatlens scan logs/ --min-severity high -o report.json -f json
threatlens scan logs/ --custom-rules my_rules/ --sigma-rules sigma/rules/
threatlens follow /var/log/events.json --buffer-size 50

That last one is a tail -f-style live monitor with a ring buffer for in-memory correlation — handy if you're hunting during an active incident instead of after the fact.

Results so far

Against sample datasets I baked in: zero false positives on benign activity and 100% detection across the embedded techniques. Worth the asterisk that this is my test corpus — I'd love more folks running it against real logs and opening issues.

What's next

On the roadmap: a built-in rule marketplace, richer EVTX field extraction, and a lightweight Windows service wrapper for continuous monitoring.

Try it

If you're a SOC analyst, student, or homelabber who wants a dead-simple offline triage tool, give it a run. If it helps, a ⭐ on the repo means a lot.

Repo: github.com/TiltedLunar123/ThreatLens

PRs, issues, and detection rule contributions welcome.

I Built an Offline Threat Hunting CLI That Parses EVTX, JSON, Syslog & CEF Logs

Jude Hilgendorf — Thu, 16 Apr 2026 14:37:48 +0000

If you've ever worked in a SOC or done any incident response, you know the pain: you've got a pile of log files from a compromised host, and you need answers fast. Maybe you don't have Splunk access. Maybe the SIEM is down. Maybe you're on a plane with a laptop full of EVTX files and zero internet.

That's why I built ThreatLens — a Python CLI that does offline log analysis and threat hunting without requiring any infrastructure.

What ThreatLens Does

ThreatLens ingests logs in multiple formats (EVTX, JSON, NDJSON, Syslog RFC 3164/5424, and CEF), runs them through 12 built-in detection modules, and outputs color-coded alerts mapped to the MITRE ATT&CK framework.

No Elasticsearch cluster. No cloud account. Just pip install threatlens and point it at your logs.

Why I Built It

I'm a cybersecurity student, and every time I practiced incident response scenarios, I hit the same wall: the tools that do log analysis well are either expensive, require complex deployment, or need network access. I wanted something I could run anywhere — on an air-gapped forensics workstation, in a Docker container during a CTF, or in a CI/CD pipeline for automated security checks.

So I started building ThreatLens as a learning project, and it grew into something I actually use regularly.

The Detection Engine: A Code Walkthrough

The part I'm most proud of is the multi-stage attack chain correlation. Most log analysis tools look at events individually. ThreatLens connects the dots.

Each detection module registers itself with a tactic and technique mapping. When ThreatLens processes a log file, it doesn't just flag individual events — it builds a timeline. If it sees a brute-force login (Initial Access), followed by a suspicious PowerShell execution (Execution), followed by a new scheduled task (Persistence), it correlates those into a potential attack chain and raises the severity.

The detection modules cover:

Brute-force & password spray detection
Lateral movement (RDP, PsExec, WMI patterns)
Privilege escalation monitoring
LOLBin abuse (living-off-the-land binary execution)
Encoded PowerShell commands
Defense evasion (log clearing, AV tampering)
Persistence mechanisms (scheduled tasks, services, registry run keys)
Kerberos attacks (Kerberoasting, Golden Ticket indicators)
Data exfiltration patterns
Multi-stage attack chain correlation

Each module uses a YAML-configurable rule format with 12 operators, so you can write custom rules without touching Python code. And if you already have Sigma rules from your team, ThreatLens supports those natively too.

Quick Start

Install from PyPI:

pip install threatlens

Scan a single log file:

threatlens scan /path/to/security.evtx

Scan a directory recursively with HTML report output:

threatlens scan /var/log/ -r -o report.html

Run with custom Sigma rules:

threatlens scan logs/ --sigma-rules ./my-rules/

Tail logs in real-time:

threatlens tail /var/log/syslog --severity high

Push alerts to Elasticsearch:

threatlens scan logs/ --es-host https://elastic:9200

Output Formats

ThreatLens gives you flexibility in how you consume results:

Terminal: Color-coded severity with MITRE technique IDs inline
JSON/CSV: For piping into other tools or importing to spreadsheets
HTML: Self-contained reports with charts and timelines
Elasticsearch: Push alerts directly for dashboarding

CI/CD Integration

One underrated use case: drop ThreatLens into your pipeline to scan application logs for security events. It returns proper exit codes, so you can fail a build if high-severity detections fire.

# GitHub Actions example
- name: Security log check
  run: threatlens scan ./logs/ --severity high --exit-code

What's Next

I'm working on expanding the detection library, improving the EVTX parser performance, and adding a plugin marketplace where the community can share detection modules.

Try It Out

The repo is at github.com/TiltedLunar123/ThreatLens. If it's useful to you, a star helps a lot with visibility. Issues and PRs are welcome — especially new detection rules.

If you're a SOC analyst, threat hunter, or IR responder, I'd love to hear what detections you'd want added. Drop a comment below.