Registry Run Keys / Startup Folder

Windows offers several built-in ways for a program to run automatically at logon, and the registry Run keys (and their older sibling, the Startup folder) are the simplest of them. An installer, an updater, a chat client, a cloud-sync tool: legitimate software adds itself to one of these locations constantly, since it's the standard, supported way to say "launch me every time this user logs in."

That same mechanism, once written, doesn't care who wrote it or why. A Run key entry pointing at malware behaves identically to one pointing at a legitimate app: it runs, silently, at every logon, for as long as the entry survives.

Once an attacker has code running on a host, even briefly, writing a Run key (or dropping a shortcut into the Startup folder) turns that momentary access into something that outlives the current session. The next time the user logs in, or the machine restarts, the referenced program runs again on its own, with no further action needed from the attacker.

This is a low-effort, high-reliability technique precisely because it uses an ordinary, well-documented Windows feature rather than anything exotic. It's often paired with other persistence mechanisms rather than relied on alone, since Run keys are also one of the first places a defender or a piece of endpoint software will look.

Data source: registry value-set records (Sysmon Event ID 13) carrying the hive, value data, account and process GUID, which joins to process-creation records for the entry at logon

{
  "host": {
    "name": "wkstn-example"
  },
  "event": {
    "code": "13",
    "action": "Registry value set"
  },
  "process": {
    "name": "reg.exe"
  },
  "registry": {
    "data": {
      "strings": [
        "C:\\Users\\Public\\Updater.cmd"
      ]
    },
    "path": "HKU\\S-1-5-21-...\\Software\\Microsoft\\Windows\\CurrentVersion\\Run\\Updater"
  }
}

Prebuilt Elastic rule: Startup or Run Key Registry Modification

Filter registry-write events against the known Run/RunOnce paths, then read the actual value written, not just the fact that a write happened. A path pointing at a well-known, signed application in its expected install location reads very differently from one pointing at a script interpreter, a temp directory, or an unsigned binary with a generic name. A value-set proves the entry was armed, not that it ran; the later process-creation event whose parent is the logon shell proves execution. Sysmon spells the user hive HKU where rules written for other sensors expect HKEY_USERS, so check the spelling before trusting a zero.

One detail worth knowing specifically, since it's easy to get wrong: a process running as SYSTEM that writes an HKCU-style Run path does not write into the actual logged-on user's registry hive. It lands in HKU\.DEFAULT instead, a hive no real user's logon session ever reads. Practically, that cuts two ways for a hunter. First, a Run entry sitting in .DEFAULT is functionally inert as persistence, since nothing will ever execute it on the next logon, which is itself a tell that whoever wrote it didn't fully understand the mechanism they were using. Second, and more useful: the writing process's own user context doesn't tell you whose persistence this actually is, so treat the writing principal and the SID of the hive actually written as two separate, independent attribution facts rather than assuming they're the same thing.

This is one of the noisiest legitimate mechanisms on a Windows host. Installers, updaters, and any application offering a "start with Windows" option all write here as a normal part of installation, and this happens constantly across a real fleet.

The distinguishing signal is the actual target, not the fact that a write occurred: a known, signed, expected application writing to its own standard install path is routine. An unfamiliar or unsigned binary, a script interpreter being pointed at an unusual file, or an entry written by a process with no obvious relationship to what it's launching are all worth real attention. Volume also matters: a host that suddenly gains several new Run entries in a short window is a different story than one gaining its usual one or two over months.

• MITRE ATT&CK T1547.001: Registry Run Keys / Startup Folder
• Elastic Security: Startup or Run Key Registry Modification

1 scenario in this catalog covers T1547.001. We don't name it — identifying the technique is part of what a scenario grades. Explore the dashboard →