Attackers use Registry Run Keys / Startup Folder to persist by adding programs or scripts that launch automatically when a user signs in or the system starts. That gives them repeated execution without a scheduled task or service. Defenders should audit autostart locations, compare them with approved software, and investigate new or altered entries immediately.
How attackers turn Run Keys and Startup Folder into persistence
registry run keys and the Startup Folder are simple persistence points because they execute automatically at logon or system start. Attackers abuse them to keep a foothold without needing a service, scheduled task, or user interaction each time. The technique is attractive because it is low friction, durable, and often blends into normal startup behaviour.
In practice, the malicious payload can be a binary, script, shortcut, or command line that launches silently in the user context. The risk is highest when the entry points are writable by a compromised user or when defenders do not baseline what should already be present on the host.
Where defenders should look first
The most useful starting point is the specific autostart location on the affected system, not a broad hunt across every persistence mechanism. Compare entries against approved software, installed applications, and expected user profile changes, then verify whether the item was created recently or modified outside a change window. For broader persistence tradecraft, Persistence Techniques Guide gives the surrounding attack patterns that commonly accompany Run Keys and Startup Folder abuse.
Because these locations are part of a larger persistence toolkit, a single suspicious entry should be treated as a lead, not an isolated finding. If the startup artifact points to a script or unusual executable path, inspect the parent process, the drop location, and any companion changes that would explain how the entry was planted.
Why this persistence method is effective
Run Keys and Startup Folder entries are effective because they rely on built-in operating system behaviour rather than an exotic implant. That makes them resilient across reboots and easier for an intruder to maintain than more obvious footholds. They also give the attacker repeated execution opportunities, which can support credential theft, command execution, or staging for later movement. Techniques that lean on registry modification and logon execution patterns are well covered in defensive mappings such as MITRE D3FEND Guide, especially where the defender needs to connect registry-change evidence to executable behaviour.
Attackers often prefer this method when they want persistence that is easy to hide among legitimate software. A startup item may survive long enough to evade casual review, especially if it is named to resemble a vendor component or placed in a user-specific path that security teams do not routinely inspect.
Risk and Threat Considerations
Run Keys and Startup Folder abuse is risky because it gives an attacker reliable re-execution after every logon or reboot, which can preserve access even when an interactive session is closed. It also creates a quiet foothold for follow-on activity such as credential theft, payload delivery, or command-and-control setup.
Failure mechanism: The attacker writes an autorun entry in a registry location or startup directory that the operating system trusts and launches automatically, often with no service or scheduled task to draw attention.
Impact: The malicious program or script can reappear after restart, extend dwell time, and provide a stable base for deeper compromise while blending with normal startup activity.
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 NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1547.001 — Registry Run Keys / Startup Folder | This technique is the exact abuse pattern in the question. |
| T1112 — Modify Registry | Registry Run Keys depend on registry modification to create persistence. | |
| T1547 — Boot or Logon Autostart Execution | Startup Folder abuse is one form of boot or logon autostart persistence. | |
| Recommendation — Map suspicious autostart entries to T1547.001 and hunt for persistence activity around registry and startup paths. Monitor and alert on unauthorized registry changes that create or alter autorun locations. Review logon autostart mechanisms together to catch alternate persistence paths beyond a single key or folder. | ||
| NIST SP 800-53 Rev 5 | SI-4 — System Monitoring | Detecting unauthorized autorun changes depends on host monitoring and alerting. |
| Recommendation — Instrument endpoint monitoring to flag new or changed autorun entries promptly. | ||
Practitioner Guidance
What to verify: Confirm whether the entry belongs to approved software, whether it was created by an expected installer, and whether the file it launches still exists at the recorded path. Check whether the command line points to a script host, a user-writable directory, or a disguised filename that does not match the normal software inventory.
Decision rule: If the entry is new, altered, or points to an unapproved binary, treat it as a persistence event first and a software issue second. Remove the autostart entry, preserve the original artifact for analysis, and then determine whether the host also shows evidence of initial compromise or credential access.
What practitioners underestimate: Startup Folder items can be less visible than services or tasks because they look like ordinary desktop or logon customization. At scale, the real problem is not one suspicious autorun path, but the lack of a trustworthy baseline for what should be present on each class of endpoint.
Practitioner takeaway: The key judgement is to distinguish legitimate startup behaviour from attacker-owned re-execution, then treat any unapproved autorun entry as a persistence lead that may already imply broader host compromise.