An autostart registry run key is a Windows registry location used to launch programmes automatically when a user signs in or the system starts. Attackers and administrators use these keys to persist software execution, so defenders monitor them for unauthorised changes, unexpected executables, and suspicious command lines.
What the Autostart Registry Run Key Does
An autostart registry run key is a Windows persistence mechanism, not a program in itself. It tells the operating system to launch specified software at logon or startup, which makes it useful for legitimate administration and equally useful for covert persistence when a system is compromised.
Because the mechanism is simple and native to Windows, defenders usually treat it as an execution point that deserves baseline monitoring. Changes to the key can be benign, but they are also a common signal that software is trying to survive reboots or user logoff.
Why Run Keys Matter to Attackers and Defenders
Run keys are attractive because they can provide low-friction persistence with minimal additional tooling. An attacker who can write to the relevant registry location can arrange for a payload, loader, or script to execute automatically without needing to stay in the foreground.
For defenders, the same convenience makes the key a high-value detection point. Unexpected command lines, unusual paths, or entries that point to user-writable locations often indicate that the registry value is being used to retain execution rather than to support a legitimate application.
The pattern is part of the broader Persistence Techniques Guide, which covers how autostart mechanisms such as run keys fit into attacker persistence and host eviction workflows.
How to Investigate Autostart Registry Run Keys
Exposure analysis starts with the endpoint inventory, because you need to know which hosts, users, and startup locations exist before you can tell whether a given value is expected. From there, compare the current registry state with a known-good baseline and check whether the entry was added recently, points to an odd executable, or launches a script from a temporary or user profile path.
It is also worth correlating the registry change with process creation, logon activity, and any nearby file writes. A benign application typically leaves a predictable installation trail, while malicious persistence often appears alongside staging files, renamed binaries, or unusual parent-child process relationships.
The broader Windows telemetry context in the Windows Internals for Defenders Guide helps place registry autoruns alongside tokens, privileges, and native logging sources that can confirm whether the change is expected.
Detection, Cleanup, and Safe Response
Defence should focus on both the registry value and the file or command it launches. If the entry is malicious, deleting the key alone may not be enough, because the payload can recreate persistence through another autostart location, a scheduled task, a service, or a startup folder item.
When you remove a suspicious run key, validate whether the associated executable, script, or supporting loader still exists, then review nearby autoruns for related persistence. The T1547 Boot or Logon Autostart Execution Defensive Guide is useful here because it maps run keys to the wider boot and logon persistence family and shows where defenders should look next.
Risk and Threat Considerations
Run keys are risky because they convert a single registry write into repeatable execution. That makes them a durable persistence point for malware, post-exploitation tooling, and stealthy re-entry after reboot or sign-in.
Failure mechanism: an attacker or rogue installer gains write access to the autostart value, inserts a trusted-looking command, and relies on the operating system to launch it automatically on the next logon or boot.
Impact: the system can keep re-running the malicious payload, which increases dwell time, complicates eradication, and can preserve access even after the original intrusion path is closed.
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 NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1547.001 — Boot or Logon Autostart Execution: Registry Run Keys / Startup Folder | Run keys are the exact persistence technique defined by this ATT&CK sub-technique. |
| Recommendation — Map suspicious autorun changes to T1547.001 and hunt for associated persistence artifacts. | ||
| NIST SP 800-53 Rev 5 | AU-6 — Audit Review, Analysis, and Reporting | Run key changes are a loggable event that needs review and correlation. |
| CM-6 — Configuration Settings | Autostart locations are configuration settings that should be governed and baselined. | |
| SI-4 — System Monitoring | Detecting malicious persistence depends on monitoring registry and process behaviour. | |
| Recommendation — Correlate registry autorun changes with audit events and investigate unexplained persistence activity. Baseline approved autorun locations and review deviations from the expected configuration. Monitor autorun registry locations and related process launches for suspicious changes. | ||
| CIS Controls v8 | CIS-8 — Audit Log Management | Run key tampering is easier to spot when registry and process events are retained and reviewed. |
| CIS-10 — Malware Defenses | Autostart persistence is a common malware survival mechanism that defensive controls must disrupt. | |
| Recommendation — Collect and review endpoint logs that expose registry autorun creation or modification. Use malware defences to block, detect, and evict persistence that depends on autorun registry entries. | ||
Practitioner Guidance
Why practitioners should care: treat autostart registry values as part of your endpoint control surface, not just as startup convenience. A small number of well-understood autostart paths are usually enough for legitimate software, so unexplained entries deserve quick review.
What to watch for: prioritise values that point to scripts, living-off-the-land binaries, temporary directories, user-writable paths, or oddly named executables. Those patterns are often more informative than the registry location alone.
Practitioner takeaway: the most effective response is to baseline, alert, and investigate the registry entry together with the binary it launches, because the key is only one half of the persistence chain.
Related resources from NHI Mgmt Group
- Registry Run Key Persistence
- How should security teams use automated registry-key remediation to reduce malware persistence without creating operational risk?
- What are the signs that a root CA key signing ceremony is being run poorly?
- What happens when a malicious container image is pulled from a public registry and run in production?
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 November 3, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org