A method for making malware start automatically when a user logs in by writing entries to Windows registry run keys. This creates a simple but effective persistence mechanism because the malicious binary is launched repeatedly without requiring the attacker to re-enter the system manually.
How Run Keys Create Persistence
Windows run keys are registry locations that tell the operating system to start a program when a user signs in. For defenders, the important detail is that the mechanism is built into normal logon behavior, so abuse can look like a routine startup action rather than an obvious service installation.
Because run keys are evaluated at logon, they are attractive to malware that wants reliable re-execution after reboot or user logoff. The technique is simple, widely understood, and easy to script, which makes it a common persistence choice for commodity malware and for more targeted intrusions that need low-friction footholds.
Where Run Key Persistence Usually Lives
run key persistence is not one registry value, but a small family of locations with different scope. Commonly abused entries include per-user and system-wide startup paths, allowing code to run in the context of a specific account or for all users depending on where the key is written.
That scope matters operationally. A user-level entry may persist quietly inside a single profile, while a machine-wide entry can affect every interactive session. In both cases, the attacker is relying on trusted OS startup behavior, which means the malicious payload may be launched long after the initial intrusion and without any separate persistence service.
Why Defenders Care About Run Key Abuse
Run keys are a classic persistence mechanism because they are easy to deploy and easy to overlook during a quick incident review. They also create a durable re-entry path for the attacker, especially when combined with stolen credentials, scheduled follow-on activity, or lateral movement already achieved elsewhere in the environment. NHIMG’s Salt Typhoon US telecoms breach is a useful reminder that stolen access and persistence often travel together, even when the initial foothold began elsewhere.
Defenders should treat unexpected startup entries as an integrity signal, not just a malware indicator. A suspicious run key can indicate compromise, but it can also reveal poor endpoint hygiene, weak change control, or an environment where attackers can survive routine restarts long enough to blend into normal activity.
Detection and Cleanup Focus
Good detection work for run key persistence starts with comparing registry startup entries against known-good software, expected logon behavior, and recent administrative change windows. Unexpected paths, odd parent-child process relationships, executable names that mimic legitimate software, and references to writable user locations are all common warning signs.
Cleanup should remove both the registry entry and the payload it points to, then verify that related footholds are not still present elsewhere in the system. Because run keys are only one persistence option, responders should also look for companion mechanisms such as shortcuts, startup folders, services, or other autorun locations when the intrusion profile suggests broader persistence planning.
Risk and Threat Considerations
Run key abuse matters because it turns a one-time compromise into repeatable execution at every login. The technique is low-noise, durable, and often hard to spot in environments that do not baseline startup behavior.
Failure mechanism: An attacker writes a malicious executable path into a registry run key, then relies on normal user logon processing to relaunch the payload after reboot or sign-out.
Impact: The attacker preserves access, increases dwell time, and can repeatedly stage follow-on actions such as credential theft, lateral movement, or payload refresh without re-establishing the initial foothold.
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 CSF 2.0, 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 | Covers registry-based logon persistence through startup execution. |
| Recommendation — Detect and hunt for unexpected autorun registry entries and remove malicious startup persistence. | ||
| NIST CSF 2.0 | DE.CM-09 — Configurations are monitored for unauthorized changes | Run-key persistence is an unauthorized startup configuration change that should be monitored. |
| DE.AE-03 — Event data are collected and correlated from multiple sources | Correlate registry, process, and logon events to spot persistence behavior. | |
| Recommendation — Monitor startup-related registry paths for unauthorized changes. Correlate registry modifications with logon execution to identify persistence. | ||
| CIS Controls v8 | CIS-8 — Audit Log Management | Startup registry abuse is best found through centralized logging and alerting on persistence changes. |
| Recommendation — Log and alert on autorun registry modifications and related process activity. | ||
| NIST SP 800-53 Rev 5 | CM-5 — Access Restrictions for Change | Unauthorized persistence relies on uncontrolled configuration change to startup locations. |
| Recommendation — Restrict and review changes to startup-related registry locations. | ||
Practitioner Guidance
What to watch for: Treat unusual run key changes as a persistence event, not just a registry modification. Focus on newly created startup entries, unexpected script hosts or binaries, and entries that point to user-writable locations or obscure directories.
Governance implication: Persistence controls work best when endpoint monitoring, registry change visibility, and startup-path baselining are part of standard detection coverage. If those signals are missing, this technique is much easier to miss during both compromise and recovery.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 25, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
