简介面向具备基础C语法、希望在Windows平台实现进程隐藏的开发者这是一份完整的示例工程RAR包围绕CreateProcess、ShowWindow、GetModuleHandle与GetProcAddress等关键API讲解如何让新进程启动时即处于隐藏状态并配有可直接编译运行的代码供对照修改。包内共45个文件以cpp/h源码、obj中间文件、tlog构建日志、vcxproj工程配置、pdb调试符号及exe可执行文件为主完整打包大小约5.39MB目录中包含Debug与Release生成结果方便查看工程结构与构建产物。该资源已有2742人浏览学习。通过阅读源码、工程配置和可执行示例读者既能掌握STARTF_USESHOWWINDOW标志及ShowWindow配合隐藏窗口的具体用法也能在此基础上扩展为后台服务或常驻任务同时理解进程隐藏并非绝对不可检测应在合法合规且不过度影响系统稳定的前提下使用。1. 为什么“进程隐藏”不是把窗口藏起来那么简单做 C 实现进程隐藏这个需求的人多半不是想干坏事而是想搞清楚那个摆在自己面前的黑匣子为什么任务管理器里看不到的进程换个工具就现形了为什么一个改了名的进程在日志里还是能被揪出来。常见的诉求无非三种分析恶意样本时给监控环境留出观察窗口、SDK 调试时让常驻进程不那么碍眼、写防御规则时验证自己家的 EDR 到底能不能发现特定进程。第一件事不是找代码而是先想清楚你手上有哪些工具在“看”进程它们各看哪份数据。进程隐藏是一个“按视角生效”的技术不是“把进程干掉”的魔法。同样一个进程任务管理器、内核驱动、安全日志看到的字段各不相同隐藏其中一层对另外的观察者完全无效。这篇文章按我自己的落地顺序讲先分清楚观察者视角再给三套可编译的 C 方案窗口隐藏、PEB 改名、启动早期伪装最后用五条避坑记录把最容易翻车的点一次说清。2. 先搞清“谁在看进程”再决定隐藏哪一层三种视角与四条路线对比2.1 任务管理器、Process Explorer、内核驱动各看各的数据源窗口程序里点击“任务管理器”时进程列表的名称列来自内核进程对象 EPROCESS 里的 ImageFileName也就是进程创建时从 exe 文件路径拷出来的文件名。它跟你在代码里怎么改字符串没有任何关系只要进程是用某个 exe 映像拉起来的这一列就固定了。Process Explorer 这类工具显示得更细。它的“映像路径”“命令行”“工作集”等列读的是进程 PEB进程环境块里 RTL_USER_PROCESS_PARAMETERS 这份用户态参数包括可执行文件全路径、命令行、当前目录、环境变量块。这些字段是进程自己可以修改的这就是我们在用户态做文章的空间。最容易被忽略的是安全日志视角。EDR 和系统监控工具记录进程创建事件靠的是内核的回调机制通常在 CreateProcess 返回前后就已经把「父进程、子进程路径、命令行、哈希」打包成一条事件写进日志。事后你再去改 PEB事件里留下的还是创建那一刻的快照。所以要隐藏进程第一步是搞清楚你要骗的是哪类观察者。骗过任务管理器最简单骗过 Process Explorer 需要改 PEB骗过安全日志需要在进程“出生”那一刻就把参数改好。三件事彼此独立没有一招通吃。2.2 进程隐藏的四条路线与选型对比按我处理这类需求的经验进程隐藏大体可以分成四条路线成本从低到高路线操作位置影响范围成本与风险窗口隐藏用户态 Win32 窗口只影响桌面会话里的可见窗口最低适合有 GUI 的辅助程序PEB 改名进程自身 PEB让读取 PEB 的工具看到假路径和假命令行低不影响任务管理器的进程名启动早期伪装挂起创建 跨进程改 PEB影响进程创建日志中的部分字段中需要处理跨进程内存写入内核断链EPROCESS 链表让枚举进程列表的工具看不到它高需要驱动签名64 位蓝屏风险大另外还有一条“宿主注入”路线把代码注入到一个合法进程里让独立进程根本不存在。这个方案隐蔽性最好但要处理注入检测、崩溃隔离、位数对齐重量级远高于改 PEB在只想“让进程名不出现在分析任务里”的场景下属于过度设计。四条路线里窗口隐藏只能骗过人眼PEB 改名能骗过半吊子观察者启动早期伪装能影响日志快照内核断链理论上最彻底但代价是系统稳定性。我自己的选择习惯是能用用户态解决的绝不动内核。2.3 选型原则先定义“要骗过谁”再决定写哪层代码接到类似需求我一般会先让对方明确一个问题你说的“隐藏”是让普通用户看不见还是让排查工具认不出来还是让安全日志里没有记录这三个答案对应的代码量分别是一行、几十行和上百行。如果你的场景只是“常驻托盘程序别让用户觉得烦”窗口隐藏就够了别把 PE 里那套东西搬出来如果是在做恶意样本分析你需要的是不干扰样本行为的观察环境那 PEB 改名解决不了核心问题因为样本自己会调用 API 检查自己隐藏反而造成干扰如果你是在验证自己的检测规则那重点不是“隐藏”而是“隐藏后检测规则能不能从行为上把它揪出来”。一句话隐藏越深代码越重边界越窄。先定义被谁看再决定写不写代码这是最容易省时间的一步。3. PEB 改名最小实现运行时伪装进程名与命令行3.1 隐藏窗口一个 FindWindow ShowWindow 就够了先给一个最容易被误认为“进程隐藏”的起点隐藏窗口。如果目标程序有 GUI 窗口在 C 里三行代码就能让它“看不见”HWND hTarget ::FindWindowW(nullptr, L某程序主窗口标题); if (hTarget) { ::ShowWindow(hTarget, SW_HIDE); }这段代码的逻辑很简单FindWindowW 按窗口标题找顶层窗口ShowWindow 把它的 WS_VISIBLE 样式去掉。调用后桌面上没有窗口但任务管理器里进程还在网络连接还在CPU 占用还在。它改变的只是“用户肉眼可见的形态”不是进程的存在性。窗口隐藏的意义在于它能瞬时生效不需要提前注入、不需要重启而且被隐藏的程序可以继续正常绘制窗口内容只是看不到而已。但它对控制台程序、服务程序、无窗口程序完全没有效果这类程序从出生起就没有窗口谈不上隐藏。把它当成进程隐藏的入门热身可以当成解决方案远远不够。3.2 修改 PEB 的 100 行代码把进程名改成 svchost 的样子真正能在“可执行程序层面”骗过多数工具的做法是改 PEB 里的 ImagePathName 和 CommandLine。核心思路是进程自己通过 GetCommandLineW 或 NtQueryInformationProcess 拿到的命令行来自 PEB 中的 RTL_USER_PROCESS_PARAMETERS 结构我们把它直接改掉就能让所有从用户态读这个结构的工具看到一套伪造的参数。下面这段代码是我在实验室里常用的最小实现用动态获取函数地址的方式写出MSVC 和 MinGW 都能编译// peb_spoof.cpp : 修改当前进程 PEB 中的 CommandLine #include windows.h #include winternl.h #include stdio.h // 动态获取 NtQueryInformationProcess避免连接 ntdll.lib typedef NTSTATUS(NTAPI* pNtQueryInformationProcess)( HANDLE, ULONG, PVOID, ULONG, PULONG); // PEB 中 ProcessParameters 的偏移按位数区分 #ifdef _WIN64 #define PEB_PARAMS_OFFSET 0x20 #else #define PEB_PARAMS_OFFSET 0x10 #endif // RTL_USER_PROCESS_PARAMETERS 中 CommandLine 字段偏移 #ifdef _WIN64 #define CMDLINE_OFFSET 0x70 #else #define CMDLINE_OFFSET 0x40 #endif // UNICODE_STRING 中 Buffer 指针的偏移 #ifdef _WIN64 #define STRING_BUFFER_OFFSET 8 #else #define STRING_BUFFER_OFFSET 4 #endif bool SpoofCommandLine(const wchar_t* fakeCmd) { HMODULE nt GetModuleHandleW(Lntdll.dll); auto fn (pNtQueryInformationProcess)GetProcAddress(nt, NtQueryInformationProcess); if (!fn) return false; // 1. 查询当前进程的 PEB 地址 PROCESS_BASIC_INFORMATION pbi{}; if (fn(GetCurrentProcess(), 0, pbi, sizeof(pbi), nullptr) ! 0) return false; // 2. 读取 PEB 中的 ProcessParameters 指针 BYTE* peb (BYTE*)pbi.PebBaseAddress; BYTE* params *(BYTE**)(peb PEB_PARAMS_OFFSET); // 3. 在堆上分配新字符串避免栈上局部变量被回收 size_t bytes (wcslen(fakeCmd) 1) * sizeof(wchar_t); wchar_t* store (wchar_t*)HeapAlloc(GetProcessHeap(), 0, bytes); if (!store) return false; wcscpy(store, fakeCmd); // 4. 改写 UNICODE_STRING 的长度字段和 Buffer 指针 USHORT len (USHORT)(wcslen(fakeCmd) * sizeof(wchar_t)); *(USHORT*)(params CMDLINE_OFFSET) len; *(USHORT*)(params CMDLINE_OFFSET 2) len sizeof(wchar_t); *(wchar_t**)(params CMDLINE_OFFSET STRING_BUFFER_OFFSET) store; return true; } int main() { wprintf(L[before] %s\n, GetCommandLineW()); if (SpoofCommandLine(LC:\\Windows\\System32\\svchost.exe -k netsvcs)) { wprintf(L[after ] %s\n, GetCommandLineW()); } Sleep(60000); // 保持进程存活方便观察 return 0; }代码逻辑分成四步先用 NtQueryInformationProcess 取 PEB 地址再从 PEB 的固定偏移取出 ProcessParameters 指针接着在堆上分配一块能容纳新命令行字符串的内存最后直接改写 CommandLine 这个 UNICODE_STRING 的长度和 Buffer 指针。这里有个关键点必须说明UNICODE_STRING 是自定义的结构Length 字段是字节数不是字符数所以 wcslen 结果要乘以 sizeof(wchar_t)。Buffer 的数据类型是指针在不同位数下占 4 或 8 字节因此 STRING_BUFFER_OFFSET 也要跟着变。再有HeapAlloc 分配的内存不要主动释放因为进程运行期间仍可能有人来读这个 Buffer释放会导致悬空指针。运行这个程序后控制台里第二次打印的命令行已经变成伪造值。此时用 Process Explorer 看该进程的“命令行”列显示出来的也是 svchost 那串。这就是 PEB 改名能做到的事让靠读取用户态参数的观察者看到幻象。3.3 用 tasklist 与 Process Explorer 验证伪装效果写完代码可以先做一轮快速自检。开一个管理员 CMD用 tasklist 查看进程名tasklist /v /fo csv | findstr /i peb_spooftasklist 的“映像名称”列来自 EPROCESS不会因为改了 PEB 而变化所以你仍然能看到 peb_spoof.exe 的名字。这一步是让读者建立认知改了 PEB 不等于改名。再打开 Process Explorer找到该进程查看“命令行”列这里应该已经是伪造的 svchost 参数。如果显示的还是真实命令行大概率是偏移算错或者程序是 32 位却用了 64 位偏移。拿不到预期结果时先从编译产物是 x64 还是 x86 查起再检查 peb_spoof.exe 运行时是否真的执行到了 SpoofCommandLine。这个对比验证的意义在于让你直观感受到“不同数据源之间的割裂”。真实业务里做隐藏方案最难的不是写代码而是理解各种工具到底信任哪一份数据然后决定自己要不要把每一份都处理掉。4. 启动早期伪装用 CREATE_SUSPENDED 让日志只看到“马甲”4.1 为什么“出生前改名”比“出生后改名”更接近目的第 3 章的运行时改名有一个天然短板进程是用真实 exe 启动的启动那一刻系统监控工具已经通过内核回调记录了一条进程创建事件事件里带的原始路径和命令行是真实值。你运行中再去改 PEB日志快照早就生成完了等于藏着给监控看。常见做法是改用挂起创建CreateProcess 时传入 CREATE_SUSPENDED让子进程的主线程先不运行这个时候 PEB 已经初始化完毕进程参数也已经写入但还没有人触发主线程入口代码。趁这个窗口期用 WriteProcessMemory 跨进程改写子进程 PEB 里的 CommandLine 和 ImagePathName改完再 ResumeThread这个进程就“一出生就披着马甲”。和注入方案相比挂起改 PEB 做的是“数据修正”而不是“代码注入”没有往目标进程写入可执行代码检测面小很多。缺点也明显CreateProcess 时 lpApplicationName 必须是你真实程序路径所以早先一步到达的驱动回调如果有拿到的还是真实路径它影响的是“依赖进程参数块做监控的日志”做不到骗过内核层。4.2 创建挂起进程并在 Resume 前改写 PEB 的完整代码下面的关键函数可以拉出来直接用到你自己的工程里。它做的事情是父进程创建子进程时挂起然后查询子进程 PEB 地址跨进程读取 ProcessParameters再分配一段子进程内存写入伪造命令行最后恢复主线程。// spawn_spoof.cpp : 创建挂起进程跨进程改写 CommandLine 后恢复运行 #include windows.h #include winternl.h #include stdio.h typedef NTSTATUS(NTAPI* pNtQueryInformationProcess)( HANDLE, ULONG, PVOID, ULONG, PULONG); #ifdef _WIN64 #define PEB_PARAMS_OFFSET 0x20 #define CMDLINE_OFFSET 0x70 #define STRING_BUFFER_OFFSET 8 #else #define PEB_PARAMS_OFFSET 0x10 #define CMDLINE_OFFSET 0x40 #define STRING_BUFFER_OFFSET 4 #endif bool SpoofChildCommandLine(HANDLE hProcess, const wchar_t* fakeCmd) { HMODULE nt GetModuleHandleW(Lntdll.dll); auto fn (pNtQueryInformationProcess)GetProcAddress(nt, NtQueryInformationProcess); if (!fn) return false; // 1. 查询子进程 PEB 地址 PROCESS_BASIC_INFORMATION pbi{}; if (fn(hProcess, 0, pbi, sizeof(pbi), nullptr) ! 0) return false; BYTE* peb (BYTE*)pbi.PebBaseAddress; // 2. 读取 PEB 里的 ProcessParameters 指针 BYTE* params nullptr; SIZE_T read 0; if (!ReadProcessMemory(hProcess, peb PEB_PARAMS_OFFSET, params, sizeof(params), read)) return false; // 3. 在子进程地址空间分配新字符串缓冲区 size_t bytes (wcslen(fakeCmd) 1) * sizeof(wchar_t); PVOID newBuf VirtualAllocEx(hProcess, nullptr, bytes, MEM_COMMIT | MEM_RESERVE, PAGE_READWRITE); if (!newBuf) return false; if (!WriteProcessMemory(hProcess, newBuf, fakeCmd, bytes, read)) return false; // 4. 改 UNICODE_STRING 的长度与 Buffer 指针 USHORT len (USHORT)(wcslen(fakeCmd) * sizeof(wchar_t)); USHORT maxLen len sizeof(wchar_t); WriteProcessMemory(hProcess, params CMDLINE_OFFSET, len, sizeof(len), read); WriteProcessMemory(hProcess, params CMDLINE_OFFSET 2, maxLen, sizeof(maxLen), read); WriteProcessMemory(hProcess, params CMDLINE_OFFSET STRING_BUFFER_OFFSET, newBuf, sizeof(newBuf), read); return true; } int main() { STARTUPINFOW si{ sizeof(si) }; PROCESS_INFORMATION pi{}; wchar_t fakeCmdLine[] LC:\\Windows\\System32\\svchost.exe -k netsvcs; BOOL ok CreateProcessW( LE:\\lab\\sleeper.exe, // 真实程序只 Sleep 的测试进程 fakeCmdLine, // 展示给监控日志的“马甲” nullptr, nullptr, FALSE, CREATE_SUSPENDED, // 关键先挂起 nullptr, nullptr, si, pi); if (!ok) return 1; SpoofChildCommandLine(pi.hProcess, fakeCmdLine); ResumeThread(pi.hThread); CloseHandle(pi.hThread); CloseHandle(pi.hProcess); return 0; }调用流程是固定的CreateProcessW 带 CREATE_SUSPENDED 创建子进程SpoofChildCommandLine 完成三处跨进程写入ResumeThread 放行。注意 CreateProcessW 第一个参数是真实 sleeper.exe 的路径第二个参数是你要显示的马甲命令行两者不一致是故意的。这段代码里最容易写错的是 ReadProcessMemory 读指针的环节。ProcessParameters 是一个 4 或 8 字节的指针必须按指针宽度读同时第二个参数传的是params CMDLINE_OFFSET而不是params CMDLINE_OFFSET 8因为我们要改的是 UNICODE_STRING 的 Length 字段指针字段在 Length 之后偏移 4 或 8 字节。编译时务必让父子进程是同一位数否则偏移全乱。4.3 注入完成后的进程视野变化跑完上面的程序后在 Process Explorer 里看子进程的“映像名称”列仍然是 sleeper.exe这一点改变不了“命令行”列显示 svchost 的马甲系统监控工具记下的创建事件如果它读取的是 ProcessParameters 里的初始快照则能看到与命令行一致的假值如果它拦截的是更底层的路径信息则仍会暴露真实文件路径。这个方案不是万能的它解决的是“启动早期快照被记录”的问题不能解决“内核层已经拿到真实映像名”的问题。但它在实战里已经足够改变很多日志分析结论排查人员顺着命令行线索走会先看到一个 svchost而不是一个不知名的 sleeper。至于这个 svchost 的行为是否合理那是行为和舆情层面的分析不在进程隐藏技术范围内。5. 进程隐藏避坑记录5 个反复出现的坑与排查办法5.1 改了 PEB任务管理器还是旧名字现象程序已经执行了 SpoofCommandLineProcess Explorer 里的命令行也变了但任务管理器“进程”页显示的名称纹丝不动。原因任务管理器的进程名列来自内核 EPROCESS.ImageFileName它由加载器在进程创建时从 exe 路径写入属于内核数据结构用户态怎么改都碰不到。解决接受这个边界。想让任务管理器显示别的名字只有两条路改 EPROCESS需要内核权限或者不创建独立进程改用宿主注入。在纯用户态方案里PEB 改名目标应该是“命令行/路径”而不是“进程名”。5.2 64 位系统上断链后直接蓝屏现象写了一个驱动把目标 EPROCESS 从 ActiveProcessLinks 双向链表里摘掉跑了几分钟系统直接蓝屏转储代码与内核保护机制相关常见 0x109 系列。原因64 位内核有内核结构完整性守护机制周期性校验活动进程链表等关键结构链表被手动摘除后校验失败直接触发蓝屏。解决放弃在 64 位系统上做断链。如果只是做检测规则验证改用过滤的方式拦截特定进程的枚举请求或者干脆用第 4 章的启动早期伪装方案别拿宿主机试这个一点也不值得。5.3 安全软件报的不是“隐藏”是“行为”现象程序已经伪装成 svchost 并且命令行也改了运行一会儿还是被安全产品拦截提示“可疑进程行为”。原因进程名和命令行只是静态特征安全产品的行为检测会综合分析一个系统服务进程为什么没有合法签名、为什么访问了用户目录、为什么建立外连。伪装的名字只是外套行为还是原来的样子。解决把实验程序里那些和隐藏无关的敏感调用先摘掉比如删掉网络请求、减少频繁读写临时目录、不要给自己提权。在验证阶段可以先把它放到白名单目录跑通流程确认隐藏技术本身有效再逐步增加行为干扰。5.4 伪装的进程名和真实场景撞车现象把测试程序伪装成 svchost.exe结果排查时发现这台机器上一堆 svchost你的伪装进程混在里面反而引起了怀疑。原因svchost 是高频出现的高危关注对象安全分析师和脚本都会优先筛它。伪装成“常见名字但不常见行为”的进程往往比伪装成“冷门名字”更显眼。解决选一个这台机器上确实存在、且工作和你的测试程序行为相近的进程做马甲。比如测试程序只读写文件就找同名文件访问频繁的进程如果只是驻留睡眠找后台服务比找交互程序合适。名字要服务于行为而不是越“系统”越好。5.5 32 位程序伪装 64 位进程名导致 PEB 布局对不上现象用 32 位编译的测试程序去改自身 PEB结果写进去之后 GetCommandLineW 返回乱码或者 Process Explorer 显示空命令行。原因32 位进程在 64 位系统上它的 PEB 和 RTL_USER_PROCESS_PARAMETERS 都是 32 位布局ProcessParameters 偏 0x10CommandLine 偏 0x40Buffer 指针 4 字节。如果把 64 位的偏移套进去写的就是错误的内存区域。解决编译前统一用 _WIN64 宏区分偏移不要靠“系统是 64 位”来判断要看“进程自己是几位”。测试代码全部编译成 x64 可以省掉一半麻烦但如果目标环境有 32 位进程还是要单独编一版。6. 用防御方视角验证隐藏Sysmon 日志里藏不住的真相顺着“我要骗过谁”的思路最后验证不能只看 Process Explorer还得看日志。最简单有效的方法是用 Sysmon 的进程创建事件把它开起来再跑一次你的伪装程序然后查事件里到底记了什么。如果日志里记录的 ImagePath 和 CommandLine 与伪装后的一致说明第 4 章的做法对这类监控视角有效如果记录的是 sleeper.exe 真实路径说明该监控组件采集数据的时机早于你的修改。用下面这段 PowerShell 能快速过滤出相关事件Get-WinEvent -FilterHashtable {LogNameMicrosoft-Windows-Sysmon/Operational; Id1} -MaxEvents 200 | Where-Object { $_.Message -match sleeper -or $_.Message -match svchost } | Format-List TimeCreated, Message把它当成一个自检工具而不是绕过工具。正常的验证流程是在干净虚拟机里开启 Sysmon → 跑一次隐藏方案 → 查日志 → 和 Process Explorer 的显示做对比 → 记录哪些数据源看到真实值、哪些看到马甲。往复几次你就能画出一张“本方案对哪些观察者有效”的覆盖表后续再换系统版本或换监控组件只需要重跑同一套流程。我自己的习惯是每次做这类实验都强制自己在关闭虚拟机快照之前把日志和工具输出全拷出来归档。因为隐藏方案经常只对特定版本的系统和特定工具生效换一个环境就翻车没有当时的日志对照排查起来全靠猜。这个习惯帮我避掉过很多次“改完代码发现不是偏移错是验证环境没对上号”的麻烦。希望帮到你。本文还有配套的精品资源点击获取
简介面向具备基础C语法、希望在Windows平台实现进程隐藏的开发者这是一份完整的示例工程RAR包围绕CreateProcess、ShowWindow、GetModuleHandle与GetProcAddress等关键API讲解如何让新进程启动时即处于隐藏状态并配有可直接编译运行的代码供对照修改。包内共45个文件以cpp/h源码、obj中间文件、tlog构建日志、vcxproj工程配置、pdb调试符号及exe可执行文件为主完整打包大小约5.39MB目录中包含Debug与Release生成结果方便查看工程结构与构建产物。该资源已有2742人浏览学习。通过阅读源码、工程配置和可执行示例读者既能掌握STARTF_USESHOWWINDOW标志及ShowWindow配合隐藏窗口的具体用法也能在此基础上扩展为后台服务或常驻任务同时理解进程隐藏并非绝对不可检测应在合法合规且不过度影响系统稳定的前提下使用。1. 为什么“进程隐藏”不是把窗口藏起来那么简单做 C 实现进程隐藏这个需求的人多半不是想干坏事而是想搞清楚那个摆在自己面前的黑匣子为什么任务管理器里看不到的进程换个工具就现形了为什么一个改了名的进程在日志里还是能被揪出来。常见的诉求无非三种分析恶意样本时给监控环境留出观察窗口、SDK 调试时让常驻进程不那么碍眼、写防御规则时验证自己家的 EDR 到底能不能发现特定进程。第一件事不是找代码而是先想清楚你手上有哪些工具在“看”进程它们各看哪份数据。进程隐藏是一个“按视角生效”的技术不是“把进程干掉”的魔法。同样一个进程任务管理器、内核驱动、安全日志看到的字段各不相同隐藏其中一层对另外的观察者完全无效。这篇文章按我自己的落地顺序讲先分清楚观察者视角再给三套可编译的 C 方案窗口隐藏、PEB 改名、启动早期伪装最后用五条避坑记录把最容易翻车的点一次说清。2. 先搞清“谁在看进程”再决定隐藏哪一层三种视角与四条路线对比2.1 任务管理器、Process Explorer、内核驱动各看各的数据源窗口程序里点击“任务管理器”时进程列表的名称列来自内核进程对象 EPROCESS 里的 ImageFileName也就是进程创建时从 exe 文件路径拷出来的文件名。它跟你在代码里怎么改字符串没有任何关系只要进程是用某个 exe 映像拉起来的这一列就固定了。Process Explorer 这类工具显示得更细。它的“映像路径”“命令行”“工作集”等列读的是进程 PEB进程环境块里 RTL_USER_PROCESS_PARAMETERS 这份用户态参数包括可执行文件全路径、命令行、当前目录、环境变量块。这些字段是进程自己可以修改的这就是我们在用户态做文章的空间。最容易被忽略的是安全日志视角。EDR 和系统监控工具记录进程创建事件靠的是内核的回调机制通常在 CreateProcess 返回前后就已经把「父进程、子进程路径、命令行、哈希」打包成一条事件写进日志。事后你再去改 PEB事件里留下的还是创建那一刻的快照。所以要隐藏进程第一步是搞清楚你要骗的是哪类观察者。骗过任务管理器最简单骗过 Process Explorer 需要改 PEB骗过安全日志需要在进程“出生”那一刻就把参数改好。三件事彼此独立没有一招通吃。2.2 进程隐藏的四条路线与选型对比按我处理这类需求的经验进程隐藏大体可以分成四条路线成本从低到高路线操作位置影响范围成本与风险窗口隐藏用户态 Win32 窗口只影响桌面会话里的可见窗口最低适合有 GUI 的辅助程序PEB 改名进程自身 PEB让读取 PEB 的工具看到假路径和假命令行低不影响任务管理器的进程名启动早期伪装挂起创建 跨进程改 PEB影响进程创建日志中的部分字段中需要处理跨进程内存写入内核断链EPROCESS 链表让枚举进程列表的工具看不到它高需要驱动签名64 位蓝屏风险大另外还有一条“宿主注入”路线把代码注入到一个合法进程里让独立进程根本不存在。这个方案隐蔽性最好但要处理注入检测、崩溃隔离、位数对齐重量级远高于改 PEB在只想“让进程名不出现在分析任务里”的场景下属于过度设计。四条路线里窗口隐藏只能骗过人眼PEB 改名能骗过半吊子观察者启动早期伪装能影响日志快照内核断链理论上最彻底但代价是系统稳定性。我自己的选择习惯是能用用户态解决的绝不动内核。2.3 选型原则先定义“要骗过谁”再决定写哪层代码接到类似需求我一般会先让对方明确一个问题你说的“隐藏”是让普通用户看不见还是让排查工具认不出来还是让安全日志里没有记录这三个答案对应的代码量分别是一行、几十行和上百行。如果你的场景只是“常驻托盘程序别让用户觉得烦”窗口隐藏就够了别把 PE 里那套东西搬出来如果是在做恶意样本分析你需要的是不干扰样本行为的观察环境那 PEB 改名解决不了核心问题因为样本自己会调用 API 检查自己隐藏反而造成干扰如果你是在验证自己的检测规则那重点不是“隐藏”而是“隐藏后检测规则能不能从行为上把它揪出来”。一句话隐藏越深代码越重边界越窄。先定义被谁看再决定写不写代码这是最容易省时间的一步。3. PEB 改名最小实现运行时伪装进程名与命令行3.1 隐藏窗口一个 FindWindow ShowWindow 就够了先给一个最容易被误认为“进程隐藏”的起点隐藏窗口。如果目标程序有 GUI 窗口在 C 里三行代码就能让它“看不见”HWND hTarget ::FindWindowW(nullptr, L某程序主窗口标题); if (hTarget) { ::ShowWindow(hTarget, SW_HIDE); }这段代码的逻辑很简单FindWindowW 按窗口标题找顶层窗口ShowWindow 把它的 WS_VISIBLE 样式去掉。调用后桌面上没有窗口但任务管理器里进程还在网络连接还在CPU 占用还在。它改变的只是“用户肉眼可见的形态”不是进程的存在性。窗口隐藏的意义在于它能瞬时生效不需要提前注入、不需要重启而且被隐藏的程序可以继续正常绘制窗口内容只是看不到而已。但它对控制台程序、服务程序、无窗口程序完全没有效果这类程序从出生起就没有窗口谈不上隐藏。把它当成进程隐藏的入门热身可以当成解决方案远远不够。3.2 修改 PEB 的 100 行代码把进程名改成 svchost 的样子真正能在“可执行程序层面”骗过多数工具的做法是改 PEB 里的 ImagePathName 和 CommandLine。核心思路是进程自己通过 GetCommandLineW 或 NtQueryInformationProcess 拿到的命令行来自 PEB 中的 RTL_USER_PROCESS_PARAMETERS 结构我们把它直接改掉就能让所有从用户态读这个结构的工具看到一套伪造的参数。下面这段代码是我在实验室里常用的最小实现用动态获取函数地址的方式写出MSVC 和 MinGW 都能编译// peb_spoof.cpp : 修改当前进程 PEB 中的 CommandLine #include windows.h #include winternl.h #include stdio.h // 动态获取 NtQueryInformationProcess避免连接 ntdll.lib typedef NTSTATUS(NTAPI* pNtQueryInformationProcess)( HANDLE, ULONG, PVOID, ULONG, PULONG); // PEB 中 ProcessParameters 的偏移按位数区分 #ifdef _WIN64 #define PEB_PARAMS_OFFSET 0x20 #else #define PEB_PARAMS_OFFSET 0x10 #endif // RTL_USER_PROCESS_PARAMETERS 中 CommandLine 字段偏移 #ifdef _WIN64 #define CMDLINE_OFFSET 0x70 #else #define CMDLINE_OFFSET 0x40 #endif // UNICODE_STRING 中 Buffer 指针的偏移 #ifdef _WIN64 #define STRING_BUFFER_OFFSET 8 #else #define STRING_BUFFER_OFFSET 4 #endif bool SpoofCommandLine(const wchar_t* fakeCmd) { HMODULE nt GetModuleHandleW(Lntdll.dll); auto fn (pNtQueryInformationProcess)GetProcAddress(nt, NtQueryInformationProcess); if (!fn) return false; // 1. 查询当前进程的 PEB 地址 PROCESS_BASIC_INFORMATION pbi{}; if (fn(GetCurrentProcess(), 0, pbi, sizeof(pbi), nullptr) ! 0) return false; // 2. 读取 PEB 中的 ProcessParameters 指针 BYTE* peb (BYTE*)pbi.PebBaseAddress; BYTE* params *(BYTE**)(peb PEB_PARAMS_OFFSET); // 3. 在堆上分配新字符串避免栈上局部变量被回收 size_t bytes (wcslen(fakeCmd) 1) * sizeof(wchar_t); wchar_t* store (wchar_t*)HeapAlloc(GetProcessHeap(), 0, bytes); if (!store) return false; wcscpy(store, fakeCmd); // 4. 改写 UNICODE_STRING 的长度字段和 Buffer 指针 USHORT len (USHORT)(wcslen(fakeCmd) * sizeof(wchar_t)); *(USHORT*)(params CMDLINE_OFFSET) len; *(USHORT*)(params CMDLINE_OFFSET 2) len sizeof(wchar_t); *(wchar_t**)(params CMDLINE_OFFSET STRING_BUFFER_OFFSET) store; return true; } int main() { wprintf(L[before] %s\n, GetCommandLineW()); if (SpoofCommandLine(LC:\\Windows\\System32\\svchost.exe -k netsvcs)) { wprintf(L[after ] %s\n, GetCommandLineW()); } Sleep(60000); // 保持进程存活方便观察 return 0; }代码逻辑分成四步先用 NtQueryInformationProcess 取 PEB 地址再从 PEB 的固定偏移取出 ProcessParameters 指针接着在堆上分配一块能容纳新命令行字符串的内存最后直接改写 CommandLine 这个 UNICODE_STRING 的长度和 Buffer 指针。这里有个关键点必须说明UNICODE_STRING 是自定义的结构Length 字段是字节数不是字符数所以 wcslen 结果要乘以 sizeof(wchar_t)。Buffer 的数据类型是指针在不同位数下占 4 或 8 字节因此 STRING_BUFFER_OFFSET 也要跟着变。再有HeapAlloc 分配的内存不要主动释放因为进程运行期间仍可能有人来读这个 Buffer释放会导致悬空指针。运行这个程序后控制台里第二次打印的命令行已经变成伪造值。此时用 Process Explorer 看该进程的“命令行”列显示出来的也是 svchost 那串。这就是 PEB 改名能做到的事让靠读取用户态参数的观察者看到幻象。3.3 用 tasklist 与 Process Explorer 验证伪装效果写完代码可以先做一轮快速自检。开一个管理员 CMD用 tasklist 查看进程名tasklist /v /fo csv | findstr /i peb_spooftasklist 的“映像名称”列来自 EPROCESS不会因为改了 PEB 而变化所以你仍然能看到 peb_spoof.exe 的名字。这一步是让读者建立认知改了 PEB 不等于改名。再打开 Process Explorer找到该进程查看“命令行”列这里应该已经是伪造的 svchost 参数。如果显示的还是真实命令行大概率是偏移算错或者程序是 32 位却用了 64 位偏移。拿不到预期结果时先从编译产物是 x64 还是 x86 查起再检查 peb_spoof.exe 运行时是否真的执行到了 SpoofCommandLine。这个对比验证的意义在于让你直观感受到“不同数据源之间的割裂”。真实业务里做隐藏方案最难的不是写代码而是理解各种工具到底信任哪一份数据然后决定自己要不要把每一份都处理掉。4. 启动早期伪装用 CREATE_SUSPENDED 让日志只看到“马甲”4.1 为什么“出生前改名”比“出生后改名”更接近目的第 3 章的运行时改名有一个天然短板进程是用真实 exe 启动的启动那一刻系统监控工具已经通过内核回调记录了一条进程创建事件事件里带的原始路径和命令行是真实值。你运行中再去改 PEB日志快照早就生成完了等于藏着给监控看。常见做法是改用挂起创建CreateProcess 时传入 CREATE_SUSPENDED让子进程的主线程先不运行这个时候 PEB 已经初始化完毕进程参数也已经写入但还没有人触发主线程入口代码。趁这个窗口期用 WriteProcessMemory 跨进程改写子进程 PEB 里的 CommandLine 和 ImagePathName改完再 ResumeThread这个进程就“一出生就披着马甲”。和注入方案相比挂起改 PEB 做的是“数据修正”而不是“代码注入”没有往目标进程写入可执行代码检测面小很多。缺点也明显CreateProcess 时 lpApplicationName 必须是你真实程序路径所以早先一步到达的驱动回调如果有拿到的还是真实路径它影响的是“依赖进程参数块做监控的日志”做不到骗过内核层。4.2 创建挂起进程并在 Resume 前改写 PEB 的完整代码下面的关键函数可以拉出来直接用到你自己的工程里。它做的事情是父进程创建子进程时挂起然后查询子进程 PEB 地址跨进程读取 ProcessParameters再分配一段子进程内存写入伪造命令行最后恢复主线程。// spawn_spoof.cpp : 创建挂起进程跨进程改写 CommandLine 后恢复运行 #include windows.h #include winternl.h #include stdio.h typedef NTSTATUS(NTAPI* pNtQueryInformationProcess)( HANDLE, ULONG, PVOID, ULONG, PULONG); #ifdef _WIN64 #define PEB_PARAMS_OFFSET 0x20 #define CMDLINE_OFFSET 0x70 #define STRING_BUFFER_OFFSET 8 #else #define PEB_PARAMS_OFFSET 0x10 #define CMDLINE_OFFSET 0x40 #define STRING_BUFFER_OFFSET 4 #endif bool SpoofChildCommandLine(HANDLE hProcess, const wchar_t* fakeCmd) { HMODULE nt GetModuleHandleW(Lntdll.dll); auto fn (pNtQueryInformationProcess)GetProcAddress(nt, NtQueryInformationProcess); if (!fn) return false; // 1. 查询子进程 PEB 地址 PROCESS_BASIC_INFORMATION pbi{}; if (fn(hProcess, 0, pbi, sizeof(pbi), nullptr) ! 0) return false; BYTE* peb (BYTE*)pbi.PebBaseAddress; // 2. 读取 PEB 里的 ProcessParameters 指针 BYTE* params nullptr; SIZE_T read 0; if (!ReadProcessMemory(hProcess, peb PEB_PARAMS_OFFSET, params, sizeof(params), read)) return false; // 3. 在子进程地址空间分配新字符串缓冲区 size_t bytes (wcslen(fakeCmd) 1) * sizeof(wchar_t); PVOID newBuf VirtualAllocEx(hProcess, nullptr, bytes, MEM_COMMIT | MEM_RESERVE, PAGE_READWRITE); if (!newBuf) return false; if (!WriteProcessMemory(hProcess, newBuf, fakeCmd, bytes, read)) return false; // 4. 改 UNICODE_STRING 的长度与 Buffer 指针 USHORT len (USHORT)(wcslen(fakeCmd) * sizeof(wchar_t)); USHORT maxLen len sizeof(wchar_t); WriteProcessMemory(hProcess, params CMDLINE_OFFSET, len, sizeof(len), read); WriteProcessMemory(hProcess, params CMDLINE_OFFSET 2, maxLen, sizeof(maxLen), read); WriteProcessMemory(hProcess, params CMDLINE_OFFSET STRING_BUFFER_OFFSET, newBuf, sizeof(newBuf), read); return true; } int main() { STARTUPINFOW si{ sizeof(si) }; PROCESS_INFORMATION pi{}; wchar_t fakeCmdLine[] LC:\\Windows\\System32\\svchost.exe -k netsvcs; BOOL ok CreateProcessW( LE:\\lab\\sleeper.exe, // 真实程序只 Sleep 的测试进程 fakeCmdLine, // 展示给监控日志的“马甲” nullptr, nullptr, FALSE, CREATE_SUSPENDED, // 关键先挂起 nullptr, nullptr, si, pi); if (!ok) return 1; SpoofChildCommandLine(pi.hProcess, fakeCmdLine); ResumeThread(pi.hThread); CloseHandle(pi.hThread); CloseHandle(pi.hProcess); return 0; }调用流程是固定的CreateProcessW 带 CREATE_SUSPENDED 创建子进程SpoofChildCommandLine 完成三处跨进程写入ResumeThread 放行。注意 CreateProcessW 第一个参数是真实 sleeper.exe 的路径第二个参数是你要显示的马甲命令行两者不一致是故意的。这段代码里最容易写错的是 ReadProcessMemory 读指针的环节。ProcessParameters 是一个 4 或 8 字节的指针必须按指针宽度读同时第二个参数传的是params CMDLINE_OFFSET而不是params CMDLINE_OFFSET 8因为我们要改的是 UNICODE_STRING 的 Length 字段指针字段在 Length 之后偏移 4 或 8 字节。编译时务必让父子进程是同一位数否则偏移全乱。4.3 注入完成后的进程视野变化跑完上面的程序后在 Process Explorer 里看子进程的“映像名称”列仍然是 sleeper.exe这一点改变不了“命令行”列显示 svchost 的马甲系统监控工具记下的创建事件如果它读取的是 ProcessParameters 里的初始快照则能看到与命令行一致的假值如果它拦截的是更底层的路径信息则仍会暴露真实文件路径。这个方案不是万能的它解决的是“启动早期快照被记录”的问题不能解决“内核层已经拿到真实映像名”的问题。但它在实战里已经足够改变很多日志分析结论排查人员顺着命令行线索走会先看到一个 svchost而不是一个不知名的 sleeper。至于这个 svchost 的行为是否合理那是行为和舆情层面的分析不在进程隐藏技术范围内。5. 进程隐藏避坑记录5 个反复出现的坑与排查办法5.1 改了 PEB任务管理器还是旧名字现象程序已经执行了 SpoofCommandLineProcess Explorer 里的命令行也变了但任务管理器“进程”页显示的名称纹丝不动。原因任务管理器的进程名列来自内核 EPROCESS.ImageFileName它由加载器在进程创建时从 exe 路径写入属于内核数据结构用户态怎么改都碰不到。解决接受这个边界。想让任务管理器显示别的名字只有两条路改 EPROCESS需要内核权限或者不创建独立进程改用宿主注入。在纯用户态方案里PEB 改名目标应该是“命令行/路径”而不是“进程名”。5.2 64 位系统上断链后直接蓝屏现象写了一个驱动把目标 EPROCESS 从 ActiveProcessLinks 双向链表里摘掉跑了几分钟系统直接蓝屏转储代码与内核保护机制相关常见 0x109 系列。原因64 位内核有内核结构完整性守护机制周期性校验活动进程链表等关键结构链表被手动摘除后校验失败直接触发蓝屏。解决放弃在 64 位系统上做断链。如果只是做检测规则验证改用过滤的方式拦截特定进程的枚举请求或者干脆用第 4 章的启动早期伪装方案别拿宿主机试这个一点也不值得。5.3 安全软件报的不是“隐藏”是“行为”现象程序已经伪装成 svchost 并且命令行也改了运行一会儿还是被安全产品拦截提示“可疑进程行为”。原因进程名和命令行只是静态特征安全产品的行为检测会综合分析一个系统服务进程为什么没有合法签名、为什么访问了用户目录、为什么建立外连。伪装的名字只是外套行为还是原来的样子。解决把实验程序里那些和隐藏无关的敏感调用先摘掉比如删掉网络请求、减少频繁读写临时目录、不要给自己提权。在验证阶段可以先把它放到白名单目录跑通流程确认隐藏技术本身有效再逐步增加行为干扰。5.4 伪装的进程名和真实场景撞车现象把测试程序伪装成 svchost.exe结果排查时发现这台机器上一堆 svchost你的伪装进程混在里面反而引起了怀疑。原因svchost 是高频出现的高危关注对象安全分析师和脚本都会优先筛它。伪装成“常见名字但不常见行为”的进程往往比伪装成“冷门名字”更显眼。解决选一个这台机器上确实存在、且工作和你的测试程序行为相近的进程做马甲。比如测试程序只读写文件就找同名文件访问频繁的进程如果只是驻留睡眠找后台服务比找交互程序合适。名字要服务于行为而不是越“系统”越好。5.5 32 位程序伪装 64 位进程名导致 PEB 布局对不上现象用 32 位编译的测试程序去改自身 PEB结果写进去之后 GetCommandLineW 返回乱码或者 Process Explorer 显示空命令行。原因32 位进程在 64 位系统上它的 PEB 和 RTL_USER_PROCESS_PARAMETERS 都是 32 位布局ProcessParameters 偏 0x10CommandLine 偏 0x40Buffer 指针 4 字节。如果把 64 位的偏移套进去写的就是错误的内存区域。解决编译前统一用 _WIN64 宏区分偏移不要靠“系统是 64 位”来判断要看“进程自己是几位”。测试代码全部编译成 x64 可以省掉一半麻烦但如果目标环境有 32 位进程还是要单独编一版。6. 用防御方视角验证隐藏Sysmon 日志里藏不住的真相顺着“我要骗过谁”的思路最后验证不能只看 Process Explorer还得看日志。最简单有效的方法是用 Sysmon 的进程创建事件把它开起来再跑一次你的伪装程序然后查事件里到底记了什么。如果日志里记录的 ImagePath 和 CommandLine 与伪装后的一致说明第 4 章的做法对这类监控视角有效如果记录的是 sleeper.exe 真实路径说明该监控组件采集数据的时机早于你的修改。用下面这段 PowerShell 能快速过滤出相关事件Get-WinEvent -FilterHashtable {LogNameMicrosoft-Windows-Sysmon/Operational; Id1} -MaxEvents 200 | Where-Object { $_.Message -match sleeper -or $_.Message -match svchost } | Format-List TimeCreated, Message把它当成一个自检工具而不是绕过工具。正常的验证流程是在干净虚拟机里开启 Sysmon → 跑一次隐藏方案 → 查日志 → 和 Process Explorer 的显示做对比 → 记录哪些数据源看到真实值、哪些看到马甲。往复几次你就能画出一张“本方案对哪些观察者有效”的覆盖表后续再换系统版本或换监控组件只需要重跑同一套流程。我自己的习惯是每次做这类实验都强制自己在关闭虚拟机快照之前把日志和工具输出全拷出来归档。因为隐藏方案经常只对特定版本的系统和特定工具生效换一个环境就翻车没有当时的日志对照排查起来全靠猜。这个习惯帮我避掉过很多次“改完代码发现不是偏移错是验证环境没对上号”的麻烦。希望帮到你。本文还有配套的精品资源点击获取
