AppInit_DLLs.

AppInit_DLLs-Missbrauch (MITRE ATT&CK T1546.010) zielt auf HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Windows\AppInit_DLLs und dessen WOW6432Node-Pendant. Ist LoadAppInit_DLLs auf 1 gesetzt, mappt die Initialisierungsroutine von user32.dll jede in AppInit_DLLs gelistete DLL in jeden Prozess, der user32.dll lädt – also praktisch jede interaktive GUI-Anwendung. Ein einziger Registry-Schreibvorgang liefert somit breite Codeausführung und Persistenz und wirkt eher als „Trigger bei neuem Prozess" denn als einmaliger Autostart.

Die Technik ist alt, aber lehrreich. Sie lieferte den Lademechanismus für das klassische Vanquish-Rootkit, und kommerzielle Software nutzte sie historisch (und unbeholfen): Nvidia und diverse IMEs lieferten AppInit-DLLs aus, weshalb Sicherheitsteams nicht einfach darauf alarmieren können, dass der Wert nicht leer ist. Seit Windows 8 wird der AppInit-Mechanismus bei aktiviertem Secure Boot deaktiviert, sofern nicht jede gelistete DLL codesigniert ist, was seine Reichweite stark reduziert; unter Windows 10/11 mit aktiviertem Secure Boot ist er praktisch tot. Er taucht weiterhin in Legacy-Umgebungen mit Windows 7/Server 2008 sowie auf Hosts auf, bei denen Secure Boot aus Kompatibilitätsgründen deaktiviert wurde.

Abwehr: Secure Boot aktiviert lassen, die Richtlinie „signierte AppInit-DLLs erzwingen" durchsetzen, den Wert mit Sysinternals Autoruns als Baseline erfassen und Registry-Schreibvorgänge auf diese Schlüssel über Sysmon Event ID 13 oder EDR-Telemetrie alarmieren.

flowchart TD
  A[Angreifer mit lokalem Admin] --> W[Schreibt DLL-Pfad in AppInit_DLLs-Schluessel]
  W --> L[Setzt LoadAppInit_DLLs = 1]
  L --> N[Neuer GUI-Prozess startet]
  N --> U[Prozess laedt user32.dll]
  U --> SB{Secure Boot aktiv und DLL unsigniert?}
  SB -->|Ja| BLK[Laden uebersprungen - Technik neutralisiert]
  SB -->|Nein| INJ[Schaedliche DLL in Prozess gemappt]
  INJ --> RUN[Code laeuft in jeder interaktiven App -> Persistenz]
  W -.erkannt.-> DET[Sysmon EID13 / Autoruns-Baseline-Alarme]