https://www.freebuf.com/articles/network/256372.html

前言

DCOM是COM（组件对象模型）的扩展，它允许应用程序实例化和访问远程计算机上COM对象的属性和方法，就像使用基于DCERPC的DCOM协议在本地计算机上的对象一样。有关每个COM（和DCOM）对象的标识，实现和配置的信息存储在注册表中，并与一些重要的标识符相关联：

CLSID

-所述类标识符是一个GUID，它充当一个COM类的唯一标识符，并且每一个在Windows注册类与CLSID相关联（COM对象可以在没有登记使用，但是这超出了本文的范围） 。注册表中的CLSID密钥指向类的实现，如果是基于dll的对象，则使用InProcServer32子项；如果是exe ，则使用LocalServer32项。

ProgID

-该编程标识符是一个可选的标识符，其可被用作对用户更友好的替代一个CLSID，因为它不必坚持的CLSID的恐吓GUID格式（“System.AppDomainManager”，例如，是比GUID容易得多）。ProgID不能保证是唯一的，并且与CLSID不同，并非每个类都与ProgID相关联。
-该应用程序标识符用于指定一个的配置或多个COM对象与同一可执行相关联。这包括授予各个组的权限，以在本地和远程实例化和访问关联的类

为了使DCOM可访问COM对象，必须将AppID与该类的CLSID关联，并且需要为该AppID提供适当的权限。没有关联的AppID的COM对象不能从远程计算机直接访问。

在powershell中我们可以使用

get-CimInstance来列出本地COM程序列表

也可以使用OleView .NET了来列出

远程DCOM对象的实例表现如下：

客户端计算机从远程计算机请求实例化由CLSID表示的对象。如果客户端使用ProgID，则首先将其本地解析为CLSID。
远程计算机检查是否存在与所讨论的CLSID关联的AppID，并验证客户端的权限。
如果一切顺利，则DCOMLaunch服务将创建所请求类的实例，通常是通过运行LocalServer32子项的可执行文件，或者通过创建DllHost进程来承载InProcServer32子项引用的dll。
在客户端应用程序和服务器进程之间建立通信。在大多数情况下，新过程是在与DCOM通信关联的会话中创建的。
然后，客户端可以访问新创建的对象的成员和方法。

所以我们给出的思路就是找到一些默认权限（DefaultLaunchPermission）的COM程序来进行利用

可以利用的DCOM

这里说的是公开的。

1.EXCEL DDE

首先创建“ ”对象的实例，这里我们使用ProgID

$a = [activator]::CreateInstance([type]::GetTypeFromprogID("Excel.Application","10.10.10.10"))