Partying by the pool. Mastering PoolParty process injection techniques

Code injection is an efficient attack technique: malicious code is injected into a third-party process to gain control over it or perform certain actions. Since this operation can be performed not only by a pentester but also by a hacker, any cybersecurity specialist must be proficient in injection techniques to be able to repel such attacks.

Windows Thread Pools

The Windows Thread Pools mechanism significantly simplifies thread management for programmers. Such tasks as asynchronous interaction and performance management are solved under the hood by reusing existing threads, which reduces CPU costs required to create and kill them. Concurrently, Windows Thread Pools solves problems associated with thread queues and zillions of tiny nuances that could easily drive a programmer crazy.

The code that manages thread pools is located mostly in user mode (ntdll.dll), and only a small part of it is located in the kernel; as a result, there is no need to waste resources on frequent context switching between the kernel and user space.

The main elements of Windows Thread Pools are as follows:

• Worker Factory that manages the creation and deletion of new threads; and 
• Work queues:
  • task queue dispatches tasks that are passed to the pool. These tasks can be either fast (i.e. executed within a short time) or longer. The thread pool is scaled automatically; if the number of tasks is large, the pool can create additional threads to cope with the load;
  • I/O completion queue performs tasks related to I/O operations (e.g. file operations or network requests); and 
  • timer queue makes it possible to execute tasks at certain intervals or at a specified time.

From the PoolParty exploitation perspective, the above-listed Thread Pools elements are of utmost interest.

It must be noted that all processes running in a Windows environment use Thread Pools by default. To verify this experimentally, you can launch Process Explorer, select any process, and go to the Handles tab.

As you can see, the svchost.exe process uses Worker Factories, which means that the Thread Pools mechanism is enabled.

To see the PoolParty technique in action, let’s try to attack Worker Factories. But first of all, you must be aware of how are they created.

NtCreateWorkerFactory is an NTAPI function that creates a Thread Pools Worker Factory. Its WorkerProcessHandle and StartRoutine arguments are of special interest.

StartRoutine is a pointer to the code that will be executed by the Worker Factory when a new thread is created; while WorkerProcessHandle is a handle to the process whose context will be used to execute the worker threads. This can be a handle to the current process or another one (distributed processing). Let’s try to modify the StartRoutine code so that it executes your payload, thus, making the factory work for you.

But before you can start modify StartRoutine, some preparations are required.

Capture the target handle

Interaction with Thread Pools elements is implemented via handles. Accordingly, to gain access to the Working Factory of the target process, you have to find its handle and capture it using the WinAPI DuplicateHandle function.

Thread Pools handles are divided into several types. If you need access to a Worker Factory, a handle whose object type is TpWorkerFactory should be used; to access a timer queue, IRTimer; and to access an I/O queue, a handle of the IoCompletion type. Since you are going to attack a Worker Factory, you have to look for the TpWorkerFactory object manager type.

In addition, NTAPI functions NtQueryInformationProcess and NtQueryObject will be required; their addresses can be obtained dynamically from ntdll.dll (FYI: addresses of other NTAPI functions mentioned in this article can be obtained in a similar way).

Next, you get the list of all open handles for the target process using the GetProcessHandleCount function and allocate memory for the PROCESS_HANDLE_SNAPSHOT_INFORMATION and PROCESS_HANDLE_TABLE_ENTRY_INFO structures. Important: some extra memory might be required should the number of handles change afterwards.

To fill the previously allocated memory with information about process handles, you have to call NtQueryInformationProcess with the ProcessHandleInformation argument.

Then you have to capture all process handles stored in processes->NumberOfHandles. To do this, call DuplicateHandle for each handle using NtQueryObject, get information about it contained in the PUBLIC_OBJECT_TYPE_INFORMATION structure, and filter out the suitable handles whose type is TpWorkerFactory.

Now that the required handles are obtained, let’s proceed to the most interesting part: intercepting control by modifying the StartRoutine code.

Modifying StartRoutine

StartRoutine cannot be modified if the Worker Factory has already been created (and, as you understand, this is exactly the case: it has already been created in a third-party process), but you can modify the code it points to! To continue the attack, the following NTAPI functions will be required:

• NtQueryInformationWorkerFactory – to get information about the Worker Factory; and 
• NtSetInformationWorkerFactory – to modify information about the Worker Factory.

Let’s examine their prototypes:

First, you get information about your factory (or more precisely, about above-discussed StartRoutine) by calling NtQueryInformationWorkerFactory with the WorkerFactoryBasicInformation argument. Also, you have to fill in the WORKER_FACTORY_BASIC_INFORMATION structure.

Time has come for the most exciting part – direct modification of StartRoutine:

• using VirtualProtectEx, you change access rights to memory containing StartRoutine to be able to write your payload to this area; and 
• using WriteProcessMemory, you write your payload to memory and restore the initial access rights to this memory area by calling VirtualProtectEx again.

Voila! Your Worker Factory is ‘charged’. Now let’s change the minimum number of threads in the pool because an additional thread has been created. To do this, use the NtSetInformationWorkerFactory function.

The minimum number of threads in the pool was increased to ensure that your payload will be executed. After changing code in the StartRoutine factory, you create a new thread that will execute this code. To make this operation possible, the WorkerFactoryThreadMinimum parameter has to be increased.

Important: this is the key step required to deliver your attack; without it, your payload won’t be executed (or you would have to wait indefinitely without any guarantee).

Importantly, the payload is executed without calling the standard functions used to create threads and processes. This prevents antivirus tools from detecting such attacks: the above-described approach breaks the standard behavior pattern that makes EDR suspicious.

Conclusions

Pentesters can use the PoolParty technique to covertly inject code into highly privileged processes. From a security perspective, the growing popularity of PoolParty necessitates the need to improve monitoring of system calls and enhance control over access rights to system objects. And needless to say, you should always keep your security systems up to date.

This article addressed only one type of PoolParty techniques: attacks on Worker Factories. If necessary, you can attack all three queues used by Windows Thread Pools, although, as practice shows, this approach is slightly less efficient.

Good luck!