The command that betrays intent
Some commands change meaning depending on who runs them. passwd in the hands of an administrator is routine. In the hands of a freshly authenticated attacker, it's a declaration: I didn't come to steal data, I came to stay. The difference between reconnaissance and persistence fits in three commands.
The uname and id are last-second reconnaissance — confirming the server is Linux and that root access is in hand. Then, straight to passwd. No exploration, no downloads, no exfiltration commands. The script is short because the goal is simple.
Why it's more dangerous than installing malware
The technical detail that makes it hard to detect: passwd writes no file in unusual paths, opens no network ports, creates no new processes. Malware scanners look for artifacts — suspicious binaries, crontab entries, installed services. A password change leaves none of those traces.
- Owner lockout: if the change succeeds, the legitimate administrator loses password access. SSH keys still work — but if the server only has password auth, the owner is locked out.
- Persistence without artifacts: there's no file to scan, no process to kill, no crontab entry to remove. The only trace is in
/etc/shadow, and only if you know to look for it. - Definitive indicator of compromise: finding the root password changed without any administrator having done it is not ambiguous. Someone was there.
What the honeypot saw — and the attacker didn't
The honeypot accepts passwd as normal: it shows the change prompt, the attacker enters the new password, receives confirmation. Everything appears to work.
The change is logged — but it doesn't persist in the real system. The honeypot returns confirmation to the attacker; in the next session, the original credentials are still valid. The signature stays in the log, not in the system.
Detection
The signals are clear. The problem is they require active logging — most servers don't alert on passwd executions by default.
- Alert on
passwdin SSH sessions: no legitimate CI/CD script runspasswd. If the command appears in the logs of an interactive SSH session, it's a high-level alert. - Covers
chpasswdandusermod -ptoo: an attacker with shell access can change credentials without an interactive prompt:echo 'root:nueva' | chpasswddoesn't produce the same session pattern aspasswd. The only reliable detection is at the filesystem level — not session behavior. - Key-only authentication: if
PasswordAuthentication nois set in/etc/ssh/sshd_config, changing the root password grants no additional access to anyone who doesn't already have the private key.
The only defense that covers every variant — passwd, chpasswd, usermod -p — is to monitor the file directly. Two lines of auditd on Debian/Ubuntu:
This rule logs any modification of the password file regardless of the method used. It doesn't matter whether the attacker used interactive passwd, chpasswd from a script, or usermod: if it touched /etc/shadow, auditd saw it.
The passwd command leaves no binaries. It opens no ports. It installs no services. What it leaves is silence — and silence, in cybersecurity, is the hardest signal to detect. The difference between a compromised system and a clean one fits in a single field of /etc/shadow. That field has no alarm by default. Now it can have one.
Data collected for cybersecurity research purposes. All information comes from unsolicited activity recorded on our own infrastructure.
honeypot CipherSentry · 2026-06-26 a 2026-06-28