Module 8: Full Chain, Detection & Impact

All 8 variants at a glance, EDR bypass results, detection strategies, IOCP-based monitoring, and defensive recommendations.

1. All 8 Variants Summary

Here is a comprehensive reference table of every PoolParty variant, its mechanism, and key characteristics:

2. Variant Classification

The 8 variants can be grouped by their approach to achieving execution:

3. EDR Bypass Results

At Black Hat EU 2023, Alon Leviev demonstrated PoolParty against 5 leading EDR products. The results showed a 100% bypass rate across all tested solutions:

4. Why EDRs Missed It

Understanding why existing EDRs failed reveals the gaps in current detection approaches:

5. Detection Strategies

Detecting PoolParty requires moving beyond the traditional execution trigger monitoring model. Here are strategies organized by detection layer:

5.1 IOCP-Based Detection

Since most PoolParty variants go through the IOCP, monitoring IOCP operations is the most direct detection approach:

C++ (Detection Logic)// Monitor NtSetIoCompletion calls targeting cross-process IOCPs
// Detection heuristic:
//
// 1. Track which process owns each IOCP handle
// 2. When NtSetIoCompletion is called, check if the IOCP
//    belongs to a different process
// 3. Cross-process IOCP posting is extremely rare in
//    legitimate software
//
// Alert condition:
// Process A calls NtSetIoCompletion on an IOCP owned by Process B

BOOL IsSupiciousIocpPost(HANDLE IoCompletionHandle,
                          DWORD CallerPid)
{
    DWORD ownerPid = GetIocpOwnerProcess(IoCompletionHandle);
    return (ownerPid != CallerPid && ownerPid != 0);
}

5.2 Handle Duplication Monitoring

C++ (Detection Logic)// Monitor DuplicateHandle calls for IoCompletion and
// TpWorkerFactory object types
//
// Legitimate reasons to duplicate these handles are rare.
// An attacker must duplicate the target's IOCP or Worker
// Factory handle into their process to use PoolParty.

// Track:
// 1. Source process (target being injected)
// 2. Target process (attacker)
// 3. Object type (IoCompletion, TpWorkerFactory)
// 4. Correlation with subsequent NtSetIoCompletion or
//    NtSetInformationWorkerFactory calls

typedef struct _DUPLICATE_HANDLE_EVENT {
    DWORD  SourcePid;
    DWORD  TargetPid;
    USHORT ObjectTypeIndex;  // IoCompletion or TpWorkerFactory
    HANDLE DuplicatedHandle;
} DUPLICATE_HANDLE_EVENT;

5.3 Worker Factory Monitoring

C++ (Detection Logic)// Detect Variant 1: Monitor NtSetInformationWorkerFactory
// with WorkerFactoryBasicInformation class
//
// Alert when:
// 1. The caller is a different process than the factory owner
// 2. The StartRoutine is being changed
// 3. MinimumThreadCount is being increased (forces thread creation)

// ETW provider: Microsoft-Windows-Kernel-Process or
// custom minifilter/callback
BOOL DetectWorkerFactoryModification(
    HANDLE WorkerFactory,
    DWORD CallerPid,
    WORKER_FACTORY_INFO_CLASS InfoClass)
{
    DWORD ownerPid = GetWorkerFactoryOwner(WorkerFactory);
    if (CallerPid != ownerPid &&
        (InfoClass == WorkerFactoryBasicInformation ||
         InfoClass == WorkerFactoryThreadMinimum))
    {
        return TRUE;  // Suspicious cross-process modification
    }
    return FALSE;
}

5.4 ETW-Based Detection

5.5 Memory Analysis

C++ (Detection Logic)// Periodic scan of thread pool structures for anomalies:
//
// 1. Walk TP_POOL task queues and verify all callback
//    pointers reference known module address ranges
//
// 2. Check TP_WORK/TP_TIMER/TP_WAIT callback pointers
//    against loaded module ranges
//
// 3. A callback pointing to unbacked executable memory
//    (not within any loaded DLL) is highly suspicious

BOOL IsCallbackSuspicious(PVOID CallbackAddr, HANDLE hProcess)
{
    // Check if the callback address falls within any
    // loaded module's address range
    HMODULE modules[1024];
    DWORD needed;
    EnumProcessModulesEx(hProcess, modules, sizeof(modules),
                         &needed, LIST_MODULES_ALL);

    for (DWORD i = 0; i < needed / sizeof(HMODULE); i++) {
        MODULEINFO modInfo;
        GetModuleInformation(hProcess, modules[i],
                           &modInfo, sizeof(modInfo));
        PVOID base = modInfo.lpBaseOfDll;
        PVOID end = (PBYTE)base + modInfo.SizeOfImage;

        if (CallbackAddr >= base && CallbackAddr < end)
            return FALSE;  // Within a known module
    }

    return TRUE;  // Points to unbacked memory - suspicious
}

6. Defensive Recommendations

7. Impact on the Security Landscape

PoolParty’s contribution to offensive security extends beyond the 8 specific variants:

8. Beyond PoolParty: Future Research Directions

PoolParty opens several research directions for both offensive and defensive security:

• Other internal dispatch mechanisms — Windows has many internal callback systems (DPC, APC, registered waits, power callbacks) that may be similarly exploitable
• Kernel thread pool — the kernel-mode thread pool (ExQueueWorkItem) is a potential target for kernel-level injection
• Cross-session injection — using thread pool techniques to inject across session boundaries
• Detection via hardware — Intel CET and hardware-based call stack verification may detect anomalous thread pool callbacks
• ThreadlessInject integration — combining PoolParty with CCob’s ThreadlessInject for hook-based callback triggering

9. Course Summary