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 Startup Folder Persistence Means
startup folder persistence is a Windows autorun technique that turns a normal sign-in path into an execution point. By placing a shortcut or script where the operating system loads it automatically, an attacker can make code run every time the user logs on.
This is not a privilege-escalation method by itself. Its value is durability: once the malicious file is in the right startup location, it can reappear after reboot and keep the foothold alive with very little friction. That makes it common in commodity malware, post-compromise tooling, and long-dwell intrusion chains.
How It Works in Windows
The technique relies on user profile startup paths rather than kernel, service, or scheduled-task mechanisms. In practice, an attacker may drop a shortcut, batch file, PowerShell script, or other launcher into a startup folder so Windows executes it when the relevant user signs in.
Because it is tied to logon behavior, the payload may run only in the context of that user session. That still matters: many intrusions do not need immediate admin rights to maintain access, collect data, stage follow-on tooling, or reconnect to command and control once the user returns.
The method is especially attractive because it blends into a legitimate operating-system feature. A startup folder entry can look like an ordinary user artifact unless defenders inspect the actual file, target path, arguments, and parent process that created it.
Why Attackers Use It
persistence mechanism are often about survivability, not sophistication. Startup folder abuse gives an intruder a reliable way to regain execution after reboot without depending on a service install, registry run key modification, or elevated task creation.
It also supports quieter post-compromise activity. If the attacker already has a foothold, a logon-triggered launcher can refresh tooling, relaunch a loader, or restore remote access when the victim signs in, which reduces the need for repeated manual intervention.
For defenders, that means startup folder persistence should be treated as a durable indicator of compromise, not a harmless convenience artifact. In an intrusion, even a small autorun entry can become the anchor that preserves access across days or weeks.
Detection and Defensive Context
Because this technique is straightforward, detection should focus on changes to user startup paths, especially files that were recently created, modified, or renamed. Review the object itself, but also the process lineage that placed it there, since the creation path often exposes the initial intrusion or payload staging step.
Pair file-system monitoring with logon-time execution visibility. A startup item may only be malicious because of what it launches, so defenders need to inspect the command line, referenced script, signed versus unsigned status, and any network activity that follows sign-in.
Defensive depth is stronger when logon persistence is one signal among several. Correlate startup folder changes with suspicious downloads, email attachments, browser-based delivery, or lateral movement so the persistence artifact is interpreted in context rather than as an isolated file event.
Risk and Threat Considerations
Startup folder persistence creates durable exposure because it turns a benign user-logon mechanism into a repeatable execution path for malware. The main risk is not complexity, but reliability: once planted, the payload can survive reboots and re-trigger at the next sign-in, extending dwell time and making cleanup incomplete if the autorun artifact is missed.
Failure mechanism: The attacker abuses a trusted Windows startup location so the malicious script or shortcut runs automatically when the user logs on, preserving execution without needing fresh delivery each time.
Impact: The compromise can persist longer, reestablish tooling after reboot, and keep collecting data or maintaining access from a low-friction entry point that blends into normal user 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 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1547.001 — Boot or Logon Autostart Execution: Registry Run Keys / Startup Folder | Directly covers logon-based persistence via Windows startup paths. |
| Recommendation — Map startup-folder findings to T1547.001 and hunt for related logon persistence artifacts. | ||
| NIST SP 800-53 Rev 5 | SI-4 — System Monitoring | System monitoring supports detecting unauthorized autorun changes and suspicious execution at logon. |
| CM-5 — Access Restrictions for Change | Change restrictions help prevent unauthorized modification of startup locations used for persistence. | |
| AU-6 — Audit Review, Analysis, and Reporting | Audit analysis helps correlate startup-folder changes with the process that created them. | |
| Recommendation — Monitor startup-path changes and logon-triggered execution for unauthorized persistence. Restrict who can modify user startup paths and review unexpected changes promptly. Correlate file creation events with parent processes to identify the persistence source. | ||
| CIS Controls v8 | CIS-8 — Audit Log Management | Audit logs provide the evidence needed to spot unauthorized autorun persistence and related activity. |
| CIS-10 — Malware Defenses | Malware defenses are directly relevant because startup-folder abuse is a common malware persistence method. | |
| CIS-4 — Secure Configuration of Enterprise Assets and Software | Secure configuration reduces exposure from default or weakly governed autorun locations. | |
| Recommendation — Centralize endpoint logs so unauthorized startup-path changes are reviewable and alertable. Detect and quarantine malicious files that attempt to establish logon persistence. Harden endpoint configurations so startup paths are controlled and routinely validated. | ||
Practitioner Guidance
What to watch for: Treat any unexpected file in a startup path as a potential persistence artifact, especially when the referenced target is an unfamiliar script, archive, or command interpreter. A legitimate-looking name is not enough to dismiss it; the launcher path and execution chain matter more than the filename.
Governance implication: Startup locations should be part of standard endpoint hardening and incident response baselines, with clear ownership for review, containment, and removal. If your team only hunts for services and scheduled tasks, you will miss a common low-complexity persistence method.
Related resources from NHI Mgmt Group
- Startup-folder persistence
- 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
Reviewed and updated by the NHIMG editorial team on September 24, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
