AppInit_DLLs
What is AppInit_DLLs?
AppInit_DLLsLegacy Windows persistence technique that abuses a registry value so a specified DLL is loaded into every user-mode process linking user32.dll.
AppInit_DLLs abuse (MITRE ATT&CK T1546.010) targets HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Windows\AppInit_DLLs (and the WOW6432Node twin). When LoadAppInit_DLLs is set to 1, the user32.dll loader maps any DLL listed in AppInit_DLLs into every process that links user32.dll - effectively most interactive applications. Attackers gain broad code execution and persistence with one registry write. Since Windows 8, Secure Boot disables AppInit_DLLs unless the DLL is signed and signature requirements are relaxed, but the technique still appears on legacy or misconfigured hosts. Defenses include keeping Secure Boot enabled, requiring signed AppInit DLLs, baselining the value with Autoruns, and alerting on changes via Sysmon registry events.
● Examples
- 01
Adding a malicious helper DLL path to AppInit_DLLs on a Windows 7 server to log every keystroke across processes.
- 02
Combining AppInit_DLLs with disabled Secure Boot to deploy a userland rootkit.
● Frequently asked questions
What is AppInit_DLLs?
Legacy Windows persistence technique that abuses a registry value so a specified DLL is loaded into every user-mode process linking user32.dll. It belongs to the Attacks & Threats category of cybersecurity.
What does AppInit_DLLs mean?
Legacy Windows persistence technique that abuses a registry value so a specified DLL is loaded into every user-mode process linking user32.dll.
How does AppInit_DLLs work?
AppInit_DLLs abuse (MITRE ATT&CK T1546.010) targets HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Windows\AppInit_DLLs (and the WOW6432Node twin). When LoadAppInit_DLLs is set to 1, the user32.dll loader maps any DLL listed in AppInit_DLLs into every process that links user32.dll - effectively most interactive applications. Attackers gain broad code execution and persistence with one registry write. Since Windows 8, Secure Boot disables AppInit_DLLs unless the DLL is signed and signature requirements are relaxed, but the technique still appears on legacy or misconfigured hosts. Defenses include keeping Secure Boot enabled, requiring signed AppInit DLLs, baselining the value with Autoruns, and alerting on changes via Sysmon registry events.
How do you defend against AppInit_DLLs?
Defences for AppInit_DLLs typically combine technical controls and operational practices, as detailed in the full definition above.
What are other names for AppInit_DLLs?
Common alternative names include: AppInit DLL injection, user32 AppInit persistence.
● Related terms
- attacks№ 331
DLL Hijacking
An attack that abuses Windows DLL search order to make a legitimate program load an attacker-controlled library instead of the intended one.
- attacks№ 200
COM Hijacking
A persistence technique that redirects a Windows Component Object Model CLSID lookup to attacker code, executing it whenever a host process instantiates that object.
- attacks№ 515
IFEO Injection
A persistence and privilege-escalation technique that abuses the Windows Image File Execution Options registry key to run attacker code whenever a target executable launches.
- attacks№ 914
Registry Run Key Persistence
Classic Windows persistence technique that adds an entry under a Run or RunOnce registry key so a binary or script executes every time a user logs on.
- attacks№ 1246
WMI Event Subscription Persistence
Persistence technique that registers a permanent WMI event filter and consumer so attacker code runs whenever a chosen system event occurs.
- attacks№ 610
LD_PRELOAD Hijacking
Linux persistence and library-hijacking technique that uses the LD_PRELOAD environment variable or /etc/ld.so.preload to inject attacker code into dynamically linked processes.