RunOnce Persistence

Expanded Definition

RunOnce persistence refers to a Windows startup mechanism that executes a specified command the next time a user logs on, or after a reboot, depending on how the registry entry is configured. Security practitioners usually discuss it as an abuse of legitimate operating-system behaviour rather than as a standalone malware family. The technique is valuable to attackers because it can trigger a payload once, then hand off control to a second-stage process or re-establish foothold without needing a service, driver, or scheduled task.

Definitions vary slightly across vendors because some treat RunOnce as a broader startup persistence category, while others reserve the term for specific registry paths such as RunOnce and RunOnceEx. The practical distinction is that the attacker is relying on built-in Windows execution logic, which makes the activity look routine unless registry monitoring, endpoint telemetry, or startup auditing is in place. NIST guidance on access control and system monitoring, including the NIST SP 800-53 Rev 5 Security and Privacy Controls, is relevant because defenders need visibility into persistence mechanism as part of baseline host hardening.

The most common misapplication is treating all registry autostart entries as equivalent, which occurs when analysts fail to distinguish one-time execution keys from broader logon persistence locations.

Examples and Use Cases

Implementing detection for RunOnce persistence rigorously often introduces tuning overhead, requiring organisations to weigh startup visibility against the risk of false positives from legitimate installers and update workflows.

• Malware drops an executable into a user-writable directory and writes a RunOnce key so the payload launches after the next interactive logon.
• An attacker chains RunOnce with script execution to unpack a second-stage tool only once, reducing the window in which defenders can catch the initial file.
• A compromised admin account adds a registry value under a logon autostart path to re-launch a remote access tool after reboot, then removes the original dropper.
• Security teams use MITRE ATT&CK startup registry key guidance to map how this technique fits into broader persistence tradecraft, while remembering that ATT&CK describes techniques, not governance controls.
• Incident responders inspect startup registry paths during triage to confirm whether a “clean reboot” actually removed persistence or merely delayed execution.

In legitimate environments, software installers sometimes use RunOnce-style entries to complete first-boot configuration, which is why context matters. The same mechanism can be benign during deployment and malicious after compromise. Guidance from the CISA StopRansomware guidance reinforces the need to harden common persistence points and investigate unusual autorun behaviour quickly.

Why It Matters for Security Teams

RunOnce persistence matters because it hides in a control path that defenders often expect to be noisy, routine, and harmless. That assumption can let an intruder survive a restart, re-open remote access, or stage follow-on tooling after user login. For security teams, the risk is not just initial compromise but failure to remove the mechanism that makes reinfection effortless.

This concept intersects with identity in a practical way: if an attacker obtains privileged credentials, they can convert temporary access into repeatable access by writing persistence into the host startup path. In a Zero Trust or privileged access programme, that means the incident is not complete when the suspicious process is killed. It is complete only when the registry change, the dropped binary, the associated account abuse, and any secondary execution path are all removed.

Effective host baseline controls, file-integrity monitoring, and registry auditing help reduce this exposure, and Microsoft security guidance on Windows persistence and startup locations is often used by defenders to validate where these entries live. Organisations typically encounter recurring reinfection only after an apparently resolved incident, at which point RunOnce persistence becomes operationally unavoidable to address.

Related resources from NHI Mgmt Group

• When does malware persistence become an NHI governance issue?
• How do security teams know if persistence has been established on a compromised AI node?
• How should security teams prevent unwanted persistence in Active Directory and Entra ID?
• Why do stale accounts and old privilege create such a large persistence risk?