Windows defenders have leaned on Sysmon for years. Since Microsoft released Sysmon for Linux, the same structured, rule-driven telemetry model is available on the servers where much of our critical infrastructure actually runs.
What it captures
Sysmon for Linux is built on eBPF and emits events in the same schema Windows defenders already know:
| Event ID | Event | Detection value |
|---|---|---|
| 1 | Process creation | Execution chains, suspicious binaries |
| 3 | Network connection | C2 beaconing, unexpected egress |
| 11 | File created | Dropped payloads, persistence artifacts |
| 23 | File deleted | Anti-forensics, log tampering |
Events land in syslog as XML, ready for your forwarder of choice.
Quick deployment (Ubuntu example)
sudo wget -qO- https://packages.microsoft.com/keys/microsoft.asc | gpg --dearmor | \
sudo tee /usr/share/keyrings/microsoft.gpg > /dev/null
sudo apt-get update
sudo apt-get install sysmonforlinux
# Apply a configuration and verify
sudo sysmon -accepteula -i config.xml
sudo tail -f /var/log/syslog | grep sysmonThe configuration format mirrors Windows Sysmon, include/exclude rules keyed
on fields like Image, DestinationIp and TargetFilename, so existing
config discipline carries over.
Sysmon vs auditd
They overlap but aren’t interchangeable. auditd reaches deeper into
syscalls and satisfies compliance frameworks; Sysmon produces cleaner,
detection-oriented events with far less tuning. In practice I treat Sysmon as
the detection layer and auditd as the forensic/compliance layer, and let the
SIEM parser effort follow that split.
Where to start with rules
Begin with an exclude-nothing config on a test host, measure volume, then exclude the noisy legitimate paths (package managers, monitoring agents) rather than trying to enumerate evil. Ship process creation and network connection events first; they carry most of the hunting value.
This article was originally published on Medium.