基于 Windows 线程池机制的隐蔽进程注入技术分析与评估

摘要

传统的进程注入技术——包括 CreateRemoteThread、NtCreateThreadEx 及 QueueUserAPC——均依赖于在目标进程中创建新线程或在现有线程中插入 APC 对象，这些操作均会被端点检测与响应（EDR）系统的用户态钩子所监控。本文分析一种利用 Windows 原生线程池机制实现进程注入的替代方法。该技术通过将 Shellcode 封装为线程池工作项，提交至目标进程的线程池队列中，由线程池的现有空闲线程自动执行，全程无需调用线程创建相关 API，从而规避基于线程创建监控的检测规则。本文对该技术的原理、实现约束及适用范围进行了系统分析，并从监控策略与内核级检测两个维度提出了相应的防御建议。

关键词：进程注入；线程池；EDR 绕过；Windows 安全；攻击面分析

1. 引言

进程注入是红蓝对抗中最基础也最常被使用的技术之一。从最初的 CreateRemoteThread，到 NtCreateThreadEx、SetThreadContext 结合 ResumeThread，再到基于异步过程调用（APC）的注入技术，攻击者与防御者围绕"如何在目标进程中执行任意代码"这一命题展开了长期的攻防博弈。

每一次注入技术的演进，本质上都是攻击者对防御检测维度的重新选择。传统注入技术之所以被 EDR 有效检测，根本原因在于它们都需要调用特定的 Windows API 来创建或操纵线程执行流，而这些 API 恰恰是 EDR 用户态钩子的核心监控对象。

2023 年，SafeBreach 实验室披露了一种利用 Windows 线程池机制实现进程注入的新型技术。该技术的核心思想是：不创建新线程，而是将恶意代码封装为线程池工作项（Work Item），提交到目标进程的现有线程池中，由系统线程池的已有空闲线程执行。由于整个过程完全绕过了线程创建 API，EDR 基于内核回调或用户态钩子的线程监控机制将完全失效。

本文对该技术的原理、实现与检测进行了系统性分析。

2. Windows 线程池机制概述

2.1 线程池架构

Windows 线程池是一组由系统预先创建的线程，用于高效处理异步任务、定时器回调及等待对象。在 Windows Vista 及之后的版本中，每个进程默认包含一个由系统管理的线程池。线程池的核心组件包括：

• 工作队列（Work Queue）：存储待执行的工作项
• 等待队列（Wait Queue）：存储等待内核对象信号的工作项
• 定时器队列（Timer Queue）：存储定时执行的工作项

2.2 核心 API

线程池相关 API 是 Windows 原生提供的线程池编程接口，主要包括：

API	功能
CreateThreadpool	创建自定义线程池实例
CreateThreadpoolWork	创建工作项，指定回调函数与参数
SubmitThreadpoolWork	将工作项提交至线程池执行队列
WaitForThreadpoolWorkCallbacks	等待工作项执行完成
CloseThreadpoolWork	关闭并释放工作项

这些 API 的设计初衷是简化异步编程模型，其回调函数在提交后由线程池中的空闲线程调用执行。

3. 注入技术原理

3.1 核心思路

线程池注入的核心思路可概括为：在目标进程的内存空间中写入 Shellcode，然后构造一个线程池工作项，将其回调函数指针指向 Shellcode 的入口地址，最后将该工作项提交至目标进程的线程池。

由于线程池工作项的执行由系统线程池调度器管理，不需要调用 CreateRemoteThread 或 NtCreateThreadEx，因此 EDR 安装在上述 API 上的用户态钩子不会被触发。

3.2 实现步骤

线程池注入的实现包含以下四个步骤：

步骤一：获取目标进程句柄。通过进程名、PID 或窗口句柄等方式定位并打开目标进程，获取具有必要访问权限的进程句柄。

步骤二：内存分配与 Shellcode 写入。在目标进程中调用 VirtualAllocEx 分配具有读写执行权限（PAGE_EXECUTE_READWRITE）的内存区域，并通过 WriteProcessMemory 写入 Shellcode 载荷。

步骤三：创建工作项。调用 CreateThreadpoolWork API，将工作项的回调函数指针设置为 Shellcode 在目标进程中的地址：

PTP_WORK work = CreateThreadpoolWork(
    (PTP_WORK_CALLBACK)shellcodeAddr,
    NULL,        // 回调参数（可选）
    NULL         // 线程池环境（NULL 表示使用默认线程池）
);

步骤四：提交工作项。调用 SubmitThreadpoolWork 将工作项提交至线程池。线程池调度器会将其分配至一个空闲线程执行：

SubmitThreadpoolWork(work);

此时，Shellcode 在目标进程上下文中被执行，整个注入过程完成。

3.3 技术约束

尽管线程池注入在绕过 EDR 方面表现出显著优势，但其在实际应用中仍面临以下约束：

• 跨进程工作项提交的限制：SubmitThreadpoolWork 默认将工作项提交至调用进程的线程池，而非目标进程。若要注入远程进程，需要在目标进程中创建线程池或利用现有机制实现跨进程工作项投递，这增加了实现复杂度。
• Shellcode 自包含性要求：线程池工作项的回调函数执行上下文不同于常规线程，Shellcode 需要能够在此上下文中正常运行，不能依赖特定的线程初始化状态。
• 同步与清理：工作项提交后的执行时机由线程池调度器决定，Shellcode 执行完成后需要自行清理，否则可能导致目标进程不稳定。

4. 攻防评估

4.1 攻击优势

线程池注入技术的主要攻击优势在于其检测规避能力。2026 年 4 月的独立测试显示，采用该技术的 Shellcode 加载器在 VirusTotal 平台上的检出率为 0/67，CrowdStrike、SentinelOne、Microsoft Defender 等主流 EDR 均未产生告警。

适用场景包括：

• 持久化：将 Beacon Shellcode 注入至 svchost.exe、explorer.exe 等系统常驻进程，实现跨会话持久化
• 横向移动：将 Shellcode 注入至远程主机的可信进程中，实现无文件横向移动
• 无文件攻击：结合反射式 DLL 加载或 Shellcode 加载器，实现完全无文件的进程注入

4.2 检测局限

线程池注入技术对基于用户态 API 钩子的 EDR 具有天然免疫能力，但并非无法检测。以下检测维度仍然有效：

• 内核回调监控：基于内核态进程创建回调（PsSetCreateThreadNotifyRoutine）的检测机制可捕获线程创建事件，但对于线程池已存在线程的执行则无法区分。
• 内存扫描：对目标进程中可疑的 PAGE_EXECUTE_READWRITE 内存区域进行周期性扫描，仍然可以检测到 Shellcode 的存在。
• 行为分析：监控 CreateThreadpoolWork 与 SubmitThreadpoolWork 的异常调用模式，尤其是来自非可信进程（如浏览器、办公软件）的调用，可作为检测指标。

5. 防御建议

5.1 用户态监控

EDR 产品应将 CreateThreadpoolWork、SubmitThreadpoolWork、SetThreadpoolThreadMaximum 等线程池 API 纳入监控范围，对来自低信誉进程的线程池操作调用进行告警。

5.2 内核态加固

启用 Windows LSA 保护（RunAsPPL），限制对关键系统进程的访问权限。采用内核驱动监控线程池工作项的提交与执行行为，识别异常的回调函数地址。

5.3 进程安全策略

对于关键进程（如 lsass.exe、svchost.exe），启用额外的访问控制策略，防止非授权进程通过 VirtualAllocEx 和 WriteProcessMemory 进行内存操作。Windows Defender Application Control（WDAC）可有效限制未签名代码的执行。

6. 结论

Windows 线程池注入技术代表了进程注入技术从"创建线程"到"复用线程"的范式转变。它并非利用系统漏洞，而是利用线程池这一原生机制的设计特性——工作项回调由现有线程池线程执行，天然绕过了基于线程创建事件的检测模型。

然而，任何攻击技术都有其适用范围和局限性。线程池注入在跨进程场景下的实现复杂度较高，且无法规避基于内存扫描与行为分析的高级检测。对防御者而言，理解线程池注入的技术原理，有助于构建更加完善的、覆盖用户态与内核态的多层次检测体系。

参考文献

[1] SafeBreach Labs. "Process Injection Using Windows Thread Pools." https://www.safebreach.com/blog/process-injection-using-windows-thread-pools

[2] Microsoft Corporation. "Thread Pool API Reference." https://learn.microsoft.com/en-us/windows/win32/procthread/thread-pool-api

[3] Microsoft Corporation. "Windows Defender Application Control." https://learn.microsoft.com/en-us/windows/security/application-security/application-control/windows-defender-application-control/