The command that gives away the 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 is a statement: I did not come to steal data, I came to stay. The difference between reconnaissance and persistence fits in three commands.
The uname and the id are last-second reconnaissance — confirming that the server is Linux and that root access is in hand. Then, straight away, passwd. No exploration, no downloads, no exfiltration commands. The script is short because the goal is simple.
Why it is 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.
- Locking out the owner: 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 is 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. - A definitive indicator of compromise: finding the root password changed without any administrator having done so is not ambiguous. Someone was there.
What the honeypot saw — and the attacker did not
The honeypot accepts the passwd as normal: it shows the change prompt, the attacker enters the new password, and receives confirmation. Everything appears to work.
The change is logged — but it does not persist on 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 that they require active logging — most servers do not alert on passwd executions by default.
- Alert on
passwdin SSH sessions: no legitimate CI/CD script runspasswd. If the command shows up in the logs of an interactive SSH session, it is a high-level alert. - Cover
chpasswdandusermod -ptoo: an attacker with shell access can change credentials without an interactive prompt:echo 'root:nueva' | chpasswddoes not generate the same session pattern aspasswd. The only reliable detection is at the filesystem level — not at the session-behavior level. - Key-only authentication: if
PasswordAuthentication nois set in/etc/ssh/sshd_config, changing the root password grants no additional access to anyone who does not 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 does not 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.
CipherSentry SSH honeypot · 2026-06-26 a 2026-06-28