Post-Exploitation and Lateral Movement · Topic 1 of 5
Persistence Concepts
Understand how attackers and testers keep access after exploitation: persistence on Windows, Linux and cloud systems, plus how to detect and remove it.
- 5 min
- Persistence keeps access after reboots, logoffs and credential changes.
- Typical Windows mechanisms are scheduled tasks, Run keys, services, WMI subscriptions and new accounts.
- Typical Linux mechanisms are cron, systemd units, shell profiles and authorised SSH keys.
What it is
Post-exploitation is everything that happens after the tester gains a foothold. Persistence is the part that keeps access alive across reboots, password changes and lost connections.
In a real attack, persistence lets the intruder come back at will. In a penetration test, it is normally shown only to the extent needed to prove the risk, and every mechanism is recorded so that it can be removed.
How it works
Why persistence matters
A first foothold is fragile. A reboot, a patch or a closed session may end it, so attackers set up a second way back.
Testers do the same only when the rules of engagement allow it, because persistence changes the client's systems. Often a short, documented proof is enough, and any change is logged for cleanup.
Common categories
Persistence works by making the system run something again or by creating a new valid way to log in. The categories below match the MITRE ATT&CK tactic called Persistence.
| Category | Windows examples | Linux examples |
|---|---|---|
| Scheduled execution | Scheduled tasks | cron jobs |
| Startup items | Registry Run keys, startup folder | Shell profile files, init scripts |
| Services | New or modified service | systemd service or timer |
| New accounts or keys | Local or domain account added, stolen credentials | New user, added Secure Shell (SSH) authorised key |
| Event-driven triggers | Windows Management Instrumentation (WMI) event subscriptions | udev rules |
| Library or binary replacement | DLL (dynamic-link library) search order hijack | Replaced shared libraries |
| Web access | Web shell in a web server folder | Web shell in a web server folder |
A web shell is a script placed on a web server that gives remote command access through a web request. It is a common persistence method on compromised servers.
Shells and backdoors
A backdoor is any hidden way back into a system. Two shell types appear in the outline.
| Type | Idea |
|---|---|
| Reverse shell | The target connects outward to the tester, which egress filtering can limit |
| Bind shell | The target listens for an incoming connection, which inbound firewall rules often block |
Other backdoor forms include a trojan, which is malicious code hidden inside legitimate-looking software, and a web shell on a web server. A rootkit hides processes and files, in user mode or more deeply in kernel mode, and a deeply compromised host is best rebuilt rather than cleaned. Malicious browser extensions are another persistence route, countered by an extension allow list.
Domain and cloud persistence
In a Microsoft Active Directory domain, long-lived access can come from forged or stolen Kerberos material, extra privileged accounts or changed group memberships. Because these live in the directory, they survive the rebuilding of a single host.
In the cloud, persistence is usually an identity change rather than a program on a machine.
- A new access key or user created for later use.
- A role with a trust policy that lets an external account assume it.
- A changed policy that grants wider rights to an existing identity.
- A backdoor application registration or token with a long lifetime.
For this reason, cloud incident response must review identities and keys, not only servers.
Detection
Persistence usually leaves small changes, and defenders find them by comparing against a known good baseline.
| Indicator | Where to look |
|---|---|
| New scheduled tasks or cron entries | Task scheduler, crontab files |
| New or changed services and startup entries | Service list, registry autorun locations |
| Unknown accounts or authorised keys | Directory, local user lists, SSH key files |
| Unexpected files in web folders | Web root, file integrity monitoring |
| Strange outbound connections at regular intervals | Firewall and proxy logs, which indicate beaconing |
| New cloud keys, roles or policy changes | Cloud audit trail |
Tools such as Sysinternals Autoruns list Windows startup locations in one view. File integrity monitoring and endpoint detection and response (EDR) products alert on changes to those places.
Prevention and removal
- Apply least privilege so that a low-level foothold cannot write to startup locations.
- Restrict who can create accounts, tasks, services and cloud keys.
- Log and alert on changes to these items.
- Rebuild a compromised host from a trusted image instead of cleaning it by hand, when the compromise was deep.
- Rotate credentials and keys after an incident.
Every persistence mechanism a tester installs must be written down at the time, with its location and time, so that it can be removed and the client can verify it is gone.
What to remember for the exam
- Persistence keeps access after reboots, logoffs and credential changes.
- Typical Windows mechanisms are scheduled tasks, Run keys, services, WMI subscriptions and new accounts.
- Typical Linux mechanisms are cron, systemd units, shell profiles and authorised SSH keys.
- A web shell is a persistent remote-access script on a web server.
- In the cloud, persistence is usually a new key, role, trust relationship or policy change.
- Detect persistence by comparing against a baseline and using tools such as Autoruns, EDR and cloud audit logs.
- Persistence changes the client's systems, so the rules of engagement must allow it.
- Record every mechanism so that it can be cleaned up.
Common mistakes
Thinking persistence is always malware. Many forms are legitimate features, such as scheduled tasks and SSH keys, used in unwanted ways.
Forgetting identity persistence. Removing a tool does not help if a new account or key remains.
Persisting without permission. A test that leaves access on production systems without approval is a risk.
Cleaning by guesswork. Without a record of what was changed, a tester can leave something behind.
Looking only on hosts in the cloud. The audit trail for identities is often where the evidence is.
Check yourself
What is the purpose of persistence?
To keep access to a system after reboots, logoffs or credential changes.
Name two Linux persistence locations.
cron jobs and authorised SSH keys, or systemd units and shell profile files.
How do defenders usually find persistence?
By comparing current startup items, tasks, accounts and keys against a known good baseline.
Topic 1 of 5 in Post-Exploitation and Lateral Movement
Test yourself on Post-Exploitation and Lateral Movement
The full CompTIA PenTest+ PT0-003 question bank has 653 questions, with timed practice exams and an explanation for every answer.
This study guide is independent and is not affiliated with, endorsed by, or sponsored by CompTIA. Vendor names, certification names and exam codes are trademarks of their respective owners and are used for identification only.