Persistence: what I'd look for after an attacker gets in

Persistence is interesting from both sides of security. An attacker wants access that survives a reboot, a logout, or an interrupted session. A defender wants to find the mechanism and remove the access that made it possible.

My focus here is the defender's investigation: what evidence I'd need and where I'd look for it. I haven't written this up from a real incident or engagement.

Find the mechanism, then find the context

Scheduled tasks, services, startup entries, and account changes can all be relevant. They also show up in normal administration, so a name that looks odd isn't enough on its own.

I'd want the creation time, the creating identity, the command or target, the permissions, and any related process activity. Does the task point to a user-writable location, and did it appear near the initial compromise? Is its owner consistent with how that software normally gets installed?

Before I change a registry entry or a scheduled task, I'd preserve the exact registry path and value, or the task definition and its execution history if that's available. That gives the investigation something more reliable than a screenshot of a suspicious name.

Look beyond the first host

Access can also persist through identities and connected applications. A new privileged account, an added authentication method, a service credential, or an unexpected application grant can outlive a cleanup on one endpoint.

I'd follow the identities involved and check the relevant authentication and administrative logs. Removing one file doesn't mean the access is gone.

Use a reference without turning it into a checklist

MITRE ATT&CK's persistence tactic organizes many mechanisms and how they relate to each other. I'd use it to widen an investigation from the evidence I already have. It doesn't mean every technique on the list happened.

The useful output is a supported timeline: how the mechanism appeared, what it could do, whether it executed, and what other access is linked to it. Where logs are missing, that gap should stay visible.

Verify the cleanup

I'd check that the mechanism is removed or disabled, that the credentials and sessions involved have been dealt with, and that the original access path has been fixed. Then I'd look for recurrence under the conditions that triggered it before.

To learn this, a disposable VM is enough to study a benign startup task and the logs it produces. Document the baseline, make one controlled change, capture the evidence, and remove it. Memorizing the command is the easy part. The exercise did its job if I can explain the artifacts and the cleanup afterward.