{"id":265,"date":"2024-03-18T22:54:46","date_gmt":"2024-03-18T22:54:46","guid":{"rendered":"https:\/\/fin3ss3g0d.net\/?p=265"},"modified":"2024-03-26T16:20:52","modified_gmt":"2024-03-26T16:20:52","slug":"weaponizing-windows-thread-pool-apis-proxying-dll-loads","status":"publish","type":"post","link":"https:\/\/fin3ss3g0d.net\/index.php\/2024\/03\/18\/weaponizing-windows-thread-pool-apis-proxying-dll-loads\/","title":{"rendered":"Weaponizing Windows Thread Pool APIs: Proxying DLL Loads Using I\/O Completion Callbacks"},"content":{"rendered":"\t\t
\n\t\t\t\t
\n\t\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

In today’s blog, we are going to be covering the topic of proxying DLL loads using the Windows thread pool API with C++\/assembly. This specific example is going to use an I\/O completion callback and is a complementary article for my GitHub repository here<\/a>. Before we jump in, let me introduce some background information.<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t

\n\t\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t

Background<\/h2>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t
\n\t\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

Chetan Nayak<\/a> has covered this topic in depth here<\/a> and will serve as the inspiration behind this research. Getting to the core of what this research is really about, we have to imagine the situation where we have a payload in a position independent format that will ultimately load DLLs. When we are loading a shellcode, we must allocate a region of memory that is RX\/RWX. Better OPSEC would be to use a RX region. Nonetheless, if we were to load these DLLs using a standard function call such as LoadLibraryA <\/em>there will be a call<\/em> assembly instruction executed to invoke LoadLibraryA<\/em>. This would place the return address of the caller on the stack and would originate from a RX region of memory (our shellcode). Some of you may be wondering, so what? What is the problem here?<\/p>\n

The problem is an EDR can hook DLL loading functions such as LoadLibraryA<\/em> then examine the stack to determine the return address of the caller, which would point back to your RX shellcode region. It is also going to scan this memory region for anything malicious and against known payload signatures which can result in you getting caught – simply from loading specific DLLs in this way. So, you have unhooked a given DLL containing the DLL loading function, you should be fine right? This is not the only thing you have to be worried about, remember those very annoying things called kernel callbacks? There is a callback named PsSetLoadImageNotifyRoutine(Ex)<\/em> <\/em>allowing EDRs to register a callback function that gets called every time a DLL gets loaded in a process. Once the EDR examines the stack after the callback gets triggered, it can get the return address of the caller who loaded the DLL and examine this memory region the same as I mentioned before. In comes proxy DLL loading to address these OPSEC issues.<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t

\n\t\t\t\t
\n\t\t\t\t\t

The Windows Thread Pool API<\/h2>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

The Windows Thread Pool API provides a high-level abstraction for managing a set of worker threads that can be used to perform various asynchronous tasks or work items. This API simplifies the management of thread resources within applications, allowing developers to focus on application logic rather than the complexities of thread management, synchronization, and concurrency control. The API is part of the Windows operating system, and it enables efficient execution of callbacks on worker threads drawn from a pool managed by the system.<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t

\n\t\t\t\t
\n\t\t\t\t\t

Why Certain Callback Functions Exist<\/h3>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

  1. Work Item Callbacks<\/strong>: These functions are executed when a work item is processed by a worker thread. They encapsulate the task or computation that needs to be performed asynchronously, allowing the application to offload work from the main thread and improve responsiveness or throughput.<\/p><\/li>

  2. Timer Callbacks<\/strong>: Timer callbacks are executed when a timer expires. This is useful for periodic updates, maintenance tasks, or delayed execution of code without blocking a thread by sleeping.<\/p><\/li>

  3. I\/O Completion Callbacks<\/strong>: These functions are executed upon the completion of asynchronous I\/O operations. They allow applications to initiate I\/O operations without blocking and to process the results asynchronously, which is critical for maintaining high performance in I\/O-intensive applications.<\/p><\/li>

  4. Wait Callbacks<\/strong>: Wait callbacks are executed when a wait object (such as an event or mutex) becomes signaled. This mechanism is used to asynchronously wait for events or conditions without blocking a worker thread, facilitating synchronization among threads or reacting to external events.<\/p><\/li><\/ol>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t

    \n\t\t\t\t
    \n\t\t\t\t\t

    You Complete Me<\/h2>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
    \n\t\t\t\t
    \n\t\t\t\t\t\t\t\t\t

    As I previously mentioned, there are multiple callbacks that exist. The example I am sharing with you is going to be an I\/O completion callback example. To utilize an I\/O completion callback with the Windows Thread Pool API effectively, you essentially need to create a thread pool I\/O object via CreateThreadpoolIo<\/em>, associating it with a file handle that supports overlapped I\/O operations. This setup allows for the execution of asynchronous I\/O operations, such as file reads or writes, in a manner that does not block the executing thread. The key to this process is the OVERLAPPED<\/em> structure, which the system uses to track the progress of these operations. When initiating any asynchronous I\/O, you must first call StartThreadpoolIo<\/em>\u00a0to prepare the thread pool for the incoming operation, ensuring the system is ready to handle the completion callback properly.<\/p>

    Your callback function, defined to match the thread pool API\u2019s expectations, will be invoked upon the completion of the I\/O operation. This function will receive details about the operation, including the outcome and the number of bytes transferred, allowing for any necessary post-operation processing. After the operations and their associated callbacks have been completed, cleaning up resources by closing the thread pool I\/O object and any open file handles is essential for resource management and to prevent leaks.<\/p>

    In summary, leveraging the Windows Thread Pool API for I\/O completion callbacks involves preparing for asynchronous operations with a properly configured file handle and OVERLAPPED<\/em> structure, managing the lifecycle of the operation with StartThreadpoolIo<\/em> and CloseThreadpoolIo<\/em>, and handling the results in a predefined callback function. This approach facilitates efficient, non-blocking I\/O operations within Windows applications.<\/p>

    Now that we know what is required, let’s talk about the implementation. As I previously mentioned, the code for this example is in a GitHub repository of mine here<\/a>, but the C++ code is as follows:<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t

    \n\t\t\t\t\t
    \n\t\t\t\t
    \n\t\t\t\t
    \n\t\t\t\t\t\r\n