Sysmon vs. auditd on Linux: What a Sandworm-Style Attack Actually Reveals

Disclosure: This article is a technical review and analysis of the following paper for my Computer System Security (CSS) course at PIEAS:
Joshua Keller, "Enhancing Linux Threat Detection: A Sysmon-Based Approach to Identifying Sandworm TTPs," SANS Institute, January 2026.
All experimental results, lab data, and findings referenced here belong to the paper's author. My contribution is the analysis, summary, and commentary.

---

Why This Paper Caught My Attention

Linux runs a lot of critical infrastructure — 78.3% of internet-facing web servers, and critical workloads for 72.6% of Fortune 500 companies. And attackers have noticed: Kaspersky reported a 130% year-over-year increase in Linux exploit attacks in Q1 2024 alone.

Yet most of the tooling, research, and community knowledge around endpoint detection still skews heavily toward Windows. Sysmon for Linux has existed since 2021, but there has been very little published research on how it actually performs against real APT-style activity.

This SANS paper by Joshua Keller addresses that gap directly — and the results are worth understanding if you work in, or are studying, Linux security.

---

What the Paper Does

The author ran a controlled, reproducible experiment: set up identical Ubuntu 24.04 servers, run the same 16-step Sandworm-style attack against each one, and then count what each logging configuration actually caught.

Three configurations were tested:

The attack was modelled on MITRE's ATT&CK evaluation for Sandworm — a well-documented APT group attributed to Russia's GRU, responsible for attacks including the three-year Centreon intrusion disclosed by France's ANSSI in 2021.

Tools used by the paper's author: VMware Workstation Pro 17.6.2, MITRE Caldera (adversary emulation), Hydra (SSH brute-force), Elasticsearch + Kibana 8.14.3 for log analysis.

---

The Attack Chain

The simulated attack followed six broad stages across 16 steps:

1. Initial Access
SSH brute-force using Hydra against a weak credential (fherbert:horses). This is the noisiest stage — all three tools detected it.

2. Web Shell Deployment
Using the compromised credentials, a PHP web shell was uploaded to /tmp/ via SCP and then moved to the web root at /var/www/html/. Suspicious, detectable — if your logging is configured for it.

3. Discovery
Via the web shell, the attacker ran whoami, uname -a, ls -lsahR, and cat /etc/passwd using curl. These commands ran under the www-data user — which is not normal and is a strong indicator of web shell activity.

4. Execution & Privilege Escalation
A Sandcat agent (Sandworm's golang-based implant) was downloaded from the Caldera C2 server on port 8888, given executable permissions, and run via a SUID binary named /bin/backup. The outbound curl to a non-standard port is a detection opportunity.

5. Persistence
Two persistence mechanisms were established:

• A crontab entry to run the agent every hour and on reboot
• A fake systemd service file named syslogd.service — deliberately named to blend in

6. Credential Access
With root access via the agent, the attacker read /etc/shadow (all password hashes), .bash_history (which contained credentials added during setup), and SSH private keys.

---

What Each Tool Actually Saw

This is the part of the paper that matters most.

After Initial Access — DISA STIG Goes Nearly Blind

Once the attacker moved past the SSH brute-force, the DISA STIG auditd configuration generated almost no useful telemetry. It missed the web shell discovery commands, the agent download and execution, both persistence mechanisms, and the credential access stage entirely.

This is striking because DISA STIG is a regulatory standard — it represents what many organizations actually deploy on production systems.

Sysmon Caught Everything

Sysmon logged relevant events at every stage. A few examples from the paper's data:

• Web shell detection: Sysmon Event ID 1 captured mv /tmp/search.php /var/www/html/ with the full command line, user (fherbert), and process executable.
• Discovery stage: Event ID 1 captured sh -c -- whoami running under www-data — a clear web shell indicator.
• Persistence: Event ID 11 logged the creation of the crontab temp file and the syslogd.service file.
• Credential access: cat /etc/shadow, cat .bash_history, cat id_rsa — all captured with the user (root) and full command.

Total logs during the attack window: 996

Neo23x0 Also Caught Everything — But Louder

The community-maintained Neo23x0 auditd ruleset matched Sysmon's coverage across all stages. However, it generated 2,624 log entries — about 2.63× Sysmon's volume.

There's also a usability difference: auditd often splits event context across multiple log entries (e.g., the username in a syscall log, the command arguments in a proctitle log), which requires correlation. Sysmon consolidates this into a single event.

---

The Detection Comparison at a Glance

---

Three Things Worth Taking Away

1. Compliance ≠ Security
The DISA STIG is a serious, widely-applied standard. But it was built for regulatory coverage, not detection. This paper demonstrates with actual log data that passing a compliance checklist does not mean your system can detect a real intruder.

2. The Log-to-Noise Tradeoff Is Real
Sysmon's 996 logs vs. Neo23x0's 2,624 logs isn't just a number — it's analyst time, SIEM ingestion costs, and alert fatigue. Detection capability matters, but so does the signal-to-noise ratio of what you're sending to your SIEM.

3. Sysmon Has a Genuine Advantage in Usability
For teams already familiar with Sysmon on Windows (and that number is growing, especially with Microsoft's announcement that native Sysmon functionality is coming to Windows in 2026), the Linux version offers a consistent rule syntax and consolidated event format. The barrier to adoption is lower than auditd for teams without deep Linux audit expertise.

---

One Notable Limitation

Sysmon does not capture SSH usernames via PAM. During the SSH brute-force stage, auditd's USER_AUTH and USER_LOGIN records included the targeted username (fherbert) directly. Sysmon only saw the connection spike — to determine the affected user, you'd need to correlate with SSH application logs.

This is a real gap for initial access investigation and worth knowing before deploying Sysmon as a sole detection layer.

---

My Takeaway from Reviewing This Paper

I reviewed this paper for my Computer System Security course at PIEAS, and wrote a structured summary report and class presentation based on it.

The thing that stayed with me is how concrete the paper is. It doesn't argue theoretically that Sysmon is better than auditd — it runs the same attack against both and counts the logs. That methodology is simple and reproducible, and the results are clear.

For anyone working toward a blue team or detection engineering role, this paper is a useful read. Not because Sysmon is a silver bullet, but because it illustrates how much detection capability is left on the table when logging is configured for compliance rather than for visibility.

---

Resources

• My summary report and class presentation slides: https://github.com/Computer-System-Security/linux-threat-detection-sysmon-review/
• Original SANS paper: Joshua Keller, SANS Institute Reading Room, January 2026
• MITRE ATT&CK Sandworm evaluation: https://attackevals.github.io/ael/enterprise/sandworm/
• Neo23x0 auditd ruleset: https://github.com/Neo23x0/auditd
• Sysmon for Linux: https://github.com/microsoft/SysmonForLinux

---

This article is a review and analysis written as part of CSS coursework (MS in Cyber Security, PIEAS). All experimental findings referenced here are from the original SANS paper by Joshua Keller.