2026-10-07 04:42:55 网络安全文章来源：ZONE.CI 全球网 0 阅读模式

文章总结： 文档披露了一起针对VS编译时触发的供应链投毒后门事件。攻击者在vcxproj文件中植入恶意initialtargets与内联C#代码，利用MSBuild构建进程执行经多层混淆的x64下载器shellcode，联网释放并执行伪装文件。作者确认该后门与项目功能无关，属人为植入，并提醒检查本机是否已被植入及外联痕迹。 综合评分： 85 文章分类： 恶意软件,供应链安全,漏洞分析,应急响应

惊心！歹毒！遭遇【VS编译时触发后门】保卫战

原创

MicroPest MicroPest

MicroPest

2026年10月6日 19:11 安徽

在小说阅读器读本章

去阅读

在公众号小说中沉浸阅读

今日，在研究一个带“COM BypassUAC + 反射式 DLL 注入功能”的源代码时，遭遇了“编译VS源代码时触发后门”的惊心动魄时刻，且听我分析道来。

源代码下载下来后，我习惯性地用vs2022打开了reflective_dll.sln直接编译，发现了报错项2个。现在有了AI，直接用AI来检查下代码报错，这下发现大问题了，在reflective_dll.vcxproj里包含了一段后门shellcode，它会在你编译时直接触发这个后门，用心之歹毒。****

一、结论：这是人为植入的第三方后门，与项目功能无关，专门等编译时触发

我可以明确排除「项目自带功能」这一可能，依据如下：

1. 与项目业务逻辑完全无关

项目本身是 COM BypassUAC + 反射式 DLL 注入（C 代码，src/ReflectiveDll.c / ReflectiveLoader.c）。而这段 shellcode 是一个 x64 联网下载器：下载 SearchFilter.7z 到 %LOCALAPPDATA%\Microsoft\Feeds，释放伪装成 C:\ProgramData\sevenZip\7z.exe 解压，再执行 SearchFilter.exe。两者毫无代码或功能关联——项目里没有任何一行代码引用、加载或需要它。

2. 实现手法是典型的「后门/投毒」特征，而非工程配置

藏在 .vcxproj 的 InitialTargets + CodeTaskFactory 里——这是供应链投毒的经典手法（利用 MSBuild 在构建进程内执行任意代码），而非任何正常工程会用到的配置；
载荷经 Base64 + 三轮 XOR + GZip 层层混淆，并调用 VirtualAlloc/VirtualProtect/CreateThread 在内存中直接执行，刻意规避静态查杀；
shellcode 自身无导入表，靠 PEB 遍历 + 哈希 动态解析 API，且用伪装 Chrome UA、伪装成 7-Zip / 系统 Feeds 目录——这些都是恶意软件的规避与伪装技术，正常构建脚本绝无必要。

3. 工程内其他文件全部干净，唯独 `.vcxproj` 被动过

.sln

、.vcxproj.filters、.vcxproj.user、.gitignore、全部 .c/.h、README.md、LICENSE —— 均无任何异常；
后门只存在于 reflective_dll.vcxproj 这一处。若是项目自带功能，必然会在 README 中说明、并配套源码；实际却完全隐形。
.vcxproj

其余内容（各平台配置、宏定义）是正常且专业的，唯独首尾被插入了两段与工程无关的代码——属于「在干净工程上追加后门」的篡改特征。

4. 「等人来编译」的意图非常明确

InitialTargets 的语义就是任何构建动作前自动执行。它不依赖用户做任何额外操作——只要有人：

用 Visual Studio 打开并点「生成」，或
命令行跑 msbuild / devenv /build，

后门就会在编译进程内静默运行。这正是「布好陷阱、等人上钩」的定向投毒形态。

5. 本机已经触发过一次（重要）

x64/Debug/ 下有今天 17:46 的构建产物（.obj、.tlog、unsuccessfulbuild 等），说明该工程已被本机 MSBuild 执行过。unsuccessfulbuild 表明编译在 C2440 报错处失败了——但 InitialTargets 在编译之前就已执行，所以后门的 shellcode 当时已经跑过一次。

需要你注意的风险

本机可能已被植入

：检查这两个路径是否存在落地物

C:\ProgramData\sevenZip\7z.exe
%LOCALAPPDATA%\Microsoft\Feeds\SearchFilter.7z

/ SearchFilter.exe

可能已外联

：shellcode 运行即会联网下载，建议查该时段的网络连接/EDR 记录。
C2 地址未明文存储

：shellcode 里没有硬编码 URL（唯一的 131.0.0.0 是 UA 字符串的一部分），下载地址应是运行时拼接的，需动态分析或抓包才能拿到。

二、reflective_dll.vcxproj中的shellcode触发原理

后门就在 reflective_dll.vcxproj 里，分两处，配合构成一条完整的「构建期自动执行」链。

位置一：文件根节点（第 2 行）

<Project&nbsp;DefaultTargets="Build"&nbsp;ToolsVersion="4.0"&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;xmlns="..."&nbsp;InitialTargets="cYhrfP5mH9">

InitialTargets 是 MSBuild 的合法属性，作用是在本次构建的任何目标之前，先自动执行指定的 Target。这里被塞进了 cYhrfP5mH9 —— 也就是说，只要用 VS 打开并构建这个工程（甚至 msbuild reflective_dll.vcxproj），cYhrfP5mH9 都会先跑。

位置二：文件末尾（第 262–270 行，紧跟在合法内容 `ImportGroup` 之后）

<UsingTask&nbsp;TaskName="cG5nbiSNoL"&nbsp;TaskFactory="CodeTaskFactory"&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;AssemblyFile="$(MSBuildToolsPath)\Microsoft.Build.Tasks.Core.dll">&nbsp;&nbsp;<Task>&nbsp; &nbsp;&nbsp;<Code&nbsp;Type="Method"&nbsp;Language="cs"><![CDATA[&nbsp; &nbsp; &nbsp; ... 恶意 C# ...&nbsp; &nbsp; ]]></Code>&nbsp;&nbsp;</Task></UsingTask><Target&nbsp;Name="cYhrfP5mH9">&nbsp;&nbsp;<cG5nbiSNoL&nbsp;/></Target>

CodeTaskFactory 允许在工程文件里内联 C# 代码，MSBuild 会在构建进程内直接编译并执行它 —— 这是它的正常功能，被滥用来藏后门。这段内联 C# 做的正是：

解码载荷

：SlqjPF = 一大段 Base64（主数据），另有 3 个 32 字节 Base64 密钥 DOil5/xe3zp/roZ8G；
三轮 XOR 解密

：三个 for 循环各按 32 字节循环密钥 XOR 一遍；
GZip 解压

：GZipStream(... Decompress) → 得到最终 shellcode；
内存执行

（这是关键，全部通过 P/Invoke 调 Windows API）：

HQGzyT0

= VirtualAlloc，分配 0x3000(MEM_COMMIT|MEM_RESERVE) + 0x04(PAGE_READWRITE)；
Marshal.Copy

把 shellcode 写进去；
PBe2MlH

= VirtualProtect，改成 0x20(PAGE_EXECUTE_READ)；
D2k9VLa

= CreateThread（vfcyzgU = GetCurrentProcess）创建线程执行；
WaitForSingleObject(..., 0xFFFFFFFF)

等它跑完。

解码后是一段 12998 字节的 x64 shellcode（非 PE，直接可执行），内含 urlmon.dll/wininet.dll、伪装 UA Chrome/131.0.0.0，以及落地路径 C:\ProgramData\sevenZip\7z.exe、%LOCALAPPDATA%\Microsoft\Feeds\SearchFilter.exe —— 典型的「联网下载 + 伪装目录落地 + 执行」下载器。

一句话：后门 = 第 2 行的 InitialTargets="cYhrfP5mH9"（触发点）+ 第 262–270 行的 <UsingTask cG5nbiSNoL> 与 <Target cYhrfP5mH9>（执行体）。前者让后者在每次构建时自动运行，后者在构建进程内解密并执行远程加载器 shellcode。

三、shellcode功能

以下是从 reflective_dll.vcxproj 中提取并还原的完整结果。

解密结果

三个密钥（hex）：

5cc2ab1518392c8008104f857cfb673973c111b1cde6af6a35a66d7eb1e402db
66c766278d1ed308ed85b4ec1cae96f2761e921c6c292f7b40ad3dcef01ee0de
73a0d35c24ceb1c833c49fe4dfa83f621fa9c4c74f2ade214ccae9cdddd77a68

这段 shellcode 干什么（已反汇编确认）

入口（偏移 0）：

0x00: JMP +9525 &nbsp; &nbsp; &nbsp; &nbsp;; 跳到 0x253a 的主逻辑0x05: (strlen / strcmp / strcmpi 等辅助函数)0x34: PEB 遍历 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;; 标准 API 解析器

0x34 起是经典的 PEB → InMemoryOrderModuleList 遍历，通过模块名比较（OR AX,0x20 做大小写归一）定位 kernelbase.dll（偏移 0xe3）和 kernel32.dll（偏移 0xeb），再按哈希解析 API（偏移 0xf0 起 ror+累加的 0xd3 轮转哈希，与主程序同款手法）。

字符串区（偏移 0x2fa9–0x32xx）暴露全部意图：

行为总结：这是一段 x64 位置无关下载器（downloader）——

无导入表，通过 PEB 遍历 + 哈希动态解析 kernelbase.dll/kernel32.dll/urlmon.dll/wininet.dll/rpcrt4.dll 的 API；
用伪装 Chrome UA 联网下载载荷到 %LOCALAPPDATA%\Microsoft\Feeds\SearchFilter.7z；
释放/伪装成 C:\ProgramData\sevenZip\7z.exe 进行解压；
最终执行 SearchFilter.exe。

这与构建期后门「在 MSBuild 进程内 VirtualAlloc+VirtualProtect+CreateThread 直接内存执行」的设计完全吻合——任何一次编译该工程，本机就会被注入并运行这个下载器。

四、关于木马文件的分析

7z.exe和SearchFilter.exe，这两个文件放在各种云沙箱、杀毒软件查杀均不报毒，越来越有趣了。我坚信它们是有问题的，至于真相是什么，放在下一篇中了。

免责声明：

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

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

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

本文转载自：MicroPest MicroPest MicroPest《惊心！歹毒！遭遇【VS编译时触发后门】保卫战》