Startup Folder Persistence

Every item placed in a Startup folder is launched by Explorer when the corresponding user logs on. There is a per-user folder and an all-users folder; writing to the per-user one requires no special privileges, which is why low-sophistication commodity malware leans on it heavily. The dropped item can be the payload executable itself, a script, or — most commonly — a .lnk shortcut that points to the payload elsewhere on disk.

Because it is purely file-based, this technique leaves no registry autorun value, but it is also one of the most visible to a defender: the folders are well known, small, and almost always near-empty on a clean system.

How it works

The two Startup folders are:

Per-user:  %AppData%\Microsoft\Windows\Start Menu\Programs\Startup
All-users: %ProgramData%\Microsoft\Windows\Start Menu\Programs\StartUp

Their true paths are resolved from the registry "Shell Folders" values (Startup / Common Startup), which attackers occasionally repoint to a different directory to evade folder-only inspection:

HKCU\...\CurrentVersion\Explorer\User Shell Folders → "Startup"
HKLM\...\CurrentVersion\Explorer\User Shell Folders → "Common Startup"

A dropper typically writes a shortcut such as OneDrive.lnk whose target is a hidden payload:

File:   ...\Startup\OneDrive.lnk
Target: C:\Users\Public\update\svchost.exe

Malicious .lnk files are notable because they embed the target path, arguments, working directory, and sometimes the machine name and MAC address of the system where they were built — valuable for the analyst.

Detection & analysis

Static analysis:

• List both Startup folders directly; on a clean system they are nearly empty, so any executable, script, or unexpected shortcut warrants inspection. Autoruns ("Logon" tab) shows Startup-folder items alongside Run keys and resolves shortcut targets.
• Parse suspicious .lnk files with LECmd or a shell-link parser to extract the target path, arguments, and embedded build-host artifacts (MAC address, volume serial, creation timestamps) for attribution and scoping.
• Check the User Shell Folders registry values to confirm the Startup path has not been redirected away from the default location.

Dynamic analysis:

• Run the sample under Procmon filtered on Operation is CreateFile and Path contains \Startup to capture the dropped filename and content as it is written.
• Sysmon Event ID 11 (FileCreate) records new files in the Startup directories with the writing process; at the next logon, Event ID 1 shows explorer.exe launching the item.

Detection rule hint:

Alert on any file creation in a Startup folder by a process other than a trusted installer, and on .lnk files whose target resolves to a user-writable directory (%Temp%, %AppData%, %Public%) or to a script interpreter. Also monitor User Shell Folders "Startup"/"Common Startup" value changes, which indicate folder redirection.