Lesson 2.65: Who really did it: attribution through sudo
Logs that say 'root did it' answer nothing on a server where several admins use sudo. The kernel keeps a login UID for every session: set once at login, inherited by every child process and unchanged by sudo, su or sudo -i. Audit records carry it as auid next to the effective uid. In the lab a second account with UID 0 appeared on Northwind's jump host. You confirm that your own login UID survives sudo, find the account, and use the identity watches and execve records to tie every step, including an attempt to clean root's history, to one person's login.
18 min
You will learn to
- Explain loginuid and why it survives sudo
- Find UID 0 accounts
- Read identity watch events
- Read auid next to uid in execve records
- Contain a rogue account
Key terms
- loginuid
- The UID a session logged in as, stored per process in /proc/PID/loginuid.
- pam_loginuid
- The PAM module that sets loginuid at login (sshd, login, cron).
- auid vs uid
- auid: who logged in. uid/euid: whose rights the process uses now.
- UID 0 duplicate
- A second account with UID 0 is a full root under another name.
- Session ID (ses)
- A number per login session in audit records; groups everything one login did.
← Containers are processes: namespaces · All lessons · Recovering shell history from memory →