Runonce.exe is a Windows component associated with one-time logon tasks and startup actions. Attackers may abuse it to trigger code execution during user logon or to persist through registry-based one-time execution points. Defenders should review unexpected RunOnce entries, watch for changes to logon execution settings, and confirm that startup actions are legitimate.
What Runonce.exe Does in Windows
Runonce.exe is part of Windows logon behaviour, where one-time execution points can run commands or tasks after a user signs in. That makes it useful for legitimate setup actions, but also attractive to abuse when defenders are not watching startup paths closely.
Because the mechanism executes during logon, it sits in a high-trust moment in the operating system lifecycle. A malicious entry can blend into normal administrative activity, especially when the command line or payload location looks routine.
For context on how this fits into broader living-off-the-land abuse patterns, see Living off the Land Guide.
How Runonce.exe Is Abused
Attackers abuse Runonce.exe to get code to execute at the next logon or to create persistence through registry-based one-time execution points. The technique is appealing because it leverages built-in Windows behaviour rather than dropping an obviously suspicious standalone program.
This style of abuse often pairs with other LOLBin activity, where a legitimate binary launches script interpreters, shells, or staged payloads. The real danger is not the binary name alone, but the fact that it can trigger execution through a trusted pathway that defenders may overlook.
Entries tied to unexpected paths, unusual parent-child process chains, or commands that do more than normal setup work deserve close review. In practice, Runonce.exe is often less about the binary itself and more about the execution point it represents.
Why This Technique Matters to Defenders
Runonce.exe can reduce an attacker’s need for noisy persistence mechanisms, making follow-on activity harder to distinguish from ordinary user-session startup behaviour. If an adversary can shape what runs at logon, they may gain a reliable foothold for credential access, lateral movement, or repeated execution after reboots.
Defenders should treat registry-based one-time execution points as part of startup and persistence monitoring, not as a niche Windows curiosity. The key question is whether the entry is expected, approved, and aligned to the system’s role.
A broader detection and hardening view is available in the Living off the Land Guide, which covers LOLBins, application control, and audit signals that help separate normal administration from abuse.
What Good Monitoring Looks Like
Good monitoring focuses on inventory, change visibility, and logon execution paths. That means reviewing RunOnce-related registry changes, correlating them with logon events, and confirming that the associated process tree and command line make operational sense.
Unexpected use of the mechanism is a strong clue, but so is over-reliance on it for software deployment or automation that should have a more controlled management path. If startup actions are legitimate, they should still be explainable, bounded, and easy to audit.
When defenders do find suspicious entries, the next step is not only removal but also a review of the surrounding host for related persistence, staged payloads, and any identity or session material that may have been exposed during execution.
Risk and Threat Considerations
Runonce.exe is risky because it abuses a trusted Windows execution point that can fire during user logon, a moment when persistence is easy to hide and malicious activity can look normal. The same mechanism can be used to re-run payloads after reboot, survive routine cleanup, and blend into startup noise.
Failure mechanism: An attacker places or modifies a RunOnce entry so Windows launches attacker-controlled code during logon, using the built-in startup flow as a persistence and execution mechanism.
Impact: The result can be repeated code execution, stealthier persistence, and downstream exposure if the payload steals credentials, spawns additional tooling, or alters startup behaviour across multiple hosts.
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 CIS Controls v8 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1037 — Boot or Logon Autostart Execution | RunOnce executes at logon, matching autostart persistence behavior. |
| Recommendation — Map unexpected RunOnce execution to T1037 and hunt for logon-based persistence paths. | ||
| CIS Controls v8 | CIS-4 — Secure Configuration of Enterprise Assets and Software | RunOnce abuse is a configuration and startup-path hardening problem. |
| Recommendation — Harden startup paths and monitor configuration drift for RunOnce changes. | ||
| NIST SP 800-53 Rev 5 | CM-5 — Access Restrictions for Change | RunOnce entries are a system change that should be controlled and reviewed. |
| AU-6 — Audit Record Review, Analysis, and Reporting | Detection depends on reviewing startup and logon-related audit evidence. | |
| Recommendation — Restrict and review changes that create or alter RunOnce execution points. Correlate audit data to identify suspicious RunOnce activity at logon. | ||
Practitioner Guidance
What to watch for: Treat RunOnce activity as a change-control question, not just a malware question. Review who created the entry, why it exists, what it launches, and whether that action belongs in a one-time logon path at all.
Governance implication: Establish a clear standard for which startup actions are allowed, how they are approved, and how they are removed after use. The safest pattern is to reserve this mechanism for narrowly scoped, well-documented tasks and to validate that any automation using it is still necessary.
Practitioner takeaway: If a RunOnce entry is unexplained, assume it is part of a persistence or execution chain until you can prove otherwise.