Persistence, Seen From the Defensive Side — Ethical Hacking: Penetration Testing Methodology

An attacker who gains access to a system often wants that access to survive a reboot, a password change, or simple bad luck. This is called persistence. Rather than teaching persistence techniques, which this course deliberately avoids providing as functional, ready-to-use material, this lesson teaches you to recognise the concept and, especially, to look for it as a defender and as an auditor.

Why this lesson is framed defensively

Persistence mechanisms are, by nature, exactly the kind of "functional offensive technique against a real target" that this course's brief explicitly rules out providing. But understanding the concept is essential for two very practical reasons directly relevant to a penetration tester: first, part of a thorough post-exploitation assessment includes checking whether an attacker (simulated by the tester) could have established persistence, and clearly reporting the categories of mechanism that were available, without needing to actually deploy one; second, every tester should understand how real incident responders detect persistence, since a professional in this field frequently works alongside defensive teams.

What persistence generally looks like, as a concept

At a conceptual level, persistence means arranging for some action to happen automatically, repeatedly or after a specific trigger (a reboot, a scheduled time, a user logging in), without needing the original point of entry to remain open. Common categories, described here only as categories to recognise, not as techniques to deploy:

Scheduled or automatic tasks: both Linux and Windows systems provide legitimate mechanisms to run programs automatically at specific times or events, which can be abused to repeatedly re-establish unauthorised access.
Modified startup configuration: both operating systems have well-known places where programs are configured to start automatically when the system boots or a user logs in, which can similarly be abused.
Additional accounts or credentials: creating a new account, or adding credentials to an existing legitimate mechanism, that the legitimate administrators are not aware of.
Modified legitimate software: altering an existing, trusted program or script so that, alongside its normal function, it also performs an unauthorised action.

None of these categories require any specific, named tool or exact technique to understand at this level; what matters is recognising the pattern "something is arranged to happen automatically or repeatedly, outside the awareness of legitimate administrators."

Why persistence is hard for attackers to hide perfectly

Every one of the categories above leaves some trace, because by definition they rely on legitimate system mechanisms (scheduled tasks, startup configuration, account lists, trusted programs) being used in an unexpected way. This is precisely why defenders focus heavily on baseline comparison: knowing what scheduled tasks, startup entries, accounts and critical files are expected to exist on a system, so that anything unexpected stands out clearly.

What a tester checks and reports, without deploying anything persistent

During an authorised engagement, rather than actually establishing lasting access (which carries real risk and ethical weight, and is typically reserved for specific, clearly agreed red team engagements, as discussed in chapter 1), a standard penetration test usually assesses and reports:

Whether the compromised account or access level obtained would, in principle, have allowed creating a scheduled task, modifying startup configuration, adding an account, or altering a trusted program.
Whether any logging or monitoring exists that would likely detect such a change, which is itself one of the most valuable things to report, since it tells the client how quickly a real intrusion might be noticed.
A clear, explicit statement in the report that no actual persistence mechanism was deployed, which protects both the tester and the client by making the boundary of the test completely unambiguous.

Legal reminder

Deploying an actual persistence mechanism, even in a lab, carries real operational risk (a forgotten scheduled task or account can remain long after a course exercise ends) and, in a real client engagement, requires very explicit, specific agreement, since it directly touches the client's trust in the integrity of their own systems. This course does not provide functional persistence techniques, and any lab practice should focus on recognising and detecting the categories above, for example on a training platform's dedicated detection or "blue team" exercises, rather than deploying anything new.

The defender's toolkit, conceptually

From the defensive perspective you studied earlier in this track, detecting persistence generally relies on: maintaining an accurate baseline of what should be running and scheduled, monitoring changes to startup configuration and account lists, reviewing logs for the creation of new scheduled tasks or accounts, and verifying the integrity of critical system files and scripts against known-good copies. These are exactly the kind of controls a thorough report should recommend whenever a post-exploitation assessment suggests that persistence would have been possible.

Your fil rouge: a persistence risk statement for Lighthouse Labs

Based on the privilege level you obtained in your lab exercises for this chapter (Linux, Windows, or both), write a short, honest "persistence risk" paragraph for your Project Lighthouse notes: which category or categories from this lesson would, in principle, have been available to you at that privilege level, whether any logging seemed present to detect such a change (reason about this conceptually if you did not specifically test it), and an explicit statement that no persistence mechanism was actually deployed.

Your turn: spot what is missing

A junior tester's report includes the line: "Persistence was tested and worked successfully." Explain what is missing from this statement and rewrite it following the principles of this lesson.

See a solution

The original line is dangerously vague: it does not say which category of mechanism was used, whether it was actually deployed and left in place or only assessed as theoretically possible, whether any monitoring would have detected it, and crucially, whether it was properly removed afterwards if it was deployed at all. A much better version: "At the privilege level obtained, creating an additional scheduled task would, in principle, have been possible; no such task was actually created during this engagement. No monitoring was observed that would have alerted on this category of change, which is itself a notable finding. We recommend implementing monitoring for new or modified scheduled tasks." This version is specific, honest about what was and was not done, and immediately useful to the client's defenders.

Tip

If you ever find yourself about to write "I achieved persistence" in a report without an explicit note about whether anything was actually left running, stop and add that note. It is one of the most important sentences in that section.

Key takeaways

Persistence means arranging unauthorised access to survive reboots or credential changes, through legitimate system mechanisms used unexpectedly.
Common categories include scheduled tasks, startup configuration, extra accounts, and modified trusted programs.
A standard penetration test usually assesses whether persistence would have been possible, and whether it would be detected, without actually deploying it.
Defenders rely on accurate baselines and monitoring of exactly these categories to detect persistence.
Reports must explicitly state whether any persistence mechanism was actually deployed, to keep the engagement's boundaries unambiguous.

The last lesson of this chapter looks at lateral movement: how access can spread from one compromised machine to others across a network, tying together many themes from this chapter and the previous one.