logtriage

The problem

The first few minutes with a log file are always the same: skim for the interesting lines, pull out the IPs and hashes, count how many times that one address failed to log in, and try to lay it out in order so the story makes sense. It is exactly the kind of mechanical correlation a small tool should do for you, leaving you to do the part that needs judgment.

How it works

It parses each line across a few common shapes — syslog and auth.log, ISO-8601-prefixed lines, JSON lines, and a plain fallback — pulling a timestamp where one exists. From every line it extracts indicators, refanging any that arrived defanged, and tags each IP as internal or external based on whether it is globally routable. Alongside that it flags notable events (authentication failures and successes, privilege use, new accounts, errors, outbound connections) and counts failed-auth attempts per source IP, flagging likely brute force. The output is a summary, the failed-auth tally, the indicators by frequency, and a timeline of the notable lines.

It pairs with ioc-enrich

A log tells you what happened; enrichment tells you who. So logtriage can emit just its external indicators, one per line, to hand straight to ioc-enrich:

python -m logtriage server.log --format iocs | python -m ioc_enrich --stdin

That takes you from a raw log to an enriched picture of the external indicators in two commands.

Using it

# a built-in sample: an SSH brute force with follow-on activity
python -m logtriage --demo

# your own log, from a file or stdin
python -m logtriage /var/log/auth.log
python -m logtriage server.log --external-only --format json -o triage.json

Limits

Parsing is best-effort across common formats; an unusual format still yields indicators and events, just without parsed timestamps. Event tagging is keyword-based and English-oriented, so it is worth tuning to your stack. And it is a triage aid meant to point you at what matters — not a SIEM, and not a substitute for one.