Linux Backdoor Account Persistence
Creating a backdoor account gives persistent access that survives payload restarts, cron removal, and web shell cleanup. A local account with sudo rights or a UID of 0 gives root-equivalent access on every reconnect. Requires root to create privileged accounts.
Techniques covered on this page:
- Standard backdoor user with sudo group membership
- UID 0 account for root-equivalent access
- Passwordless sudo via
sudoers.ddrop-in file - Direct
/etc/passwdmanipulation to bypass audit logging
Choose an account name that blends into the system. Names like sysadm, backup, or netops draw less attention than generic strings. Defenders checking for new accounts typically run lastlog, diff /etc/passwd snapshots, or query audit logs for useradd events. Creating accounts via direct file writes bypasses the useradd process event and avoids those alerts. A SIEM rule on account creation outside provisioning windows is common in monitored environments.
Create a backdoor user
uid=1001(backdoor) gid=1001(backdoor) groups=1001(backdoor),27(sudo)
UID 0 backdoor
Adding a second account with UID 0 gives it root privileges without it being the actual root account. The account appears as a normal user in ls /home but operates as root.
Linux privilege checks use UID, not the username. SSH logs the backdoor account name rather than root, which helps avoid root login alerts. After creation, confirm with id support and verify the UID returned is 0. Some PAM modules and SSH configurations explicitly block UID 0 logins for non-root accounts. Check sshd_config for PermitRootLogin and AllowUsers directives before relying on SSH access. The -o flag in useradd allows duplicate UIDs. Hardened distributions may disable this at compile time. If the flag is unavailable, use direct /etc/passwd manipulation instead.
Passwordless sudo
Adding a NOPASSWD sudo rule for an existing account gives root access without needing to know or set a password. This is less detectable than creating a new account.
Use a drop-in file under /etc/sudoers.d/ rather than editing /etc/sudoers directly. A syntax error in /etc/sudoers can lock out all sudo access on the system. Errors in drop-in files affect only that file and fail gracefully. File permissions must be exactly 440, otherwise sudo ignores the file entirely without an error. Name the drop-in file something that resembles a system package file, such as 98-cloud-init or sysupdate. This technique leaves no new account entry in /etc/passwd and creates no process artifact from account creation commands. Endpoint agents monitoring /etc/sudoers.d/ for file integrity changes will still flag the new file.
Modify /etc/passwd directly
On older systems without shadow passwords, or when you have direct file write access, a password hash can be embedded directly in /etc/passwd.
Modern systems store passwords in /etc/shadow and use an x placeholder in /etc/passwd. Replacing that x with a real hash still works, because PAM reads the field before falling back to shadow. Use SHA-512 (-6) over MD5 (-1) where possible. MD5 hashes crack in seconds on any modern rig. On systems where PAM enforces shadow-only lookups, the passwd field hash is ignored entirely. Test the account immediately after adding the entry to confirm access works. This approach skips useradd and chpasswd process events, reducing audit log entries. The trade-off is that /etc/passwd is world-readable, so any local user on the system can see the new entry.
Cleaning up
Remove artifacts in the reverse order they were created. Remove sudoers drop-in files before deleting accounts. An orphaned sudo rule grants access to the next user who gets that username. The userdel -r flag removes the home directory along with the account. If you created the account via direct file writes only, the home directory may not exist and userdel errors harmlessly. Check /var/log/auth.log or /var/log/secure for login events tied to the backdoor account. Those log entries persist after the account is removed. Audit logs from auditd may record the original useradd syscalls and each subsequent login. Coordinate with the client on which log artifacts to preserve as evidence before clearing entries.