🚨 At 2:14 AM, a SOC analyst caught something most teams miss entirely.
A production server started sending traffic to an unfamiliar IP. By the time the incident responder got a shell open, the attacker was gone. But they'd left something behind — Linux bash history.
Within minutes, that single command reconstructed the entire attack:
whoami → id → sudo -l → curl (payload download) → tar (data staging) → curl -X POST (exfiltration) → history -c
That last line, history -c, was the giveaway. The attacker tried to erase their tracks after stealing a config file that likely held database credentials. It's such a common move that MITRE ATT&CK tracks it as its own technique: T1070.003 — Indicator Removal: Clear Command History.
Here's the thing most people don't realize: clearing bash history rarely saves an attacker in a well-monitored environment. If a SOC is shipping shell activity to a SIEM in real time (via auditd, osquery, or similar tools), the "cleanup" command itself becomes evidence of intent.
I wrote a full breakdown covering:
- Every major Linux history command — what it does, when to use it, expected output
- A real breach timeline traced entirely through bash history
- How attackers try to cover their tracks (and why it often backfires)
- Detection and prevention techniques SOC teams actually use in production
If you're studying for GCIH/GCFA, working in a SOC, or just curious how incident responders reconstruct an attack from a shell log, this is worth a read:
https://www.xpert4cyber.com/2026/07/bash-history-forensics-soc-analyst-breach-story.html
Top comments (0)