Why a compromised root account means rebuilding the server, not cleaning it.

Every account on a Unix system has a birth certificate. A line in the authentication log that records who created it, when, and with what tool. An account with no such line was not created through any tool. It was written, by hand, straight into the user file. When that account also carries UID 0, the missing line is not a gap in your records. It is the evidence.

UID 0 is a number, not a name

Root is not the account named root. Root is any account whose user ID is 0. The kernel grants privilege on the number, and the name is decoration. So a backdoor does not need to touch the root account or guess a password. It needs one more line in the user file with a 0 in the third field.

Give that line a name a single character off a legitimate system daemon, and it disappears in plain sight. A user list is long, the names are cryptic by design, and a responder scanning it reads a known daemon, slightly misspelled, and moves on. The disguise is not sophisticated. It only has to survive a glance.

# Root is a UID, not a name. List every account with UID 0.
awk -F: '$3 == 0 { print $1 }' /etc/passwd

# Exactly one line should come back: root. Any second line is a
# full-privilege account, whatever it calls itself.

Two reasons to move on. Both wrong.

A good responder can be walked right past a hidden root account by two reasonable observations. Both are the kind of thing you nod at and move on. Neither survives a second look.

“A single automated check is not proof. Confirm it with an independent scan.”

The account with no birth certificate

Every account created through the standard tools leaves a line in the authentication log: created by whom, when, with what command. A planted account has none. Not a deleted line, no line at all, because the attacker never used the tool. The password hash is written straight into the user file by hand, which is why there is nothing to log.

And it is written into the wrong file. On any modern Unix system the password field in the user file is delegated to the shadow file. It holds a placeholder, never a real hash. A genuine hash sitting in the user file is not a configuration choice or a legacy quirk you can wave off. It is the fingerprint of a manual edit, and it is an indicator on its own.

With no log line, the account's real creation time has to be reconstructed from side channels: file timestamps, and the records other events left around it. The absence of a birth certificate does not stop you from establishing the time of birth. It just means you work for it.

# The password field in /etc/passwd should be a placeholder (x),
# never a hash. The real hash lives in /etc/shadow.
awk -F: '$2 != "x" && $2 != "*" && $2 != "!" { print $1 }' /etc/passwd

# A name that comes back here has its hash in the wrong file.
# That is a manual edit, not a managed account.

“A UID-0 account with no creation log wasn't created. It was written.”

When an update locks the attacker out by accident

The strangest thing about this failure mode is what a routine automatic update can do to it. An unattended update can rewrite a planted hash as a side effect and lock the attacker out of their own backdoor. The account stays. The access is gone. The backdoor can then sit dormant indefinitely: an unlocked door into a room whose key no longer turns. That looks like safety. It is not.

You don't clean it. You rebuild it.

The tempting close is 'delete the bad account, apply the patch, done.' Refuse it. Root access for any window, even a window that luck later slammed shut, means every byte on that machine is now suspect: binaries, cron jobs, libraries, and the very tools you would use to inspect it. You cannot audit your way back to trust on a system whose auditing tools you can no longer trust.

“Root for a minute is root until the rebuild. You don't clean that machine. You rebuild it from a point you can prove was clean.”