4

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?

2 Answers 2

6

TLDR: No, no and no.

You have several questions hiding there in your post:

  1. Is is possible to inject a DLL into each and every process?
  2. If it is possible, can the following methods do that:
    1. SetWindowsHookEx?
    2. AppInit_Dlls?

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".

SetWindowsHookEx and AppInit_Dlls

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:

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:

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 smss.exe, csrss.exe, 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 (SetWindowsHookEx, AppInit_Dlls, or something more robust that doesn't depend on user32.dll).

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 ProcessSignaturePolicy.

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:

3

DLL injections is a big subject, but to answer your two specific questions:

  1. Yes, SetwindowsHookEx can inject to all currently running processes. This is done by providing the value of zero (0) to the dwThreadId parameter.
  2. Yes, generally AppInit_DLLs works 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_DLLs controls 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_DLLs is automatically disabled (enable with the LoadAppInit_DLLs registry value) on machines with secure boot.

EDIT:

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.

4
  • 4
    BTW, AppInit_DLLs only works if the process loads user32.dll.
    – Igor Skochinsky
    Sep 11, 2017 at 16:37
  • 3
    The PROCESS_CREATION_MITIGATION_POLICY_EXTENSION_POINT_DISABLE_ALWAYS_ON mitigation policy disables both AppInit_Dlls and global hooks.
    – conio
    Sep 11, 2017 at 16:41
  • 2
    Also, starting with Windows 8, AppInit_Dlls are disabled by default, regardless of signing, when secure boot is enabled. See AppInit DLLs and Secure Boot. You probably don't see this on VMs (unless you use Hyper-V), but real machines have Secure Boot enabled by default.
    – conio
    Sep 11, 2017 at 16:43
  • 1
    Thanks, Added a paragraph to note there are many caveats, that those techniques are discouraged and refer to the comments for additional forewarnings.
    – NirIzr
    Sep 11, 2017 at 16:57

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.