什么是DLL劫持，以及为何您的新AI插件可能是最简单的入侵方式

今年我花了很多时间观察组织如何将AI集成到从未设计来处理它的工具中。大部分风险都以数据暴露或模型行为的形式讨论。较少关注的是更基础的东西：安装过程本身。当团队将AI插件附加到遗留桌面应用程序时，通常会添加一个新的可执行文件、一组新的依赖项，以及Windows在该应用程序加载DLL时会搜索的一组新文件夹。对于多年来关注DLL劫持的人来说，这是一个熟悉的设置，而且这种情况越来越普遍。

什么是DLL劫持

Windows 应用程序并不总是从固定且受信任的位置加载其 DLL。当应用程序按名称而非完整路径请求 DLL 时，Windows 会按定义的目录顺序搜索。如果攻击者能在该搜索顺序中较早的位置放置一个具有正确文件名的恶意 DLL，应用程序就会加载攻击者的代码，而不是合法的库，并且会以应用程序已有的权限运行。

这不是一种新技术。多年来它一直是一个有文档记录的弱点，并且之所以持续有效，是因为许多桌面应用程序，尤其是较旧或设计不佳的应用程序，仍然按名称而非完整路径加载DLL。变化的是攻击面。每个安装在遗留应用中的插件、附加组件或AI驱动的扩展，都是对松散控制文件夹、未签名依赖项或搜索路径中可写目录的新机会。

DLL劫持示例

想象一个工程团队运行着一款已经使用了十年的CAD应用程序。IT部门添加了一个AI插件，为用户的图纸提供智能搜索和摘要层。像该类别中的许多软件一样，CAD应用程序通过名称而非完整路径加载其辅助DLL之一，这是一个设计决策，因为从未引起过明显问题，没人对此提出质疑。

攻击者即使仅通过网络钓鱼、被攻破的账户或其他立足点获得对该机器的有限访问权限，也无需破解AI插件本身。他们只需将一个同名的DLL放入应用程序搜索顺序中更靠前的文件夹。下次用户启动应用时，应用会加载攻击者的DLL，恶意代码便以与CAD应用相同的权限运行。无需针对AI插件的漏洞利用。插件只是给攻击者提供了一个新的工作文件夹。

如何检测DLL劫持

检测通常归结为观察不符合合法DLL应有行为的情况：

• 应用程序从不寻常或用户可写的目录按名称加载DLL，而不是从完整的受信任路径加载
• 通过如rundll32.exe等工具启动的未签名DLL，是一种常见的劫持模式
• 文件完整性监控 标记不应在补丁周期之间更改的DLL变更
• Endpoint日志显示合法的父进程，随后是意外或未签名的DLL加载

另一种方法是通过将搜索路径中任何DLL（实际上是所有文件）的哈希值与已知的良好来源进行比较，来检查文件的完整性。

这并不是什么新奇的东西。这是安全团队已经应用于文件完整性和进程监控的相同纪律，专门针对第三方插件和遗留应用程序倾向于引入弱加载顺序行为的文件夹。

如何防止DLL劫持

预防通常分为两类：修复应用程序和控制允许在endpoint上运行的内容。

修复应用程序意味着使用完全限定的路径加载DLL，收紧文件夹权限，防止标准用户写入应用程序搜索的目录，并保持供应商软件的补丁更新。这是正确的长期解决方案，但依赖于每个供应商完成工作，而许多最容易受到此问题影响的应用程序恰恰是最不可能快速打补丁的。

控制端点意味着不必等待供应商。 PolicyPakPolicyPak 的 DLL Hijack Protection，是 Least Privilege Manager 的一部分，运行在三种模式之一：审计模式，记录风险 DLL 加载但不阻止，以便团队先评估暴露；安全提升模式，阻止提升进程的风险 DLL 加载；反劫持模式，将阻止扩展到从受保护位置（如 Program Files）运行的常规进程。它直接阻止两种最常见的劫持模式：应用程序通过非限定名而非完整路径加载 DLL，以及通过 rundll32.exe 等工具启动的未签名 DLL。当合法 DLL 被误拦截时，管理员可以通过文件路径、数字签名或文件哈希允许该 DLL，而无需完全关闭保护。

如果您的团队正在向早于本次讨论的应用程序推出 AI 功能，DLL 劫持应被列入风险登记册，不是作为假设，而是作为这些插件安装方式的近期后果。