TL;DR

Anything placed in a Windows user's Startup folder runs automatically at logon — under that user, with that user's permissions, with zero UAC prompts. That one-liner is why Startup Folder Abuse (MITRE ATT&CK T1547.001) is the single most common Windows persistence technique in the wild: documented in 300+ malware families and used by 54 distinct APT groups, more than any other persistence method. Here is the exact mechanism, the paths attackers target, and the telemetry that lights it up for defenders.

What's happening

A recent post by @hack_ademy walked through how a compromised Windows user inspects their Startup folder to find suspicious programs. The post is a small demo, but the technique behind it is massive — and still working in 2026. Startup Folder Abuse is not a bug, a 0-day, or a misconfiguration. It is a built-in Windows convenience feature that was never tightened because tightening it would break legitimate apps. Attackers know that.

Why it matters

Three properties make this the attacker's favorite persistence primitive:

  • No privilege escalation needed. The per-user Startup folder and HKCU\...\Run keys are writable by the logged-on user. After a phishing payload lands, the malware already has everything it needs to survive reboot.
  • Trusted by design. Windows does not flag new Startup items. Task Manager shows them cheerfully under the Startup tab, right next to Slack and OneDrive.
  • Rarely monitored. Many organizations audit Scheduled Tasks and Services but leave the per-user Startup folder as a blind spot — precisely where the persistence lives.

Technical facts: exactly where the payloads go

Two folders do the heavy lifting:

  • Per-user (no admin required):
    C:\Users\<User>\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup
  • System-wide (admin required, affects every user):
    C:\ProgramData\Microsoft\Windows\Start Menu\Programs\StartUp

Anything that lands in either — .exe, .lnk, .vbs, .js, .bat, .ps1 — is executed at the next logon for the relevant user. Shortcuts (.lnk) are the most common choice because they hide the real payload path behind a trusted-looking icon.

The closely related Registry run keys (same sub-technique) give attackers a second knob:

Registry keyAdmin?Fires when
HKCU\Software\Microsoft\Windows\CurrentVersion\RunNoCurrent user logs in
HKCU\Software\Microsoft\Windows\CurrentVersion\RunOnceNoNext logon, then deletes itself
HKLM\Software\Microsoft\Windows\CurrentVersion\RunYesAny user logs in
HKLM\Software\Microsoft\Windows\CurrentVersion\RunOnceExYesNext logon, with DLL loading

Comparison with other persistence techniques

TechniqueNeeds admin?StealthTypical detection maturity
Startup folder / HKCU RunNoHighLow in many orgs
Scheduled Tasks (T1053)SometimesMediumMedium
Windows Services (T1543.003)YesMediumHigh
WMI Event Subscription (T1546.003)YesVery highLow

Startup folder wins on the cost-to-stealth ratio: zero privilege cost, works on every modern Windows, produces no new service artifact, and blends in with legitimate autostart apps.

Who actually uses this

Pretty much everyone. MITRE attributes T1547.001 to 54 threat groups and 300+ malware families, including:

  • APT28, APT29, APT32, APT37, APT41 — nation-state crews copying payloads into Startup or modifying Run keys.
  • Lazarus Group — explicitly documented as maintaining persistence by loading malicious code into a Startup folder or adding a Run key.
  • Commodity banking / stealer malware — Emotet, TrickBot, Ryuk, AgentTesla, FormBook.
  • Ransomware crews — Ryuk and Conti pre-stage loaders in Startup so the encryptor relaunches after an incomplete reimage.

How defenders catch it

MITRE is blunt about prevention: "This type of attack cannot be easily mitigated with preventive controls since it is based on the abuse of system features." So the game is detection. The signals that matter:

  • Sysmon Event ID 11 — file creation in either Startup path. Alert on writes from non-installer parents (browsers, Outlook, powershell.exe, wscript.exe, mshta.exe).
  • Sysmon Event ID 13 — registry value writes to ...\CurrentVersion\Run and RunOnce.
  • Windows Event ID 4663 — object-access writes to Startup folders (needs a SACL on the folder).
  • Windows Event ID 4657 — registry value modification (needs Audit Registry enabled).
  • Windows Event ID 4688 — process creation when the staged binary launches at next logon. Pair with parent-process = explorer.exe spawning an unsigned binary out of %APPDATA%.
  • PowerShell 4104 — script-block logging for New-ItemProperty HKCU:\...\Run patterns.

Ready-made content exists in Elastic Detection Rules (Startup Folder Persistence via Unsigned Process), Sigma (Suspicious Startup Folder Persistence), and Splunk ESCU. Turn them on.

Limitations & user self-check

You can inspect your own Startup folder in one line. Press Win+R, type shell:startup, enter — File Explorer opens the per-user folder. Or, in PowerShell:

Get-ChildItem "$env:APPDATA\Microsoft\Windows\Start Menu\Programs\Startup"
Get-ItemProperty "HKCU:\Software\Microsoft\Windows\CurrentVersion\Run"

Anything that does not match software you actually installed — especially shortcuts pointing into %APPDATA%, %TEMP%, or user-profile subfolders — is worth investigating. For enterprise defenders, baseline the legit entries per device class and alert on deltas.

What's next

T1547.001 is not going away. It is older than Windows Vista, cheaper than any other persistence, and supported by every build of Windows 10 and 11. The correct response is telemetry-first: Sysmon on, FIM on the Startup folders, unsigned-binary-in-Startup alerts wired to the SOC. Treat the Startup folder like a tripwire — because for 54 APT groups, it already is.

Sources: MITRE ATT&CK T1547.001, Nextron Systems, Picus Security, Elastic Detection Rules, @hack_ademy.