Proxy DLL Loads

A repository with different scripts to demonstrate the DLL-load proxying using undocumented Functions and VEH. This repo is not about teaching you what DLL Load proxying is and how it works, it is greatly explained on this blogpost. Instead, the main focus is on explaining how the DLL be loaded using VEH and on finding undocumented callback functions by reversing the DLLs and creating your own version. Below are the two methods used to proxy DLL Load:

1. VEH

We'll leverage the VEH (Vectored Exception Handler) to modify the context, especially RIP register to take us to the LoadLibraryA, and the RCX to hold the function's argument (module name) of LoadLibraryA. To trigger our exception, VirtualProtect is used to set the page to PAGE_GUARD, thus triggering the STATUS_GUARD_PAGE_VIOLATION.

2. Tp* Functions

Hunting for undocumented functions

Before getting in directly to reversing the DLLs, we need to first know what to look for. We can start by looking at the Microsoft documentation (MSDN), which provides an excellent example of a custom thread pool, which creates a work item and a thread pool timer. The code alone is also suitable for archiving the execution of LoadLibrary via callback functions, but as already known, the userland functions are prone to hooking. So using their respective function would be a better approach. Looking at the MSDN documentation, the example code uses the following Win32API functions:

CreateThreadpool
SetThreadpoolThreadMaximum
SetThreadpoolThreadMinimum
CreateThreadpoolCleanupGroup
CreateThreadpoolTimer
SetThreadpoolTimer
CloseThreadpoolCleanupGroupMembers

If you use IDA, open kernel32.dll, go to "Exports" and search for the mentioned Win32 APIs, in this case CreateThreadpool. Double-clicking the function redirect us to its dissassembled code:

Through the assembly instructions, we see the TpAllocPool function being executed: call cs:__imp_TpAllocPool

If you repeat the process with the other functions, you will end up with the following functions:

Ntdll!TpAllocPool
Ntdll!TpSetPoolMaxThreads
Ntdll!TpSetPoolMinThreads
Ntdll!TpAllocCleanupGroup
Ntdll!TpAllocTimer
Ntdll!TpSetTimer
Ntdll!TpReleaseCleanupGroupMembers

Now you have everything you need to start creating your own version of proxying the DLL Loads. You can look at this documentation from Process Hacker to help you implement the undocumented functions in your code.

Debugging

Set a breakpoint before the assembly code in Callbackstub get's executed. Look at right tab of x64dbg as the registers are being populated.

demo_dbg.mp4

RAX -> pointer to LoadLibraryA
RCX -> library name string 

Result

3. Tp* Functions with Call Gadget

This is the same as the Tp* PoC, but additionally uses call gadgets from AuthenticateFAM_SecureFP.dll to insert arbitrary modules in the call stack during module load, breaking signatures used in detection rules.

Below is the dissassembled part where the call gadget and ret is located:

AuthenticateFAM_SecureFP.dll:
   1800041db:   ff d0                   call   rax
   1800041dd:   33 c0                   xor    eax,eax
   1800041df:   48 83 c4 28             add    rsp,0x28
   1800041e3:   c3                      ret

The use of gadgets was introduced to bypass Elastic callstack detection rule. For more technical information on how this works, please refer to the initial research by @SAERXCIT.

Resources

https://0xdarkvortex.dev/proxying-dll-loads-for-hiding-etwti-stack-tracing/
https://github.com/hlldz/misc/tree/main/proxy_calls
https://processhacker.sourceforge.io/doc/nttp_8h.html#adad18de6710381f08cf36a0fa72e7529
https://offsec.almond.consulting/evading-elastic-callstack-signatures.html

OPSEC Considerations

• Custom implmentation of GetModuleHandleA/GetProcAddress
• Don't use VirtualProtect to trigger the VEH

Detections

https://github.com/elastic/protections-artifacts/blob/main/behavior/rules/defense_evasion_library_loaded_via_a_callback_function.toml