Establishing persistence

Objective 5.1 in this course covers post-exploitation activities — CompTIA describes it as establishing persistence, performing lateral movement, and cleaning up artifacts. This lesson opens Domain 5 with persistence. Runs on machines you own, in the lab from lesson 2. Everything a persistence mechanism places goes on the cleanup list the moment you place it (lesson 39).

Why this matters

Post-Exploitation and Lateral Movement is 14% of PT0-003, and it is where the engagement stops being about individual flaws and becomes about what an attacker would actually do with a foothold.

Persistence is the first of those activities, and it is the one that most needs careful framing, because a tester establishing persistence is deliberately doing the thing that, left behind, is the worst outcome in this course.

The lesson

Why a tester needs persistence at all, and for how long

An honest question, because persistence sounds like an attacker's goal rather than an assessment activity. The reasons a tester needs it:

• Survive a reboot or a lost connection during a multi-day engagement, so progress is not lost when a machine restarts.
• Demonstrate the risk. Whether an attacker could maintain access is part of what the client is paying to learn — a foothold that survives is a different risk from one that does not.
• Test detection. Whether the client notices persistence being established is a valuable finding, and often the point of a red-team-style engagement (lesson 1).

And the crucial limit: only as long as the engagement, and every mechanism tracked. A tester's persistence is temporary by definition, scoped to the window, and removed at the end. The difference between a tester and an attacker here is entirely one of authorisation and cleanup — which is why lesson 39 is not optional.

Scheduled tasks, services and startup locations

The common mechanisms, described so they are recognisable rather than as a how-to:

• Scheduled tasks and cron jobs run something on a schedule or at boot. The most common mechanism because it is reliable and ordinary-looking.
• Services and daemons that start at boot and run privileged.
• Startup and autorun locations that launch something when a user logs in.
• Modifications to legitimate startup scripts — profile scripts, init scripts — so existing infrastructure runs your code.

Each is a change to the system, and the defensive point is that each is a change file-integrity monitoring and configuration baselines are meant to catch. A new scheduled task, a new service, a modified startup file — these are exactly what a client's monitoring should flag, and whether it does is the finding.

Account and key based persistence

The other family, based on credentials and access rather than scheduled execution:

• A new account, or an existing dormant account re-enabled, ideally one that blends in. The most durable, because it survives software changes and looks like a legitimate user.
• Adding an existing controlled account to a privileged group, which is quieter than a new account.
• Authentication keys added to an account's authorised set, granting access without a password.
• Application-level access — an API token, an integration, an OAuth grant — which persists outside the operating system's account controls entirely and is frequently the least monitored.

These are more durable than execution-based persistence and often quieter, which is exactly why they are the ones to check whether the client can detect. An unexpected new account, a new key, a new integration are all events worth alerting on.

Recording every mechanism you place, as you place it

The rule that separates this lesson from an attack, and it is stated as a practice rather than an aspiration.

Every persistence mechanism goes on the cleanup list at the moment you establish it — not reconstructed from memory at the end. The list records: what it is, where it is, when you placed it, and how to remove it.

Why at the moment, not the end:

• Memory fails, and a multi-day engagement establishes many changes. The one you forget is the one you leave behind.
• A mechanism can outlive your notes if it is not written down when created — a scheduled task fires whether or not you remembered it.
• The client may ask mid-engagement what you have placed, and the answer must be complete and immediate.

Keep the list open in a second window (lesson 24's habit) and add to it as the first action after establishing anything. This is the discipline that makes lesson 39's cleanup reliable rather than hopeful.

What persistence looks like to a defender hunting for it

The defender's half, and the reason the lesson catalogues mechanisms — so you can describe what the client's defences should have seen.

• New scheduled tasks, services and startup entries are baseline deviations — detectable by comparing against a known-good configuration.
• New accounts, group changes and new keys are identity events that should generate alerts.
• New application grants and tokens are the most often missed, because they live outside the operating system's monitoring.
• The establishment itself — the commands that create these — is behaviour EDR (lesson 29) can catch in the act.

So the report has the usual two halves: here are the persistence mechanisms an attacker could establish, and here is which of them your monitoring detected. A client who detects none of it has a finding as serious as any technical one, because persistence undetected is an attacker who never leaves.

What to take into the exam

• A tester's persistence is temporary, scoped to the engagement, tracked, and removed; only authorisation and cleanup separate it from an attacker's.
• Execution-based persistence (scheduled tasks, services, startup locations) is detectable as baseline deviation; account/key/token-based persistence is more durable, quieter, and often less monitored.
• Application-level grants and tokens persist outside OS account controls and are the most frequently missed.
• Every mechanism is recorded on the cleanup list at the moment it is placed, and whether the client detected establishment is itself a finding.