Offboard an insider completely, and find what you would have missed

applied · 70 min · Objective 2.2

Task

An insider starts past most of your controls, and the structural answer the lesson gives is prompt, complete offboarding. Create a realistic identity on your own lab VM with access spread across several places, then write and test an offboarding checklist. The value is in the items you discover you had forgotten, which is exactly how real offboarding fails.

Steps

  1. First run sudo find / -xdev -nouser 2>/dev/null | wc -l and note the number (normally 0). Then create the identity and spread its access deliberately: add a user named labuser, give it a group membership, a cron job, a sudoers entry, a file it owns outside its home directory, and a running process. Give it an SSH key made with ssh-keygen -C labuser, and put the public key in /home/labuser/.ssh/authorized_keys AND in your own account's ~/.ssh/authorized_keys -- the shared-account key is the classic survivor.
  2. Now WITHOUT looking at what you just did, write /tmp/offboarding.md from memory: the checklist you would follow to remove a leaver completely, starting at the moment they are told they are leaving rather than at the end of their notice.
  3. Execute your checklist exactly as written.
  4. Then hunt for what survived: search for the username across /etc/passwd, /etc/group, /etc/sudoers and /etc/sudoers.d, /home, /var/spool/cron, every authorized_keys file, and the process table, and files owned by the now-deleted UID.
  5. Record every survivor in /tmp/survivors.md -- these are the items your checklist was missing.
  6. Revise the checklist to cover them, and note which survivor would have been the most dangerous in a real estate and why. Add one line on which of the lesson's structural controls (least privilege, separation of duties, behavioural detection) would have limited it had offboarding been late.

Verify

U=labuser
grep -c "^$U:" /etc/passwd
sudo grep -rc "$U" /etc/sudoers /etc/sudoers.d/ 2>/dev/null | awk -F: '{s+=$2} END {print s+0" sudoers reference(s)"}'
sudo find / -xdev -nouser 2>/dev/null | wc -l
sudo grep -rl "$U" /home/*/.ssh/authorized_keys 2>/dev/null | wc -l
grep -c . /tmp/survivors.md

The first four must all be 0 after your revised checklist has run (the third must equal the number you noted before step 1) -- no account, no sudoers entry, no files orphaned by the deleted UID, no key left behind anywhere. The key check works because the key's comment is labuser; a key with no comment is invisible to it, which is why the comment is worth insisting on. find -nouser is the one people miss: deleting a user leaves their files owned by a numeric UID that the next user created will inherit. The fifth must be non-zero, because the survivors you found are the output of this lab.

Notes

In a real estate the survivor list is longer and worse: SaaS accounts outside single sign-on, API keys the person created, shared credentials they knew, and their access at third parties. The lesson generalises -- offboarding fails by forgetting one system, and the only defence is a checklist built from what was actually found rather than from what someone remembered. A revenge-motivated insider clusters around exactly this window, which is why access goes when the notice is given.

This is an independent study companion for CompTIA Security+ SY0-801 and is not produced by or endorsed by CompTIA.