Cleaning up: restoring everything you changed

Objective 5.1 in this course covers post-exploitation activities — establishing persistence, performing lateral movement, and cleaning up artifacts. This is that last one, and lessons 24, 36, 37 and 38 have each pointed forward to it.

Why this matters

CompTIA lists cleanup as a named post-exploitation activity, which tells you it is examinable and that it is considered part of the job rather than an afterthought. It is also the activity where the difference between a professional and a liability is starkest: an engagement that leaves access mechanisms, weakened configurations or planted files behind has made the client less secure than before it started.

Framed carelessly, "cleaning up artifacts" sounds like anti-forensics. It is the opposite, and getting that framing right is most of the lesson.

The lesson

The cleanup list you started on day one, not at the end

The single most important point, and it is a practice rather than a technique.

The cleanup list is written as you work, not reconstructed at the end. Every lesson in Domains 4 and 5 has said this: record each change at the moment you make it — the exploit's artefacts (lesson 24), each persistence mechanism (lesson 36), each credential and route (lessons 37, 38).

Why the end is too late:

• You will not remember. A multi-day engagement makes dozens of changes across many hosts, and the one you forget is the one you leave behind.
• Some changes act on their own. A scheduled task fires whether or not you remembered creating it, so an unrecorded one persists indefinitely.
• The list is also evidence of what you did, which the client may need and which feeds the attack narrative.

The habit from lesson 24 — the cleanup list open in a second window, added to at the moment of each change — is what makes this lesson's work reliable rather than hopeful. If the list is complete, cleanup is mechanical; if it is not, cleanup is guesswork.

Removing persistence, accounts, tools and payloads

Working through the list, the categories to account for:

• Persistence mechanisms (lesson 36) — every scheduled task, service, startup entry, account, key, group change and application grant. These are the most important to remove completely, because a missed one is standing access.
• Accounts and credentials you created — test accounts, scan accounts (lesson 16), keys added for access.
• Tools and payloads placed on hosts — uploaded binaries, scripts, web shells, exploit artefacts, the pivot configurations from lesson 38.
• Files written — output, captures, downloaded data, anything staged.

For each, removal is verified rather than assumed: confirm the mechanism is gone, the account is deleted, the file is removed — the same discipline as verifying a restore in this repository's own tooling, where a delete that did not happen is worse than one that failed loudly.

Restoring configuration you altered, and proving it

Changes that are not additions but modifications are the ones most often missed, because there is nothing new to delete — there is an original state to restore.

• Configuration you weakened to enable an attack — a permission you loosened, a setting you changed, a service you reconfigured (lesson 28). These must go back exactly, and this is where a snapshot of the original setting, taken when you changed it, is worth the seconds it cost.
• Anything you disabled — a protection turned off to demonstrate a flaw — is turned back on.
• State you modified in an application or database while proving a finding.

Proving restoration matters because a half-restored configuration can be worse than the original: a permission loosened and then "mostly" tightened may leave a gap that did not exist before. So restoration is verified against the recorded original, and where you cannot verify it, you say so to the client rather than assume it.

What you must NOT remove: the client's own logs of your activity

The line that separates cleanup from anti-forensics, and the one the exam is most likely to test.

You remove what you added and restore what you changed. You do not touch the client's records of your activity.

• Do not delete or alter logs. The client's logs of what you did are theirs, they are often needed for their own compliance, and removing them is anti-forensics — the thing a real attacker does, and the thing that would make your engagement indistinguishable from an intrusion.
• Do not clean up to hide, ever. Cleanup restores the system; it does not conceal that testing happened. The client knows a test happened — you are reconciling your activity with their logs (lesson 8), not erasing it.
• The distinction in one line: removing your changes to their system is cleanup; removing their records of your changes is a cover-up. The first is required; the second is forbidden.

If an engagement genuinely requires testing whether log-tampering is possible, that is a specific, scoped objective agreed in writing — and even then you demonstrate the capability without destroying the actual records.

Why this is an obligation to the client and not anti-forensics

The framing that ties the lesson together, and the client message.

Cleanup exists because the engagement must leave the client exactly as secure as it found them, plus a report — never less secure. Every artefact left behind is a way the assessment harmed the thing it was meant to protect:

• A persistence mechanism left behind is standing access for whoever finds it.
• A weakened configuration left behind is a vulnerability you introduced.
• A tool left on a host is attacker infrastructure you donated.

So cleanup is not tidiness and it is not hiding; it is the final safety obligation of the engagement, symmetrical with the authorisation that opened it. And it connects directly to lesson 40: the attack narrative describes what you did, the cleanup list confirms you undid it, and a report that documents both is what tells the client the assessment was safe as well as thorough.

The re-test angle: the cleanup list also becomes part of what you hand over, so the client can confirm independently that nothing remains — which is the trust that gets you rehired.

What to take into the exam

• Cleanup is a named post-exploitation activity: leaving a client less secure than you found them is a failure of the engagement.
• The cleanup list is written as you work, not reconstructed at the end, because memory fails and some changes act on their own.
• Remove what you added (persistence, accounts, tools, files) and restore what you changed (configuration, disabled protections), verifying each.
• Never touch the client's logs of your activity — that is anti-forensics and a cover-up; removing your changes is cleanup, removing their records is forbidden.