在Windows安全领域，DLL劫持（DLL Hijacking）始终是威胁排行榜上的"常客"。攻击者通过巧妙利用系统的DLL搜索机制，用恶意文件替换或伪装成合法DLL，让目标程序"主动"加载恶意代码。从早期的U盘病毒到现代的APT攻击，这种手法因隐蔽性强、成功率高而被广泛滥用。
本文将从Windows DLL搜索的底层逻辑出发，拆解劫持攻击的核心手法，结合实战案例给出可落地的防御方案，帮你建立一套完整的"反劫持"防线。
一、DLL劫持的"原罪"：搜索机制中的安全漏洞
DLL劫持的本质，是攻击者利用了系统在搜索DLL时的"信任链缺陷"。根据Windows加载器的工作流程，这些环节最容易被钻空子：
1. 搜索路径的"优先级陷阱"
未打包的传统Win32应用在默认安全模式下，搜索顺序中存在两个高危目录：
当前工作目录（CWD）：排在第11位，看似靠后，但用户常将程序放在桌面、下载目录等可写路径运行
PATH环境变量目录：包含大量用户可控路径（如C:\Users\XXX\AppData\Local\）
当程序调用LoadLibrary("xxx.dll")而未指定绝对路径时，加载器会按顺序扫描这些目录。若攻击者在优先路径中放置同名恶意DLL，就会被优先加载。
更危险的是，若程序通过SetDllDirectory将不可信目录加入搜索路径，或直接禁用安全模式（将CWD提到第8位），相当于给攻击者"开了后门"。
2. 依赖链的"传导漏洞"
即使主程序用绝对路径加载DLL，其依赖的子DLL仍可能使用相对路径加载。例如：
程序加载C:\app\main.dll（绝对路径）
main.dll依赖sub.dll，但未指定路径
加载器会按默认搜索顺序找sub.dll，若当前目录有恶意sub.dll则被加载
这种"嵌套依赖"导致的劫持更难察觉，很多知名软件的漏洞都源于此。
3. 系统机制的"兼容代价"
为兼容旧程序，Windows保留了一些风险机制：
.local文件重定向：应用目录若有app.exe.local，会强制优先加载同目录DLL，无视KnownDLLs
Manifest版本冲突：若清单中未明确定义依赖版本，可能加载到攻击者伪造的"兼容版本"
API集合的虚拟映射：虽然API Set是虚拟DLL，但对其解析过程的攻击仍有案例
这些机制本是为了解决"DLL地狱"，却成了攻击者的"武器库"。
二、攻击者的"三板斧"：主流劫持手法解析
1. 经典路径劫持：利用默认搜索顺序
攻击步骤：
分析目标程序依赖的DLL列表（用Dependency Walker或Process Monitor）
寻找程序未带绝对路径加载的DLL（如LoadLibrary("util.dll")）
在程序的搜索优先路径（如当前目录）放置同名恶意DLL
诱骗用户运行程序，恶意DLL被自动加载
典型案例：早期Adobe Reader曾因加载icucnv36.dll时未指定路径，被攻击者利用——将恶意DLL放入PDF文件所在目录，用户打开PDF即触发攻击。
2. 依赖链劫持：钻空子的"嵌套攻击"
攻击步骤：
用Process Monitor追踪程序加载的所有DLL及其依赖
找到某合法DLL（如plugin.dll）依赖的"弱引用"DLL（未绝对路径加载）
制作恶意版本的弱引用DLL，放在搜索路径中
当plugin.dll被加载时，自动触发恶意依赖的加载
防御难点：主程序即使规范了自身加载路径，也无法控制第三方DLL的依赖行为。例如某视频播放器使用合法的codec.dll，但该 codec 依赖parser.dll，攻击者只需替换parser.dll即可。
3. 路径混淆：利用系统重定向与别名
攻击技巧：
大小写混淆：Windows路径不区分大小写，可制作USER32.dll伪装系统user32.dll（但KnownDLLs会阻止）
短文件名滥用：利用8.3格式，如myapp.dll的短名为MYAPP~1.DLL，可放置同名恶意文件
UNC路径欺骗：在网络环境中，诱导程序加载\\attacker\share\legit.dll
案例：某企业软件在加载config.dll时，未处理短文件名，攻击者上传CONFIG~1.DLL到当前目录，成功劫持。
三、防御体系：构建多层级"反劫持"防线
1. 基础防御：规范DLL加载方式
核心原则：尽可能消除"模糊路径"加载，让每一个DLL的来源都可预测。
使用绝对路径加载：
// 错误：依赖搜索路径，存在风险
HMODULE hDll = LoadLibrary(L"module.dll");
// 正确：明确指定路径，杜绝歧义
WCHAR dllPath[MAX_PATH];
GetModuleFileName(NULL, dllPath, MAX_PATH);
PathRemoveFileSpec(dllPath); // 获取exe所在目录
PathAppend(dllPath, L"module.dll");
HMODULE hDll = LoadLibrary(dllPath);
控制依赖链加载行为：
加载主DLL时使用LOAD_LIBRARY_SEARCH_DLL_LOAD_DIR标志，强制其依赖项从同目录加载：
HMODULE hMainDll = LoadLibraryEx(L"C:\\app\\plugin.dll",
NULL,
LOAD_LIBRARY_SEARCH_DLL_LOAD_DIR);
清理搜索路径：
移除当前目录和PATH等不可信路径：
// 移除当前目录
SetDllDirectory(L"");
// 仅允许系统目录和指定目录
SetDefaultDllDirectories(LOAD_LIBRARY_SEARCH_SYSTEM32 | LOAD_LIBRARY_SEARCH_USER_DIRS);
AddDllDirectory(L"C:\\app\\trusted_plugins");
2. 进阶防御：验证DLL身份与完整性
数字签名校验：
加载前用WinVerifyTrust检查DLL是否带有可信签名：
BOOL IsDllTrusted(LPCWSTR dllPath) {
WINTRUST_FILE_INFO fileInfo = {0};
fileInfo.cbSize = sizeof(WINTRUST_FILE_INFO);
fileInfo.pcwszFilePath = dllPath;
GUID policy = WINTRUST_ACTION_GENERIC_VERIFY_V2;
return WinVerifyTrust(NULL, &policy, &fileInfo) == ERROR_SUCCESS;
}
哈希校验：
对核心DLL预计算SHA256哈希，加载时比对：
// 伪代码：校验DLL哈希
if (CalculateFileHash(dllPath) !=预设哈希值) {
LogSecurityEvent("DLL被篡改");
return FALSE;
}
3. 环境加固：减少攻击面
采用打包应用：
迁移到MSIX/UWP等打包格式，其沙箱机制限制DLL只能来自应用包或声明的依赖，天然阻断路径劫持。
配置KnownDLLs：
对核心业务DLL，通过组策略将其加入KnownDLLs注册表项，强制从系统目录加载（需管理员权限）。
监控异常加载行为：
用ETW（事件跟踪）监控LoadLibrary调用，发现从用户可写目录加载DLL时报警：
# PowerShell示例：监控DLL加载事件
Get-WinEvent -FilterHashtable @{
LogName = "Microsoft-Windows-Debugger/LoadDll"
ID = 1
} | Where-Object { $_.Message -match "C:\\Users\\.*\.dll" }
四、实战排查：如何发现潜在的劫持风险
用Process Monitor追踪异常路径：
过滤条件设为"Process Name=目标程序.exe"且"Operation=Load Image"，检查DLL加载路径：
警惕从C:\Users\Public\、%TEMP%等可写目录加载的DLL
注意同一DLL被多次从不同路径加载（版本冲突隐患）
扫描依赖链中的"弱引用"：
使用dumpbin /dependents分析所有DLL的依赖，标记未带绝对路径的条目：
dumpbin /dependents C:\app\main.exe > dependencies.txt
重点检查第三方组件（如开源库、插件）的依赖是否规范。
检测不安全的API调用：
用静态分析工具（如IDA、Binary Ninja）扫描代码中是否存在：
无路径的LoadLibrary/LoadLibraryEx调用
危险的SetDllDirectory使用（如添加%TEMP%）
禁用安全搜索模式的SetDefaultDllDirectories调用
总结：防御的本质是"确定性"
DLL劫持攻防的核心，是围绕"DLL来源的确定性"展开的博弈。攻击者希望利用系统的"灵活性"制造模糊性，而防御者的任务就是通过技术手段消除这种模糊性：
从"依赖系统搜索"转向"明确指定路径"
从"信任所有来源"转向"只信任预定义目录"
从"被动加载"转向"主动验证身份"
对于商业软件，除了代码层面的加固，还应结合专业保护工具（如Virbox Protector）实现DLL加密、防篡改和运行时监控，形成"规范加载+身份验证+环境隔离"的三重防线，让攻击者无机可乘。