DEV Community: Jude Hilgendorf

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.

I Built a Portable SIEM Toolkit That Runs Sigma Rules Without Deploying a Full SIEM

Jude Hilgendorf — Mon, 13 Apr 2026 16:59:44 +0000

You don't always have a full SIEM stack at your fingertips. Maybe you're a student spinning up a home lab, a junior SOC analyst triaging logs on a budget, or a pentester who just needs to check some Sysmon logs against known attack patterns. Standing up Splunk or Elastic just to run a few detection rules feels like overkill.

That's why I built SIEMForge — a portable detection toolkit that lets you scan logs against Sigma rules, convert detections to Splunk/Elastic/Kibana queries, validate rule syntax, and map your coverage to the MITRE ATT&CK framework. All from the command line. No SIEM required.

What SIEMForge Actually Does

At its core, SIEMForge is a Python CLI tool with four main capabilities:

1. Log Scanning Without a SIEM

Feed it a JSON, JSONL, syslog, or CSV log file and it executes Sigma detection rules against it locally:

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

It ships with 10 pre-built Sigma rules covering techniques like suspicious PowerShell downloads (T1059.001), LSASS memory dumps (T1003.001), CertUtil abuse (T1105), and scheduled task persistence (T1053.005).

2. Multi-Backend Rule Conversion

Need to move a Sigma rule into your production SIEM? SIEMForge converts to Splunk SPL, Elasticsearch Lucene, and Kibana KQL:

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

This spits out ready-to-paste queries. No manual translation, no syntax guessing.

3. Rule Validation

Before deploying rules to production, validate them:

python -m siemforge --validate rules/sigma/

This catches YAML formatting issues, missing required fields, and structural problems before they break your detection pipeline.

4. MITRE ATT&CK Coverage Mapping

Visualize which techniques your rule set covers:

python -m siemforge --mitre rules/sigma/

This is huge for gap analysis — you can immediately see where your detection coverage is thin.

A Closer Look: The Converter Architecture

The part I'm most proud of is the converter module. Each SIEM backend has its own translation layer under siemforge/converters/:

siemforge/converters/
    ├── splunk.py
    ├── elastic.py
    └── kibana.py

Each converter takes a parsed Sigma rule (field mappings, detection logic, conditions) and outputs the target query language. The tricky part was handling Sigma's conditional logic — things like selection AND NOT filter with nested field conditions need to be properly parenthesized for each backend's syntax.

For example, a Sigma rule detecting suspicious PowerShell downloads becomes Splunk SPL like:

index=windows source="WinEventLog:Microsoft-Windows-Sysmon/Operational"
EventCode=1
CommandLine="*powershell*" AND (CommandLine="*-ep bypass*" OR CommandLine="*DownloadString*")

But the same rule in Elasticsearch Lucene looks like:

event.code:1 AND process.command_line:(*powershell* AND (*-ep bypass* OR *DownloadString*))

Field names change, quoting rules change, wildcard syntax changes. The converter handles all of this.

Why I Built It

I'm a cybersecurity student, and I kept running into the same problem: I wanted to practice threat detection and log analysis, but every tutorial assumed you had a full Splunk or Elastic deployment. Setting up those stacks takes hours and eats resources on a student laptop.

SIEMForge lets me (and anyone else) practice detection engineering with just Python and a log file. It's the tool I wished existed when I started learning.

Getting Started

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

The test suite has 138 tests if you want to poke around the internals:

pip install -r requirements-dev.txt
pytest tests/ -v

What's Next

I'm planning to add more Sigma rules, support additional log formats, and potentially add a web UI for the MITRE coverage matrix. If you're into detection engineering or just want a lightweight way to work with Sigma rules, give it a try and let me know what you think.

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

If this is useful, drop a star — it helps more than you think.

I Built an Offline Threat Hunting CLI That Runs Sigma Rules and Maps Everything to MITRE ATT&CK

Jude Hilgendorf — Sat, 11 Apr 2026 12:26:31 +0000

Most log analysis workflows assume you have a full SIEM stack running. Splunk, Elastic, Sentinel — they're powerful, but they're also heavy. When I needed to triage Windows security logs during a lab exercise, I didn't want to spin up infrastructure. I wanted to point a tool at a folder of logs and get answers.

That's why I built ThreatLens — a Python CLI that parses EVTX, JSON, Syslog, and CEF logs offline, runs detection rules (including native Sigma support), correlates multi-stage attacks, and outputs structured alerts mapped to MITRE ATT&CK. No agents, no cloud, no dependencies beyond PyYAML.

What It Actually Does

ThreatLens automates the first pass of triage. You feed it log files and it catches:

Brute-force attacks and password spray patterns
Lateral movement (single account hopping across hosts)
Privilege escalation (SeDebugPrivilege, SeTcbPrivilege assigned to non-system accounts)
Suspicious process execution (LOLBins, encoded PowerShell, certutil download cradles)
Defense evasion (log clearing, Defender disabled, audit policy changes)
Persistence mechanisms (new services, scheduled tasks, registry Run keys)
Credential access (LSASS dumps, SAM hive access, DCSync)
Multi-stage attack chain correlation that links activity across the entire kill chain

Every alert maps to a specific MITRE ATT&CK technique with an actionable recommendation.

The Feature I'm Most Proud Of: Attack Chain Correlation

Individual alerts are useful, but real attacks are sequences. ThreatLens has a correlation engine that links events across kill chain phases — if it sees credential access followed by privilege escalation followed by lateral movement followed by execution from the same source, it flags the entire chain as a single CRITICAL alert.

Here's the logic in simplified form: the engine groups alerts by time windows, tracks source entities across detection modules, and looks for progressions through the MITRE ATT&CK lifecycle. When it finds a chain, it bundles all the evidence into one high-confidence alert instead of flooding you with disconnected findings.

This is the kind of analysis that normally requires a SIEM correlation rule or a dedicated XDR platform. Having it in a standalone CLI means you can run it during incident response, in a lab, or in a CI/CD pipeline.

Sigma Rule Support

One of my goals was interoperability with the existing detection community. ThreatLens loads Sigma rules natively — selections, filters, field modifiers (|contains, |startswith, |endswith, |re, |all), compound conditions with correct operator precedence, and logsource pre-filtering.

git clone https://github.com/SigmaHQ/sigma.git
threatlens scan logs/ --sigma-rules sigma/rules/windows/

This means you get access to thousands of community-maintained detection rules without writing anything custom.

CI/CD Integration

ThreatLens returns structured exit codes: 0 for clean, 2 for alerts above your threshold. Drop it into a pipeline:

threatlens scan logs/ --fail-on high --summary-only --no-color

Use it to gate deployments or trigger incident workflows based on log findings.

Getting Started

pip install threatlens
threatlens scan your_logs/

Or clone it and run against the included sample data:

git clone https://github.com/TiltedLunar123/ThreatLens.git
cd ThreatLens
pip install -e .
threatlens scan sample_data/sample_security_log.json --verbose

The sample dataset includes a focused attack simulation (26 events) and a mixed enterprise log (52 events with benign noise plus embedded attacks). ThreatLens hit 100% detection with zero false positives on the benign traffic.

What's Next

I'm actively working on this project and planning to add more detection modules, improve the Sigma compatibility layer, and build out the plugin system so teams can drop in environment-specific detectors.

If you work in security operations, do incident response, or just want a fast way to analyze Windows logs without infrastructure — give it a try and let me know what you think.

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

If this was useful, follow me for more security tooling and detection engineering content.

I Built a Chrome Extension That Auto-Saves Your Form Data Locally (Zero Network Requests)

Jude Hilgendorf — Sat, 04 Apr 2026 10:02:44 +0000

The Problem

You're halfway through a long form — maybe a job application, an insurance quote, or a school registration — and you accidentally close the tab. Or the page crashes. Or your session expires.

Everything you typed is gone.

Browser autofill only covers the basics (name, email, address). It doesn't save the custom fields, text areas, or dropdowns that make up 90% of real forms.

What I Built

FormVault is a Chrome extension that automatically saves everything you type into any web form — locally, on your machine. No accounts, no cloud sync, no network requests at all.

When you come back to a form, FormVault lets you restore your previous inputs with one click.

How it works:

Detects form fields on any page
Saves inputs to Chrome's local storage as you type
Restore button appears when you revisit a page with saved data
All data stays on your device — zero network requests, ever

Why I built it this way

I wanted something I'd actually trust with sensitive form data. Most form-saving tools either sync to a cloud or require an account. FormVault does neither. You can read every line of the source code yourself.

Try it out

The extension is free and open source. If you've ever lost form data and wanted to throw your laptop, this might save you some frustration.

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

I'm a cybersecurity student building tools in my spare time, so feedback is genuinely welcome — especially on the privacy/security side. What would you improve?

I built a portable SIEM detection toolkit that converts Sigma rules to Splunk, Elastic, and Kibana queries

Jude Hilgendorf — Wed, 01 Apr 2026 13:15:34 +0000

The problem

If you've ever tried to manage detection content across different SIEMs, you know the pain. Sigma rules live in one folder, your Sysmon config is somewhere else, Wazuh custom rules are in yet another directory, and none of it maps cleanly back to MITRE ATT&CK. Converting rules between SIEM formats usually means installing sigmac or setting up a whole pipeline just to get a Splunk query out of a YAML file.

I'm a cybersecurity student and I got tired of this workflow in my home lab, so I built SIEMForge — a single Python CLI that keeps all your detection content in one place and converts it natively.

What it does

SIEMForge is a portable toolkit that handles:

Sigma rule conversion — translates detection rules to Splunk SPL, Elasticsearch Lucene, or Kibana KQL without any external dependencies (no sigmac needed)
10 pre-built detection rules covering credential dumping (T1003.001), process injection (T1055.003), lateral movement via PsExec (T1021.002), suspicious PowerShell (T1059.001), SSH brute-force (T1110.001), and more
Tuned Sysmon configuration for Windows event monitoring
Wazuh custom rules with agent config snippets
MITRE ATT&CK mapping across all rules
One-command export of the complete detection package

Quick start

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

Only dependency is PyYAML. Runs on Python 3.8+.

Example usage

# See what's in the toolkit
python siemforge.py

# Convert all rules to Splunk SPL
python siemforge.py --convert splunk

# Convert a single rule to Kibana KQL
python siemforge.py --convert kibana --convert-rule lsass_credential_dump.yml

# View MITRE ATT&CK coverage
python siemforge.py --mitre

# Export everything as a packaged bundle
python siemforge.py --export-all

The --export-all flag generates an organized directory with Sigma YAML rules, Sysmon XML config, and Wazuh rules ready to drop into your stack.

Why I built it

Mostly for my own learning. I wanted to understand how Sigma rules actually translate to different query languages under the hood, and I wanted a single tool I could carry between lab environments without installing a bunch of dependencies. Figured other students or home lab folks might find it useful too.

What's next

I'm planning to add more detection rules and possibly support for more output formats. If you work in blue team or run a home lab, I'd love to know: what detection rules or SIEM formats would be most useful to add?

Check it out here: github.com/TiltedLunar123/SIEMForge

MIT licensed, contributions welcome.

I Built a Chrome Extension That Auto-Saves Your Form Data Locally (Zero Network Requests)

Jude Hilgendorf — Sun, 29 Mar 2026 13:15:24 +0000

The Problem

Ever spent 20 minutes filling out a long form — job application, insurance quote, registration — and then the page crashes, your session expires, or you accidentally hit the back button?

All that data, gone. Browser autofill doesn't help because it only remembers basic fields like name and address, not the custom stuff you actually typed.

What I Built

FormVault is a Chrome extension that automatically saves everything you type into web forms, locally on your machine. If the page crashes or you navigate away, your data is still there when you come back.

Key details:

Zero network requests — your form data never leaves your browser
Auto-saves as you type, restores when you revisit the page
Works on any form on any site
One-click clear if you want to wipe saved data for a page
Lightweight, no account needed, no permissions beyond the active tab

Why I Made It Privacy-First

Most form-saving tools sync your data to a cloud server. That means your half-finished job applications, medical forms, and financial info sits on someone else's infrastructure. I didn't want that.

FormVault uses chrome.storage.local exclusively. Nothing is transmitted. Nothing is stored externally. You own your data, period.

Try It / Give Feedback

I'm a cybersecurity student and this is one of my side projects. I'd genuinely appreciate feedback — especially on edge cases where form detection might break, or ideas for features that would make this more useful for your workflow.

Check it out here: FormVault on GitHub

What form-saving solutions do you currently use? Or do you just accept the risk and re-type everything?