Persistence: Keeping Your Foothold
Getting a shell is exciting, and fragile. Your session can drop, the machine can reboot, the vulnerability you used can get patched, and just like that you're locked out. Persistence is everything an attacker does to make sure they can get back in reliably, without re-exploiting anything. It's the stage that turns a one-time break-in into ongoing access.
Where it fits
The order is: get access, escalate to root, then plant persistence so the access sticks. Persistence almost always comes after privilege escalation, because root lets you hide in places a normal user can't touch (system-wide cron, systemd units, the root account itself).
The families of Linux persistence
Persistence isn't one trick; it's a category. Almost every technique falls into one of these, and each is a lesson in this week:
| Family | Examples | Covered in |
|---|---|---|
| Accounts & keys | add your SSH key to authorized_keys; create a hidden user; add a second uid-0 account | SSH & account backdoors |
| Scheduled tasks | a cron job or systemd timer that reconnects every few minutes | startup & scheduled persistence |
| Startup files | .bashrc, .profile, rc.local, systemd services that run on boot/login | startup & scheduled persistence |
| Binaries | a SUID-root backdoor shell; a web shell dropped in the web root | across this week |
The common thread: put your trigger somewhere the system runs automatically, on a schedule, at boot, at login, or on connection, so it keeps giving you a way in.
The professional line
This is where ethics stop being a footnote. On a real system:
- Only with permission and in scope. Planting a backdoor on a machine you're not authorised to persist on is a crime, full stop.
- Keep it minimal and documented. A pentester notes exactly what they added, where, and when, one clearly-labelled key or account, not a dozen hidden implants.
- Clean it up. Persistence you add during a test gets removed during clean-up. You leave the box as you found it. (Attackers, of course, don't, which is the point of the next stage, covering tracks.)
The defender's mirror
Here's the good news for the blue team: every persistence technique is a place to look. Learning where attackers hide is exactly how you hunt for them:
- Diff
~/.ssh/authorized_keysand/etc/passwdagainst a known-good baseline. - Audit cron (
/etc/cron.*, user crontabs) andsystemctl list-timers --all. - Watch for new or modified systemd units, and odd lines in
.bashrc/rc.local. - Alert on new uid-0 accounts and unexpected SUID binaries.
Every lesson in this week is dual-use: read it as an attacker to learn the trick, and as a defender to learn the hunt.
Why this matters
Access without persistence is a candle in the wind. Understanding how a foothold is made durable is essential to red teaming, and even more so to defending, because you can't detect what you don't know to look for. This week walks the main techniques, one place at a time.