Run Keys

What Run Keys Do in Windows

Run Keys are registry values that Windows checks at sign-in to launch programs automatically. They are a normal startup mechanism, which is why they are used by both legitimate software and attackers looking for persistence.

Because they live in the registry and execute at logon, Run Keys sit at a high-value point in the boot or sign-in chain. A change to one of these values can quietly alter what runs for a user session without changing the visible desktop experience.

Why Run Keys Matter for Persistence

Run Keys are important because they provide a predictable, low-friction way to establish persistence. An attacker that can write to the relevant registry location can cause code to reappear every time the user signs in, even after a reboot or a simple process kill.

This makes them a classic autostart technique in Windows incident response. They are especially useful to malware when the goal is to blend into ordinary startup behaviour rather than rely on a more obvious scheduled task or service.

Run Keys are also part of a wider family of autostart mechanisms, so defenders usually treat them as one indicator among several rather than as a standalone signal. The practical question is not just whether a value exists, but whether the target program is expected, signed, approved, and associated with the user or system context it claims to run under.

How Administrators Check for Abuse

Exposure checks usually start with inventory and baselining. Administrators compare current Run Key entries against known-good startup software, approved admin tooling, and the normal software load for a given endpoint or workstation role.

They also look at where the value points. A legitimate startup entry should map to a known publisher or business need, while suspicious entries often point to unusual paths, recently dropped binaries, user-writable locations, or commands that look like staging logic rather than application startup.

Telemetry matters as much as the registry value itself. T1547 Boot or Logon Autostart Execution Defensive Guide is useful here because it covers Run Keys alongside other logon persistence methods and shows how defenders can baseline, detect, and evict this class of technique.

Remediation and Verification After Change

When a Run Key is malicious or unnecessary, the immediate goal is to remove the persistence point and confirm what launched from it. That means deleting the unwanted registry value, preserving evidence first, and then verifying whether the referenced payload created additional persistence elsewhere.

Cleanup should not stop at the registry entry. If the launched program was introduced by malware, defenders often need to review adjacent artefacts such as startup folders, services, scheduled tasks, and supporting binaries, because Run Keys are frequently one part of a broader persistence chain.

Windows Internals for Defenders Guide helps explain why this review matters, since autoruns, tokens, privileges, and service contexts shape whether the same payload can be relaunched or escalated after the initial Run Key is removed.

Detecting Reappearance and Unauthorized Change

Run Keys should be monitored for unexpected creation, modification, or restoration after cleanup. Reappearance can indicate that the original actor still has access, that another persistence mechanism is rewriting the value, or that an approved tool is being misused to re-establish launch control.

Post-patch or post-removal review should include the parent process that wrote the registry change, the account that made it, and whether the launched program is still present on disk. If the file remains but the registry entry vanishes and then returns, defenders should assume active persistence management rather than a one-off cleanup issue.

For broader defensive mapping, MITRE ATT&CK Enterprise Matrix is a useful reference for correlating Run Keys with adjacent persistence and privilege-abuse techniques, while NIST SP 800-53 Rev 5 Security and Privacy Controls supports the underlying monitoring, configuration, and audit controls that make these changes visible.

Risk and Threat Considerations

Run Keys are risky because they turn a simple registry write into repeated execution at sign-in. If an attacker gains the right to alter the value, they can persist on the endpoint with relatively little noise and survive routine user logoffs or process termination.

Failure mechanism: The attacker abuses a trusted autostart location, plants a command or executable path, and relies on the next user logon to trigger execution again.

Impact: The compromise can become durable, enabling repeated access, follow-on payload delivery, credential theft, or lateral movement from an endpoint that appears to be back to normal.

Practitioner Guidance

What to watch for: Treat any new or altered Run Key as a change that deserves ownership, not just a registry edit. The most useful triage question is whether the entry was created by approved software installation, by a controlled administrative action, or by an unexpected process under a user context that should not be writing persistence.

Governance implication: On Windows estates, Run Key monitoring works best when endpoint hardening, software allowlisting, and change control are aligned. If those three are loose, the registry becomes an easy place for both legitimate auto-start logic and abuse to hide in plain sight.

Related resources from NHI Mgmt Group

• Guide: Persistence Techniques Guide
• How should security teams respond when an AI model accesses exposed keys or other sensitive artifacts during a run?
• How do attackers use Windows Registry Run Keys?
• How can security teams detect Windows Registry Run Keys?
• What mitigations reduce the risk of Windows Registry Run Keys?