DLL injection

Approaches on Microsoft Windows

There are multiple ways on Microsoft Windows to force a process to load and execute code in a DLL that the authors did not intend:

• DLLs listed in the registry entry HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Windows\AppInit_DLLs are loaded into every process that loads User32.dll during the initial call of that DLL. Beginning with Windows Vista, AppInit_DLLs are disabled by default. Beginning with Windows 7, the AppInit_DLL infrastructure supports code signing. Starting with Windows 8, the entire AppInit_DLL functionality is disabled when Secure Boot is enabled, regardless of code signing or registry settings.
• DLLs listed under the registry key HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\AppCertDLLs are loaded into every process that calls the Win32 API functions CreateProcess, CreateProcessAsUser, CreateProcessWithLogonW, CreateProcessWithTokenW and WinExec. That is the right way to use legal DLL injection on current version of Windows - Windows 10. DLL must be signed by a valid certificate.
• Process manipulation functions such as CreateRemoteThread or code injection techniques such as AtomBombing, can be used to inject a DLL into a program after it has started.
  1. Open a handle to the target process. This can be done by spawning the process or by keying off something created by that process that is known to exist – for instance, a window with a predictable title, or by obtaining a list of running processes and scanning for the target executable's filename.
  2. Allocate some memory in the target process, and the name of the DLL to be injected is written to it.

     This step can be skipped if a suitable DLL name is already available in the target process. For example, if a process links to User32.dll, GDI32.dll, Kernel32.dll or any other library whose name ends in 32.dll, it would be possible to load a library named 32.dll. This technique has in the past been demonstrated to be effective against a method of guarding processes against DLL injection.

  3. Create a new thread in the target process with the thread's start address set to be the address of LoadLibrary and the argument set to the address of the string just uploaded into the target.

     Instead of writing the name of a DLL-to-load to the target and starting the new thread at LoadLibrary, one can write the code-to-be-executed to the target and start the thread at that code.

  4. The operating system then calls the initialization routine of the injected DLL.

  Note that without precautions, this approach can be detected by the target process due to the DLL_THREAD_ATTACH notifications sent to every loaded module as a thread starts.

• Windows hooking calls such as SetWindowsHookEx.
• Use the SuspendThread or NtSuspendThread function to suspend all threads, and then use SetThreadContext or NtSetContextThread function to modify an existing thread's context in the application to execute injected code, that in turn could load a DLL.
• Exploit design limitations in Windows and applications that call the LoadLibrary or LoadLibraryEx function without specifying a full-qualified path to the DLL being loaded.
• Operating system-level shims.
• Substituting an application-specific DLL with a rogue replacement that implements the same function exports as the original.
• Reflective DLLs or DLLs that are able to load themselves. The reflective DLL is copied into memory space of the target process and execution is passed to the entry point of the DLL which then loads itself from memory.