Detect it by monitoring the user and common system startup folders for new or changed executables, scripts, or shortcuts. Alert when files appear in those locations without an approved software installation or administrative change. Also inspect the parent process that created the file, because persistence commonly arrives through a dropper, script, or post-compromise tooling.
What startup folder persistence means on Windows
startup folder persistence is a logon-based autorun technique: an attacker places a file in a user or machine startup folder so Windows launches it automatically when a user signs in. Detection works best when you treat those folders as high-signal execution paths, then compare file creation events against expected software deployment, admin activity, and known shortcuts or scripts.
The key distinction is between legitimate autostart use and unapproved persistence. Many environments allow a small number of approved shortcuts, updater stubs, or administrative tools in startup paths, so the detection logic should focus on change control, file type, naming, and provenance rather than folder presence alone.
Because this technique often follows initial compromise, parent process context matters. A suspicious file written by a dropper, script host, archive utility, Office process, or remote management tool is more meaningful than the same file written by a trusted installer or endpoint management system.
What to monitor for in startup folders
Monitor both the per-user startup location and the common system startup location for new or modified executables, scripts, and shortcuts. File creation, rename, and replacement events are the core signals, but you should also watch for changes to file metadata such as timestamps, owner, hash, and digital signature status when your tooling supports it.
Pay attention to file types that can execute or redirect execution: .exe, .com, .bat, .cmd, .ps1, .vbs, .js, .lnk, and similar launchable content. A persistence file may be an obvious binary, or it may be a shortcut that points to a payload elsewhere on disk or over the network.
Context improves signal quality. A startup item created immediately after a suspicious login, after privilege escalation, or during a burst of other post-compromise activity is more likely to be malicious than a file added during a known software rollout. For broader persistence tradecraft, the Persistence Techniques Guide helps place startup folders alongside other common autostart mechanisms.
How to separate benign startup items from malicious ones
Start with allowlisting and change baselines. If your environment already expects a small set of startup entries, detection becomes much stronger when any deviation appears outside that baseline. New shortcuts, renamed payloads, or scripts dropped by an unexpected process should be treated as review-worthy until proven otherwise.
Then validate the execution chain. A malicious startup item often points to a payload path in user-writable directories, uses misleading names, or launches through an unusual interpreter. A shortcut that launches PowerShell, cmd.exe, wscript.exe, or a helper binary from an odd location deserves closer inspection than a signed vendor updater in a managed path.
The surrounding process tree is often the fastest way to judge intent. If the parent process is a browser, macro-enabled document, script engine, or remote admin tool, that may indicate initial compromise or follow-on persistence setup. If the parent process is your software deployment tooling, the event may be normal change activity and should be triaged against the approved deployment record.
Risk and Threat Considerations
Startup folder persistence is attractive because it is simple, durable, and easy to hide inside normal user activity. If defenders only alert on service creation, scheduled tasks, or registry autoruns, they can miss a lower-friction path that gives an attacker repeated execution at logon.
Failure mechanism: An attacker gains write access to a startup folder, drops a launchable file or shortcut, and waits for the next logon to trigger execution. The main weakness is poor visibility into file creation provenance and weak separation between approved startup items and unapproved additions.
Impact: The payload can re-establish access after reboot or sign-out, enabling credential theft, lateral movement, and longer dwell time. In some cases the startup item is only the launcher, while the real objective is to keep a second-stage tool alive long enough to exfiltrate data or maintain remote control.
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, NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1547.001 — Boot or Logon Autostart Execution: Startup Folder | Directly covers startup folder persistence on Windows. |
| Recommendation — Hunt for logon autostart artifacts in startup folders and correlate them with parent process lineage. | ||
| CIS Controls v8 | CIS-10 — Malware Defenses | Startup-folder persistence is a malware execution and detection problem. |
| Recommendation — Tune malware defenses to alert on unauthorized startup-folder changes and suspicious launch paths. | ||
| NIST SP 800-53 Rev 5 | CM-5 — Access Restrictions for Change | Startup-folder writes should be governed as controlled system changes. |
| AU-6 — Audit Record Review, Analysis, and Reporting | Detection depends on reviewing file and process audit events for suspicious startup changes. | |
| Recommendation — Restrict who can modify startup locations and alert on unauthorized file creation there. Review file-creation and process-lineage audit data for unexpected startup-folder activity. | ||
| NIST CSF 2.0 | DE.CM-01 — Continuous Monitoring | Ongoing monitoring is required to detect new persistence artifacts in startup paths. |
| Recommendation — Continuously monitor startup folders for unauthorized additions and configuration drift. | ||
Practitioner Guidance
What to verify: Confirm that every startup-folder write maps to an approved installation, endpoint-management action, or documented admin change. If you cannot tie the file to a known change event, treat it as suspicious and inspect the file path, signer, hash, and parent process before deciding it is benign.
Decision rule: If the file is executable, scriptable, or a shortcut created by an unusual parent process, prioritize containment and review over simple file deletion. Deleting the item without understanding how it arrived can leave the foothold mechanism intact or miss a related payload elsewhere on the host.
Practitioner takeaway: The best startup-folder detection is correlation, not folder watching alone, successful programs pair file-change telemetry with process lineage and change-control context so a single logon-triggered artifact can be judged as either ordinary administration or true persistence.
Related resources from NHI Mgmt Group
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 20, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org