How can one go about injection of a DLL into every process? Can
SetwindowsHookEx() do the trick? Does
AppInit_DLLs work as it used to?
TLDR: No, no and no.
You have several questions hiding there in your post:
- Is is possible to inject a DLL into each and every process?
- If it is possible, can the following methods do that:
The answer to the first question is "no".
The answer to both parts of the second question is "no, even if the answer to the first question had been yes".
Let's start from the second question. Both methods only apply to processes that load
user32.dll. So that's already not "every process" which is what you asked.
On top of that is everything I mentioned in the comments to NirIzr's answer:
- Starting with Windows 8
AppInit_Dllsare disabled by default on machines with Secure Boot enabled (i.e. all real-world machines).
- A process can opt-out from both methods by setting the
Process that have
ProcessExtensionPointDisablePolicy set include most Chrome processes (renderer, gpu, ppapi) and a few system processes (like
RuntimeBroker.exe), for example.
I don't think that this is merely a caveat. The question is can you inject into all processes, and the answer is no.
DLL injection and loading in general
But there are other ways to do DLL injection. What about them?
This brings us back to the first question.
Since Windows Vista, some processes are "protected processes" for DRM reasons. See:
- Protected Processes (from Windows Internals 5th edition)
- Inside the Windows Vista Kernel: Part 3 (scroll to "Protected Processes")
To load into these process you must be signed with a special certificate, which you probably don't have.
Since then Microsoft has expanded the protected process infrastructure more and more to include more processes and to allow third-party processes to be protected. See Protecting Anti-Malware Services.
There are different levels of protection, but to load into some of these processes you also have to be signed with a special certificate that you also don't have, and to load into the rest of them you need a certificate that you can't have (since Microsoft doesn't supply it to any third party).
Processes protected in that way are
services.exe, some instances of
svchost.exe as well the processes for any AV that respects itself. You can't inject into those either, regardless of method (
AppInit_Dlls, or something more robust that doesn't depend on
Additionally, another mitigation policy,
ProcessSignaturePolicy, available starting with Windows 10 can prevent loading of DLLs not signed by Microsoft, WHQL or the Windows Store. And unlike being a protected process which requires a certificate from Microsoft, any process can opt-in to
Process that have this mitigation enabled include
WinStore.App.exe (the Windows Store app itself, obviously),
MicrosoftEdgeCP.exe (Store only),
csrss.exe (Microsoft only),
wininit.exe (Microsoft only) and
services.exe (Microsoft only).
In summary: You can't load arbitrary DLLs into many processes, including by calling
LoadLibrary from the program's own legitimate code. You can't inject DLLs into these processes, regardless of the method you use.
If you find a way to do this it would be a major subversion of the Windows 10 security mechanisms and such novelty is more likely to be presented in a professional conference rather than on the SE network.
More links on Windows 8.1 Protected Processes, from Alex Ionescu's blog:
- The Evolution of Protected Processes Part 1: Pass-the-Hash Mitigations in Windows 8.1
- The Evolution of Protected Processes Part 2: Exploit/Jailbreak Mitigations, Unkillable Processes and Protected Services
- Protected Processes Part 3 : Windows PKI Internals (Signing Levels, Scenarios, Root Keys, EKUs & Runtime Signers)
DLL injections is a big subject, but to answer your two specific questions:
SetwindowsHookExcan inject to all currently running processes. This is done by providing the value of zero (
0) to the
- Yes, generally
AppInit_DLLsworks on recent windows versions, however microsoft are working their way towards disabling and heavily limiting its usage. For example, since Windows 7, a registry value called
RequireSignedAppInit_DLLscontrols whether only code-signed DLLs are allowed to load. While the value is set to
0(turned off) for Windows 7, it is on by default on windows 10. Furthermore, in Windows 8 (and above)
AppInit_DLLsis automatically disabled (enable with the
LoadAppInit_DLLsregistry value) on machines with secure boot.
Both of these techniques are being phased out (or completely blocked) by multiple counter-measure features in Windows versions. They're not recommended (actually they are often discouraged by Microsoft itself) for legitimate software (or malware). Users are piling up caveats and restrictions in the comments, but for the sake of clarity and simplicity (and because there're numerous caveats here) I chose to only include a few.