攻击者把一个精心构造的完成DLL文件丢进目标程序的启动目录，然后等管理员双击那个程序。持漏就这么简单。洞利没有漏洞扫描，完成没有流量劫持，持漏甚至不需要接触目标机器——只要你能让文件落地，洞利系统就会替你完成剩下的完成工作。DLL劫持的持漏可怕之处在于，它不是洞利利用某个数学层面的缺陷，而是完成利用Windows自身的设计逻辑：程序加载DLL时，会按固定顺序搜索目录，持漏而当前工作目录往往排在系统目录之前。洞利

我见过一个真实案例。完成某企业内网部署了一款老旧的持漏财务软件，版本停留在2016年，洞利没人敢升级，因为业务部门抱怨新界面“不会用”。安全团队做渗透测试时，发现该软件启动时会加载一个名为“common_utils.dll”的组件——这个DLL既不在软件安装目录，也不在系统目录，纯粹靠Windows的搜索顺序去当前目录碰运气。测试人员往软件快捷方式所在的共享文件夹里放了一个伪造的common_utils.dll，里面只写了三行代码：创建管理员用户、加入本地组、删除自身。第二天早上，财务总监双击桌面图标，他的电脑就多了一个隐藏的管理员账号。整个利用过程耗时不到两秒，日志里只有一条正常的DLL加载记录。

为什么这种老掉牙的技术到现在还能奏效？答案藏在两个地方。一是开发者习惯：很多人用Visual Studio写代码时，默认链接方式就是“延迟加载”或“隐式加载”，根本没指定DLL的绝对路径，代码能跑就行。二是系统兼容性包袱：微软不敢轻易修改DLL搜索顺序，怕把全世界的老软件全搞崩。于是这个中间地带就成了攻击者的游乐场——你不需要多高深的技巧，会编译一个带导出函数的DLL就够了，甚至用Python的ctypes库都能伪造。

实际利用时有个细节特别讽刺：很多安全软件会监控DLL加载行为，但它们只盯着系统目录和启动项，对“当前目录下的DLL”基本不设防。因为正常软件很少从当前目录加载关键组件，安全产品觉得没必要浪费性能去监控这个路径。攻击者恰恰利用了这种“安全盲区”。我做过一个小实验：把一个伪造的version.dll放到某聊天软件的安装目录旁，软件启动后照样正常工作，只是多加载了一个恶意模块——没有任何弹窗，进程列表里看不出异常，只有用Process Monitor才能抓到那个瞬间的加载记录。

防御手段其实不复杂，但执行起来总被业务部门抵制。最有效的方法是修改注册表里的KnownDLLs列表，把常用系统DLL全部加进去，强制系统从System32加载。可这招对第三方软件无效，因为它们的私有DLL不在列表里。更实在的做法是给程序打补丁，用绝对路径加载所有依赖项——但这意味着要重新编译，很多厂商宁愿发个安全公告也不愿意动代码。所以现实情况是：你检查一个程序是否容易受DLL劫持影响，只需要看它安装目录下有没有“裸奔”的DLL引用，有的话，基本就能判定可利用。整个评估过程不超过十分钟。

最后说句得罪人的话：DLL劫持之所以长期存在，某种程度上是软件行业集体懒惰的结果。开发者懒得写绝对路径，安全厂商懒得监控所有加载点，用户懒得更新软件——三方互相“信任”，结果就是攻击者捡了个大便宜。你不需要成为什么黑客大神，只要会看Process Monitor的日志，就能在大多数Windows应用里找到类似的利用点。这技术不酷，但有效。有效到让人怀疑：我们到底是在用系统，还是在给系统打工。