Courses Advanced Linux securityHunting & detections

Detections that survive contact

Behavior over strings, tests over hope.

Advanced14 min · lesson 13 of 17

All the visibility in the world is wasted on brittle detections. A detection "survives contact" with a real adversary when it keys on behaviour the attacker cannot cheaply change, not on the incidental details they change in seconds. Match on a file hash, a specific tool name, or an IP address, and the attacker recompiles, renames, or rotates and sails past. Match on the behaviour — a service process spawning a shell, a write to a persistence path, a mass read of SSH keys — and they cannot evade it without abandoning the technique itself.

Brittle vs durable detection signals

brittle (rotates in minutes)

file hashes

recompile changes it

tool / file names

rename and pass

IP addresses

new infra, new IP

durable (costly to change)

behaviour / syscall patterns

a shell from nginx

relationships

service → /tmp → outbound

anomalies vs baseline

this host never did that

The Pyramid of Pain: the higher up (behaviour, TTPs) you detect, the more it costs the attacker to adapt.

Test your detections like code

A detection you have never triggered is a hope, not a control — you do not know if it fires, or fires on the right thing, until you test it. Treat detections as code: for each rule, have a way to safely reproduce the behaviour it should catch (an atomic test, a script that performs the benign version of the technique) and confirm the alert fires, and confirm normal activity does not. This is how you avoid the two failure modes — the rule that never fires (a false sense of coverage) and the rule that fires constantly (alert fatigue) — before an incident reveals them.

terminal

# test a detection by safely performing the behaviour it should catch
$ nginx -c /dev/null -g 'daemon off;' &   # (stand-in) then, from that context:
$ /bin/sh -c 'id'                          # a "service spawned a shell" event
# → confirm your Falco/audit rule ALERTED. Atomic Red Team scripts systematize this.
# a rule you have not fired on purpose is a rule you cannot trust in an incident.

Coverage: map to ATT&CK, mind the gaps

Individual good detections are not the same as coverage. Map your detections to the MITRE ATT&CK techniques relevant to Linux and look for the blind spots — the persistence method you do not watch, the escalation path with no alert. The goal is not a rule for every possible thing (impossible and noisy) but deliberate coverage of the techniques that matter for your environment, with the gaps known and accepted rather than accidental. Detection engineering is a portfolio you curate, not a pile of rules you accumulate.

Detect behaviour, not the tool of the week

The strongest and most common temptation is to write detections for the specific malware or tool in the latest report — a hash, a filename, a domain. Those are trivially rotated and your rule is stale before it ships. Spend your detection effort at the behaviour level: what does the technique fundamentally have to do (spawn a shell, write a persistence file, read credentials, load a module)? Detections at that level cost the attacker real effort to evade and stay useful across tools and campaigns.

Falco on bare hostsThreat hunting on Linux