这篇文章讨论了一种日常渗透测试中备用的DCOM渗透过程目标发现和有效载荷执行的方法。主要依据是找到DCOM注册表键/值，该键指向一台 “远程”计算机上的一个不存在的二进制文件的路径。如果mobsync.exe不在\\target\admin$\system32\中，而这是Windows 2008 R2和Windows 2012 R2操作系统安装上的默认设置。通过被入侵的机器上的管理员权限（通过PowerShell可以获取），你可以执行如下操作：

– dir \\target\system32\mobsync.exe   //should not exist

– copy evil.exe \\target\admin$\system32\mobsync.exe

– [activator]::CreateInstance([type]::GetTypeFromCLSID("C947D50F-378E-4FF6-8835-FCB50305244D","target"))

介绍

在这篇文章中，我们将讨论一种滥用DCOM（分布式组件对象模型）来实现远程有效载荷执行和横向移动的一种'新'且'简单'的方法。一般来说，这种技术相对简单，但可能为其他众所周知的渗透测试姿势提供了一种替代方法。主要内容包括：

· 初级的DCOM渗透测试技术（参考文献）

· 研究的动机

· 并不复杂的'DCOM横向移动方法

· 为防御者提供检测或防止此类潜在活动的建议

DCOM初级利用

在过去一年半的时间里，DCOM渗透测试技术已得到很好的证明。马特纳尔逊（enigma0x3）发表了一系列优秀的博客文章，描述了利用MMC20.Application，ShellWindows，ShellBrowserWindow，Excel.Application和Outlook.Application等DCOM或COM对象优势的横向移动技术。Philip Tsukerman（@PhilipTsukerman）已经发现并提出了非常有趣的WMI横向移动技术，并撰写了一篇很好的文章，为DCOM功能，横向移动技术和防御性考虑提供了很好的背景知识。几个月前，我发布了一篇博客关于滥用ShellWindows和ShellBrowserWindow的Navigate和Navigate2函数来启动一个可执行文件或'url'文件来实现远程主机上的有效载荷的执行。我强烈建议在继续阅读本文之前先学习了解上述资源。

*请注意，这里介绍的方法和示例在Threat Actor TTP Totem Pole

虽然看起来比较低级（可能会这么认为）。然而，我坚信许多智能威胁操作者使用基于风险的方法来评估目标，因此他们不会总是使用他们最好的操作员、工具、策略和程序来实现其预期的效果或目标。因此，这里讨论的技术和想法可能仍然有用。

研究动机

几个星期前，我决定虚拟化一台旧笔记本电脑的操作系统。转换过程非常痛苦，经过一些故障排除（以及大量重新启动）后，我终于找到了正确的虚拟化驱动程序和工具。但是，我想到了我的决定对安全性的影响，并想知道是否还有其他有趣的老旧的东西可以作为物理机器。我没有合适的“基准”机器，也没有兴趣进行调查分析。但是，我选择在注册表入手，很快遇到了这个有趣的CLSID注册表路径，该路径引用了一个二进制文件，该文件可能为笔记本电脑上的以前的（驱动程序）程序提供了一些实用/诊断功能：

快速DIR验证C:\WINDOWS\system32\IntelCpHDCPSvc.exe不再位于磁盘上：

这让我立即想到四件事：

· IntelCpHDCPSvc.exe对我来说显然是未知的

· 旧软件的卸载程序并未完全删除所有注册表键值

· 我应该更好地检查和信任我的机器上的软件（这个转换过程需要一天或三杯啤酒的时间）

· 这看起来像一个DCOM应用程序（它已通过下面的Get-CimInstance Win32_DCOMApplication查询进行验证）

通过谷歌搜索显示IntelCpHDCPSvc.exe与英特尔的内容保护HDCP服务有关，但最让我感兴趣的是LocalServer32和InProcServer32键值可能存在的安全隐患（或机会），它引用了不存在的二进制文件的路径。由于IntelCpHDCPSvc可能不会在非常常见的情况下出现，因此我想找到任何情况下都可以利用的被“遗弃”的DCOM参考，它们都是Microsoft Windows Server本身的版本。

被遗弃的DCOM横向运动方法论

二进制发现

第一步是在DCOM应用程序中找到合适的二进制路径。为此，我制作了非常粗略的PowerShell cmds，以使用以下命令从Windows 2012完全修补的实例中提取LocalServer32可执行文件和InProcServer32 DLL：

gwmi Win32_COMSetting -computername 127.0.0.1 | ft InProcServer32 -autosize | Out-String -width 4096 | out-file dcom_dlls.txt

规范化的，重复删除的输出（来自Windows 2012机器）看起来像这样：

在连接这些文件并删除一些开关之后，我使用下面这个粗糙的cmd字符串测试了磁盘上实际文件的存在：

$file = gc C:\Users\test\desktop\dcom_things.txt
foreach ($binpath in $file) {
 $binpath
 cmd.exe /c dir $binpath > $null
}

执行结果如下：

%SystemRoot%\system32\mobsync.exe
File Not Found

执行结果如下图所示：

根据How-To Geek的说法，mobsync “属于Microsoft Sync Center和脱机文件功能的一个过程。”这很好理解，但mobsync.exe由于其他原因变得非常有趣……

验证AppID和CLSID

由于我之前没有很好地枚举适当的AppID和CLSID，我选择了浏览注册表来查找这些内容，如下图所示：

特别是在下一阶段需要CLSID [C947D50F-378E-4FF6-8835-FCB50305244D]来创建DCOM对象的实例。

远程负载执行和渗透测试

现在已经识别出候选的DCOM和COM对象了，让我们尝试调用远程有效负载执行。在继续之前，请注意以下环境因素：

· 为了远程实例化DCOM对象，我们必须拥有适当的权限。管理员帐户就足够了。

· 为了使有效负载执行更有实际意义，我们将利用域环境。在这个测试案例中，我们将假设我们已经捕获了域管理员证书。远程执行尝试将从Windows 10客户端发生到Windows 2012域控制器。

· 希望能有对我们有利的可能性…

让我们分析我们准好的恶意的有效负载并确认mobsync.exe不在目标上（由于某些添加的角色或管理设置）：

dir C:\evil.exe
dir \\acmedc\admin$\system32\mobsync.exe

不错！由于mobsync.exe不存在，我们的evil.exe有效载荷清楚地规避了任何类型的主机保护机制,让我们将其复制到DC：

copy C:\evil.exe \\acmedc\admin$\system32\mobsync.exe
dir \\acmedc\admin$\system32\mobsync.exe

由于我们的二进制不是“DCOM”，实例化后应该会“失败”，但实际上仍然触发了有效载荷。让我们来尝试一下：

[activator]::CreateInstance([type]::GetTypeFromCLSID("C947D50F-378E-4FF6-8835-FCB50305244D","target"))

在Windows 10域成员机器上…

在Windows 2012域控制器上…

不错！'恶意'的mobsync.exe触发了notepad.exe有效负载的执行！

其他重要说明和利用机会

· 此技术也可能对Windows Server 2008起作用，因为默认情况下，mobsync.exe不在\system32目录中。但是，mobsync.exe会被放入Windows 2016服务器计算机上的system32目录中。

· 还有其他方法可能会调用这种DCOM横向移动的技巧。如前所述，有很多“DCOM”的二进制文件。一个简单的方法是（暂时）替换这些二进制文件中的一个，并执行相同类型的调用。劫持远程计算机上的mshta.exe可能没有操作上的意义，但是操纵远程文件系统（例如文件复制/移动操作，远程文件权限等）存在令人头痛的问题，当然还有处理增加的风险的检测。

· 另一种（乏味的）方法可能是操纵远程注册表，将DCOM二进制文件的相应CLSID LocalServer32键/值文件路径更改为指向磁盘上的另一个位置或远程文件共享。与前面的示例类似，这对处理注册表更改和权限以及引入额外的检测风险具有一定的影响。

· 第三方“DCOM”应用程序，软件和实用程序为定位找到“废弃”的DCOM路径提供了另一种类似横向移动的机会。IntelCpHDCPSvc.exe是一个演示用例，但可能不是一个很好的例子。然而，企业组织每隔几年购买一台新的计算机设备并不罕见。在“更新换代”设备时，机器需要维护，打补丁和升级。删除某些实用软件和较旧的设备驱动程序后，软件残留的可能性（例如注册表中的DCOM配置设置）可能会引入这些横向移动攻击路径。一个坚定的持久攻击者可能会对此进行仔细调查和分析。

· 在其他版本的Windows中可能会放弃DCOM二进制引用，包括客户端设备。

防御性考虑

对于供应商来说：

· 确保在卸载实用程序软件时删除DCOM注册表工件。

· 不要创建指向不存在的二进制文件的DCOM二进制路径注册表键值。

对防御者来说：

· 一般来说，防御者应该在他们各自的博客文章中获取由@ enigma0x3和@PhilipTsukerman提供的IOC和建议。

· 使用这些DCOM方法（可能）需要对远程机器进行特权访问。保护特权域帐户。避免跨本地计算机帐户重新使用密码。

· 确保防御深度控制，基于主机的安全产品和主机监控到位，以检测/阻止可疑活动。启用基于主机的防火墙以防止RPC / DCOM交互和实例化。

· 监视文件系统（和注册表）以查找新引入的软件和更改。

· 在环境中监视可疑的PowerShell使用情况。无论何时/只要有可能就启用强制约束语言模式（*注意：对于特权帐户来说这可能很困难）。

· 在DCOM调用“失败”时，可以参考CLSID在目标机器上生成系统事件ID 10010（Error，DistributedCOM）：

结论

感谢你花时间阅读我的这篇文章！与往常一样，如果你有任何疑问，意见或反馈，请随时与我们联系。