Run key persistence

Expanded Definition

Run key persistence is a Windows persistence method in which an attacker places a command, script, or executable path inside a registry Run value so it launches automatically during user logon. Security teams often discuss it alongside other startup persistence mechanism, but it is distinct because the trigger is tied to registry-based autorun behavior rather than a scheduled task, service, or shortcut. In practice, the technique may live under MITRE ATT&CK Registry Run Keys / Startup Folder, although ATT&CK describes the technique as an adversary behavior rather than a governance definition.

For defenders, the important question is not only whether the value exists, but whether its target path, command line, parent process, and file origin match expected software installation or user workflow. Definitions vary across vendors when they bundle all autoruns together, so analysts should separate Run keys from Startup folder entries, services, and other persistence points. The most common misapplication is treating every Run value as malicious, which occurs when legitimate software updaters, remote support tools, or enterprise agents are not baselined and therefore generate false positives.

Examples and Use Cases

Implementing detection rigorously often introduces more telemetry and triage effort, requiring organisations to weigh startup visibility against alert volume and registry-monitoring overhead.

• An intruder adds a payload path to a per-user Run value so it executes at every logon without needing elevated privileges.
• A legitimate remote administration tool registers itself in a Run key during installation, which is why context from software inventory is essential.
• Threat hunters correlate a Run value with file creation, PowerShell activity, and a new outbound connection to confirm whether the entry is part of a broader intrusion chain.
• Defenders compare Windows persistence mechanisms across endpoints to identify unusual entries that do not match approved baselines.
• Analysts use registry auditing and endpoint detection rules to separate one-time cleanup artifacts from active persistence intended to survive reboots and user logons.

Why It Matters for Security Teams

Run key persistence matters because it is one of the simplest ways to survive remediation if teams only remove a malicious process without finding the autorun source. It also creates a visibility problem: the registry value may look ordinary while the referenced file sits in a user-writable location, an archive, or a renamed staging directory. That makes endpoint telemetry, registry auditing, and process lineage essential to validate whether the entry is sanctioned or adversarial. Guidance from NIST SP 800-53 Rev 5 Security and Privacy Controls is relevant here because malware response, audit logging, and configuration management controls support detection and recovery even though the framework does not name this technique directly.

For identity and access teams, Run key persistence can also indicate stolen user context or an abused endpoint account, especially when the autorun is written into a profile the attacker can control. In environments with EDR and SIEM, the key lesson is to tie registry modifications to process execution and logon events rather than reviewing them in isolation. Organisations typically encounter the operational impact only after a reboot or new session brings the hidden payload back to life, at which point Run key persistence becomes operationally unavoidable to address.

Related resources from NHI Mgmt Group

• Who is accountable when machine-key theft turns a SharePoint breach into persistence?
• What are the key NHI security metrics every CISO should track?
• How should security teams run access reviews for non-human identities?
• What is the difference between role-based access and API key governance for NHI security?