Malware Persistence Techniques: How Malware Survives Reboot

Getting onto a machine is only useful if you stay on it. A reboot, a logoff, or a crashed process would otherwise end the intrusion, so almost every piece of malware that intends to last plants a way to relaunch itself. That mechanism is persistence, and it is one of the most productive things a defender can hunt for, because it is where a quiet compromise leaves a durable mark.

Persistence rarely uses anything exotic. It hooks into the ordinary startup machinery that Windows uses to launch your applications, run your scheduled maintenance, and start your services. The malware is hiding among the legitimate autostart entries, which is exactly why baselining what should be there is the whole game.

What persistence is, and why it matters

Persistence is any technique that ensures malicious code runs again after the event that would normally stop it: a reboot, a user logging off and back on, or the process simply exiting. The attacker registers their payload with something the system executes automatically, whether at boot, at logon, on a schedule, or when a trigger fires.

For defenders, persistence is valuable precisely because it is durable. The initial delivery is a fleeting event that may be long gone from logs. The persistence entry, though, usually sits on the machine until someone removes it. Finding it is often how a compromise that began weeks earlier finally surfaces.

The common mechanisms

Most persistence on Windows falls into a handful of families. Each is a legitimate feature being used for an illegitimate purpose.

The run key and the startup folder are the simplest and run in the user's context. Scheduled tasks and services are favoured for reliability and for the ability to run with higher privilege or at boot before a user logs in. The lower rows are quieter and harder to spot, which is why attackers reach for them when they expect to be hunted.

Registry run keys and the startup folder

The classic persistence is a value under a run key that names an executable to launch at logon. It is trivial to set, works without admin rights in the user hive, and survives reboot. The startup folder is the same idea expressed as files: a shortcut or script placed there runs when the user logs in.

Both are heavily used and heavily monitored, so commodity malware relies on them while more careful actors avoid them. For a defender they are also the easiest win, because the legitimate contents of these locations change slowly and a new entry stands out.

Scheduled tasks and services

Scheduled tasks are a favourite because they are flexible and normal. A task can run at boot, at logon, at a set time, on idle, or on an event, which lets malware relaunch itself on almost any trigger. Because administrators create tasks constantly, a malicious one blends in unless you are watching who created it and what it runs.

Services persist even more strongly. A service configured to start at boot launches before any user logs in and can run with high privilege. Installing a service is a privileged action that Windows records, which is both why attackers value it and why it is catchable if you collect the right log. These map to Scheduled Task/Job (T1053) and Create or Modify System Process (T1543).

The quieter corners

Beyond the workhorses, Windows offers many less-travelled autostart points: Winlogon helper keys, image-file-execution-options debuggers, COM hijacking, WMI event subscriptions, and more. These are catalogued under Boot or Logon Autostart Execution (T1547) and related techniques. They are quieter because most tools do not watch them and most admins never touch them. That same obscurity is a detection opportunity: a change to a location that legitimately almost never changes is a strong signal on its own.

Whatever the mechanism, the persistence entry ultimately points at a file, and that file is usually one of a small set of abused formats: a script, a shortcut, a DLL, an executable in a user-writable path. Our File-Format Abuse Atlas covers what those payload files look like and how to recognise them, which pairs directly with finding the entry that launches them.

How to detect and defend

Persistence is one of the most huntable phases, because the artefacts sit still and the legitimate baseline changes slowly. A practical approach:

1. Baseline the autostart surface. Enumerate run keys, startup folders, scheduled tasks, and services on known-good systems. Tools that list every autostart entry give you the full picture. Anything new against that baseline is a lead.
2. Alert on creation, not on presence alone. The moment a service is installed or a scheduled task is created is a discrete, loggable event. Watching creation catches persistence as it is planted, before the next reboot even uses it.
3. Collect the right event logs. Windows records service installation, scheduled-task creation, and many registry changes. Enable and centralise these, along with process-creation logging, so persistence events are searchable across the fleet.
4. Correlate the creator. The most useful question about a new autostart entry is what created it. A scheduled task created by a script host that spawned from a document is a very different story from one created by your patch-management tool. Tie the persistence event back to its parent process chain.
5. Judge the target path. A run key, task, or service pointing at a payload in a temp folder, a user profile, or another user-writable location is far more suspicious than one pointing at a signed binary in a normal install path.
6. Watch the quiet corners. Extend hunting beyond run keys to Winlogon helpers, COM references, and WMI subscriptions. Their legitimate change rate is near zero, so any change is worth reviewing.
7. Constrain who can persist. Least privilege limits which accounts can install services or create system-level tasks. Application control stops unapproved payloads from being what an autostart entry launches in the first place.

A persistence hunt, walked through

To see how these pieces fit, trace how a single suspicious autostart entry unfolds into a full picture of an intrusion. Suppose your baseline comparison flags a new scheduled task on a workstation that was not present last week.

The first question is what the task runs. Say it launches a script interpreter with a path to a file in the user's profile directory. That is already two signals stacked: a script host rather than a signed application, and a payload living in a user-writable location instead of a normal install path. Neither is proof, and both are worth explaining.

The second question is what created the task. Scheduled-task creation is a discrete, logged event that records the account and often the process responsible. If the creating process was a document viewer or an email client spawning a script host, you are looking at a likely delivery chain: a user opened something, it spawned a script, and that script planted the task. If instead the creator was your endpoint-management agent, the entry is probably benign and the file path is explained by a legitimate deployment.

The third question is what else happened in that window. The creation timestamp anchors a search. Around that moment you would expect to see the process that dropped the file, any network connections it made, and possibly other persistence planted at the same time, since attackers often install more than one mechanism for redundancy. Following the parent process chain backward frequently reaches the initial access event, which is how a compromise that began weeks earlier finally gets dated.

The fourth question is what the payload does when it runs. The file the task points at is often the live payload or a loader for it. Pulling that file for analysis, rather than deleting the task and moving on, is what turns a single detection into an understanding of the whole intrusion. Deleting the entry alone removes one relaunch mechanism and leaves any others, plus the initial foothold, in place.

That sequence, from entry to creator to timeline to payload, is the core loop of persistence hunting, and it works precisely because the autostart entry sits still while everything around the initial break-in has already scrolled out of the logs.

Persistence on other systems

Windows dominates persistence discussion because of its rich autostart surface, and the same logic carries to other systems even though the mechanisms differ.

On Linux and Unix-like systems, the workhorses are service manager units, cron and its per-user variants, shell profile and startup scripts, and entries that run at login or at boot. A malicious service unit that starts at boot is the direct analogue of a Windows service, and a cron entry mirrors a scheduled task. The hunting approach is identical: baseline the units, cron entries, and startup scripts that should exist, alert when a new one appears, and judge it by what created it, where its target lives, and whether it is signed or expected.

On macOS, launch agents and launch daemons play the role of autostart entries, alongside login items and configuration profiles. Again the pattern holds. A new launch agent pointing at a binary in a user-writable directory, created by an unexpected process, is the same shape of finding as a suspicious Windows run key.

The portable lesson is that every general-purpose operating system offers a set of places code can register to run automatically, those places change slowly under normal use, and that slow change rate is what makes new entries a reliable hunting signal regardless of platform. These autostart families across platforms are grouped under Boot or Logon Autostart Execution (T1547) and the service and scheduled-job techniques alongside it. Container and cloud workloads add their own variants, such as init scripts baked into an image or a scheduled job defined in an orchestration platform, and the same baseline-and-alert discipline applies to them as well.

Detection signals

Beyond the general hunting loop, specific indicators separate suspicious persistence from routine administration. Concrete signals worth building detections around:

• An autostart entry created by a process spawned from a document or email client. A script host or shell that traces its parentage back to an office application or mail reader, then writes a run key, task, or service, is a strong delivery-to-persistence chain.
• A target path in a user-writable or temporary location. Run keys, tasks, and services that point at a payload in a temp folder, a user profile, or a public directory are far more suspicious than those pointing at signed binaries in standard install paths.
• An unsigned target file written shortly before the entry appeared. Persistence pointing at a binary or script created minutes earlier and lacking a valid signature is a common commodity-malware pattern.
• Changes to autostart locations that legitimately almost never change. Winlogon helper keys, image-file-execution-options debugger values, COM references, and WMI event subscriptions have a near-zero baseline change rate, so any modification is worth reviewing on its own.
• A service or task installed outside a maintenance or deployment window. Legitimate service and task creation usually clusters around patching and software rollout. One appearing at an odd hour on a single host stands out against that rhythm.
• Duplicate or redundant persistence appearing together. Several new autostart entries created in the same short window, pointing at the same or related payloads, suggest an attacker installing redundancy rather than a single benign install.

How persistence compares to nearby techniques

Persistence is sometimes conflated with the phases around it. Separating them clarifies what you are hunting.

Persistence and privilege escalation overlap because some mechanisms do both. Installing a service persists the payload and can run it with high privilege at boot, so the same action lands in two phases. Persistence and execution are distinct: execution is running now, persistence is arranging to run again later. Keeping these separate matters for hunting, because the loggable event you key on differs. Execution shows up as a process launch, persistence shows up as the creation of an autostart entry, and the richest detections tie the two together, catching the moment a suspicious process creates a durable relaunch mechanism.

Common misconceptions

A few beliefs lead teams to hunt persistence badly or not at all.

• "Antivirus will catch anything that autostarts." Signature and reputation engines catch known-bad payloads. Persistence often points at a novel loader, a living-off-the-land binary, or a script that is not inherently malicious, so the entry itself is the more reliable signal than the file being flagged.
• "Deleting the run key removes the malware." Removing one autostart entry stops one relaunch path. Careful actors plant redundant persistence, and the initial payload and foothold remain. Remediation means finding the payload and the delivery chain, then the entry as the last step.
• "Only admin-level persistence matters." User-context run keys and startup-folder items need no special privilege and survive reboot perfectly well. Commodity malware relies on them precisely because they are easy and effective without escalation.
• "Fileless means there is nothing to find." Techniques such as WMI event subscriptions or registry-stored payloads avoid a conventional file on disk, but they still register somewhere the system reads at a trigger. That registration is the artefact, and it lives in exactly the slow-changing locations worth baselining.
• "If it has been quiet, there is no persistence." A dormant implant can sit idle for long periods and relaunch on a schedule or an event without generating obvious activity. Absence of noise is not evidence of a clean autostart surface. The baseline comparison is what confirms it.

Frequently asked questions

What is the difference between persistence and execution? Execution is running code once, right now, such as a script launching from an opened document. Persistence is arranging for code to run again after the event that would normally stop it, such as a reboot or logoff, by registering the payload with something the system starts automatically. They are separate ATT&CK phases and they produce different loggable events, a process launch versus the creation of an autostart entry.

Which persistence mechanisms are most common? Registry run keys, startup-folder items, scheduled tasks, and Windows services are the workhorses because they are reliable, well-documented, and blend into normal administration. Run keys and startup items work in the user context without special privilege, while services and boot-triggered tasks are favoured when the attacker wants higher privilege or execution before a user logs in.

How do I detect persistence I do not already have a signature for? Baseline the autostart surface on known-good systems, then alert on anything new against that baseline. Judge each new entry by what created it, where its target points, and whether the target is signed and recently written. This catches novel payloads because it keys on the act of registering to autostart rather than on recognising the specific file.

Does persistence require administrator privileges? No. Run keys in the user hive and items in the user's startup folder need no elevation and survive reboot. Some mechanisms, such as installing a service or a system-level scheduled task, do require higher privilege and in exchange offer boot-time execution and elevated rights. Both privileged and unprivileged persistence are common.

What logs do I need before I can hunt persistence effectively? At a minimum, process-creation logging, service-installation events, scheduled-task creation events, and relevant registry-change auditing, all centralised so they are searchable across the fleet. Without these, the discrete moment a persistence entry is planted is invisible, and you are left comparing static state instead of catching creation as it happens.

Why follow an autostart entry back instead of just deleting it? Because the entry is one visible end of an intrusion. The file it points at is often the live payload, the process that created it points toward how the machine was compromised, and its timestamp anchors a search for redundant persistence and the initial foothold. Deleting the entry alone removes one relaunch path and leaves the rest of the intrusion intact.

Does this apply beyond Windows? Yes. Linux uses service manager units, cron, and login and boot scripts. macOS uses launch agents, launch daemons, and login items. The mechanisms differ, but every general-purpose system offers a slow-changing set of places code can register to run automatically, and that slow change rate makes new entries a reliable hunting signal on any platform.

Persistence is where a transient intrusion becomes a resident one, and that is exactly what makes it findable. The malware has to leave something behind that the system will faithfully execute, and that something sits among a small, slow-changing set of startup locations. Know what belongs there, watch what gets created, and follow every new entry back to what made it. The mechanism that keeps the attacker alive is the same one that gives them away.

Related guides

• Windows Event IDs for Security
• What Is a Rootkit
• Threat Hunting Guide
• Living Off the Land Explained