Startup-folder persistence

Expanded Definition

Startup-folder persistence is a living-off-the-land persistence technique that abuses a standard Windows logon mechanism rather than introducing an obviously malicious service or driver. Attackers place a shortcut, script, or executable in a per-user or shared Startup folder so the payload launches automatically when the user signs in. Because the mechanism is native to the operating system, it can blend into ordinary admin activity unless defenders monitor both the file path and the process lineage that created the entry.

Definitions vary slightly across vendor write-ups, especially on whether a shortcut that launches another binary should be treated separately from direct executable placement, but the security meaning is consistent: an attacker is trying to survive reboots and re-logons through user startup execution. For defenders, the distinction matters because the control is not just “look for malware,” but “look for unauthorised changes to startup execution points” and correlate them with user context and installation behavior. NIST guidance on file, process, and configuration monitoring is a useful anchor for this kind of detection discipline, including NIST SP 800-53 Rev 5 Security and Privacy Controls.

The most common misapplication is treating all Startup folder entries as harmless noise, which occurs when defenders whitelist the folder path without validating who created the file, what it launches, and whether the entry matches approved software deployment.

Examples and Use Cases

Implementing detections for Startup-folder persistence rigorously often introduces endpoint telemetry and triage overhead, requiring organisations to weigh simpler filtering against the cost of investigating legitimate software installers and admin scripts.

• A phish compromises a user account and drops a shortcut into the user’s Startup folder so a stager runs on the next login.
• A malicious installer places a signed-looking helper binary in a roaming profile’s Startup path to maintain access across sessions.
• An adversary uses a script in the Startup folder to launch PowerShell and retrieve the next payload after each logon.
• A defender tests detection by creating a benign startup entry and validating that EDR records the file creation event, the creator process, and the destination path.
• A helpdesk workflow unintentionally creates a startup item, illustrating why change control and allowlisting must be paired with monitoring.

For Windows environments, these patterns should be reviewed alongside broader endpoint hardening and log collection practices described in NIST SP 800-53 Rev 5 Security and Privacy Controls, especially where configuration baselines and auditability are expected.

Why It Matters for Security Teams

Startup-folder persistence matters because it converts a single foothold into recurring access with very little attacker effort. If defenders only hunt for suspicious services, scheduled tasks, or registry run keys, they can miss a persistence path that appears routine to the operating system and to users. That gap is especially important in environments with weak endpoint logging, roaming profiles, or inconsistent software deployment controls.

For security teams, the core challenge is to treat startup execution as a monitored control point, not a file system convenience. This means correlating file creation events, user logon behavior, parent process data, and approved software change records. It also intersects with identity governance: an attacker who controls a user account can weaponise that account’s normal logon experience to maintain presence without needing higher privileges. The relevant lesson aligns with the access and monitoring emphasis in NIST SP 800-53 Rev 5 Security and Privacy Controls and the broader detection logic expected in mature endpoint operations.

Organisations typically encounter the operational burden of startup-folder persistence only after an incident review reveals repeated re-entry through a user logon path, at which point the control becomes operationally unavoidable to address.

Related resources from NHI Mgmt Group

• When does malware persistence become an NHI governance issue?
• How do security teams know if persistence has been established on a compromised AI node?
• Known Folder Move
• MFA persistence