Autostart registry hijack

A registry value that Windows itself consults to decide what code to load was written. Unlike a Run key — which merely starts a program at logon — every value below causes an EXISTING trusted process to load attacker code, which is why they are chosen: the payload never appears as its own autostart entry.

* Winlogon\Shell / Userinit / Notify / Taskman — loaded by winlogon at every interactive logon, before the desktop exists. * Image File Execution Options\<exe>\Debugger — Windows launches the named "debugger" INSTEAD of the program. Setting it on a common binary (sethc.exe, utilman.exe, notepad.exe) is both persistence and, on the accessibility binaries, a pre-logon SYSTEM shell. * SilentProcessExit\<exe>\MonitorProcess with GlobalFlag — runs a chosen program every time the named process exits. Same primitive, different trigger, and far less commonly monitored. * User Shell Folders\Startup — redirects the Startup folder itself, so everything in an attacker-chosen directory runs at logon while the real Startup folder stays empty and innocent. * AppInit_DLLs / AppCertDlls — a DLL injected into (nearly) every process that loads user32. * BootExecute / SetupExecute — runs before Windows has finished starting, ahead of most security tooling. * Winsock Protocol_Catalog9 / NameSpace_Catalog5 — a layered service provider loaded into every process that opens a socket. * Microsoft\NetSh — a helper DLL loaded whenever netsh runs.

• T1547.001Boot or Logon Autostart Execution: Registry Run Keys / Startup Folder· Persistence
• T1546.012Event Triggered Execution: Image File Execution Options Injection· Privilege Escalation
• T1546.009Event Triggered Execution: AppCert DLLs· Persistence
• T1546.010Event Triggered Execution: AppInit DLLs· Persistence
• T1546.015Event Triggered Execution: Component Object Model Hijacking· Persistence

Two of these have real benign traffic. Image File Execution Options is written by genuine debugging setups and by a few application-compatibility shims — and Windows itself writes a GlobalFlag there for its own diagnostics. Some legacy and enterprise software still registers an AppInit_DLLs entry.

To confirm: read Details= for the value written. A path under \Users\, \Temp\, \ProgramData\ or a network share is the finding, and so is cmd.exe/powershell.exe anywhere in these values — nothing legitimate points a Winlogon or IFEO value at a shell. On IFEO, check WHICH executable was targeted: sethc.exe, utilman.exe, osk.exe, magnify.exe and displayswitch.exe are the accessibility binaries reachable from the logon screen, and a Debugger on any of them is a pre-authentication SYSTEM backdoor — treat that as critical and assume the host is fully compromised.

Declarative YAML read by the detection engine — data, never executed. Confidence 80%. Source: rules/windows/autostart_registry_hijack.yaml, licensed under the Apache License 2.0.

id: windows.persistence.autostart_registry_hijack
version: 1.0.0
status: stable
severity: high
confidence: 0.8
platforms: [windows]
mitre_techniques: [T1547.001, T1546.012, T1546.009, T1546.010, T1546.015]
description: |
  A registry value that Windows itself consults to decide what code to load was
  written. Unlike a Run key — which merely starts a program at logon — every value
  below causes an EXISTING trusted process to load attacker code, which is why they
  are chosen: the payload never appears as its own autostart entry.

    * `Winlogon\Shell` / `Userinit` / `Notify` / `Taskman` — loaded by winlogon at
      every interactive logon, before the desktop exists.
    * `Image File Execution Options\<exe>\Debugger` — Windows launches the named
      "debugger" INSTEAD of the program. Setting it on a common binary
      (`sethc.exe`, `utilman.exe`, `notepad.exe`) is both persistence and, on the
      accessibility binaries, a pre-logon SYSTEM shell.
    * `SilentProcessExit\<exe>\MonitorProcess` with `GlobalFlag` — runs a chosen
      program every time the named process exits. Same primitive, different trigger,
      and far less commonly monitored.
    * `User Shell Folders\Startup` — redirects the Startup folder itself, so
      everything in an attacker-chosen directory runs at logon while the real
      Startup folder stays empty and innocent.
    * `AppInit_DLLs` / `AppCertDlls` — a DLL injected into (nearly) every process
      that loads user32.
    * `BootExecute` / `SetupExecute` — runs before Windows has finished starting,
      ahead of most security tooling.
    * Winsock `Protocol_Catalog9` / `NameSpace_Catalog5` — a layered service
      provider loaded into every process that opens a socket.
    * `Microsoft\NetSh` — a helper DLL loaded whenever netsh runs.
match:
  registry_path_contains_any:
    - 'CurrentVersion\Winlogon\Shell'
    - 'CurrentVersion\Winlogon\Userinit'
    - 'CurrentVersion\Winlogon\Taskman'
    - 'CurrentVersion\Winlogon\AppSetup'
    - 'CurrentVersion\Winlogon\Notify\'
    - 'Image File Execution Options\'
    - 'SilentProcessExit\'
    - 'User Shell Folders\Startup'
    - 'User Shell Folders\Common Startup'
    - 'AppInit_DLLs'
    - 'AppCertDlls'
    - 'Control\Session Manager\BootExecute'
    - 'Control\Session Manager\SetupExecute'
    - 'WinSock2\Parameters\Protocol_Catalog9'
    - 'WinSock2\Parameters\NameSpace_Catalog5'
    - 'SOFTWARE\Microsoft\NetSh'
correlation_keys: [hostname, user_name]
false_positive_guidance: |
  Two of these have real benign traffic. `Image File Execution Options` is written
  by genuine debugging setups and by a few application-compatibility shims — and
  Windows itself writes a `GlobalFlag` there for its own diagnostics. Some legacy
  and enterprise software still registers an `AppInit_DLLs` entry.

  To confirm: read `Details=` for the value written. A path under `\Users\`,
  `\Temp\`, `\ProgramData\` or a network share is the finding, and so is
  `cmd.exe`/`powershell.exe` anywhere in these values — nothing legitimate points
  a Winlogon or IFEO value at a shell. On IFEO, check WHICH executable was
  targeted: `sethc.exe`, `utilman.exe`, `osk.exe`, `magnify.exe` and
  `displayswitch.exe` are the accessibility binaries reachable from the logon
  screen, and a Debugger on any of them is a pre-authentication SYSTEM backdoor —
  treat that as critical and assume the host is fully compromised.

• Registry Run Key Persistence via reg.exeSeverity medium
• COM object hijackSeverity high
• Run key modifiedSeverity high
• Startup folder executable writeSeverity high
• WMI event subscriptionSeverity high
• Microsoft 365 Power Automate mail flowSeverity high