Hunting the process that launched from a Run key or the Startup folder

The question we keep coming back to on a triage is not what a process is doing. It is where the process came from. A binary running out of %APPDATA% might be malware or might be a badly packaged line-of-business app, and the behavior alone rarely settles it. What settles it is the launch path: who started this thing, and why does it start every time the user logs in. Autostart persistence is the oldest trick in the Windows book and it keeps working precisely because the launched process wears an ordinary parent. So we hunt the launch, not the payload.

Two places, and two different signals

There are two classic autostart homes and they leave different traces. The registry Run and RunOnce keys, under both HKCU\Software\Microsoft\Windows\CurrentVersion\Run and the matching HKLM hive, hold a command line that Explorer runs at logon. The Startup folder, at %AppData%\Microsoft\Windows\Start Menu\Programs\Startup per user and the %ProgramData% equivalent for all users, holds shortcuts or binaries that Explorer launches the same way. Both map to T1547.001 in ATT&CK. The reason we care about the split is that one is a registry event and one is a file event, and if you only watch process creation you catch the launch but miss the plant that happened hours or days earlier.

Catch the plant: the registry write

The earliest signal is the write that establishes persistence, and Sysmon gives it to you cleanly. Event ID 13 is a registry value set; Event ID 12 covers key create and delete. We hunt EID 13 where the target object lands under a \CurrentVersion\Run or \RunOnce path and the process doing the writing is not a known installer. That last clause is the whole tuning problem, and we will get to it, but the raw hunt is simple: show me every Run-key value set on the estate in the last day, grouped by the writing process. Most of what comes back is software you recognize. The interesting rows are the ones where a script host, a freshly dropped binary, or an Office child process is the one writing autostart.

For the Startup folder, the equivalent is Sysmon Event ID 11, file create, filtered to the two Startup paths. A shortcut or executable being written into a user’s Startup folder by anything other than that user’s own installer activity is worth a look, every time.

Catch the launch: the process at logon

The launch itself is Sysmon Event ID 1. Both Run-key commands and Startup-folder items are executed by explorer.exe, so the tell is a process whose parent is explorer.exe, that appears right around logon, and whose image sits somewhere it should not: a user temp directory, %APPDATA%, %PROGRAMDATA%, a public folder. Explorer legitimately launches plenty of things, so parent alone is nothing. Parent explorer.exe plus an image path outside Program Files plus a logon-adjacent timestamp is a hunt worth running weekly. If you have the command line, and with Sysmon you do, a Run entry pointing at rundll32.exe, mshta.exe, powershell.exe, or regsvr32.exe with arguments is the kind of thing you want surfaced automatically rather than found by accident.

Our setup

We run Sysmon 15 with a tuned config on Windows 11 and Server 2022, shipped by Winlogbeat into an Elastic cluster, and we keep a scheduled Autoruns sweep as a point-in-time cross-check because live telemetry only shows you persistence planted while you were watching. The Sysinternals Autoruns tool enumerates every autostart location on a box in one pass, which is how we catch things that were already there before Sysmon was deployed. If you are still standing up your endpoint pipeline, the Sysmon documentation covers the registry and process-create schemas you will be filtering on.

The false positives are mostly your own software

Here is the honest part: legitimate software loves these keys. Updaters, cloud-sync clients, GPU control panels, chat apps, and half your endpoint agents all write Run entries and drop Startup shortcuts, and installers do it under msiexec.exe or a vendor setup binary. If you alert on every Run-key write you will spend your week acknowledging OneDrive. The tuning that survives contact is to exclude the known installer parents and the known-good image directories, then judge what is left by where the autostart target points. A Run value pointing into Program Files under a signed binary is almost always fine. A Run value pointing at a script in %TEMP% is almost always not. This catches most of the abuse, not all, because a patient operator can drop into a signed-looking path, and that is why the point-in-time Autoruns sweep still earns its place next to the streaming rules.

What we alert on

We do not alert on the raw event on any of these. We alert on the combinations: a non-installer process writing a Run or RunOnce value, a binary appearing in a Startup folder outside normal software deployment, and an Explorer child launching from a user-writable path at logon time. Each one is a lead, not a verdict, and the fastest way to close a lead is the parent-process history. If the thing that wrote the Run key was itself spawned by an Office application or a script host, you are most of the way to an incident. That parent-chain reasoning is the same muscle we use in the abnormal child process detection writeup, and the collection side, which config keys to actually capture so these hunts have data, is covered in the 2026 Sysmon baseline. Get the telemetry right first. The hunt is easy once the events are actually landing.