Who Got Root: Spotting Privilege Escalation in Linux Auth Logs
The challenge
Something on this Linux box escalated to root. Real admins use sudo all day, so that alone is not suspicious. But one account that should only ever run backups was added to the sudo group and then immediately ran a root shell. Read the auth log, separate the normal admin activity, and submit the account that escalated to root.
What you'll learn
- Read Linux auth and sudo log events as a behaviour timeline
- Distinguish routine admin sudo from anomalous escalation
- Recognise the usermod-to-sudo then root-shell chain
- Use account purpose as a baseline for what is normal
- Attribute a privilege escalation to a specific account
Skills tested
Prerequisites
- Familiarity with Linux users, groups, and sudo
- Understanding of service accounts versus interactive accounts
- Awareness of su and root shells
How it works
On a Linux host, escalation to root is normal - administrators do it dozens of times a day with sudo. So you cannot flag every privileged action; you have to know what each account is supposed to do and spot the one whose behaviour breaks its baseline. That baseline is the key idea: a service account like svc_backup exists to run one job (backup.sh) on a schedule. It should never log in interactively, never be added to a privileged group, and never open a root shell.
Read the log as a timeline and the chain for svc_backup stands out: it authenticates over SSH with a password from an external IP (203.0.113.45) instead of running from cron, then root runs usermod -aG sudo svc_backup to grant it sudo, and seconds later it executes sudo /bin/su - to open a full interactive root session. Inside that session it reads /etc/shadow, creates a new user, and downloads and runs a script - clear post-escalation activity. Meanwhile alice, bob, carol, and dave use sudo only for routine, single-command tasks and never get a group change or a root shell.
This is why event:usermod and event:session are the high-value filters. The escalation is not one event - it is the combination of an out-of-character login, a group grant, and a root shell, all on the same non-admin account.
Common mistakes
- Flagging the first account you see using sudo. Admin sudo is constant background noise here; the escalation is the account that should never have it.
- Submitting root.
rootappears in the usermod and session lines, but the question asks which account escalated to root - that issvc_backup. - Stopping at the usermod line. Being added to sudo is half the story; the confirmation is the
su -root shell that follows. - Ignoring the account's purpose. Without knowing
svc_backupis a backup-only service account, the activity looks like just another admin.
How to defend against it
Privilege escalation is detectable when you alert on changes to who can become root, not just on root activity itself. Baseline each account and watch for deviations.
- Alert immediately on
usermodor group changes that add an account tosudoorwheel, especially a service account. - Forbid interactive and password SSH logins for service accounts - restrict them to a specific command via a forced command or systemd unit.
- Alert when a non-admin account opens a root shell (
su -orsudo -i). - Use least privilege: give the backup account only the exact capabilities it needs, never blanket sudo.