Detect it by monitoring the common autorun registry locations for new or changed values that launch executables, scripts, or command shells at logon or startup. Compare entries against a known-good baseline, then inspect the referenced files, paths, and signer information. Prioritise changes made by standard users, especially when the target points to writable directories or temporary locations.
What registry autorun persistence looks like on a Windows host
Registry autorun persistence is the use of startup-related registry entries to launch code when a user logs on or the system starts. The technique is common because it survives reboots, blends into normal system behaviour, and can be hidden among legitimate software entries. Detection starts by understanding which keys are meant to launch software and which entries are unusual for the host.
On Windows, the practical question is not just whether an autorun key exists, but whether the value is consistent with the workstation or server’s approved software set. A legitimate updater, security tool, or user shell extension can create noisy but expected entries, while persistence usually stands out through new values, uncommon executables, odd command-line arguments, or references to locations that should not normally execute code.
Good detection also depends on context. A value under a run key is more suspicious when it points to a user-writable directory, a temporary path, or a renamed binary in an application data folder. It becomes even more interesting when the change is made by a standard user or by a process that should not be modifying startup locations. For broader persistence coverage, the Persistence Techniques Guide is the natural reference point because autoruns are only one part of the larger startup-abuse problem.
How to validate an autorun entry before you call it malicious
The first validation step is to compare the current registry state with a baseline. That baseline can be built from gold images, approved software inventories, or a known-good snapshot from the same endpoint class. Focus on additions, deletions, and edits to values that resolve to executable files, scripts, PowerShell, or command shells. If the entry is new, renamed, or points to an unexpected parent process, treat it as a candidate persistence mechanism.
Then inspect the target object itself. Check the referenced file path, file hash, digital signature, and signer reputation, and confirm whether the file exists where the registry says it should. A mismatch between the registry value and the on-disk binary, or a path that resolves through a writable directory, can indicate an attempt to persist without obvious malware stubs. The same logic applies when the value uses command interpreters or indirect launch methods, because those often provide the attacker with easier execution and evasion options.
It is also useful to correlate registry modification events with the process that wrote them. A benign installer usually has a coherent installation story, while persistence often shows an odd parent-child chain, a user context that should not be administering startup locations, or repeated changes after cleanup. When those patterns appear across multiple hosts, the finding moves from isolated anomaly to likely campaign behaviour.
Why autorun persistence matters for detection and response
Registry autorun entries matter because they give an attacker a durable way to regain execution after logout or reboot. That makes them a high-value foothold for ransomware staging, loader persistence, and repeat access after a defender removes the obvious payload. A key defensive concern is that the persistence mechanism may survive even when the original dropper, scheduled task, or exploit vector has been removed.
Once an autorun entry is confirmed as malicious or suspicious, the response should include more than deleting the registry value. The host may already have been used for credential theft, lateral movement, or additional persistence elsewhere. Review adjacent startup surfaces, recent login activity, and any process that created the registry change, then decide whether the compromise is local-only or part of a broader intrusion. The Identity Threat Detection and Response (ITDR) Guide helps frame the downstream investigation when persistence is tied to identity abuse and repeated access.
Risk and Threat Considerations
Registry autorun persistence is risky because it turns a single successful execution into recurring access. Attackers prefer it when they want resilience across reboots, stealth inside normal startup behaviour, and a simple way to relaunch a payload without needing a fresh exploit each time.
Failure mechanism: The attacker writes or modifies startup registry values so Windows launches attacker-controlled code at logon or boot, often from a user-writable or hidden location that makes the entry easy to restore and hard to notice.
Impact: The system can repeatedly re-infect itself, preserve access after cleanup, and support follow-on activity such as credential theft, lateral movement, or repeated payload execution until the persistence entry and any supporting files are removed.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while CIS Controls v8 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1547.001 — Registry Run Keys / Startup Folder | Directly covers Windows autorun registry persistence |
| T1112 — Modify Registry | Registry editing is the mechanism used to establish autorun persistence | |
| Recommendation — Monitor run keys and startup folders for unauthorized additions and changes. Alert on suspicious registry modification activity that creates persistence. | ||
| CIS Controls v8 | CIS-8 — Audit Log Management | Detection depends on logging registry changes and process provenance |
| Recommendation — Collect and review registry change telemetry for persistence hunting. | ||
| NIST SP 800-53 Rev 5 | AU-6 — Audit Record Review, Analysis, and Reporting | Registry persistence detection requires log review and correlation |
| CM-7 — Least Functionality | Autorun persistence is reduced by limiting unnecessary startup execution paths | |
| Recommendation — Review host audit records for autorun key creation and modification events. Restrict unnecessary autorun locations and startup execution paths. | ||
Practitioner Guidance
What to verify: Verify that every startup-related value on the host maps to an approved application, approved signer, and expected execution path. If the value launches from AppData, Temp, Downloads, or another writable location, treat it as suspicious until proven otherwise.
Decision rule: If the registry change was made by a standard user, a script host, or a process that should not manage startup configuration, prioritise containment and file inspection before you spend time on cosmetic cleanup. The change source often matters more than the registry value alone.
Common mistake: Removing only the registry value and assuming the issue is fixed. If the payload file, scheduled task, or supporting loader remains on disk, the persistence will usually come back.
Practitioner takeaway: The strongest signal is not “an autorun key exists”, it is “a startup entry appeared, from an unusual writer, pointing to an unexpected executable path that can re-establish execution.”
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 20, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org