通过在进程级别操纵环境变量，可以让受信任的应用程序加载任意 DLL 并执行恶意代码。这篇文章列出了近 100 个在 Windows 11 (21H2) 上易受此类 DLL 劫持的可执行文件；它演示了如何仅用三行 VBScript 就可以实现这一点。

环境变量

环境变量是在 1970 年代后期在 Unix V7 [ 1 , p.99-101 ] 中引入的，作为将信息传递给进程的一种简单方法。事实证明它很受欢迎：几年后它也被 PC DOS 2.0 [ 2 , p.477 ] 采用，最终演变成 Windows 操作系统。大约四十年后，环境变量仍然存在于 Windows 中——尽管其他发展，例如在 Windows 3.1 中引入注册表，已经在一定程度上改变了它的角色。

环境变量的概念很简单：键值对的集合在进程启动时可供进程使用，并可用作程序流的一部分。顾名思义，这些变量通常包含有关操作系统环境的信息。例如，如果将HOMEDRIVE具有值C:的环境变量提供给进程，它可能会使用该信息来决定将文件存储到C:驱动器，而不是任何其他驱动器。

显示环境变量在进程环境块 (PEB) 中的存储位置的图表。

Windows 中的每个进程都有一个关联的进程环境块 (PEB)，这是一种包含进程可用的各种信息的数据结构 [ 3 ]。如上图所示，环境变量是该结构的一部分：所有变量键和值都存储在单个字符串中，总共可以包含多达 32,767 (2 15 -1) 个字符 [ 4 ]。

至关重要的是，这意味着环境变量可以从进程更改为进程。当一个新进程启动时，父进程负责提供环境变量；这些将包含在新流程的 PEB 中。在大多数情况下，父级将简单地传递它自己启动时收到的环境变量。

这就引出了最父进程从哪里获取其环境变量的问题。不同的级别上设置环境变量：系统、用户和进程 [ 5 ]。在系统级别设置的环境变量适用于所有用户；用户级变量仅适用于当前用户。两者都存储在注册表中，前者在HKLM下，后者在HKCU下。当 Windows 启动时，它首先获取所有系统环境变量。当用户登录时，它会添加（并可能覆盖）任何用户环境变量。例如，HOMEDRIVE可能设置为C:系统级别，但个别用户可能已决定将其设置为D:. 当在该用户的上下文中启动一个新进程时，它将HOMEDRIVE=D:作为环境变量接收。最后，当在进程级别设置环境变量时，它会在单个进程中更改，尽管它可以传递给所有新的子进程，但它不像系统和用户级别的环境变量那样“持久” . 一个很好的例子是set HOMEDRIVE=X:在 Windows 命令提示符中运行；从此提示启动的任何新进程都将HOMEDRIVE=X:作为环境变量接收，但如果提示关闭并重新打开，该HOMEDRIVE变量将重置为其原始值。

Windows 开箱即用地定义了许多环境变量。尽管可以覆盖这些值，但这些值通常是在安装 Windows 时设置的，并且永远不会更改。包括系统组件在内的各种程序都依赖于这些变量；例如，某些程序使用SYSTEMROOT（或更旧的WINDIR）来获取 Windows 文件夹的路径，通常是C:\Windows.

劫持机会

如前所述，程序可能依赖这些“标准”环境变量来确定某些文件的路径。例如，事实证明有相当多的程序依赖SYSTEMROOT并WINDIR加载位于C:\Windows\System32文件夹中的 DLL。hostname.exe例如，尝试在%SYSTEMROOT%\System32\mswsock.dll运行时加载带有路径的 DLL；在正常情况下，这将解析为C:\Windows\System32\mswsock.dll. 因为这是一条绝对路径，所以不会调用 DLL 搜索顺序，因此人们可能会得出结论，这不会为我们提供 DLL 劫持机会 [ 6 ]。

然而，由于涉及到一个变量，这仍然可以被利用：如果要更改 to 的值SYSTEMROOT，C:\Evil程序将尝试加载C:\Evil\System32\mswsock.dll。如果攻击者将恶意 DLL 放在该位置，则会导致合法hostname.exe的 DLL 被欺骗加载攻击者的 DLL；因此，这毕竟为我们提供了一种新型的 DLL Hijacking

可以说，执行这种技术说起来容易做起来难。在系统或用户级别更改值的一个主要问题SYSTEMROOT是它实际上会破坏整个操作系统。如此多的系统组件依赖于SYSTEMROOT许多程序，如果您将其指向一个不包含它们所期望的 DLL 的目录，那么许多程序将无法正常工作。这会导致系统不稳定，甚至可能导致操作系统完全停止工作。因此，在大多数情况下，它首先会破坏执行 DLL 劫持的目的。

但是，正如我们所见，也可以仅在进程级别更改环境变量。这意味着只有那个单一的新进程将具有更新的值（或者，如果它碰巧创建了任何子进程，那么这些也可能）。因此，其他程序将不受影响，系统不应因此而变得不稳定。

[与其他 DLL 劫持方法  6 ]相比，这种方法有许多优点。例如，无需移动易受攻击的可执行文件：只需在从正常位置执行易受攻击的程序之前更改环境变量，就会导致加载恶意 DLL。此外，由于可以使用更改的环境变量启动程序，而不必执行诸如文件写入或注册表更改之类的嘈杂操作，因此检测机制不太可能检测到劫持本身。最后，可以通过多种方式使用更改的环境变量启动新进程。除了从已编译的可执行文件中执行此操作外，PowerShell、VBScript 和 JScript 等内置脚本引擎也支持这一点。

显示基于环境变量的 DLL 劫持工作的图表。

上图从高层次展示了成功的基于环境变量的 DLL 劫持可能是什么样子。VBScript 不必特别复杂；例如，下面的代码就足够了：

Set shell = WScript.CreateObject("WScript.Shell")
shell.Environment("Process")("SYSTEMROOT") = "C:\Evil"
shell.Exec("C:\windows\system32\hostname.exe")

在 Windows 11 上，在创建后运行此脚本C:\Evil\system32\mswsock.dll确实会hostname.exe加载 DLL，如下所示：

示例显示执行 VBScript 文件导致位于 C:\windows\system32 中的合法 hostname.exe 被执行并成功加载 mswsock.dll 的恶意版本。

在 PowerShell 中这样做可以通过$env:SYSTEMROOT="C:\Evil"在调用目标进程之前的简单语句来实现；但是，由于 PowerShell 本身也将使用这个新值，它可能会导致 PowerShell 在某些情况下中断。一种更可靠的启动新进程并且只更新新进程的环境变量的方法如下：

$s = New-Object System.Diagnostics.ProcessStartInfo
$s.FileName="C:\windows\system32\hostname.exe"
$s.EnvironmentVariables.Remove("SYSTEMROOT")
$s.EnvironmentVariables.Add("SYSTEMROOT", "C:\Evil")
$s.UseShellExecute = $false
$p = New-Object System.Diagnostics.Process
$p.StartInfo = $s
$p.Start()

识别易受攻击的可执行文件

要了解这种技术引入的问题的规模，应该通过针对更大的可执行文件组进行测试来调查这种类型的 DLL 劫持易受攻击的普遍程度。我们将自己限制在System32标准 Windows 11 安装文件夹中的签名可执行文件中，我们有一个包含 600 多个可执行文件的测试组。

一个简单的方法是在进程级别设置一个有趣的环境变量，例如SYSTEMROOTor WINDIR，将其指向一个唯一的目录，然后执行我们测试组中的每个可执行文件（没有任何特殊的命令行参数）。使用 Procmon [ 9 ]，可以有效地监控位于我们目录下的 DLL 加载尝试。尽管这立即为我们提供了许多可能的候选者，但它并没有为我们提供任何证据证明如果存在恶意 DLL 文件，它们实际上会被加载。

为此，将自定义 DLL 文件放在提供的位置并验证哪些文件已成功加载将是有益的。在通常解析为的SYSTEMROOT和的情况下，这意味着必须编译超过 20,000 个“自定义”DLL 文件才能使测试尽可能完整。编译自定义 DLL 并不像听起来那样简单 [ 6 ]，更不用说必须编译数千个 DLL。WINDIR``C:\Windows

在本研究采用的方法中，编译的 DLL 文件将在加载时将指纹文件写入磁盘，从而识别哪个 DLL 是由哪个进程加载的。如果这些“植入”DLL 都被复制到前面提到的唯一文件夹中，执行我们测试组中的每个可执行文件应该会生成许多正在创建的指纹文件；准确告诉我们哪些进程易受攻击，以及涉及哪些 DLL。

支持代码，可用于编译大量 DLL 以实现 DLL 劫持、利用开源工具并使用“DLL 导出代理”和“DLL 资源克隆”以最大限度地与测试的可执行文件兼容，可以在以下位置找到GitHub [ 10 ]。那里还提供了对所采用方法的更彻底和技术性的解释。

已确认易受攻击的应用程序

应用此方法后，下表列出了C:\windows\system32Windows 11 (21H2) 上易受基于环境变量的 DLL 劫持的所有可执行文件。第一列显示了更改的环境变量，第二列显示了易受攻击的应用程序，第三列显示了从更改的位置（相对于环境变量）加载的 DLL。如上一节所述，这些不仅仅是理论上的目标，它们经过测试并确认是有效的。该列表包括 82 个可执行文件和 91 个唯一的 DLL。

显示298个条目

搜索：

如果我们考虑到其他流行/标准软件，列表会变得更大：

显示76个条目

搜索：

上述列表并非详尽无遗；许多其他软件解决方案和可执行文件可能已经过测试，和/或在不同的情况下（例如，使用某些命令行参数、提升权限等）。上面列出的最重要的一点是，这种新型的 DLL 劫持通常存在于受信任的可执行文件中，这意味着检测个别情况不会扩展。

对特权升级和持久性的影响

考虑到所有这些，值得探索这种类型的 DLL 劫持是否以及如何与普通执行之外的策略结合使用。这种方法的一个关键方面是，易受攻击的可执行文件必须以与平常略有不同的方式启动，因为需要更新进程级环境变量。这就是使用它创建适当持久性的原因：传统的持久性机制，例如自动启动注册表项和启动文件夹中的 .LNK 文件，不提供指定执行目标命令时应设置的环境变量的方法。当然，仍然可以使用设置环境变量然后运行易受攻击的程序的“中间命令”，类似于运行之前讨论的 VBScript 或 PowerShell 脚本，

但是，存在允许设置环境变量的持久性机制。一个例子是 Windows 服务：很少使用的注册表值Environment可用于为服务的目标可执行文件（在 中指定ImagePath）设置进程级环境变量。如果目标可执行文件容易受到基于环境变量的 DLL 劫持的攻击，则可以以持久的方式利用它。

例如，请考虑C:\Windows\System32\spoolsv.exe在启动时执行的 Printer Spooler 服务。将Environment值设置为使用不同的路径覆盖SYSTEMROOT，然后重新启动服务或（因为默认启用打印机后台处理程序）重新启动机器，将导致spoolsv.exe使用操纵的路径。因为spoolsv.exe试图加载%SYSTEMROOT%\System32\mswsock.dll，它现在会被欺骗加载恶意版本的mswsock.dll. 事实上，由于服务在SYSTEM用户下运行，DLL 将在该上下文中执行。

在打印机 Spooler 服务中成功劫持 mswsock.dll 的 DLL 演示，将恶意版本的 DLL 加载为 SYSTEM。

由于更改服务注册表项需要管理权限，因此这不会导致“适当的”权限提升。毕竟，如果有人无论如何都提升了权限，他们也可以更改ImagePath值并以这种方式提升到SYSTEM。然而，改变ImagePath更有可能被防御机制检测到，而添加一个Environment价值可能会被忽视。此外，由于执行依赖于合法的服务可执行文件，因此以这种方式执行代码比运行恶意可执行文件或恶意 PowerShell 命令要隐蔽得多。此外，如果 DLL Hijacking 执行得当，服务将继续按预期工作，而更改服务的命令可能会导致功能缺失，从而导致系统不稳定。

使用这种类型的 DLL 劫持获得“适当的”权限提升甚至只是绕过用户帐户控制 (UAC) 是一项挑战。如前所述，在大多数情况下，新生成的进程从父进程获取它们的环境变量。有一个例外：当一个低完整性进程启动一个高完整性进程时，高完整性进程的环境变量被“重置”为系统级环境变量。因此，如果一个新进程导致 UAC 被调用，那么新进程将被提供系统级别指定的环境变量，而不管父进程本身已设置或在创建新进程时提供了哪些环境变量。Microsoft 可能做出此设计决定是为了通过环境变量限制权限提升机会的范围（例如%PATH%拦截 [ 11 ]); 不得不说，在这种情况下，它这样做是相当成功的。尽管有记录的应用程序覆盖此行为的案例 [ 12 ]，但这些案例似乎很少见。

预防和检测

与每种类型的 DLL 劫持一样，完全防止这种情况发生的最佳方法是让应用程序始终使用绝对且明确（即完全解析）的路径。有各种可用的 Windows API 调用，完全消除了依赖环境变量获取路径的需要；例如，函数GetWindowsDirectory[ 13 ] 是SYSTEMROOT变量的替代品。更好的做法是在将 DLL 加载到内存之前始终验证它们的有效性。

具体到环境变量：正如一开始提到的，随着Windows Registry的引入，Windows中已经没有明显需要环境变量的概念了。系统设置类参数，如静态路径、用户名等，可以在Registry中设置，也可以通过API调用获取；进程类型参数可以在命令行上设置。因此，向后兼容性可能是我们在 Windows 中仍然有环境变量的原因。

从检测的角度来看，可以做的一些显而易见的事情是检查 DLL 是否从意外位置加载。例如，位于其中的可执行文件C:\Windows\System32不太可能从“temp”或 AppData 文件夹加载 DLL - 因此从这些位置加载的 DLL 值得仔细研究。然而，System32 文件夹之外的应用程序可能会从此类文件夹（例如 Microsoft Teams 和 Slack）合法地加载 DLL，因此很难将其转变为通用规则。

寻找具有已知由易受攻击的应用程序加载的名称的 DLL 文件的创建是一种效果不佳的方法 [ 14 ]。一种相关但稍微可行的方法是在意外位置寻找某些文件夹结构的创建。例如，几乎所有劫持方法都依赖%SYSTEMROOT%或%WINDIR%需要System32在用户可写位置创建一个文件夹。一般来说，这应该很少见——尽管一些合法软件似乎也在这样做，但在排除此类情况后，这可能是一种检测最明显形式的基于环境变量的 DLL 劫持的简单方法。

话虽如此，如果易受攻击的可执行文件使用另一个环境变量，上述方法也可能不起作用。因此，重要的是不要只关注检测 DLL 劫持本身，而更关注随后的活动。检测对于执行它的进程来说很少见的活动，是一天结束时出现问题的最佳指标。因此，虽然您的防御系统可能无法检测到所有内容，但它检测到的越多，攻击者就越难以完全被忽视。

这项研究首次在 DEF CON 30 上提出；[你可以在这里](https://www.wietzebeukema.nl/literature/Beukema, WJB - Save The Environment (Variable).pdf)找到幻灯片。

1. 从技术上讲，还有一种记录不足的第四种类型，VOLATILE。这与 USER 级别的环境变量相同，但在用户注销后会重置。↩
2. 作为旁注，不幸的是，基于环境变量的 DLL 劫持目前不能很好地映射到 MITRE ATT&CK [ 7 ]。由于我之前的 DLL Hijacking 博客文章中提到的这个和其他原因，我已经提交了一个提案 [ [8](https://www.wietzebeukema.nl/literature/Beukema, WJB - A Single Sub-Technique for DLL Hijacking.pdf) ]，我希望 MITRE 在开发框架的下一个版本时能够考虑到该提案。[↩]