What Is Persistence in Cybersecurity?

An incident response team works through the night and thinks it has won. They found the malware, wiped the infected host, reset the compromised passwords, and closed the entry point. The next morning, the attacker is back, on a different machine, with fresh access. The cleanup missed one thing: weeks earlier, the intruder had created a scheduled task that quietly runs every few hours, reaching out to download their tooling again. The front door was locked, but a window was left open on purpose. That window is persistence.

Persistence is the set of techniques attackers use to keep their access to a compromised environment across reboots, credential changes, and cleanup efforts. It is the difference between an intrusion you can evict in an afternoon and one that keeps coming back, and it is the reason "we removed the malware" is not the same as "we removed the attacker."

This guide covers what persistence is, why it matters so much to defenders, how it works, the common techniques mapped to MITRE ATT&CK, where it hides beyond the endpoint, and how to detect and remove it. It is written for blue teamers who have to make sure an evicted attacker stays evicted.

What is persistence?

Persistence is how an attacker maintains a foothold in a system or network so that their access survives interruptions, a reboot, a logged-off session, a password reset, even the removal of their original malware. MITRE ATT&CK catalogs it as a dedicated tactic, Persistence (TA0003), defined as the techniques adversaries use to keep access across restarts, changed credentials, and other interruptions.

It sits just after initial access and execution in an intrusion. An attacker who has broken in but established no way back is fragile: a reboot or a password change can lock them out and force them to start over. So one of their first moves, once inside, is to plant a way back in that does not depend on the original method. Persistence is the attacker buying insurance on their access.

The mechanism is almost always the same idea: arrange for attacker-controlled code or credentials to be re-activated automatically on some event the system performs anyway, a boot, a logon, a scheduled time, an incoming web request. The system does the work of restoring the attacker's access, which is what makes good tradecraft both reliable and quiet.

Why persistence matters

Persistence is the technique that decides whether an incident is truly over, and it is where many response efforts quietly fail.

Eviction is incomplete without it. You can remove the malware and reset the credentials, but if one of these mechanisms remains, the attacker simply returns, often within hours, as in the opener. Finding and removing every such mechanism is the part of incident response that determines whether the eviction holds.

It enables long dwell time. It is what lets an attacker stay in an environment for weeks or months. Mandiant's M-Trends 2026 report puts the global median dwell time at 14 days, and the long-tail intrusions that run for months, espionage in particular, are sustained entirely by robust, redundant footholds.

Sophisticated attackers plant several. A capable adversary does not rely on one mechanism. They establish multiple, redundant methods in different places, so that removing the obvious one still leaves a quiet backup. This is why thorough hunting matters: finding one mechanism is a reason to keep looking, not to declare victory.

The SolarWinds intrusion is the textbook case. After the initial compromise, the actor did not rely on the on-host backdoor alone; they moved into the identity layer, forging SAML authentication tokens that let them return as trusted users even after the malware was discovered and removed. It is the clearest illustration of why eviction is so hard: the access had been re-rooted somewhere the cleanup was not looking.

How persistence works

Establishing it follows a consistent pattern.

1. Gain access and often privilege. The attacker needs a foothold, and many of these techniques require administrator rights to install a service or a system-wide trigger.
2. Choose a trigger. They pick an event the system performs routinely, system boot, user logon, a scheduled time, a network request, that can be made to launch their code.
3. Plant the mechanism. They register their payload against that trigger: a registry key, a scheduled task, a service, a WMI subscription.
4. Blend in. Good tradecraft disguises it as something legitimate, named like a real service or task, so it survives casual inspection.

The defining trait, as with much of post-exploitation, is the abuse of legitimate functionality. Scheduled tasks, services, and startup programs are normal, necessary operating-system features. The attacker is not breaking the system; they are using its own automation against it.

There is a silver lining for defenders in this design. Because persistence has to hook into a known, finite set of system features, the list of places to check is bounded. Unlike hunting for a novel exploit, hunting for a foothold is a tractable problem: enumerate the autostart points, compare them to normal, and the malicious entry has to be in there somewhere. The attacker's need for reliability is also the defender's best lead.

Common persistence techniques

Most persistence on Windows uses a handful of well-known mechanisms. Each maps to a MITRE ATT&CK technique, which is how defenders organize detection.

Registry run keys and the startup folder are the classic, and still the most common, persistence method: anything listed there runs automatically when a user logs in. Scheduled tasks are a favorite because they can trigger on time or on events and look entirely routine. Malicious services start with the system and run with high privilege. WMI event subscriptions are stealthier, a fileless trigger that runs code when a condition is met, and are harder to spot without specifically looking. Web shells persist on internet-facing servers, giving an attacker a way back in that does not touch a workstation at all. And the quietest of all is simply valid accounts: if the attacker has working credentials or has created an account, they may not need malware to persist, they just log in.

Persistence beyond the endpoint

Persistence is not only a workstation problem. As environments move to identity and cloud, so does the foothold.

In identity systems, an attacker who reached the domain can forge Kerberos "golden tickets" or create rogue accounts and trust relationships that grant access independent of any one password, which is part of why credential dumping at the domain level is so serious. In the cloud, persistence looks like rogue API keys, added OAuth application grants, new identity federation, or backdoor IAM roles, none of which involve a file on a host. The principle is unchanged, leave an automatic way back in, but the place to look shifts from the registry to the identity provider and the cloud control plane.

A concrete cloud example: an attacker who compromises a cloud administrator can quietly add their own access key to a service account, or grant a consented OAuth application broad mailbox access. Neither drops a file, neither triggers endpoint tooling, and both survive the victim resetting their own password. Hunting these means reviewing the identity provider's audit log and the cloud control plane, not the registry, a different muscle than host-based hunting. A complete hunt now has to cover all three: endpoint, identity, and cloud.

How to detect persistence

Because persistence abuses legitimate features, detection means watching the specific places it lives and knowing what normal looks like there.

• Audit autostart locations. Monitor changes to registry run and RunOnce keys, the startup folder, scheduled tasks, and services. Tools that enumerate every autostart point (such as Autoruns) against a known baseline surface what was added.
• Watch the right event logs. Service creation (Windows Event IDs 7045 and 4697), account creation (4720), and privileged group changes (4728, 4732) are high-value signals. Centralize them in a SIEM for correlation.
• Look for WMI subscriptions. WMI event subscription persistence is stealthy but logged; monitoring for new subscriptions catches a technique many tools miss.
• Use endpoint telemetry. EDR records the process and registry activity that establishing it generates, mapped to the ATT&CK techniques above.
• Hunt proactively. It is a high-yield target for threat hunting: the list of legitimate autostart entries is finite and reviewable, so hunting for the one that does not belong is tractable and effective.

A concrete pass looks like this: pull every scheduled task, service, run-key entry, and WMI subscription from a suspect host, diff them against a clean baseline image, and investigate anything new. A scheduled task that launches PowerShell from a temp directory, a service whose binary lives in a user profile, or a run key pointing at a randomly named executable are entries that do not appear on a clean build. The anomaly is usually obvious once the baseline is in hand.

The unifying idea is baselining. The set of things that should auto-run on a system is knowable, so the anomaly, the scheduled task no one created, the service with a random name, is findable for an analyst who knows what belongs.

How to remove and prevent persistence

Removing it is the make-or-break step of eviction, and preventing it limits where an attacker can hide.

• Hunt for all of it before eviction. Because attackers plant redundant mechanisms, enumerate every autostart location and identity backdoor before you act, then remove them together. Pulling one and leaving another just tips off the attacker.
• Enforce least privilege. Most persistence needs administrator rights to install. Limiting who has them, and where, shrinks where it can be planted.
• Restrict and monitor the mechanisms. Control who can create services and scheduled tasks, lock down web-server upload paths to limit web shells, and alert on changes to autostart locations.
• Maintain credential and account hygiene. Review accounts and privileged group membership regularly so a rogue account or an unexpected admin stands out, and rotate the credentials that domain-level persistence depends on.

Layered, these turn persistence from a reliable backstop into something an attacker struggles to establish without being seen.

Getting started with detecting persistence

If you are building the skill, learn where persistence lives and practice finding it.

1. Learn the autostart locations. Know the registry run keys, the startup folder, scheduled tasks, services, and WMI subscriptions, the places attackers plant triggers.
2. Map techniques to ATT&CK. Work through the Persistence tactic so each mechanism and its detection are familiar.
3. Plant and find it in a lab. Establish persistence in a safe environment and then detect it from the logs and autostart entries it created.
4. Investigate a real intrusion. Trace how an attacker persisted and what it took to fully remove them.

The bottom line

Persistence is how an attacker turns a temporary foothold into durable access, by planting a trigger, a registry key, a scheduled task, a service, a web shell, a rogue account, that the system itself re-activates on a reboot, a logon, or a request. It is the reason eviction is hard: removing the malware is not removing the attacker if the way back in remains.

For a defender, the work is knowing where persistence lives and what belongs there, so the one entry that does not belong stands out, and hunting for all of it before evicting, because attackers plant more than one. The constant is the analyst who can tell the legitimate scheduled task from the malicious one.