What Is Registry Run Keys? Definition & Examples

Registry run keys are Windows Registry entries that trigger programs to start automatically when a user logs in or when the system boots. Attackers abuse them to create persistence, masquerade malicious programs as legitimate entries, and ensure execution under the victim’s permissions without dropping a conventional executable first.

What Registry Run Keys Do

Registry run keys are Windows persistence points, not just convenience settings. They tell the operating system to launch specific programs automatically at logon or startup, which is why both legitimate software and attackers value them as a reliable execution path.

Because the entries are stored in the Windows Registry, they can survive reboots and blend into normal system behavior. That makes them a common place for software to establish auto-start behavior without requiring a separate scheduled task, service, or visible startup shortcut.

Why Attackers Target Run Keys

From a defender’s view, run keys matter because they let adversaries turn a one-time foothold into repeatable execution. A malicious entry can load under the current user’s context or, in some cases, under system startup conditions, which helps malware reappear after logoff and can delay discovery.

Attackers also abuse run keys to masquerade as legitimate software names, point to renamed binaries, or launch scripts and loaders from obscure paths. That ambiguity is useful for persistence and for hiding the real execution chain inside routine Windows startup activity. For broader context on how adversaries map these behaviors, see the MITRE ATT&CK Enterprise Matrix.

How Run Key Abuse Works in Practice

Run-key abuse usually depends on write access to a registry location that Windows checks during startup or login. The attacker may add a value that launches code directly, calls a script host, or invokes a helper binary that later pulls down the real payload.

That approach is attractive because it is low-friction and often blends with legitimate autoruns. It can also be paired with other persistence methods, including services, startup folders, and scheduled tasks, to increase resilience if one mechanism is removed.

In malware campaigns, run keys are often selected when the goal is persistence rather than immediate privilege escalation. The key security question is not only whether the entry exists, but whether the command line, file path, publisher, and parent process all match the expected software footprint. Guidance on registry and startup-area hardening is reinforced in NIST SP 800-190 Container Security for image and runtime contexts, and in NIST SP 800-53 Rev 5 Security and Privacy Controls for system integrity, configuration, and audit controls.

What Good Detection and Review Look For

Registry run keys are best understood as a visibility problem as much as a persistence problem. Security teams need to know which autorun entries are normal for each endpoint population, because unexpected additions, path changes, or command-line edits are often more important than the registry value name itself.

Review should focus on newly created entries, suspicious parent processes, unusual binaries in user-writable locations, and references to scripts, encoded commands, or renamed system tools. If a run key points to a credentialed updater or trusted vendor component, the surrounding file metadata and provenance should still be checked, since attackers frequently imitate common software patterns.

Because autorun persistence is a recurring technique across many intrusion sets, defenders often pair registry monitoring with broader endpoint telemetry and control hardening. For a policy-level lens on least privilege and defensive verification, NIST Cybersecurity Framework 2.0 is useful for organizing detection, protection, and response responsibilities.

Risk and Threat Considerations

Registry run keys create persistence risk because a small registry change can produce repeatable code execution across logons and reboots. When attackers gain write access to an autorun location, they can maintain presence with relatively little noise and may inherit the victim’s available permissions at each startup.

Failure mechanism: unauthorized registry modification, often combined with a benign-looking path or process name, causes Windows to launch attacker-controlled code automatically before users notice the change.

Impact: the compromise becomes harder to evict, malware can re-establish itself after cleanup, and defenders may miss the entry if they do not inspect startup persistence locations directly.

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 — Registry Run Keys / Startup Folder	Defines autorun registry persistence and startup-folder abuse.
Recommendation — Map suspicious autoruns to T1547.001 and hunt for newly added persistence entries.
NIST SP 800-53 Rev 5	CM-6 — Configuration Settings	Run keys are configuration changes that should be authorized and controlled.
	AU-6 — Audit Record Review, Analysis, and Reporting	Detection depends on reviewing endpoint audit and change activity around autorun locations.
	SI-4 — System Monitoring	Run-key abuse is a monitoring and detection problem on endpoints and servers.
Recommendation — Restrict and review registry autorun changes under CM-6 to prevent unauthorized persistence. Review audit data for unexpected startup-entry creation and registry modification activity. Monitor endpoint autorun locations for unexpected registry changes and suspicious launch targets.
CIS Controls v8	CIS-10 — Malware Defenses	Run keys are a common malware persistence mechanism addressed by endpoint malware defenses.
Recommendation — Use malware defenses to detect and block persistence changes in autorun locations.

Practitioner Guidance

What to watch for: treat run-key review as a standing endpoint-hygiene control, not an incident-only task. The highest-value checks are the ones that compare current autorun entries against a known-good baseline and flag entries that point to user-writable directories, script interpreters, or unfamiliar binaries.

Common misunderstanding: a familiar registry value name does not make an autorun entry safe. Attackers can reuse expected locations and only change the target command, so the control value, command line, and file provenance all need to be examined together.

Registry Run Keys