AppInit_DLLs.

AppInit_DLLs abuse (MITRE ATT&CK T1546.010) targets HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Windows\AppInit_DLLs and its WOW6432Node twin. When LoadAppInit_DLLs is set to 1, the user32.dll initialization routine maps every DLL listed in AppInit_DLLs into any process that loads user32.dll — effectively every interactive GUI application. One registry write therefore yields broad code execution and persistence, executing as a "trigger on new process" rather than a one-shot autostart.

The technique is old but instructive. It provided the loading mechanism for the classic Vanquish rootkit, and commercial software historically (and clumsily) used it — Nvidia and various IMEs shipped AppInit DLLs, which is why security teams cannot simply alert on the value being non-empty. Since Windows 8, when Secure Boot is enabled the AppInit mechanism is disabled unless every listed DLL is code-signed, sharply reducing its reach; on Windows 10/11 with Secure Boot on, it is effectively dead. It still surfaces on legacy Windows 7/Server 2008 estates and on hosts where Secure Boot was disabled for compatibility.

Defences: keep Secure Boot enabled, enforce the "require signed AppInit DLLs" policy, baseline the value with Sysinternals Autoruns, and alert on registry writes to these keys via Sysmon Event ID 13 or EDR telemetry.

flowchart TD
  A[Attacker with local admin] --> W[Write DLL path to AppInit_DLLs key]
  W --> L[Set LoadAppInit_DLLs = 1]
  L --> N[New GUI process starts]
  N --> U[Process loads user32.dll]
  U --> SB{Secure Boot on & DLL unsigned?}
  SB -->|Yes| BLK[Load skipped - technique neutralised]
  SB -->|No| INJ[Malicious DLL mapped into process]
  INJ --> RUN[Code runs in every interactive app -> persistence]
  W -.detected.-> DET[Sysmon EID13 / Autoruns baseline alerts]