Process Injection¶

ID: crt MITRE ATT&CK: T1055.003 - Thread Execution Hijacking

How it works: Allocates memory in the remote process with VirtualAllocEx(PAGE_READWRITE), copies shellcode via WriteProcessMemory, changes protection to PAGE_EXECUTE_READ via VirtualProtectEx, then creates a remote thread at the shellcode address with CreateRemoteThread. All API calls are routed through BeaconGate when enabled.

API Call Chain:

1. VirtualAllocEx(processHandle, PAGE_READWRITE)
2. WriteProcessMemory(processHandle, shellcode)
3. VirtualProtectEx(processHandle, PAGE_EXECUTE_READ)
4. CreateRemoteThread(processHandle, shellcodeAddr)

Forensic Artifacts:

• Sysmon Event 8: CreateRemoteThread detected
• Sysmon Event 10: ProcessAccess with PROCESS_VM_WRITE
• Memory: RW -> RX protection transition in target process
• ETW: Thread creation from unexpected parent process

Limitations: Most monitored technique. Every major EDR product detects CreateRemoteThread from non-standard callers. Use only in lab environments or when detection is not a concern.

Supports InjectByPID: Yes -- opens process by PID, injects, closes handle.

Supports InjectByHandle: Yes -- direct injection with existing process handle.

ID: ntmap MITRE ATT&CK: T1055.012 - Process Hollowing (variant)

How it works: Creates a shared memory section backed by the page file using NtCreateSection, maps a writable view in the beacon process (NtMapViewOfSection with PAGE_READWRITE), copies shellcode to the local view, maps an executable view in the target process (PAGE_EXECUTE_READ), unmaps the local view, then executes via RtlCreateUserThread.

API Call Chain:

1. NtCreateSection(PAGE_EXECUTE_READWRITE) -- section max protection, not page protection
2. NtMapViewOfSection(local, PAGE_READWRITE) -- writable view in beacon
3. memcpy to local view
4. NtMapViewOfSection(remote, PAGE_EXECUTE_READ) -- executable view in target
5. NtUnmapViewOfSection(local) -- cleanup
6. RtlCreateUserThread(remote, shellcodeAddr)

Forensic Artifacts:

• Section object creation (visible in kernel object manager)
• Mapped view in target process (no VirtualAllocEx artifact)
• Thread creation via RtlCreateUserThread (different from CRT in ETW)

Limitations: Section objects may be visible to advanced memory scanners. The section maximum protection is PAGE_EXECUTE_READWRITE (required for the technique), though actual page protections are never RWX.

Supports InjectByPID: Yes. Supports InjectByHandle: Yes.

ID: setthreadctx MITRE ATT&CK: T1055.003 - Thread Execution Hijacking

How it works: Allocates and writes shellcode to the remote process, then finds the main thread of the suspended child process (fork-and-run). Opens the thread, calls GetThreadContext to capture the current register state, modifies RIP to point to the shellcode address, and applies with SetThreadContext. When the caller resumes the thread, it executes shellcode instead of the original entry point.

API Call Chain:

1. VirtualAllocEx + WriteProcessMemory + VirtualProtectEx
2. GetThreadContext(threadHandle, CONTEXT_CONTROL)
3. Set ctx.Rip = shellcodeAddr
4. SetThreadContext(threadHandle, ctx)
5. Caller calls ResumeThread

Forensic Artifacts:

• Memory: RW -> RX transition in target process
• Thread context modification (detectable via ETW)
• No CreateRemoteThread artifact

Limitations: Only works with fork-and-run (requires a suspended main thread). InjectByPID falls back to CRT because hijacking threads in running processes is unreliable -- the thread may hold locks or be in kernel mode.

Supports InjectByPID: Falls back to CRT. Supports InjectByHandle: Yes (fork-and-run only).

ID: queueapc MITRE ATT&CK: T1055.004 - Asynchronous Procedure Call

How it works: Allocates and writes shellcode, finds the main thread of the suspended child process, opens the thread, and queues an APC pointing to the shellcode address via QueueUserAPC. When the caller resumes the thread, the APC fires before the thread's normal entry point -- this is the "early-bird" pattern.

API Call Chain:

1. VirtualAllocEx + WriteProcessMemory + VirtualProtectEx
2. OpenThread(THREAD_SET_CONTEXT)
3. QueueUserAPC(shellcodeAddr, threadHandle)
4. Caller calls ResumeThread -- APC fires first

Forensic Artifacts:

• Memory: RW -> RX transition in target process
• APC queue modification (visible in kernel structures)
• No CreateRemoteThread artifact
• Early-bird: shellcode executes before process entry point

Limitations: Only works reliably with fork-and-run (early-bird pattern). For InjectByPID, the technique falls back to CRT because APC on existing threads requires an alertable wait state (SleepEx, WaitForMultipleObjectsEx), which is unreliable for arbitrary processes.

Supports InjectByPID: Falls back to CRT. Supports InjectByHandle: Yes (fork-and-run only).

ID: rtlthread MITRE ATT&CK: T1055 - Process Injection

How it works: Standard memory allocation and write, then creates a remote thread using RtlCreateUserThread from ntdll instead of CreateRemoteThread from kernel32. This bypasses usermode hooks that EDR products place on kernel32.dll exports.

API Call Chain:

1. VirtualAllocEx + WriteProcessMemory + VirtualProtectEx
2. RtlCreateUserThread(processHandle, shellcodeAddr)

Forensic Artifacts:

• Memory: RW -> RX transition in target process
• Thread creation via NT API (different ETW event from kernel32 CRT)
• Thread start address in remote process memory

Limitations: While it bypasses kernel32 hooks, kernel-level ETW instrumentation still logs the thread creation. Less evasive than techniques that avoid thread creation entirely.

Supports InjectByPID: Yes. Supports InjectByHandle: Yes.

ID: selfinject MITRE ATT&CK: T1055 - Process Injection

How it works: Allocates memory in the current (beacon) process with VirtualAlloc(PAGE_READWRITE), copies shellcode, changes protection to PAGE_EXECUTE_READ, then creates a local thread with CreateThread. When drip-loading staging is enabled, uses DripAlloc for chunked reserve-then-commit allocation to reduce allocation artifacts.

API Call Chain:

1. VirtualAlloc(MEM_COMMIT | MEM_RESERVE, PAGE_READWRITE) -- or DripAlloc if enabled
2. memcpy(shellcode)
3. VirtualProtect(PAGE_EXECUTE_READ) -- or DripProtect
4. CreateThread(shellcodeAddr)

Forensic Artifacts:

• Memory: RW -> RX transition in current process
• New thread creation (visible in ETW)
• No remote process involvement (no Sysmon Event 8/10)

Limitations: Shellcode runs inside the beacon process. If the shellcode crashes, the beacon crashes. Cannot inject into remote processes -- InjectByHandle returns an error, InjectByPID only accepts the current process PID.

Supports InjectByPID: Only if PID matches current process. Supports InjectByHandle: No (returns error).

ID: udrl MITRE ATT&CK: T1620 - Reflective Code Loading

How it works: The operator provides custom reflective loader shellcode via aggressor script (SetUDRL()). The loader is prepended to the beacon payload. During injection, the combined payload (loader + beacon) is written to the target process. The remote thread starts at the loader entry point, which handles its own PE mapping, import resolution, and relocation -- completely bypassing standard LoadLibrary detection.

API Call Chain:

1. Prepend loader shellcode to beacon payload
2. VirtualAllocEx(PAGE_READWRITE) via BeaconGate
3. WriteProcessMemory(loader + beacon) via BeaconGate
4. Track regions in BUD (Beacon User Data) for sleep mask
5. VirtualProtectEx(PAGE_EXECUTE_READ) via BeaconGate
6. CreateRemoteThread(loaderAddr) via BeaconGate

Forensic Artifacts:

• Unbacked executable memory (no corresponding file on disk)
• PE header anomalies (custom loader may omit/modify headers)
• Memory layout differs from standard PE loader
• Operator-controlled: artifacts vary per loader implementation

Limitations: Not registered by default -- only available when the operator provides loader shellcode at runtime via SetUDRL(). The quality and stealth of the loader depends entirely on the operator's implementation. If the loader requires RWX for self-modification, the UseRWX config can be set, but this degrades OPSEC.

Supports InjectByPID: Yes. Supports InjectByHandle: Yes.

ID: obfsetthreadctx MITRE ATT&CK: T1055.003 - Thread Execution Hijacking

How it works: Unlike standard SetThreadContext which hijacks an existing thread, this technique creates a NEW thread at a legitimate function address (e.g., ntdll!RtlUserThreadStart+0x21) using CreateRemoteThread with CREATE_SUSPENDED. The thread start address appears legitimate to EDR tools that analyze thread origins. After creation, GetThreadContext captures the full register state, RIP is modified to point to shellcode, SetThreadContext applies the change, and ResumeThread executes the shellcode.

API Call Chain:

1. VirtualAllocEx + WriteProcessMemory + VirtualProtectEx
2. Resolve ntdll!RtlUserThreadStart+0x21 in remote process
3. CreateRemoteThread(processHandle, legitimateAddr, CREATE_SUSPENDED)
4. GetThreadContext(threadHandle, CONTEXT_FULL)
5. Set ctx.Rip = shellcodeAddr
6. SetThreadContext(threadHandle, ctx)
7. ResumeThread(threadHandle)

Forensic Artifacts:

• Thread created at legitimate image-backed address (harder to detect)
• Memory: RW -> RX transition in target process
• Thread context modification (detectable via ETW)
• CreateRemoteThread call present, but start address appears legitimate

Limitations: Requires ntdll or kernel32 for reliable cross-process address resolution (ASLR is per-boot for system DLLs, so addresses match across processes). Other modules are not supported for the start address.

Supports InjectByPID: Yes. Supports InjectByHandle: Yes.

ID: cloneprocess MITRE ATT&CK: T1055.012 - Process Hollowing (variant)

How it works: Uses RtlCloneUserProcess to create a copy of a target process with a suspended main thread. Shellcode is written into the clone using standard allocation, then a QueueUserAPC call targets the clone's main thread. When ResumeThread is called, the APC fires and shellcode executes in the cloned process. This avoids creating remote threads in existing processes.

API Call Chain:

1. RtlCloneUserProcess(CREATE_SUSPENDED | NO_SYNCHRONIZE)
2. Extract clone process/thread handles
3. VirtualAllocEx + WriteProcessMemory + VirtualProtectEx in clone
4. QueueUserAPC(shellcodeAddr, cloneThread)
5. ResumeThread(cloneThread)

Forensic Artifacts:

• Process clone creation (unusual RtlCloneUserProcess call)
• Memory: RW -> RX transition in cloned process
• APC queue modification on clone's main thread
• No CreateRemoteThread artifact in existing processes

Limitations: Requires Windows 10+ (RtlCloneUserProcess availability). Falls back to CRT on older versions. The cloned process is a copy of the current process, which may be suspicious if the beacon is running as an unusual executable.

Supports InjectByPID: Yes (opens process, then clones). Supports InjectByHandle: Yes.

ID: tpdirect MITRE ATT&CK: T1055 - Process Injection

How it works: Based on the PoolParty research by SafeBreach Labs. Allocates shellcode in the remote process, then creates a fake TP_DIRECT structure with its callback pointer at offset 0x08 pointing to the shellcode address. Both the shellcode (RX) and the TP_DIRECT structure (RW) are written to the target process. A remote thread is created to execute through the thread pool callback path, making execution appear as a legitimate thread pool work item.

API Call Chain:

1. VirtualAllocEx + WriteProcessMemory + VirtualProtectEx (shellcode, RX)
2. Build fake TP_DIRECT structure (callback = shellcode address)
3. VirtualAllocEx(PAGE_READWRITE) for TP_DIRECT structure
4. WriteProcessMemory (TP_DIRECT to target)
5. CreateRemoteThread(shellcodeAddr, tpDirectAddr) -- thread pool dispatch

Forensic Artifacts:

• Memory: RW -> RX transition for shellcode
• Additional RW allocation for fake TP_DIRECT structure
• Remote thread creation targeting thread pool infrastructure
• Thread pool callback execution appears as legitimate worker activity

Limitations: The TP_DIRECT structure layout is version-specific (callback at offset 0x08 on Windows 10/11 x64). May break on future Windows versions if the internal structure layout changes.

Supports InjectByPID: Yes. Supports InjectByHandle: Yes.

ID: earlycascade MITRE ATT&CK: T1055.012 - Process Hollowing (variant)

How it works: Creates a process in a suspended state (CREATE_SUSPENDED | CREATE_NO_WINDOW) and hijacks its initialization path before any DLLs load. At this point, RIP points to RtlUserThreadStart or ntdll!LdrInitializeThunk -- the very first usermode instruction. The technique writes shellcode, modifies RIP via SetThreadContext, and the caller resumes the thread. Shellcode executes in the "early cascade" window before ntdll initialization, DLL loading, TLS callbacks, or any usermode hooks are active.

API Call Chain:

1. VirtualAllocEx + WriteProcessMemory + VirtualProtectEx
2. GetThreadContext(CONTEXT_CONTROL) -- captures RIP before any code executes
3. Set ctx.Rip = shellcodeAddr
4. SetThreadContext(threadHandle, ctx)
5. ResumeThread -- shellcode runs before ntdll init

For InjectByPID, the technique additionally:

1. CreateProcessW(rundll32.exe, CREATE_SUSPENDED | CREATE_NO_WINDOW)
2. Inject via InjectByHandle
3. ResumeThread

Forensic Artifacts:

• Suspended process creation (CREATE_SUSPENDED flag)
• Memory: RW -> RX transition in target process
• Thread context modification before first instruction
• Entry point never executes (distinguishes from normal execution)

Limitations: For InjectByPID, uses rundll32.exe as the default sacrificial process. This can be customized via spawn-to configuration. If injection fails, the suspended process is terminated to avoid orphaned processes.

Supports InjectByPID: Yes (creates new suspended process). Supports InjectByHandle: Yes (fork-and-run).

ID: tpstartroutinestub MITRE ATT&CK: T1055 - Process Injection

How it works: Based on PoolParty variant 7 (SafeBreach Labs). Creates a fake TP_WORK structure whose CleanupGroupMember.Callback pointer (at offset 0x40) points to the shellcode. The Task LIST_ENTRY field (at offset 0x20) is initialized as a self-referencing doubly-linked list to prevent crashes. The structure is written to the target process, and a remote thread is created with the shellcode as the entry point and the TP_WORK pointer as the parameter, simulating how TppWorkerThread dispatches work items through TpStartRoutineStub.

API Call Chain:

1. VirtualAllocEx + WriteProcessMemory + VirtualProtectEx (shellcode, RX)
2. Build fake TP_WORK structure (0x68 bytes):
   • Offset 0x20: Task LIST_ENTRY (self-referencing Flink/Blink)
   • Offset 0x40: CleanupGroupMember.Callback = shellcode address
3. VirtualAllocEx(PAGE_READWRITE) for TP_WORK structure
4. WriteProcessMemory (TP_WORK to target)
5. CreateRemoteThread(shellcodeAddr, tpWorkAddr) -- worker dispatch

Forensic Artifacts:

• Memory: RW -> RX transition for shellcode
• Additional RW allocation for fake TP_WORK structure
• Remote thread creation targeting thread pool infrastructure
• Thread pool work item execution appears as legitimate worker activity

Limitations: The TP_WORK structure layout is version-specific (callback at offset 0x40, task at offset 0x20 on Windows 10/11 x64). Unlike tpdirect which manipulates existing pool structures, this technique creates new work items, which may be detectable by advanced kernel-mode monitoring.

Supports InjectByPID: Yes. Supports InjectByHandle: Yes.

ID: modulestomp MITRE ATT&CK: T1055.001 - Dynamic-link Library Injection (variant)

How it works: Loads a legitimate signed DLL into the remote process via CreateRemoteThread(LoadLibraryW), then overwrites its .text section with shellcode. The result is shellcode backed by MEM_IMAGE memory that appears to reside in a legitimate loaded module. This defeats memory scanners that flag unbacked executable memory.

API Call Chain:

1. Load DLL locally to parse PE header (find .text offset and size)
2. Write DLL path (UTF-16) to remote process
3. CreateRemoteThread(LoadLibraryW, pathAddr) -- load DLL in target
4. WaitForSingleObject (wait for DLL load)
5. Enumerate remote modules to find DLL base address
6. VirtualProtectEx(.text, PAGE_READWRITE)
7. WriteProcessMemory(.text, shellcode)
8. VirtualProtectEx(.text, PAGE_EXECUTE_READ)
9. Clean up remote path memory

Forensic Artifacts:

• DLL load in remote process (legitimate, signed DLL)
• Memory protection change on .text section
• Shellcode appears as MEM_IMAGE backed by signed module
• Remote thread for LoadLibraryW (common API pattern)

Limitations: The DLL's .text section must be large enough to hold the shellcode. The DLL is configured via the module_stomp_dll evasion option (default: xpsservices.dll). The technique uses CreateRemoteThread for the initial LoadLibraryW call, which is detectable.

Configuration: Set the stomped DLL via the evasion config:

{
  "module_stomp_dll": "xpsservices.dll"
}

Supports InjectByPID: Handled via allocAndWriteModuleStomp + default injector. Supports InjectByHandle: Handled via allocAndWriteModuleStomp + thread execution.

ID: dllinject MITRE ATT&CK: T1055.001 - Dynamic-link Library Injection

How it works: Converts a DLL to position-independent shellcode using the sRDI (Shellcode Reflective DLL Injection) technique. The shellcode stub handles PE mapping, import resolution, and relocation entirely in memory -- no LoadLibrary call is made. The converted shellcode is then injected using the default injection technique (CRT).

API Call Chain:

1. Validate PE header (MZ check)
2. Convert DLL to shellcode via sRDI
3. Inject shellcode using default injector (InjectByPID)

Forensic Artifacts:

• Unbacked executable memory (DLL mapped without LoadLibrary)
• PE header may be present in memory (detectable by memory scanners)
• Injection artifacts depend on the underlying technique (default: CRT)

Limitations: The DLL is specified by the operator via the dllinject command. The sRDI conversion adds a shellcode stub that handles the reflective loading. The underlying injection technique is always the default (CRT) and cannot be overridden for DLL injection.

Supports InjectByPID: Yes (via default injector after sRDI conversion). Supports InjectByHandle: No (standalone command only).

ID: threadless MITRE ATT&CK: T1055 - Process Injection

How it works: Hooks an exported function in the target process by writing a trampoline (save registers + call shellcode + jmp to original function) over the function's entry point. When the target process naturally calls the hooked function, the trampoline redirects execution to the shellcode. No thread is ever created in the target process -- execution piggybacks on existing threads. Default hook target: ntdll!RtlExitUserProcess.

API Call Chain:

1. Resolve exported function address in remote process
2. Read original function bytes (for trampoline return)
3. VirtualAllocEx (RW) for shellcode + trampoline
4. Build trampoline: push registers, call shellcode, restore registers, jmp original
5. WriteProcessMemory (shellcode + trampoline)
6. VirtualProtectEx (RW -> RX)
7. WriteProcessMemory to overwrite function entry with jmp to trampoline

Forensic Artifacts:

• Modified function prologue in target process (detectable by code integrity checks)
• Memory: RW -> RX transition for shellcode allocation
• No CreateRemoteThread or APC artifacts
• No new thread creation events (Sysmon Event 8 absent)

Limitations: The hooked function must be called by the target process for shellcode to execute. Timing is non-deterministic. Default target RtlExitUserProcess fires on process exit, which may not be immediate. Choose a frequently-called export for faster triggering.

Supports InjectByPID: Yes. Supports InjectByHandle: Yes.

ID: hollowing MITRE ATT&CK: T1055.012 - Process Hollowing

How it works: Creates a new process in suspended state (CREATE_SUSPENDED | CREATE_NO_WINDOW), then replaces its image memory with shellcode. The main thread's RIP is redirected to the shellcode via SetThreadContext, and the thread is resumed. The shellcode executes as the main thread of a seemingly legitimate process. Default sacrificial process: svchost.exe.

API Call Chain:

1. CreateProcessW(sacrificialProcess, CREATE_SUSPENDED | CREATE_NO_WINDOW)
2. VirtualAllocEx + WriteProcessMemory + VirtualProtectEx (shellcode, RX)
3. GetThreadContext(CONTEXT_FULL) on main thread
4. Set ctx.Rip = shellcodeAddr
5. SetThreadContext(mainThread, ctx)
6. ResumeThread(mainThread)

Forensic Artifacts:

• Suspended process creation (CREATE_SUSPENDED flag)
• Thread context modification on main thread
• Memory: RW -> RX transition in hollowed process
• Process image mismatch (memory content doesn't match on-disk binary)

Limitations: EDR products that compare process memory against the on-disk image will detect the mismatch. The sacrificial process can be configured via spawn-to settings. If injection fails, the suspended process is terminated to avoid orphans.

Supports InjectByPID: Yes (creates new suspended process). Supports InjectByHandle: Yes.

ID: poolparty_workitem MITRE ATT&CK: T1055 - Process Injection

How it works: Based on SafeBreach Labs' PoolParty research. Locates the target process's thread pool worker factory handle via NtQuerySystemInformation, then inserts a fake TP_WORK item pointing to the shellcode. When the thread pool dispatches the next work item, the shellcode executes as a legitimate thread pool worker callback.

API Call Chain:

1. NtQuerySystemInformation(SystemHandleInformation) to find worker factory handle
2. VirtualAllocEx + WriteProcessMemory + VirtualProtectEx (shellcode, RX)
3. Build fake TP_WORK structure with callback → shellcode address
4. VirtualAllocEx(PAGE_READWRITE) for TP_WORK structure
5. WriteProcessMemory (TP_WORK to target)
6. Insert work item into thread pool queue via NtSetInformationWorkerFactory

Forensic Artifacts:

• No CreateRemoteThread -- execution via thread pool dispatch
• Memory: RW -> RX transition for shellcode
• Additional RW allocation for TP_WORK structure
• Thread pool activity appears as legitimate worker execution

Supports InjectByPID: Yes. Supports InjectByHandle: Yes.

ID: poolparty_timer MITRE ATT&CK: T1055 - Process Injection

How it works: Similar to work item insertion but uses the thread pool timer mechanism. Creates a fake TP_TIMER structure with the callback pointing to shellcode and inserts it into the target's timer queue. When the timer fires, the thread pool dispatches the callback, executing the shellcode.

API Call Chain:

1. NtQuerySystemInformation(SystemHandleInformation) to find worker factory handle
2. VirtualAllocEx + WriteProcessMemory + VirtualProtectEx (shellcode, RX)
3. Build fake TP_TIMER structure with callback → shellcode address
4. Write structure to target process
5. Insert timer into thread pool timer queue

Forensic Artifacts:

• No CreateRemoteThread artifact
• Timer callback execution appears as legitimate thread pool timer activity
• Memory: RW -> RX transition for shellcode

Supports InjectByPID: Yes. Supports InjectByHandle: Yes.

ID: poolparty_io MITRE ATT&CK: T1055 - Process Injection

How it works: Uses the thread pool I/O completion mechanism. Creates a fake TP_IO structure with the callback pointing to shellcode and associates it with an I/O completion port in the target process. When an I/O completion packet arrives, the thread pool dispatches the callback.

API Call Chain:

1. NtQuerySystemInformation(SystemHandleInformation) to find I/O completion port handle
2. VirtualAllocEx + WriteProcessMemory + VirtualProtectEx (shellcode, RX)
3. Build fake TP_IO structure with callback → shellcode address
4. Write structure to target process
5. Queue I/O completion packet to trigger callback

Forensic Artifacts:

• No CreateRemoteThread artifact
• I/O completion callback appears as legitimate async I/O handling
• Memory: RW -> RX transition for shellcode

Supports InjectByPID: Yes. Supports InjectByHandle: Yes.

ID: poolparty_alpc MITRE ATT&CK: T1055 - Process Injection

How it works: Uses the thread pool ALPC (Advanced Local Procedure Call) mechanism. Creates a fake TP_ALPC structure with the callback pointing to shellcode and associates it with an ALPC port in the target process. When an ALPC message arrives on the port, the thread pool dispatches the callback.

API Call Chain:

1. NtQuerySystemInformation(SystemHandleInformation) to find ALPC port handle
2. VirtualAllocEx + WriteProcessMemory + VirtualProtectEx (shellcode, RX)
3. Build fake TP_ALPC structure with callback → shellcode address
4. Write structure to target process
5. Send ALPC message to trigger callback dispatch

Forensic Artifacts:

• No CreateRemoteThread artifact
• ALPC callback appears as legitimate inter-process communication handling
• Memory: RW -> RX transition for shellcode

Supports InjectByPID: Yes. Supports InjectByHandle: Yes.

ID: cb_fontenum MITRE ATT&CK: T1055 - Process Injection

How it works: Uses the Windows GDI EnumFontFamiliesExW API as a shellcode trigger. Creates a suspended process, writes shellcode to it, then creates a remote thread that calls EnumFontFamiliesExW with the shellcode address as the callback parameter. When GDI enumerates fonts, it calls the callback (shellcode) for each font family.

API Call Chain:

1. CreateProcessW(sacrificialProcess, CREATE_SUSPENDED | CREATE_NO_WINDOW)
2. VirtualAllocEx + WriteProcessMemory + VirtualProtectEx (shellcode, RX)
3. GetThreadContext → modify RIP to point to EnumFontFamiliesExW stub
4. Stub calls EnumFontFamiliesExW(NULL, NULL, shellcodeAddr, 0)
5. ResumeThread -- GDI font enumeration triggers shellcode callback

Forensic Artifacts:

• Suspended process creation
• GDI API call appears legitimate (font enumeration is common)
• Memory: RW -> RX transition for shellcode
• Thread context modification

Supports InjectByPID: Yes (creates new suspended process). Supports InjectByHandle: Yes.

ID: cb_timer MITRE ATT&CK: T1055 - Process Injection

How it works: Uses CreateTimerQueueTimer as a shellcode trigger. Creates a suspended process, writes shellcode, then redirects execution to a stub that calls CreateTimerQueueTimer with the shellcode address as the timer callback. The timer fires immediately (due period = 0), executing the shellcode.

API Call Chain:

1. CreateProcessW(sacrificialProcess, CREATE_SUSPENDED | CREATE_NO_WINDOW)
2. VirtualAllocEx + WriteProcessMemory + VirtualProtectEx (shellcode, RX)
3. GetThreadContext → modify RIP to point to CreateTimerQueueTimer stub
4. Stub calls CreateTimerQueueTimer(NULL, NULL, shellcodeAddr, NULL, 0, 0, WT_EXECUTEDEFAULT)
5. ResumeThread -- timer fires immediately, triggering shellcode callback

Forensic Artifacts:

• Suspended process creation
• Timer queue creation (legitimate Windows API pattern)
• Memory: RW -> RX transition for shellcode
• Thread context modification

Supports InjectByPID: Yes (creates new suspended process). Supports InjectByHandle: Yes.

ID: cb_winenum MITRE ATT&CK: T1055 - Process Injection

How it works: Uses the EnumWindows API as a shellcode trigger. Creates a suspended process, writes shellcode, then redirects execution to a stub that calls EnumWindows with the shellcode address as the enumeration callback. When user32 enumerates top-level windows, it calls the callback (shellcode) for each window.

API Call Chain:

1. CreateProcessW(sacrificialProcess, CREATE_SUSPENDED | CREATE_NO_WINDOW)
2. VirtualAllocEx + WriteProcessMemory + VirtualProtectEx (shellcode, RX)
3. GetThreadContext → modify RIP to point to EnumWindows stub
4. Stub calls EnumWindows(shellcodeAddr, 0)
5. ResumeThread -- window enumeration triggers shellcode callback

Forensic Artifacts:

• Suspended process creation
• Window enumeration API call (common user32 activity)
• Memory: RW -> RX transition for shellcode
• Thread context modification

Supports InjectByPID: Yes (creates new suspended process). Supports InjectByHandle: Yes.