文章前言
dll劫持是一种用于执行恶意有效负载的流行技术，这篇文章列出了将近300个可执行文件，它们容易受到windows 10(1909)上相对路径dll劫持的攻击，并展示了如何使用几行vbscript绕过uac可以以提升的特权执行某些dll劫持。
DLL劫持首先，让我们弄清定义，从最广泛的意义上讲，DLL劫持是欺骗合法/受信任的应用程序以加载任意DLL，诸如DLL搜索顺序劫持、DLL加载顺序劫持、DLL欺骗、DLL注入和DLL侧面加载等术语经常被误认为是相同的，这些术语充其量只能描述DLL劫持的特定情况，但通常可互换使用，因此使用不正确，概括地说，DLL劫持更为准确，因为DLL劫持始终涉及从合法DLL接管DLL。
已经发现攻击者以不同的方式和不同的原因使用DLL劫持，动机包括执行可执行文件(通过受信任的可执行文件执行恶意代码可能不太会引起警钟，在某些情况下甚至绕过应用程序白名单功能，如AppLocker，获得持久性(如果目标应用程序已预先安装并定期运行，恶意代码也会正常运行)和特权提升(如果目标应用程序在提升的权限下运行，那么恶意代码也会运行)。
有多种方法可供选择，成功的方法取决于如何配置应用程序以加载其所需的DLL，可能的方法包括：
DLL替换：用恶意DLL替换合法的DLL，可以将其与DLL代理结合使用，以确保原始DLL的所有功能均保持不变DLL搜索顺序劫持：在不带路径的应用程序指定的DLL中，以特定顺序在固定位置搜索，通过将恶意的DLL放在实际DLL之前的搜索位置，劫持了搜索顺序，有时包括目标应用程序的工作目录Phantom DLL劫持：使用一个恶意的DLL来代替合法应用程序尝试加载的丢失/不存在的DLLDLL重定向：通过编辑改变，其中DLL被搜索的位置，例如%PATH%环境变量，或.exe.manifest/.exe.local文件，以包括含有恶DLLWinSxS DLL替换：用目标DLL的相关WinSxS文件夹中的恶意DLL替换合法的DLL，通常称为DLL侧面加载相对路径DLL劫持：将合法应用程序复制(并可以重命名)到恶意DLL旁边的用户可写文件夹中，在使用方式上，它与(签名)二进制代理执行有相似之处，这的一种变体是(带有某种逻辑上学上的称呼)"bring your own LOLbin"，其中合法应用程序带有恶意DLL(而不是从受害者计算机上的合法位置复制)。目标查找我们最大的挑战是找到可以在默认用户权限下被利用的易受攻击的可执行文件，在Windows上定位预安装的系统可执行文件时，通常不包括上面的第一个选项，而选项2和3中符合条件的任何文件夹都必须是用户可写的，选项4和5中的文件和文件夹也应该是用户可写的。
这就给我们留下了第六种选择，这是最脆弱的一种，这篇文章的其余部分将重点讨论。虽然通常不适合获得持久性或特权提升，但它经常在野外出现，以OceanLotus/APT32为例，据观察，2019年底，他们使用了合法的rekeywiz.exe和一个恶意的duser.dll，在这种情况下，恶意软件嵌入合法软件并将其放入磁盘，采用"bring your own LOLbin"的方法(另一种方法是从system32文件夹复制合法的可执行文件，假设该可执行文件尚未修补)。
为了防止此技术的新版本获得成功，有必要确定易受此类DLL劫持攻击的可执行文件，这将为红队提供新的执行手段，但更重要的是，它将允许threat hunters和防御者采取适当的措施来发现和预防。
查找方法
为了集中精力，我们默认存在可执行文件在C:windowssystem32中，在经过测试的Windows 10 v1909实例上，该实例总共包含616个可执行文件，如果仅考虑已签名的应用程序，则包含613个可执行文件。
为了监视每个进程尝试加载哪些DLL，我们将使用众所周知的Process Monitor工具，因此采取的方法是：
将受信任的可执行文件复制到用户可写的位置运行复制的可执行文件使用Process Monitor识别在用户可写位置中寻找的DLL
这允许我们识别每个应用程序查询的所有DLL，这些DLL将是所有潜在的可劫持DLL候选对象，但并不是所有的这些都会自动加载(并因此执行)，找出哪些DLL被正确加载的最可靠的方法是编译我们自己的DLL版本，并使它在成功加载时写入一个唯一的文件，如果我们对所有目标可执行文件和DLL重复上述方法，它将生成一个文件集合，告诉我们哪些DLL易受DLL劫持攻击。
编译现有DLL的自定义版本比听起来更具挑战性，因为如果缺少过程或入口点，许多可执行文件将不会加载此类DLL，诸如DLL Export Viewer之类的工具可用于枚举所有外部函数名和合法DLL的序号，确保我们编译的DLL遵循相同的格式将最大限度地提高它被成功加载的机会。
总而言之，所采用的方法是：
下表列出了windows 10 v1909上c:windowssystem32中易受"相对路径DLL劫持"变体DLL劫持攻击的所有可执行文件，在每个可执行文件的旁边是一个或多个可能被劫持的DLL，以及被调用的该DLL的过程，如前一节所述，这些目标不仅仅是理论目标，而且经过测试和确认是有效的，该列表包含287个可执行文件和263个独特的DLL。
https://github.com/wietze/windows-dll-hijacking/blob/master/dll_hijacking_candidates.csv
一些注意事项：
测试是通过简单地运行每个可执行文件来执行的，没有指定任何参数，也没有进一步的用户交互，这就解释了为什么xwizard.exeDLL劫持不在此列表中，因为它需要两个(任意)参数才能工作。有些应用程序附带了一个GUI，或者其他一些可视化元素，这些元素显示了执行的二进制文件，这还包括错误消息：所需的DLL可能丢失，而被劫持的DLL显然缺少原始功能，攻击者不太可能将此类应用程序作为DLL劫持的目标未考虑使用C++编写的原始版本的DLL结合UAC找到所有这些可执行文件后，这最多允许我们通过受信任的程序执行代码，但是如果与UAC旁路技术结合使用，也可以获得更高的权限。
用户帐户控制(UAC)作为一种安全功能在WindowsVista中引入，在以正常权限运行的进程提升到更高权限之前，通过提示请求用户确认，在用户抱怨在执行任意任务时会出现大量的UAC提示之后，Microsoft在Windows7中引入了自动提升功能，如果某些进程位于受信任的目录(如c:Windowssystem32)中，它会自动提升这些进程。
记住这一点，您可以尝试使用标记为自动提升的可执行文件来运行具有提升权限的任意代码，该可执行文件也容易受到DLL劫持的攻击，如前一节所示，大约有35个这样的可执行文件，要克服的问题是可信目录：自动提升可执行文件和自定义DLL都需要位于可信目录中，但它们都不是用户可写的。
有一些关于绕过UAC的优秀研究——我最喜欢的技术之一是使用尾随空格模拟受信任的目录(mocking of trusted directories using trailing spaces)，但归根结底，用户可以创建C:windows system32(注意第一个文件夹后面的空格)，并自动提升放置在该文件夹中的可执行文件，将其视为受信任的位置
这是否是一个适当的安全漏洞值得商榷-微软辩称不是，但鉴于大多数(非企业)Windows计算机默认使用"管理员帐户"，这至少是一个缺陷
无论哪种方式，这都为我们提供了一种极好的方法，通过这种方法，DLL劫持可以变得更加强大，需要注意的是不能在Windows上通过传统方式创建带有尾随空格的文件夹，你可以像最初的研究人员那样编译一些C代码行来完成这项工作，但事实证明VBScript实际上也可以为我们完成这项工作，下面的POC表明，只需几行代码，就可以实现这一点：
<code class="javascript">Set oFSO = CreateObject("Scripting.FileSystemObject")Set wshshell = wscript.createobject("WScript.Shell")' Get target binary and payloadWScript.StdOut.Write("System32 binary: ")strBinary = WScript.StdIn.ReadLine()WScript.StdOut.Write("Path to your DLL: ")strDLL = WScript.StdIn.ReadLine()' Create foldersConst target = "c:windows "target_sys32 = (target & "system32")target_binary = (target_sys32 & strBinary)If Not oFSO.FolderExists(target) Then oFSO.CreateFolder target End IfIf Not oFSO.FolderExists(target_sys32) Then oFSO.CreateFolder target_sys32 End If' Copy legit binary and evil DLLoFSO.CopyFile ("c:windowssystem32" & strBinary), target_binaryoFSO.CopyFile strDLL, target_sys32' Run, Forrest, Run!wshshell.Run("""" & target_binary & """")' Clean filesWScript.StdOut.Write("Clean up? (press enter to continue)")WScript.StdIn.ReadLine()wshshell.Run("powershell /c ""rm -r """"\?" & target & """""""") 'Deletion using VBScript is problematic, use PowerShell instead</code>下面的屏幕截图显示了脚本的执行情况
示例显示了合法的winsat.exe从模拟的受信任目录加载了恶意dxgi.dll之后没有任何UAC提示的情况下实现权限提升，在之前的表单中，自动提升成功的所有可执行/DLL组合都标记在第一列中，有超过160种可能的组合，有相当多的选择。
防御措施防止DLL劫持发生的一种简单方法是使应用程序始终使用绝对路径而不是相对路径，尽管某些应用程序(尤其是可移植的应用程序)并非总是能够做到这一点，但是位于system32同一文件夹中并依赖于这些DLL的应用程序没有其他借口，更好的选择(只有极少数Windows可执行文件似乎可以这样做)是在加载所有DLL之前先对其进行验证(例如，通过检查其签名)，这将在很大程度上消除该问题。
但是攻击者仍然可以被利用的合法/受信任应用程序的旧版本，因此，即使每个应用程序从现在开始在加载它们之前开始检查其DLL，我们仍然必须处理此问题。
因此，让我们把重点放在检测上，您可以从意外路径中搜寻前面提到的任何DLL的创建或加载，特别是在临时位置(如:%appdata%)中，毕竟加载DLL的(合法)应用程序的名称可以更改，但DLL的文件名始终是固定的，这里可以找到一个示例Sigma规则——它成功地检测到我们的DLL劫持，尽管正如您所看到的，它的伸缩性不是很好，很可能会出现误报，您可以采用一种更通用的方法，通过查找在意外位置是否存在Microsoft签名的二进制文件，以及此类Microsoft签名的二进制文件是否从意外位置加载DLL(无论位置如何)
最后，通过查找/windows/文件夹中或该空格中结尾的任何文件夹中的任何活动，可以轻松可靠地检测到已证明的UAC Bypass技术，如前所述，带有尾随空格的Windows文件夹无法通过常规方式创建，因此应该很少，并且总是可疑的，将您的UAC模式设置为"Always notify"(比默认值高一级)将阻止此方法和其他类似的UAC Bypass
相关阅读Applock：
https://docs.microsoft.com/en-us/windows/security/threat-protection/windows-defender-application-control/applocker/applocker-overview
DLL代理：
https://kevinalmansa.github.io/application%20security/DLL-Proxying/
DLL Side loading：
https://www.fireeye.com/content/dam/fireeye-www/global/en/current-threats/pdfs/rpt-dll-sideloading.pdf
Binary Proxy Execution：
https://attack.mitre.org/techniques/T1218/
DLL Export Viewer：
https://www.nirsoft.net/utils/dll_export_viewer.html
duser.dll：
https://twitter.com/0xCARNAGE/status/1203882560176218113
UAC Bypass by Mocking Trusted Directories：
https://medium.com/tenable-techblog/uac-bypass-by-mocking-trusted-directories-24a96675f6e
