What Is Registry Run Key Persistence? Definition & Examples

Registry Run Key Persistence is a Windows persistence technique where malware or an unauthorized program adds itself to registry locations that launch automatically at logon or startup. Technically, attackers modify keys such as Run or RunOnce so code executes when a user signs in, helping the threat survive reboots and maintain access.

What Registry Run Key Persistence Is

Registry run key persistence is a Windows startup persistence method, not a privilege escalation trick. The attacker’s goal is simple: survive reboot and regain execution automatically, often early in a user session, without needing a separate launch event.

Because the registry value is evaluated as part of normal logon behaviour, the technique blends into ordinary system activity. That makes it attractive for commodity malware and more targeted intrusions alike, especially when defenders focus only on processes currently running rather than what will relaunch after restart.

How Run and RunOnce Keys Create Persistence

Run and RunOnce locations can hold commands or paths that Windows processes during sign-in or startup. When a malicious program inserts itself into those locations, it turns a routine user logon into an execution trigger, giving the payload repeated opportunities to load.

Different startup locations can produce different persistence characteristics, but the core idea is the same: the registry becomes the launch mechanism. The technique is often paired with a benign-looking filename, a user profile path, or an executable hidden in a writable directory so the startup entry looks less suspicious during casual inspection. For broader context on how Windows artefacts support malicious execution chains, MITRE ATT&CK Enterprise Matrix maps this kind of adversary behaviour to persistence and follow-on access patterns.

Why Attackers Use This Technique

Registry Run Key Persistence is valuable because it is low-friction, durable, and often available without advanced tooling. If an attacker already has a foothold, they can keep that foothold alive across restarts and often avoid the need for repeated exploitation.

It also helps attackers maintain timing control. A payload that starts at logon can re-establish command-and-control, drop additional components, or wait for a user session to expose credentials and mapped resources. In environments that do not monitor registry autoruns closely, the persistence can remain hidden for a long time.

The technique is especially effective when paired with weak endpoint visibility. NHI Mgmt Group’s Ultimate Guide to Non-Human Identities notes that only 5.7% of organisations have full visibility into their service accounts, a reminder that durable access often survives when inventory and monitoring are incomplete.

What Defenders Should Watch For

Suspicious run-key persistence usually shows up as an unexpected autorun entry, a new value pointing to an unusual path, or a startup command that launches from a writable user location instead of a trusted program directory. Changes to these keys are particularly important when they appear soon after initial compromise or alongside other signs of defensive evasion.

Defenders should treat registry-based persistence as both a host integrity issue and an access persistence issue. The key question is not just whether a value exists, but whether the startup command is authorised, whether it survives reboot for legitimate reasons, and whether its presence matches the software baseline for that endpoint.

Risk and Threat Considerations

Registry Run Key Persistence creates durable re-entry for an attacker. Once established, it can survive reboots, complicate incident containment, and let malicious code reappear even after a process kill or temporary network isolation.

Failure mechanism: An attacker with write access to a user or system registry hive adds an autorun entry that Windows processes at logon, converting a one-time foothold into repeated execution and making removal harder if the entry is missed.

Impact: The compromise can persist across restarts, enable credential capture or lateral movement, and extend dwell time because the malicious code re-launches before defenders fully regain control.

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 defines Windows registry autorun persistence via Run keys.
Recommendation — Hunt for T1547.001 by reviewing autorun registry changes and removing unauthorized startup entries.
CIS Controls v8	CIS-4 — Secure Configuration of Enterprise Assets and Software	Run-key persistence is a configuration change that hardening and baseline control should detect.
Recommendation — Enforce secure baselines and alert on unauthorized startup registry modifications.
NIST SP 800-53 Rev 5	CM-6 — Configuration Settings	Startup registry entries are configuration settings that must be controlled and monitored.
	SI-4 — System Monitoring	Detects unauthorized persistence by monitoring endpoint changes and suspicious startup behaviour.
	AU-6 — Audit Review, Analysis, and Reporting	Audit records support review of persistence-related changes and incident investigation.
Recommendation — Define approved autorun settings and investigate any deviation from the baseline. Monitor registry autorun activity and alert on suspicious persistence creation. Review registry and process audit data for unauthorized startup modification activity.

Practitioner Guidance

Common misunderstanding: A clean malware scan does not necessarily mean persistence is gone. If the autorun entry remains, the infection can re-establish itself the next time the user signs in or the system starts.

What to watch for: Prioritise unexpected registry autorun changes, especially values created in user-writable locations or by processes that do not normally modify startup configuration. Pair host telemetry with startup baseline review so persistence is found before it is rediscovered by the attacker.

Registry Run Key Persistence