Persistence on the Host: Where Attackers Hide

What is it?

Persistence is any mechanism that re-runs an attacker's code automatically — after a reboot, a logon, or on a schedule. On Windows the common surfaces are scheduled tasks, run keys in the registry, services, WMI event subscriptions and startup folders.

Why it matters

Initial access is fragile — a reboot or a killed process ends it. Persistence is how an intrusion becomes durable. Finding and removing the persistence is what actually evicts the attacker; miss it and they return after every clean-up. Each surface also has a benign twin, so triage — not just discovery — is the skill.

Where you see it

Persistence artefacts appear in creation events — scheduled-task creation (Event 4698), service installation (Event 7045), registry run-key writes, WMI subscription creation — and in autoruns enumerations that list everything set to start automatically.

What normal looks like

Legitimate persistence is everywhere: software installs services and run keys, management tools create scheduled tasks, agents register WMI subscriptions. Created by an admin or service account, from a protected path, matching a known product — that is normal and abundant.

What suspicious looks like

Suspicious persistence is created by a non-privileged account, from a user-writable path, with no matching known product, and often runs a script or a binary from a public folder. The mechanism is ordinary; the creator, the path and the payload are what mark it.

How analysts investigate

Enumerate what starts automatically, then triage each entry against the benign twin: who created it (admin or not?), from where (protected or user-writable?), does it match a known product, and what does it actually run? A single failing answer turns a normal-looking task into a lead.

Common beginner mistakes

Treating the mere existence of a scheduled task or service as malicious — most are legitimate.
Checking only one persistence surface and declaring the host clean, when the attacker used another.
Removing the persistence without capturing what it ran, destroying the lead to the rest of the intrusion.

What you will be able to do

Name the common Windows persistence surfaces and where each is recorded.
Triage a persistence entry against its benign twin on four facts.
Decide whether an autoruns entry is a finding or normal software.

You evicted the attacker's running process — and after the next reboot it is back. That is persistence at work. The Tier-2 job is to find every mechanism set to re-run their code and triage it, because removing the process without the persistence changes nothing.

Persistence surface	Recorded in	Runs when
Scheduled task	Event 4698	A time or trigger (e.g. logon)
Run key (registry)	Registry write	User logon
Service	Event 7045	Boot / on demand
WMI subscription	WMI-Activity	A system event fires

Worked example — task or threat?

Event 4698 · scheduled-task creations

creator=svc_deploy  admin=yes  path=C:\Program Files\...  product=known
creator=a.nassar    admin=no   path=C:\Users\Public\run.job  product=none

Two new scheduled tasks. Before reading on, decide: which one is the finding, and on which fact?

The answer: the second, and the deciding facts are all three of non-admin creator, a user-writable public path, and no matching product. The first task is created by a deployment account, from a protected Program Files path, and maps to a known product — the benign twin, and normal. The mechanism (a scheduled task) is identical in both; triage is entirely in who, where and what.

Recap

Persistence is what makes an intrusion survive a reboot; remove it, not just the process.
Every surface has a benign twin — triage on creator, path, product and payload.
Check every surface; attackers plant redundant persistence.