DEV Community: logtriage

What a Single Confirmed-Malicious Threat Intel Hit Should Do to Your Risk Score

logtriage — Mon, 21 Sep 2026 09:31:35 +0000

A common design pattern in risk scoring is purely additive: every signal contributes some number of points, capped, and the points add up to a final score. It's simple to reason about and easy to tune — until a single very strong signal shows up, and the additive model quietly under-reacts to it.

Here's a concrete version of the problem we ran into: an IP address confirmed by ThreatFox as active Cobalt Strike command-and-control infrastructure, at 100% confidence, contacting an API endpoint. Under a purely additive model, that ThreatFox match contributed a capped +30 points. Combined with a low-risk user-agent signal, the event landed at 33 out of 100 — solidly in "LOW" severity, comfortably under the threshold for deeper automated review.

That's the wrong outcome. A single, independent, high-confidence confirmation that an IP is known malware infrastructure shouldn't compete on equal footing with a dozen soft probabilistic signals that each nudge the score up a little. It should dominate the score, because the evidentiary weight isn't comparable — "this user-agent is unusual" and "this exact IP is a confirmed Cobalt Strike C2 node" are not the same category of evidence, even though an additive model treats them as fungible points.

The fix was a floor rule, not a bigger additive weight: any single source independently confirming "this is malicious" — a ThreatFox IOC match, an OTX malicious flag, a non-RIOT GreyNoise malicious classification, AbuseIPDB confidence at or above 75%, or a malicious sandbox verdict — floors the event's score to 75, regardless of what the additive components alone produced. The same Cobalt Strike event that scored 33 before now scores 75, clears the threshold for full AI-assisted analysis, and gets treated with the urgency a confirmed C2 contact actually deserves.

The general lesson generalizes past this one rule: additive scoring is a reasonable default for combining many weak-to-moderate signals, but it systematically under-weights rare, high-confidence, independent confirmations. If your scoring model has any signal that's supposed to mean "we are sure," it needs a floor, not just a point value.

Detecting Impossible Travel Without Expensive UEBA Tooling

logtriage — Fri, 18 Sep 2026 06:54:31 +0000

Impossible travel detection has a reputation for being an enterprise-only feature, bundled into UEBA platforms that cost more than the rest of a security stack combined. The underlying math is not complicated, and most identity providers already give you everything you need in the raw sign-in log.

The calculation is the haversine formula — the great-circle distance between two latitude/longitude points — divided by the elapsed time between two consecutive sign-ins for the same account. If that implied speed exceeds what's physically possible (LogTriage defaults to 500 km/h, comfortably above commercial flight speed but well below "instantaneous"), the pair gets flagged. That's the entire algorithm. No machine learning model, no behavioral baseline period, no training data.

The harder part isn't the math — it's getting clean coordinates. Azure AD sign-in logs include location.geoCoordinates directly, which makes this nearly free for Entra ID. For log formats that don't carry their own geolocation, the fallback is IP-based geolocation through a standard enrichment pipeline, which is noisier (VPN exits, mobile carrier NAT, and corporate proxies all distort it) but still catches the cases that matter: an account signing in from two countries within minutes is suspicious by any geolocation method, even an imprecise one.

It's worth being honest about the false-positive sources too: a VPN client switching exit nodes, or a mobile user moving between cell towers near a regional border, can produce a coordinate jump that isn't actually impossible travel. A minimum-distance filter (LogTriage defaults to 100km) screens out same-metro noise, but no implementation of this check is going to be zero-false-positive — which is exactly why it should feed into an analyst's report as one risk factor among several, not an automatic account lockout trigger on its own.

Why a curl User-Agent Isn't Automatically Malicious

logtriage — Sun, 05 Jul 2026 06:38:20 +0000

A surprising number of security tools treat user-agent strings as a static blocklist: see curl, python-requests, or Go-http-client, raise an alert. In practice, this produces so many false positives that analysts learn to ignore the alert entirely — which defeats the purpose of having it.

curl hitting a public /health endpoint is completely unremarkable; it's almost certainly a monitoring probe or a developer's smoke test. The same curl user-agent posting to /api/v1/admin/users or /api/v1/beacon is a different story. The string itself didn't change. What changed is the context — the path being accessed, the response it got, what else that source IP did in the same session.

This is why context-aware risk scoring doesn't operate on the user-agent alone. A suspicious user-agent match is one signal among several: path sensitivity, ASN reputation, IP threat intelligence, and behavioral patterns from session grouping all feed into the same score. A compound-signal rule specifically rewards combinations — three or more independent high-severity indicators on the same event get a 1.25× multiplier. A curl request to a low-sensitivity endpoint from a clean IP stays low risk. The same user-agent on a sensitive admin path, from an ASN already flagged in a threat intelligence feed, compounds quickly.

The broader principle: a security tool that can't tell curl apart by context isn't actually doing risk assessment — it's pattern matching with an extra step.

I build LogTriage and publish a free, validated Sigma detection-rule library — each rule tested against a real sample log before it ships: logtriage.app/rules.