在今年1月份，我发表了两篇都是关于使用DCOM进行内网渗透的博客文章。其中一篇讲的是使用MMC20.Application，另外一篇讲的是使用DCOM应用程序暴露的两个“ShellExecute”方法。

虽然这类大多数技术都有一个执行的方法（WMI里有Create()方法，使用psexec可以创建一个带有自定义binpath的服务等等），但DCOM允许你使用不同的对象来暴露很多执行方法。这就使得操作员可以从父子进程的关系角度来选择他们在远程主机上的所要执行的操作。

在这篇文章中，我将通过滥用Excel.Application DCOM应用程序来执行远程主机上的任意代码。最近一段时间，我们通过使用RegisterXLL方法讨论了相同的DCOM应用程序在内网渗透中的利用姿势，你可以在这里进行阅读。在这篇文章中，我将专注于介绍“ Run() ”方法。简而言之，此方法允许你在指定的Excel文档中执行命名宏。

众所周知，VBA宏一直是攻击者最喜爱的攻击技术。通常情况下，VBA滥用涉及到包含宏的Office文档的诱骗电子邮件，以及诱惑的文字，以欺骗用户启用该恶意宏。这里的区别在于我们使用宏来作为渗透过程中的支点而不是用于初始的访问执行。因此，Office 宏的安全设置不是我们需要担心的。我们的恶意宏将执行无论Office 宏的安全设置是什么样的。

我们知道Excel.Application是通过DCOM暴露的。通过使用OLEViewDotNet由詹姆斯·福肖（@tiraniddo）编写的利用工具，我们可以看到，在系统中是否存在明确的启动或访问权限的设置：

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

由于本地管理员能够远程的调用Excel.Application接口，所以，我们可以通过PowerShell使用[Activator] :: CreateInstance()来远程实例化对象：

正如你在上图中所看到的，远程实例化已经成功。我们现在可以远程与Excel进行交互。接下来，我们需要将我们的有效载荷移动到远程主机。这将是一个包含我们的恶意宏的Excel文档。由于VBA允许Win32 API的访问，所以对于各种shellcode执行器来说，利用方式的可能性是无穷无尽的。在本文的这个例子中，我们将使用启动calc.exe的shellcode来进行演示。如果你好奇这是怎么实现的，那么你可以在这里找到示例。

只需创建一个新的宏，并将其命名为任何你想要的名称，然后添加你的代码，最后进行保存。在本文的示例中，我添加的宏的名称是“MyMacro”，我以.xls格式保存文件。

在创建实际的有效负载的情况下，下一步是将该文件复制到目标主机。由于我们使用这种技术进行内网渗透，因此我们需要在目标主机上使用本地管理员权限。因为只有这样做，我们才可以复制文件：

在目标主机上存放效载荷后，我们只需要执行它就行了。这可以使用之前实例化的Excel.Application DCOM应用程序的Run()方法来完成。在我们实际调用该方法之前，应用程序需要知道保存这个宏的Excel文件。可以使用“Workbooks.Open()”方法来实现。该方法只需要传入文件的本地路径。那么，如果我们调用该方法并传递我们刚刚复制的文件的路径会怎么样？

看起来有点问题。该文件确实是存在的，但Excel.Application貌似认为这个文件并不存在。为什么会这样呢？当通过DCOM实例化Excel.Application时，实际上是通过本地系统身份进行实例化的。默认情况下，本地系统用户没有配置文件。由于Excel假定它处于交互式用户会话中，所以就会以不太优雅的方式执行失败。我们如何解决这个问题呢？有更好的方法来做到这一点，但是一个快速的解决方案是远程创建本地系统的配置文件。

此配置文件的路径为：

C:\Windows\System32\config\systemprofile\Desktop
C:\Windows\SysWOW64\config\systemprofile\Desktop

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

从上图中我们可以看到，我们已经成功的打开了包含恶意宏的xls文件。在这一点上，我们所需要做的就是调用“Run()”方法，并传入我们的恶意宏的名称。如果你还记得的话，我所命名的宏名称是“MyMacro”。

调用“Run(myMacro)”就可以执行这个宏里面所包含的VBA代码。如果要验证这一点，我们可以在远程主机上打开Process Explorer来进行验证。如下图所示，该特定主机具有“禁用VBA for Office应用程序”的GPO集。无论安全设置怎么配置，宏都可以成功执行：

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

我已经通过PowerShell自动化了这项技术，你可以在这里找到：

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

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

这种技术最突出的一点是Excel和子进程将作为调用用户而启动的。通常是在与当前登录的用户不同的用户帐户的进程上下文中创建的。如果你在进程列表中发现唯一的两个进程的启动用户是那种通常不登录到该主机的用户账户的话，那这可能就是攻击者启动的恶意进程。