Anti-forensics SSH:
the session that tried to erase its tracks

The full sequence

Session ef742862 arrived with root credentials and, once authenticated, ran exactly seven commands. None of them downloaded software, none established persistence, none exfiltrated data. All seven commands have a single purpose: to remove evidence of access.

What each command erases

The sequence is methodical. It covers the main forensic evidence vectors of an SSH intrusion:

Command	What it removes
journalctl --vacuum-size=1K	Truncates the systemd journal to 1 KB, removing practically all system logs
cat /dev/null > /var/log/wtmp	Empties the user session log (used by last)
cat /dev/null > /var/log/btmp	Empties the failed login attempts log (used by lastb)
cat /dev/null > /var/log/lastlog	Empties each user's last-login log
cat /dev/null > /var/log/secure	Empties the SSH authentication log (on Red Hat/CentOS systems; equivalent to auth.log on Debian)
history -c	Clears the command history of the current bash session
history -w	Forces the history to be written to disk — in this case, writes an empty history over .bash_history

What it failed to erase

Here's the part that matters for defenders: the sequence is effective on systems without centralized logging, but fails in every environment with a SIEM or log shipper.

• /var/log/auth.log — if it's being ingested in real time by Filebeat, Fluentd or rsyslog into an external SIEM, the local wipe doesn't remove what was already sent.
• journalctl — if you use journald with ForwardToSyslog=yes or have remote journald, the local vacuum doesn't touch the remote logs.
• The honeypot itself — the full session, with every command, was recorded in honeypot.log outside the simulated filesystem. The attacker didn't know they were operating in a honeypot.
• Auditd — if you have auditd configured with rules to log accesses to /var/log/, the wipe operation itself is audited.

The PuTTY client as an anomaly

Another interesting indicator: while 99.5% of connections used SSH-2.0-Go, this session used SSH-2.0-PuTTY_Release_0.83. This suggests it could be a human operator (PuTTY is a GUI tool for Windows) rather than the main campaign's automated scanner. If so, there are two distinct actors: the automated Go scanner and at least one human operator who manually follows up on the accesses the scanner obtains.

Conclusion: silence is a signal too

In forensic analysis, the absence of logs is an indicator of compromise just as valid as their presence. If your authentication logs suddenly appear truncated or empty, it's not that "nothing happened" — it's that someone was there and erased them.

The defense is simple: never rely on local logs alone. If your authentication logs live solely on the disk of the compromised server, an attacker with root access can erase them in seven commands, in under ten seconds.

Data collected for cybersecurity research purposes. All information comes from unsolicited activity logged on our own infrastructure.