In 05-01 we escalated privileges and we are now root/SYSTEM on one or more TechNova hosts. A real attacker, at this point, would want not to lose that access: if the machine reboots, if the password they exploited is changed, or if the entry flaw is patched, they want to be able to return without re-exploiting. This is called persistence or maintaining access. In an authorized pentest, persistence has a very different meaning from the attacker's: it serves to demonstrate impact —"with this foothold, an adversary could have re-attached here"— and to test whether TechNova detects it. It is not an end in itself, and it is certainly not about leaving doors open.

This lesson demands the strictest framing of the module, and we do not loosen it. The golden rule becomes the central axis here: the pentester documents every persistence mechanism they create —account, task, service, key, webshell— and REVERTS it when finished, handing the client the complete list of everything introduced. No hidden access is left behind. In fact, professional pentesters do not hide this activity: they leave an auditable trail precisely so the client can verify the cleanup. And that is why we teach each mechanism from the defensive perspective: what the attacker would do, why, and —in the foreground— how the blue team detects and prevents it. There are no recipes for rootkits or deep concealment; those are named only to explain what the defender should hunt for.

1. What "persistence" means in an authorized engagement
2. The golden rule: create, document, revert
3. Persistence mechanisms and their detection
4. A controlled example: authorized SSH key
5. The defensive perspective in the foreground
6. Rootkits and concealment: only what the defender must hunt
7. Common mistakes and tips (including ethical ones)
8. Exercises
9. Conclusion

For the attacker, persisting means surviving reboots, patches, and credential changes. For the TechNova pentester, persistence answers two questions in the report:

• Impact: could an adversary who reached this point re-attach in a stable way? Demonstrating it raises the severity of a finding from "one-off access" to "sustainable compromise".
• Detection: does TechNova's SOC notice when someone creates a new account, a scheduled task, or a service? That is often the most valuable finding—a gap in detection capability.

Persistence is never the ultimate goal of the authorized engagement. The goal is the report; persistence is one more piece of evidence that is captured and, immediately afterward, removed.

Every persistence artifact follows a closed, auditable cycle:

This is upheld by an artifact log: a table the pentester maintains in real time.

This table is part of the deliverable. If something cannot be reverted within the window, it is flagged and communicated explicitly to the technical contact so they can remove it. A pentester does not leave with any doubt about what they introduced.

The mechanisms an attacker would use —and which, therefore, the defender must know and hunt. The starring column is how it is detected and prevented:

The pattern repeats: almost all persistence creates or modifies something that a system with baselines, file integrity, and event alerts can detect. That is the lesson for TechNova.

We illustrate a single mechanism, low-impact and easily reversible, to see the full cycle. Adding our public key to an account's authorized_keys grants passwordless SSH access. We do it with an identifiable marker so we can revert and audit it.

The pentest-technova comment is deliberate: it makes the entry traceable and guarantees we revert exactly what we placed, without touching legitimate keys. Defensive counterpart (the star): protect authorized_keys with file integrity monitoring (alerting on any change), restrict its permissions, and prefer centralized key management; a change to that file outside an approved process should raise an alert in the SIEM.

If this lesson leaves a single message for TechNova, it is how to detect and prevent persistence—because it is exactly what a real attacker would attempt and what the SOC must hunt:

• Baselines: know the normal state —which accounts, services, tasks, and keys exist— so that any addition stands out. Without a baseline there is no detection.
• File integrity (FIM): watch sensitive files (authorized_keys, /etc/passwd, webroot, boot points) and alert on changes.
• Event alerts in the SIEM: account creation (4720), task creation (4698), service creation (7045), cron changes. Forwarded centrally (this ties in with 05-04).
• EDR: detects the behavioral patterns typical of persistence (processes that register for autostart, shells launched by web services).
• Least privilege and account review: fewer privileged accounts and periodic reviews reduce both the surface and the places to hide.
• Credential hygiene: rotate keys after an incident and do not rely on a password change alone—an SSH key or a persistent task ignores it.

An advanced attacker would try to hide their persistence with rootkits (which conceal processes, files, or connections) or deep concealment techniques. We do not teach them as a recipe here, and TechNova's professional pentester does not use them to hide from the client: on the contrary, they leave everything traceable. We name them only so the defender knows what exists and what to look for:

• What they are: software that manipulates the operating system so its artifacts do not appear in the usual tools (ps, ls, service listings).
• Why they matter to the defender: this is why detection cannot rely solely on the compromised host itself—a rootkit lies to the system it runs on.
• How they are hunted (the relevant part): integrity verification from outside the host (clean boot, image comparison), centralized telemetry that the host cannot alter (logs already forwarded to the SIEM), network anomaly detection, and rootkit-checking tools. Robust defense assumes that the compromised host is not a trustworthy source and relies on external evidence.

This is the correct approach: know the threat in order to defend against it, not to run it against the client.

• [Ethical] Leaving an artifact unreverted. This is the module's gravest mistake: a forgotten account, task, or webshell is a real backdoor that can end up in the hands of an actual attacker. Revert everything and hand over the complete list. The log exists so that none slip past you.
• [Ethical] Persisting without the RoE covering it. Testing persistence may require explicit agreement; installing it "just because" exceeds the mandate. Confirm scope first.
• [Ethical] Hiding your activity from the client. The professional pentester leaves an auditable trail; they do not evade the SOC "to win," but to measure its detection if that was agreed. Hiding from the client betrays the engagement.
• Using artifacts without an identifiable marker. Without a recognizable comment or name (pentest-technova), you cannot guarantee you reverted exactly your own. Always mark what you create.
• Reporting persistence without the counterpart. Each mechanism comes with its detection/prevention (baseline, FIM, alerts). The value for TechNova is in learning to hunt it.
• Confusing persistence with lateral movement. Maintaining access on this host is 05-02; using it to jump to other hosts is 05-03. Do not mix them.
• Tip: treat every artifact as a loan, not a possession. You create it, show it, document it, and give it back. If you doubt whether you can revert something, do not create it.

Exercise 1. You are going to demonstrate persistence on a TechNova Linux host (10.10.10.15) by adding an authorized SSH key, within an RoE that covers it. Write the full cycle —create, document, capture evidence, revert— with particular care in how you guarantee that you reverted exactly your artifact. Add the defensive counterpart TechNova should implement.

Exercise 2. TechNova's SOC asks which events it should watch to detect the three most common persistence mechanisms on Windows (new account, scheduled task, new service). List them and explain what role having a baseline plays in making these alerts useful.

Exercise 3. A junior colleague proposes installing a rootkit "so the SOC doesn't detect the persistence and the exercise is more realistic." Explain why this is an ethical and methodological mistake in an authorized pentest, and reframe the objective correctly.

Solution 1. Full cycle: (1) Create with an identifiable marker: echo "ssh-ed25519 AAAA... pentest-technova" >> ~/.ssh/authorized_keys. (2) Document in the engagement log: host 10.10.10.15, account, file ~/.ssh/authorized_keys, comment pentest-technova, date and time. (3) Capture evidence: demonstrate SSH re-access a single time (screenshot with time) and stop. (4) Revert exactly what was added using the comment as an anchor: sed -i '/pentest-technova/d' ~/.ssh/authorized_keys and verify with grep -c pentest-technova ~/.ssh/authorized_keys that it returns 0. The marker guarantees that only the pentester's key is removed, without touching legitimate keys. Counterpart: file integrity monitoring on authorized_keys with an alert on any change, restrictive permissions, and centralized key management; the change would have shown up as an alert in the SIEM.

Solution 2. Windows events: 4720 (creation of a user account), 4698 (creation of a scheduled task), and 7045 (installation of a new service). Forwarded to a central SIEM so the compromised host cannot hide them (this ties in with 05-04). The baseline is indispensable because these alerts on their own generate a lot of noise in a large environment: only by knowing which accounts, tasks, and services are normal and expected can the SOC distinguish a malicious addition from legitimate administrative activity. Without a baseline, the 4720 alert is lost among routine creations; with a baseline, an unexpected new account jumps out immediately.

Solution 3. It is an ethical mistake because the professional pentester does not hide their activity from the client: they keep an auditable trail of everything they do, and a rootkit runs directly against that, besides introducing software that is hard to fully revert (risk of leaving a real persistent artifact). It is a methodological mistake because the goal of the engagement is not "to beat the SOC by hiding," but to measure and improve TechNova's detection. Correct reframing: if the RoE covers testing detection capability, traceable and documented persistence artifacts are created (with an identifiable marker), whether the SOC detects them is observed, and the finding —detected or not— goes into the report with its counterpart; when finished, everything is reverted and the list is handed to the client. The rootkit threat is documented as something the defender must be able to hunt (external telemetry, integrity from outside the host), not as something the pentester runs.

We have treated maintaining access as it should be in a professional pentest: a demonstration of impact and a test of TechNova's detection capability, not an end nor a backdoor. We saw the mechanisms an attacker would use —accounts, tasks/cron, services, SSH keys, webshells— always with their defensive counterpart in the foreground (baselines, file integrity, event alerts in the SIEM, EDR), and we illustrated the full cycle with a marked and reverted SSH key. Rootkits and concealment appeared only as a threat the defender must know and hunt with external telemetry, never as a recipe.

Above the technique stands the golden rule: every artifact is created by agreement, documented in the engagement log, captured as evidence, and reverted, handing the client the complete list. The pentester leaves no hidden access nor hides their activity. With access escalated (05-01) and its persistence understood and controlled (05-02), the compromise on this host is measured. The next question is how far it reaches across the network: how to use this host as a springboard toward internal segments that were not directly reachable. That is 05-03 Pivoting and Lateral Movement.