Detecting Run Key and Startup Folder Persistence

The Run and RunOnce registry keys and the Startup folder execute a payload every time a user logs on, with no elevated rights needed for the per-user hive. Commodity loaders, stealers and hands-on-keyboard operators all use them first because they are reliable and survive reboots. We can detect them from two telemetry sources: registry value sets (Sysmon Event ID 13) and file creation in the Startup directories (Sysmon Event ID 11).

Signals at a Glance

Registry Run and RunOnce Keys

Every value written under the Run family of keys is a command that will execute at logon. Legitimate installers write them constantly, so the useful question is not whether a Run value was set but what it points to and who wrote it. This Sigma rule keys on the location of the payload and filters common installer writers; extend the filter list from your own baseline.

title: Run Key Set With Suspicious Value Data
logsource:
  product: windows
  category: registry_set
detection:
  selection_key:
    TargetObject|contains:
      - '\Software\Microsoft\Windows\CurrentVersion\Run\'
      - '\Software\Microsoft\Windows\CurrentVersion\RunOnce\'
      - '\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer\Run\'
  selection_data:
    Details|contains:
      - '\AppData\'
      - '\Temp\'
      - '\ProgramData\'
      - '\Users\Public\'
      - 'powershell'
      - 'mshta'
      - 'wscript'
      - 'cscript'
      - 'rundll32'
      - 'cmd /c'
  filter_installers:
    Image|endswith:
      - '\msiexec.exe'
      - '\setup.exe'
  condition: selection_key and selection_data and not filter_installers
level: medium
# tune/validate: per-user apps (Teams, OneDrive, Zoom) legitimately register Run values in AppData.

If you run Microsoft Defender for Endpoint, the same logic works in Advanced Hunting against the registry table, and it lets you pivot straight to the initiating process:

// KQL: Run/RunOnce values that launch from user-writable paths or script hosts
DeviceRegistryEvents
| where ActionType == "RegistryValueSet"
| where RegistryKey has_any (@"\CurrentVersion\Run", @"\CurrentVersion\RunOnce")
| where RegistryValueData matches regex @"(?i)(\\AppData\\|\\Temp\\|\\ProgramData\\|\\Users\\Public\\|powershell|mshta|wscript|cscript|rundll32)"
| where InitiatingProcessFileName !in~ ("msiexec.exe", "OneDriveSetup.exe")
| project Timestamp, DeviceName, InitiatingProcessFileName, InitiatingProcessCommandLine,
          RegistryKey, RegistryValueName, RegistryValueData
| order by Timestamp desc
// tune/validate: add your software-deployment tooling to the exclusion list.

Startup Folder and Neighbouring Keys

The per-user and all-users Startup folders are the file-based twin of the Run key. A shortcut or script dropped there runs at logon without touching the registry, so a Run-key-only detection misses it. Watch file creation in both paths:

title: File Created In Startup Folder
logsource:
  product: windows
  category: file_event
detection:
  selection:
    TargetFilename|contains:
      - '\Microsoft\Windows\Start Menu\Programs\Startup\'
    TargetFilename|endswith:
      - '.lnk'
      - '.bat'
      - '.cmd'
      - '.vbs'
      - '.js'
      - '.exe'
      - '.ps1'
  condition: selection
level: medium
# tune/validate: expect legitimate .lnk drops from installers and VDI profile tooling.

• Cover the neighbours of Run in the same rule family: Winlogon\Shell, Winlogon\Userinit, Policies\Explorer\Run and the RunServices variants all execute at logon.
• Prioritise by writer. A Run value set by reg.exe, powershell.exe or an Office process is far more suspicious than one set by a signed installer.
• Resolve the target. Check whether the file in the Run value exists, is signed, and was created minutes before the key was written.
• Sweep for drift with Autoruns or the osquery startup_items table across the fleet, and diff against a golden baseline weekly.