通过 EXCEL.APPLICATION 和 DCOM 进行横向移动

在这篇文章中，我将介绍如何滥用 Excel.Application DCOM 应用程序在远程主机上执行任意代码。最近讨论了使用 RegisterXLL 方法进行横向移动的同一 DCOM 应用程序，您可以在此处阅读相关内容。在这篇文章中，我将重点介绍“Run（）”方法。简而言之，此方法允许您在指定的 Excel 文档中执行命名宏。你大概可以看到我要去哪里 🙂

众所周知，VBA 宏长期以来一直是攻击者最喜欢的技术。通常，VBA 滥用涉及带有包含宏的 Office 文档的网络钓鱼电子邮件，以及诱骗用户启用该恶意宏的诱使文本。这里的区别在于，我们使用宏进行透视，而不是初始访问。因此，Office 宏安全设置不是我们需要担心的事情。无论如何，我们的恶意宏都会执行。

此时，我们知道 Excel.Application 是通过 DCOM 公开的。通过使用 James Forshaw的 OLEViewDotNet，我们可以看到没有设置显式的启动或访问权限：

如果 DCOM 应用程序没有显式的“启动”或“访问”权限，则 Windows 允许本地管理员组的用户远程启动和访问应用程序。这是因为 DCOM 应用程序具有一组“默认”的“启动”和“访问”权限。如果未分配显式权限，则使用默认设置。这可以在 dcomcnfg.exe 中找到，如下所示：

由于本地管理员能够远程与 Excel.Application 交互，因此我们可以使用 [Activator]：：CreateInstance（） 通过 PowerShell 远程实例化它：

如您所见，远程实例化成功。我们现在能够与 Excel 进行远程交互。接下来，我们需要将有效负载移动到远程主机。这将是一个包含恶意宏的 Excel 文档。由于 VBA 允许 Win32 API 访问，因此各种 shellcode 运行器的可能性是无穷无尽的。在这个例子中，我们将只使用calc.exe开头的 shellcode。如果你好奇，你可以在这里找到一个例子。

只需创建一个新宏，随心所欲地命名它，添加代码，然后保存它。在本例中，我的宏名称是“MyMacro”，我将文件保存为.xls格式。

创建实际有效负载后，下一步是将该文件复制到目标主机。由于我们将此技术用于横向移动，因此我们需要目标主机上的本地管理员权限。既然我们有了它，我们就可以将文件复制过来：

当有效载荷在目标上时，我们只需要执行它。这可以使用之前实例化的 Excel.Application DCOM 应用程序的 Run（） 方法完成。在我们实际调用该方法之前，应用程序需要知道宏驻留在哪个 Excel 文件中。这可以使用“Workbooks.Open（）”方法完成。此方法仅采用文件的本地路径。那么，如果我们调用该方法并传递刚刚复制的文件的位置会发生什么？

嗯，这不是很有趣吗。该文件存在，但 Excel.Application 声明它不存在。为什么会这样？当 Excel.Application 通过 DCOM 实例化时，它实际上是通过本地系统标识实例化的。默认情况下，本地系统用户没有配置文件。由于 Excel 假定它位于交互式用户会话中，因此它以不太优雅的方式失败。我们该如何解决这个问题？有更好的方法可以做到这一点，但一个快速的解决方案是远程创建本地系统配置文件。

此配置文件的路径为：

C：WindowsSystem32configsystemprofileDesktop

和 C：WindowsSysWOW64configsystemprofileDesktop。

现在创建了本地系统配置文件，我们需要重新实例化 Excel.Application 对象，然后再次调用“Workbooks.Open（）”：

如您所见，我们现在能够打开包含恶意宏的工作簿。此时，我们需要做的就是调用“Run（）”方法并给它传递恶意宏的名称。如果你还记得上面的话，我把我的命名为“MyMacro”

调用“Run（myMacro）”将导致该宏中的 VBA 执行。为了验证这一点，我们可以在远程主机上打开 Process Explorer 并进行验证。如下图所示，此特定主机具有“禁用 Office 应用程序的 VBA”GPO 集。无论该安全设置如何，都允许宏执行：

在这个例子中，我只使用了 calc spawning shellcode，这导致在 Excel.exe 下生成一个子进程。请记住，由于 VBA 在与操作系统的交互方面提供了很多功能，因此可以不生成子进程，而只是注入到另一个进程中。最后一步是远程清理 Excel 对象并从目标主机中删除有效负载。

我已通过 PowerShell 自动化了此技术，您可以在此处找到：

https://gist.github.com/enigma0x3/8d0cabdb8d49084cdcf03ad89454798b

为了帮助缓解此向量，您可以手动将远程启动和访问权限应用于 Excel.Application 对象...但不要忘记查看所有其他 Office 应用程序。另一种选择是通过 dcomcnfg.exe 更改默认的远程启动/访问 DACL。请记住，任何 DACL 更改都应进行测试，因为此类修改可能会影响合法使用。除此之外，启用 Windows 防火墙和减少主机上的本地管理员数量也是有效的缓解步骤。

此技术最突出的是 Excel 和子进程将作为调用用户生成。这通常是从与当前登录的用户不同的用户帐户创建的进程。如果这是仅有的两个进程，并且正在使用的用户帐户通常不登录到该主机，则这可能是一个危险信号。

点“阅读原文”，访问无问社区

原文始发于微信公众号（白帽子社区团队）：通过 EXCEL.APPLICATION 和 DCOM 进行横向移动