DCOM
MITRE ATT&CK™ Remote Services: Distributed Component Object Model - Technique T1021.003
Last updated
Was this helpful?
MITRE ATT&CK™ Remote Services: Distributed Component Object Model - Technique T1021.003
Last updated
Was this helpful?
DCOM (Distributed Component Object Model) objects are interesting due to the ability to interact with the objects over the network. Microsoft has some good documentation on DCOM and on COM . You can find a solid list of DCOM applications using PowerShell, by running Get-CimInstance Win32_DCOMApplication.
DCOM (Distributed Component Object Model) Remote Protocol, exposes application objects (COM) via remote procedure calls (RPCs) and consists of a set of extensions layered on the Microsoft Remote Procedure Call Extensions.
The Windows Registry contains the DCOM configuration data in 3 identifiers:
CLSID – The Class Identifier (CLSID) is a Global Unique Identifier (GUID). Windows stores a CLSID for each installed class in a program. When you need to run a class, you need the correct CLSID, so Windows knows where to go and find the program.
PROGID – The Programmatic Identifier (PROGID) is an optional identifier a programmer can substitute for the more complicated and strict CLSID. PROGIDs are usually easier to read and understand. However there are no restrictions on how many PROGIDs can have the same name, which causes issues on occasion.
APPID – The Application Identifier (APPID) identifies all of the classes that are part of the same executable and the permissions required to access it. DCOM cannot work if the APPID isn’t correct.
To make a COM object accessible by DCOM, an AppID must be associated with the CLSID of the class and appropriate permissions need to be given to the AppID. A COM object without an associated AppID cannot be directly accessed from a remote machine. A basic DCOM transaction looks like this:
The client computer requests the remote computer to create an object by its CLSID or PROGID. If the client passes the APPID, the remote computer looks up the CLSID using the PROGID.
The remote machine checks the APPID and verifies the client has permissions to create the object.
DCOMLaunch.exe (if an EXE) or DLLHOST.exe (if a DLL) will create an instance of the class the client computer requested.
Communication is successful!
The Client can now access all functions in the class on the remote computer.
This technique allows loading and executing a .NET assembly in a remote computer's WaaS Medic Service svchost.exe process for DCOM lateral movement.
MMC20.Application CLSID is {49B2791A-B1AE-4C90-9B8E-E860BA07F889}.
As an administrator we can remotely interact with this COM through MS-DCOM protocol using GetTypeFromProgID.
ShellWindows CLSID is {9BA05972-F6A8-11CF-A442-00A0C90A8F39}
The ShellBrowserWindow object provide an interface into the Explorer window. This COM object is using the “Document.Application” property and you we call the ShellExecute method on the object returned by the “Document.Application.Parent” property to execute code on a remote target.
ShellBrowserWindow CLSID is {C08AFD90-F2A1-11D1-8455-00A0C91F3880}
DDE, or Dynamic Data Exchange, is a legacy interprocess communication mechanism implemented in some Windows applications. Making Excel (or other MS Office applications) evaluate an expression ("=cmd|' /C calc'!A0", for example) that requires data to be transmitted via DDE from another application. It allows an attacker to specify an arbitrary command line as the DDE server to be run.
The DDEInitiate method exposed by the Excel.Application COM object can be use to execute code on a remote target.
The method appends ".exe" to the App parameter, so we need to remove the extension
We can use following commands to execute a DLL or XLL file
One of the interesting techniques discovered by homjxi0e, you can open internet Explorer browser on remote machines by using navigate methods which you can use it get command execution by browser exploits.
First we need to encode our chosen DCOM object using base64 i.e.:
Then we can call invoke-RunasCs function using the following command
Impacket's scriot can be use to spawn a semi-interactive shell. It can leverage MMC20.Application, ShellWindows and ShellBrowserWindow objects.
The Powershell script allows to easily invoke various DCOM methods to execute code on remote targets.
The COM object allows you to script components of MMC snap-in operations. TheExecuteShellCommand method under Document.ActiveView can be abuse to execute arbitrary commands on a remote target.
The COM object is used to control and execute Shell commands, and to obtain other Shell-related objects. This COM object is using the "Document.Application" property and you we call the ShellExecute method on the object returned by the "Document.Application.Parent" property to execute code on a remote target.
Since there is no associated with this object, we can use the .NET method paired with the method to instantiate the object via its AppID on a remote host.
The RegisterXLL method exposed by the Excel.Application COM object can be use to load and execute a DLL on a remote target. The RegisterXLL function expects an which is essentially a specially crafted DLL.
DCOM objects runs under current user session which can be a problem if we have a non-interactive shell and we want to run it under higher privileged user. A quick solution is to use , an implementation of RunAs by antonioCoco in C# , which we can integrate with our chosen DCOM object to pass credentials in non-interactive shell (note this will be a better choice than invoke-command since it uses )
