Attackers modify registry run keys to make malicious code start automatically when a user logs on or the system boots. They often place persistence there after gaining access, sometimes using legitimate-looking names or user-level keys to avoid notice. Defenders should monitor changes to autorun locations, restrict write access, and review unexpected startup entries.
Why registry run keys are attractive for persistence
registry run keys are a common Windows autorun mechanism, so attackers use them to make malicious code launch automatically at logon or during startup. That makes the payload survive reboots and user sign-outs without needing another execution step. They often prefer locations and value names that blend in with normal software so the entry is less likely to stand out during casual inspection.
Because this is a persistence mechanism, the attacker’s goal is usually to keep access available, not necessarily to increase privileges. A run key can be enough to restart a backdoor, loader, or script every time the machine or user session comes up, which makes it useful after an initial compromise or for re-entry later.
Attackers also choose between machine-wide and user-level locations based on what they can write to and how visible they want the change to be. User-level autoruns can be easier to plant without admin rights, while system-wide autoruns can reach more users or execute earlier in boot.
How attackers abuse the autorun path in practice
The most common abuse pattern is simple persistence: write a registry value that points to malicious code, then rely on the operating system to execute it automatically. That code may be a binary, script, command line, or a launcher that pulls down the next stage. The key detail is that the registry entry becomes the trigger, so the malware does not need a separate scheduled task or service to survive.
Attackers often disguise the entry by using a legitimate-looking program name, placing it alongside expected software values, or using a path that resembles vendor tooling. Some also pair the run key with other startup mechanisms, so if one is removed the foothold may still remain elsewhere.
Modification of registry run keys also fits well into post-compromise activity because it is fast, low-noise, and easy to repeat. If the attacker still has write access, they can replant the entry after cleanup unless defenders remove the underlying access path and check for related persistence artifacts.
What defenders should verify first
Unexpected startup entries are the first thing to validate, but the registry change itself is only part of the story. A useful review checks which account wrote the key, whether the command points to a known file, whether the target exists on disk, and whether the timestamp matches a suspicious login or execution event.
It also helps to compare autorun changes with process creation, logon events, and file writes around the same time. If the registry value appeared shortly before a suspicious login or new binary on disk, that is stronger evidence of attacker activity than an isolated startup entry.
Where possible, defenders should separate benign persistence from malicious persistence by asking whether the entry is expected, documented, signed, and owned by a known application. Unknown values that point to temporary directories, user profile paths, or recently dropped files deserve faster scrutiny.
Risk and Threat Considerations
Run keys create a durable foothold because they convert one-time access into repeatable execution. The main risk is that even after a host is rebooted or a user session ends, the attacker can regain code execution before defenders notice the original compromise has not been fully removed.
Failure mechanism: The attacker abuses an operating system autorun location to execute malicious code automatically at boot or logon, often with a benign-looking name or user-level path that blends into normal startup activity.
Impact: Persistence increases dwell time, supports re-entry after cleanup, and can be used to stage credential theft, command execution, or follow-on payload delivery from a trusted local startup path.
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 | T1547.001 — Registry Run Keys / Startup Folder | Covers persistence via Windows autorun registry locations. |
| Recommendation — Hunt for registry autorun changes and correlate them with process creation and logon activity. | ||
| CIS Controls v8 | CIS-10 — Malware Defenses | Addresses detecting and blocking malicious persistence and startup abuse. |
| Recommendation — Monitor autorun locations and alert on unauthorized startup modifications. | ||
| NIST SP 800-53 Rev 5 | CM-5 — Access Restrictions for Change | Restricts who can modify startup and configuration entries on endpoints. |
| AU-6 — Audit Review, Analysis, and Reporting | Supports investigating suspicious registry persistence with correlated logs. | |
| SI-4 — System Monitoring | Supports monitoring for unauthorized persistence changes on hosts. | |
| Recommendation — Limit write access to autorun paths and review all privileged registry changes. Correlate registry writes with logon, process, and file activity during investigation. Detect unexpected changes to autorun registry locations and investigate them promptly. | ||
Practitioner Guidance
What to prioritise: Treat the registry change as a persistence indicator, not just a configuration drift event. If the startup entry points to an unfamiliar binary or script, validate the backing file and the account that created the key before assuming the host is clean.
What to verify: Confirm whether the entry is in a documented software path, whether it survives a reboot, and whether other autorun locations were modified around the same time. Registry persistence is often part of a broader set of startup and post-exploitation changes, so a single-key review can miss the full foothold.
Common mistake: Removing only the visible registry value without checking for the dropped payload, the original foothold, or a second persistence mechanism. If the attacker still has another execution path, the run key can simply be recreated.
Practitioner takeaway: The real security question is not whether a run key exists, but whether it gives an attacker a durable, trusted execution path that survives routine reboot and cleanup cycles.