Startup-folder persistence

What startup-folder persistence means in practice

Startup-folder persistence is a logon autostart technique, not an exploit in itself. It works by placing a shortcut or executable in a Windows Startup folder so that normal user logon launches it automatically, blending into ordinary operating-system behaviour and making it easy to overlook without file-system and process telemetry.

Because the persistence point is a standard user-facing location, defenders should treat it as an execution-control problem as much as a malware problem. The key security question is not only whether the file exists, but whether it was created by an expected installer, script, or interactive user action.

How startup-folder persistence is used by attackers

This technique is attractive because it is simple, low-friction, and durable across reboots and logons. An adversary only needs a path that Windows will open at sign-in, then an artefact that points to malicious code or launches it directly. In many environments, that is enough to regain execution after a restart without relying on a more complex persistence chain.

It is also operationally useful for evasion. The folder name and its purpose are legitimate, so defenders may focus on services, scheduled tasks, or registry run keys and miss a startup item unless they are explicitly watching for autostart locations. That is why startup-folder persistence often appears alongside broader boot or logon autostart tradecraft rather than as a standalone novelty.

Detection and verification signals

Detection should centre on the artefact and its creation path. A useful review asks what file was added, where it lives, when it appeared, and which process wrote it. If the item is a shortcut, also inspect the target it invokes, because the visible file may be benign while the linked execution target is not.

Telemetry on logon autostart locations is most useful when combined with parent-process visibility and user context. A newly created item from an office process, script host, archive extractor, or unknown installer deserves more scrutiny than one placed by a trusted software deployment path. Reviewing persistence through the lens of known boot or logon techniques helps analysts separate routine startup entries from suspicious additions.

For broader detection patterns and related autostart tradecraft, see T1547 Boot or Logon Autostart Execution Defensive Guide and the Persistence Techniques Guide.

Containment, removal, and hardening

Removal is usually straightforward once the exact file and launch path are identified, but incident response should also check whether the same actor established additional persistence elsewhere. A startup-folder item may be the visible symptom, not the only foothold. That is why eviction work should be paired with host review, autorun inspection, and a search for related execution paths.

Hardening is mostly about reducing surprise. Limit who can write to startup locations, baseline expected items on managed endpoints, and alert on new additions or unexpected modification times. On heavily monitored systems, the goal is to make startup-folder changes noisy enough that a persistence attempt becomes a detectable event rather than a hidden convenience.

Where the environment uses defensive baselines for autostarts, the same concept should be extended into change control and endpoint telemetry so that legitimate software deployment does not mask malicious persistence.

What this technique means for defenders

Startup-folder persistence is a reminder that attackers often prefer ordinary operating-system features over exotic exploits. If a control only watches for privilege escalation or registry abuse, it can miss a simple file placed in a well-known autostart directory. The defence burden is therefore equal parts prevention, monitoring, and post-execution review.

For a broader operational perspective on identity-driven compromise, logon behaviour, and persistence-linked detections, see the Identity Threat Detection and Response (ITDR) Guide.

Related resources from NHI Mgmt Group

• How do you detect startup folder persistence on Windows?
• Persistence via Startup Folder
• 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?