Windows Run Key Persistence

How Windows Run Keys Create Persistence

Windows Run and RunOnce keys are a common autostart mechanism, so a malicious entry can make code launch every time a user logs on. That turns a one-time foothold into repeatable execution without needing a separate startup service or scheduled task.

Because the mechanism is tied to logon, it is especially useful after initial compromise of a user session or endpoint profile. The payload may be a full binary, a script launcher, or a secondary stager, but the security effect is the same: the attacker has embedded execution into the normal Windows startup path.

Why Run Key Persistence Is Valuable to Attackers

run key persistence is attractive because it is simple, resilient, and often blends into ordinary registry activity. If the attacker can write to the relevant hive, they can establish long-lived access that survives reboots and user logoff without requiring a kernel-level foothold.

It also supports follow-on abuse such as credential collection, lateral movement, and reinfection. In practice, persistence is often paired with other post-compromise activity, so the presence of a Run key entry should be treated as an indicator of an active or recent intrusion path rather than a harmless startup tweak.

For a broader view of persistence patterns, the Persistence Techniques Guide covers run keys alongside other autostart and backdoor methods.

What Organisations Should Look For

Exposure is usually found through endpoint inventory, registry inspection, and investigation of which accounts can modify autostart locations. The key question is not just whether a Run or RunOnce entry exists, but whether it is expected, signed, and owned by a legitimate application.

Defenders should also correlate the persistence entry with logon activity, parent-child process chains, and recent file drops in user-writable locations. A suspicious entry that launches from a profile path, temporary directory, or unusual command line deserves immediate scrutiny.

When the endpoint is part of a broader identity compromise pattern, the Identity Threat Detection and Response (ITDR) Guide is useful for connecting persistence to stolen sessions, abused accounts, and post-compromise response.

Containment, Detection, and Cleanup

Removal should focus on both the registry value and the payload it launches, otherwise the system can be reinfected at the next logon. It is also important to review neighbouring startup locations because attackers often keep multiple persistence mechanisms in reserve.

Detection is strongest when registry change monitoring is combined with process telemetry and endpoint isolation. If the entry was created by a compromised account, remediation should include reset or rotation of affected credentials and a review of other systems where the same account or token may have been used.

For defensive mapping and control coverage analysis, the MITRE D3FEND Guide is helpful when turning observed persistence into specific detection and eviction actions.

Risk and Threat Considerations

Run key persistence is risky because it converts a single compromise into recurring execution, which can survive reboots and extend attacker dwell time. On shared or heavily used endpoints, that can make a low-friction persistence method disproportionately valuable to an intruder.

Failure mechanism: An attacker gains the ability to modify a user or system startup reference, then plants a command that runs automatically at logon. This works because Windows trusts those autostart locations as part of normal user session startup.

Impact: The attacker regains execution after every reboot or sign-in, which can support credential theft, reinfection, lateral movement, and long-term access until the registry entry and payload are removed.

Practitioner Guidance

What to watch for: Treat any unexpected Run or RunOnce entry as a persistence event, not just a configuration oddity. The strongest signal is an entry whose path, signer, or parent process does not match the installed software estate.

Governance implication: Ownership of autostart locations should be explicit, because persistence often sits between endpoint administration, identity compromise, and incident response. Teams should know who can approve startup entries, who validates them, and who removes them during containment.

Practitioner takeaway: If the entry is not clearly required by a trusted application, assume it is malicious until proven otherwise.

Related resources from NHI Mgmt Group

• How should teams respond when a remote access trojan creates Run key persistence?
• How do you detect registry autorun key persistence on Windows?
• Run key persistence
• Registry Run Key Persistence