如何突破 Hyper-V 并入侵管理员账户

不再做长文翻译了，标原创还被举报，花2,3个小时还被举报，没有动力了，自己看原文吧！简单的机器翻译，原文链接见结尾。

在这篇博文中，我们将解释影响广泛使用的协议 PowerShell Remoting 和 PowerShell Direct 的新型攻击场景。您是否使用 PowerShell Remoting 来管理您的环境？您是否使用 PowerShell Direct 来管理虚拟机管理程序平台中的虚拟机？那么您需要阅读本文并采取行动，以确保您不受影响。

这篇博文是一篇高层次的概述。如果您正在寻找完整的技术细节，请参阅本文《攻击 PowerShell CLIXML 反序列化 – Truesec》。

PowerShell Remoting 和 PowerShell Direct 是广泛使用的解决方案，用于管理企业 IT 环境。它们都具有在计算机之间共享对象的功能，这是通过称为 CLIXML 的序列化格式实现的。问题是它们信任远程系统始终提供合法的 CLIXML 数据。这是一个称为CWE-502：不受信任数据的反序列化 的漏洞。在这种攻击场景中，我们不会以服务器为目标，而是以连接的客户端为目标。因此，使用这些解决方案连接到受感染计算机的任何人都会暴露。

权限提升和横向移动

下图展示了 PowerShell Remoting 攻击场景。毫无戒心的管理员连接到受感染的服务器。但是，随着服务器受到感染，威胁行为者可以控制要返回的数据。因此，这种情况会导致管理员的计算机受到感染。请注意，这也会影响许多流行的管理解决方案，因为它们依赖于 PowerShell Remoting。

这种场景非常有趣，因为 PowerShell Remoting 通常由具有高权限的管理员用于远程管理计算机。如果威胁行为者设法入侵 Web 服务器等，他们就可以在管理员连接到受感染的服务器后立即使用此技术来提升其权限。这种内部升级概念是大多数网络攻击的重要组成部分。

在下面的视频中，我们展示了这种攻击在实践中可能是什么样子。在这种情况下，毫无戒心的域管理员使用 PowerShell Remoting 在受感染的服务器上运行一个简单的命令。我们看到，一旦执行该命令，威胁行为者就会设法窃取域管理员的网络密码哈希（Net-NTLMv2）。

脱离 Hyper-V 虚拟机

PowerShell Direct 场景非常相似。受害者使用 PowerShell Direct 连接到受感染的虚拟机。威胁行为者可以控制返回到虚拟机管理程序主机的数据。这会导致底层虚拟机管理程序主机受到损害。这种情况非常有趣，因为虚拟机管理程序安全屏障对大多数组织来说都至关重要。例如，云托管提供商依靠此安全屏障来提供客户之间的隔离。如果威胁行为者设法破坏主机层，他们将从破坏一个受害者变成破坏同一提供商托管的所有受害者。

在下面的视频中，我们看到虚拟机已被入侵的场景。毫无戒心的 Hyper-V 管理员使用 PowerShell Direct 在受感染的机器中运行一个简单的命令。在这种情况下，我们手动执行此操作，但请注意，例如，备份解决方案可以配置为自动运行重复的 PowerShell Direct 命令。

一旦执行 PowerShell Direct 命令，威胁行为者就能够利用此漏洞并突破虚拟机。在演示中，我们在底层主机上生成远程访问恶意软件。

这些漏洞有何影响？

这不是很直接，因为漏洞的影响取决于多种因素。本质上，这取决于受害者的 PowerShell 会话中有哪些小工具可用。默认情况下，只有少数小工具可用。小工具的概念相当复杂，如果您想充分了解影响，我们建议您阅读我们的技术文章。

请注意，这些小工具（影响）是我在研究中发现的。可能还有更多小工具有待发现。

报告漏洞

我于 2024 年 3 月 18 日向 Microsoft 安全响应中心 (MSRC) 提交了我的研究。MSRC 于 7 月 22 日将此案结案，并表示已“修复”，一个月后我的研究成果被公开承认。然而，这种攻击仍然有可能实施，因此组织需要采取适当的预防措施来降低风险。

对我来说，MSRC 所说的“问题已修复”是什么意思仍然不清楚，因为他们没有分享任何解决方案细节。虽然很明显 PSRP 和 PSDirect 仍然会反序列化不受信任的数据，但似乎他们也没有修复微软自己的 PowerShell 模块中的远程代码执行（由于 PSFramework 依赖性），尽管根据它们的 security.md 文件（Azure/AzOps、Azure/AzOps-Accelerator、Azure/AVDSessionHostReplacer、PAWTools）它们属于 MSRC 的范畴。

2024-08-19，我决定亲自联系 PSFramework 背后的微软员工。他立即了解了这个问题，并出色地着手解决它。

该研究于 2024-09-14 公开发布，距首次私下披露已有 180 天。

你能做什么呢？

PowerShell Remoting (PSRP) 仍然是管理环境的推荐方法。出于很多原因，您不应该再使用 RDP（远程桌面协议）或类似方法。但是，在使用 PSRP 或 PSDirect 之前，您需要记住一些事项。

1. 确保远程计算机已完全修补。如上表所示，这将解决部分问题，但并非全部。

2.切勿在充斥着第三方 PowerShell 模块的计算机上使用远程控制。换句话说，您可能不应该从一体式管理 PC 进行远程控制。

3. 使用专用于管理任务的特权访问工作站。

4. 检查您的 PowerShell 模块
通过启动新的 PowerShell 提示符并运行来检查启动时加载的模块：

get-module

但请注意，只要您使用其中一个 cmdlet，模块就会被隐式加载。因此您还应该检查系统上的可用模块。

get-module -ListAvailable

5. 减少你的 PowerShell 模块
当你安装 PowerShell 模块时，它可能会在你的系统上引入一个新的反序列化小工具，并且一旦你使用 PSRP、PSDirect 或使用任何导入不受信任的 CLIXML 的脚本，你的系统就会暴露。

通常来说，对 PowerShell 模块进行限制是一种很好的做法，因为第三方模块也存在其他风险（例如供应链攻击）。

然而，这并不像听起来那么容易。许多软件都附带自己的一套 PowerShell 模块，这些模块将安装在您的系统上。您需要确保这些模块不会引入小工具。

6. 减轻影响并禁用小工具
只要 PSRP 和 PSDirect 仍然依赖不受信任的 CLIXML 反序列化，就需要不断寻找和化解反序列化小工具。

举个例子，用一个简单的语句就可以缓解“密码窃取小工具”的威胁if 。在 中找到以下代码C:WindowsSystem32WindowsPowerShellv1.0Registry.format.ps1xml：

<ScriptBlock>
$result = (Get-ItemProperty -LiteralPath $_.PSPath | Select * -Exclude PSPath,PSParentPath,PSChildName,PSDrive,PsProvider | Format-List | Out-String | Sort).Trim()
$result = $result.Substring(0, [Math]::Min($result.Length, 5000) )
if($result.Length -eq 5000) { $result += "..." }
$result
</ScriptBlock>

然后添加验证以确保 PSPath 属性合法。更新后的格式化程序可能如下所示：

<ScriptBlock>
$result = ""
if($_.PSPath.startswith("Microsoft.PowerShell.CoreRegistry")){
   $result = (Get-ItemProperty -LiteralPath $_.PSPath | Select * -Exclude PSPath,PSParentPath,PSChildName,PSDrive,PsProvider | Format-List | Out-String | Sort).Trim()
   $result = $result.Substring(0, [Math]::Min($result.Length, 5000) )
   if($result.Length -eq 5000) { $result += "..." }
}
$result
</ScriptBlock>

原文：

https://www.truesec.com/hub/blog/attacking-powershell-clixml-deserialization

https://www.truesec.com/hub/blog/how-to-break-out-of-hyper-v-and-compromise-your-admins

原文始发于微信公众号（独眼情报）：如何突破 Hyper-V 并入侵管理员账户