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

– dir \targetsystem32mobsync.exe //should not exist

– copy evil.exe \targetadmin$system32mobsync.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:WINDOWSsystem32IntelCpHDCPSvc.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:Userstestdesktopdcom_things.txt foreach ( $binpath in $file ) { $binpath cmd.exe /c dir $binpath > $null }

执行结果如下：

%SystemRoot%system32mobsync.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 \acmedcadmin$system32mobsync.exe

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

copy C:evil.exe \acmedcadmin$system32mobsync.exe dir \acmedcadmin$system32mobsync.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）：

结论

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