利用Outlook的CreateObject方法和DotNetToJScript渗透内网
在之前的博客文章中，我介绍了多个在Windows中利用分布式组件对象模型（DCOM）进行内网渗透的方法。这些方法通常需要识别出暴露了可以允许任意代码执行的方法的DCOM应用程序。在本文的这个例子中，我将介绍Outlook 的 CreateObject() 方法。
如果你不熟悉CreateObject()，你可以点开链接看看MSDN官网上的介绍，这个方法实质上允许你实例化一个任意的COM对象。滥用DCOM应用程序渗透内网的问题在于你通常是在正常的使用的这些方法。大多数时候我们谈论的技术包括滥用ShellExecute（或类似的）方法来启动任意进程或在目标主机上打开恶意文件，这需要将有效载荷放置在磁盘（或网络共享）上。虽然这些技术效果很好，但是从安全角度来看，这些技术还是并不理想。
例如，ShellBrowser / ShellBrowserWindow应用程序只允许你使用参数启动一个进程，这个限制使得这种技术很容易受到命令行日志记录的影响。那么通过宏执行的Run()方法又如何呢？这就要求带有恶意宏的文档是在本地机器上的或者是托管在一个网络共享上（这并不完全理想）。
如果我们可以通过DCOM直接获得shellcode的执行方式，而不必担心需要向目标机器写入文件或者是启动任意进程（如powershell或regsvr32），这种想法是否可以实现呢？幸运的是，Outlook通过DCOM暴露了一些方法，并且满足我们的要求。
首先，我们需要远程实例化Outlook：
$com = [Type]::GetTypeFromProgID('Outlook.Application’,’192.168.99.152’)
$object = [System.Activator]::CreateInstance($com)
完成之后，你将拥有一个可用的CreateObject()方法：
如上所述，该方法提供了在远程主机上实例化任何COM对象的能力。这怎么可能被滥用于shellcode执行呢？使用CreateObject方法，我们可以实例化ScriptControl COM对象，它允许你通过AddCode()方法执行任意的VBScript或JScript：
$RemoteScriptControl = $object.CreateObject(“ScriptControl”)
如果我们使用James Forshaw的DotNetToJScript技术在VBScript / JScript中反序列化.NET程序集，然后我们可以通过将VBScript / JScript代码传递给AddCode()方法，通过ScriptControl对象实现shellcode的执行。由于ScriptControl对象是通过Outlook的CreateObject()方法进行远程实例化的，任何传递的代码都将在远程主机上执行。为了演示这一点，我将使用一个简单的程序集来启动calc.exe。C#编写的PoC 如下：
注意：因为代码是用C#编写的，所以它也是一个完整的shellcode 执行器
在编译了“有效载荷”之后，你可以把它传递给DotNetToJScript，并生成一些JScript / VBScript。在这个例子中，我选择生成JScript。
现在已经生成了有效载荷，我们可以将其传递给通过远程主机上的Outlook的CreateObject方法创建的ScriptControl COM对象。这可以通过将整个JScript / VBScript代码块存储到PowerShell中的变量中来完成。在这种情况下，我将它存储在一个名为“$code”的变量中：
最后，我们所要做的事情就是将ScriptControl对象上的“Language”属性设置为要执行的脚本语言（JScript或VBScript），然后使用“$code”变量作为参数调用“AddCode()”方法：
$RemoteScriptControl.Language = “Jscript” $RemoteScriptControl.AddCode($code)
在调用“AddCode()”方法之后，提供的Jscript代码将在远程主机上执行：
正如你上面所看到的，calc.exe已经在远程主机上运行了。
检测和缓解措施：
在上面的屏幕截图中，你可能已经注意到，Outlook.exe是svchost.exe的子进程。这是Outlook的一个特征。应用程序通过DCOM远程实例化，因此这个特征可以作为检测的切入点。在大多数情况下，远程启动的进程会在命令行中包含“-embedding”，表示这是一个远程实例化的对象。
另外，vbscript.dll或jscript/jscript9.dll的模块加载情况也是一个很好的检测点。通常情况下，Outlook不会加载这dll文件，并且加载了这些文件那么意味着应用程序程序使用了ScriptControl对象。
在这个例子中，有效载荷是作为Outlook.exe的子进程运行的，这很奇怪。最后要记住的一点是.NET程序集也可以被执行，这意味着shellcode注入方式是绝对可行的。攻击者不用简单地启动一个进程，而是编写一个程序集，将shellcode插入到另一个进程中，从而绕过进程的父子关系的检测。最后，最好启用Windows防火墙来阻止此类攻击，因为它会阻止DCOM的使用。
官方 