Persistence via the startup folder is a technique that places a shortcut or script in a Windows startup path so it runs automatically when the user signs in. It is simple, effective, and widely abused because it helps malware survive reboots and maintain access without advanced privilege escalation.
What the startup folder does in Windows persistence
The Windows startup folder is one of the simplest autostart locations: anything placed there can launch when the user signs in. That makes it attractive for legitimate shortcuts and for abuse, because it gives an actor a repeatable execution point tied to normal user logon rather than to a one-time exploit.
In practice, this technique is part of the broader Persistence Techniques Guide topic set, where the core idea is to survive reboots or logoffs by using trusted operating-system startup behavior. Startup-folder persistence is not stealthy in the same way as kernel or bootkit methods, but it is dependable and often overlooked because it blends into ordinary desktop activity.
Why attackers like startup-folder persistence
Startup-folder persistence is low-friction, low-privilege, and easy to adapt. An attacker does not need to modify firmware, install a driver, or necessarily obtain administrative rights if they can write to the relevant user startup path. That makes it useful after phishing, malware installation, or any compromise that yields a foothold under a user context.
Its value is not just automatic execution. It also helps malware maintain access across sessions, reestablish command execution after a reboot, and create a stable launch point for follow-on activity. In campaign terms, it is often paired with credential theft, living-off-the-land execution, or additional persistence methods when the attacker wants redundancy.
Because the startup folder is a standard Windows feature, defenders cannot treat every item in it as suspicious. The security question is not whether the path exists, but whether the contents, publisher, and execution chain are expected for that host and user.
How defenders find and verify exposure
Exposure checking starts with inventory: which startup folder paths exist on the system, which users can write to them, and what items are present at logon. Defenders should compare those entries against known-good software, deployed business shortcuts, and approved scripts, then look for anomalies such as unfamiliar filenames, recently added links, odd parent processes, or paths pointing to writable user locations.
Process and file monitoring are especially useful because startup-folder abuse often leaves a simple but detectable trail. If you already use the T1547 Boot or Logon Autostart Execution Defensive Guide, map its logging and hunting advice directly to startup-folder entries, then baseline the normal contents so new additions stand out.
For post-compromise review, look beyond the shortcut itself. A startup item may reference a script, LOLBIN, or nested payload stored elsewhere on disk. That means the startup folder is often only the trigger, not the full malicious artifact, so file provenance and parent-child execution history matter as much as the visible shortcut.
Removal, hardening, and recovery after abuse
Remediation means removing the persistence object and the payload it launches, then checking whether the same actor established another autostart path. It is common to find startup-folder persistence alongside scheduled tasks, registry run keys, or login scripts, so a narrow cleanup can leave the intrusion intact.
Hardening focuses on reducing write access to startup locations, limiting what can run from user-writable paths, and using application control or endpoint monitoring to flag unexpected autostart material. On shared or high-value endpoints, logon-time execution should be treated as a control point, not just a convenience feature.
After removal, validate that the host no longer executes the suspicious item on logon and that no related credentials, tokens, or session material were reused by the intruder to regain access. If the startup item was only one stage in a larger compromise, the cleanup is incomplete until the original access path is understood and closed.
What this technique means for incident response
For incident responders, startup-folder persistence is a strong reminder that persistence can be mundane. The technique is often chosen precisely because it does not look exotic, yet it can provide durable access with very little noise if defenders do not inspect logon autostarts.
It also matters because its simplicity can make it a reliable indicator of commodity malware or post-exploitation tooling. When you see it, the response should include both local cleanup and a wider review of user execution context, recent downloads, and any additional mechanisms that may have been planted to survive the same event.
If the host was part of a larger intrusion set, correlate the startup artifact with authentication events, lateral movement, and any evidence of credential theft or token abuse. The persistence mechanism itself is simple, but it often points to a broader compromise lifecycle that extends well beyond one folder entry.
Risk and Threat Considerations
Startup-folder persistence is risky because it turns a normal sign-in event into an attacker-controlled execution opportunity. The weakness is especially relevant on user-writable systems, where a low-privilege foothold can survive reboots without needing deeper system compromise.
Failure mechanism: An attacker drops a shortcut or script into a startup path, then relies on logon to trigger execution repeatedly. That mechanism is effective because the operating system treats the item as legitimate startup content unless defenders inspect the folder and its execution chain.
Impact: The host can repeatedly relaunch malware, preserve access after reboot, and support further abuse such as credential theft, internal reconnaissance, or reentry after partial cleanup.
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, CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1547 — Boot or Logon Autostart Execution | Startup folders are a logon autostart persistence technique in ATT&CK. |
| Recommendation — Map startup-folder artifacts to T1547 and hunt for related autostart persistence. | ||
| NIST SP 800-53 Rev 5 | CM-7 — Least Functionality | Restricting what can execute from user-writable autostart paths reduces abuse. |
| Recommendation — Enforce least functionality to block unauthorized startup-folder execution paths. | ||
| CIS Controls v8 | CIS-9 — Email and Web Browser Protections | Browser-delivered malware commonly seeds user-context persistence that startup folders can launch. |
| CIS-10 — Malware Defenses | Detection and blocking of suspicious autostart artifacts directly supports this threat. | |
| Recommendation — Use CIS-9 to reduce initial malware delivery that later plants startup persistence. Apply malware defenses to detect and quarantine suspicious startup-folder payloads. | ||
| NIST CSF 2.0 | DE.CM-01 — Networks and systems are monitored to find anomalies, indicators of compromise, and other potentially adverse events | Autostart entries should be monitored for anomalous additions and execution. |
| Recommendation — Monitor autostart locations for unexpected changes and execution on logon. | ||
Practitioner Guidance
What to watch for: Treat any unapproved startup-folder entry as an execution event, not just a file. The most useful judgement is whether the item is expected for that user and whether it launches known software, a benign admin tool, or an opaque script or binary from a writable location.
Governance implication: Ownership of startup paths should be part of endpoint hardening and response playbooks. Teams that manage Windows endpoints should define who can add logon autostarts, how those entries are reviewed, and what evidence is required before an item is allowed to remain.
Practitioner takeaway: Startup-folder persistence is simple enough that it is often missed during cleanup, so verification after removal matters as much as the initial delete.
Related resources from NHI Mgmt Group
- How do you detect startup folder persistence on Windows?
- What breaks when package install hooks or startup hooks are used as persistence mechanisms in enterprise environments?
- What breaks when malicious Python packages install persistence through cron, .pth files, and shell startup hooks?
- How should security teams reduce the risk of Python startup hooks being used for persistence?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 31, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org