Component Object Model and Distributed COM
Adversaries may abuse the Windows Component Object Model (COM) and Distributed Component Object Model (DCOM) for local code execution or to move laterally across a network. This deprecated technique encompasses both local COM abuse (now T1559.001) and DCOM-based lateral movement (now T1021.003). COM is a native Windows API component enabling interaction between software objects through well-defined interfaces; DCOM extends this functionality over a network via RPC. Adversaries exploit COM interfaces to invoke arbitrary code execution through C++, Java, VBScript, and PowerShell. For DCOM lateral movement, privileged users can remotely activate objects such as MMC20.Application (CLSID: 49B2791A-B1AE-4C90-9B8E-E860BA07F889), ShellWindows (CLSID: 9BA05972-F6A8-11CF-A442-00A0C90A8F39), and ShellBrowserWindow (CLSID: C08AFD90-F2A1-11D1-8455-00A0C91F3880) to execute commands on remote hosts. Microsoft Office application objects (Excel.Application, Outlook.Application) exposed via DCOM also permit remote code execution and macro invocation. COM surrogate processes (dllhost.exe /Processid:{CLSID}) serve as the activation vehicle for out-of-process COM servers, making dllhost.exe spawning unexpected child processes a high-fidelity indicator. DCOM lateral movement communicates over TCP 135 (RPC Endpoint Mapper) before negotiating an ephemeral high port, distinguishing it from WMI or SMB-based lateral movement.
What is T1175 Component Object Model and Distributed COM?
Component Object Model and Distributed COM (T1175) maps to the Lateral Movement and Execution tactics — the adversary is trying to move through your environment in MITRE ATT&CK.
This page provides production-ready detection logic for Component Object Model and Distributed COM, covering the data sources and telemetry it touches: Process: Process Creation, Microsoft Defender for Endpoint. The queries below are rated high severity at medium confidence, and ship for 7 SIEM platforms — KQL, SPL, Elastic, QRadar, Sumo, YARA-L, LogScale.
MITRE ATT&CK
- Tactic
- Lateral Movement Execution
- Canonical reference
- https://attack.mitre.org/techniques/T1175/
let COMShells = dynamic(["cmd.exe", "powershell.exe", "pwsh.exe", "wscript.exe", "cscript.exe", "mshta.exe", "rundll32.exe", "regsvr32.exe"]);
let OfficeApps = dynamic(["excel.exe", "outlook.exe", "winword.exe", "powerpnt.exe", "onenote.exe"]);
DeviceProcessEvents
| where Timestamp > ago(24h)
| where FileName in~ (COMShells)
| where (
// COM Surrogate (dllhost.exe /Processid:) spawning shells — primary DCOM remote activation indicator
(InitiatingProcessFileName =~ "dllhost.exe" and InitiatingProcessCommandLine has "/Processid:")
// MMC20.Application abuse — classic DCOM lateral movement vector documented by enigma0x3
or (InitiatingProcessFileName =~ "mmc.exe" and FileName in~ ("cmd.exe", "powershell.exe", "pwsh.exe", "wscript.exe", "cscript.exe", "mshta.exe"))
// Office application DCOM — Excel, Outlook, or Word spawning shells via COM interfaces
or (InitiatingProcessFileName in~ (OfficeApps) and FileName in~ ("cmd.exe", "powershell.exe", "pwsh.exe", "wscript.exe", "cscript.exe", "mshta.exe"))
)
| extend COMVector = case(
InitiatingProcessFileName =~ "dllhost.exe", "COM_Surrogate_Activation",
InitiatingProcessFileName =~ "mmc.exe", "MMC20_Application_DCOM",
InitiatingProcessFileName in~ (OfficeApps), "Office_Application_DCOM",
"Unknown_COM"
)
| extend DCOMIndicator = InitiatingProcessCommandLine has_any ("/Processid:", "-Embedding")
| project Timestamp, DeviceName, AccountName, FileName, ProcessCommandLine,
InitiatingProcessFileName, InitiatingProcessCommandLine,
InitiatingProcessParentFileName, COMVector, DCOMIndicator
| sort by Timestamp desc Detects COM and DCOM abuse by identifying suspicious process chains originating from known COM activation parents. Covers three primary vectors: (1) COM surrogate processes (dllhost.exe with /Processid: argument) spawning shells — the most reliable DCOM remote execution indicator because all out-of-process COM server activations route through dllhost.exe; (2) MMC20.Application DCOM lateral movement where mmc.exe spawns a command interpreter; (3) Microsoft Office DCOM execution where Excel, Outlook, or Word spawn shells via exposed COM application objects. The DCOMIndicator flag highlights processes showing DCOM-specific activation arguments for analyst prioritization.
Data Sources
Required Tables
False Positives
- Legitimate IT administration tools using MMC snap-ins that internally spawn helper processes for managed operations (disk management, event viewer, device manager)
- Software installation packages activating COM servers via dllhost.exe as part of normal registration workflows (MSI installers, COM+ application setup)
- Microsoft Office macros performing legitimate document automation that spawn helper processes such as mail merge or report generation scripts
- Remote management products (RMM tools, monitoring agents) that use DCOM as a transport mechanism for legitimate administrative operations on managed endpoints
- COM+ application servers hosting business line applications that legitimately spawn worker processes via dllhost.exe as part of their normal operation
Sigma rule & cross-platform mapping
The detection logic for Component Object Model and Distributed COM (T1175) above is provided in a vendor-neutral
form so you can deploy it on any SIEM. The same logic is shipped here as native
KQL (Microsoft Sentinel / Defender), SPL (Splunk), Elastic (Elastic Security (EQL)), QRadar (IBM QRadar (AQL)), Sumo (Sumo Logic CSE), YARA-L (Google Chronicle / SecOps), LogScale (CrowdStrike LogScale (CQL)) queries. In Sigma terms, this detection targets the
following logsource:
logsource:
category: process_creation
product: windows Browse the community-maintained Sigma rules for this technique:
Platform-specific guides for T1175
References (12)
- https://attack.mitre.org/techniques/T1175/
- https://attack.mitre.org/techniques/T1021/003/
- https://attack.mitre.org/techniques/T1559/001/
- https://www.fireeye.com/blog/threat-research/2019/06/hunting-com-objects.html
- https://enigma0x3.net/2017/01/05/lateral-movement-using-the-mmc20-application-com-object/
- https://enigma0x3.net/2017/01/23/lateral-movement-via-dcom-round-2/
- https://enigma0x3.net/2017/09/11/lateral-movement-using-excel-application-and-dcom/
- https://enigma0x3.net/2017/11/16/lateral-movement-using-outlooks-createobject-method-and-dotnettojscript/
- https://www.cybereason.com/blog/leveraging-excel-dde-for-lateral-movement-via-dcom
- https://github.com/redcanaryco/atomic-red-team/blob/master/atomics/T1175/T1175.md
- https://learn.microsoft.com/en-us/windows/win32/com/com-technical-overview
- https://googleprojectzero.blogspot.com/2018/04/windows-exploitation-tricks-exploiting.html
Testing Methodology
Validate this detection against 4 adversary techniques from Atomic Red Team. Each test below lists the behaviour to exercise and the telemetry you should expect to see. Executable commands and cleanup steps are available with Pro.
- Test 1MMC20.Application DCOM Local Shell Execution
Expected signal: Sysmon Event ID 1: mmc.exe created (parent: powershell.exe), then cmd.exe spawned with ParentImage=mmc.exe, CommandLine='/c whoami > %TEMP%\dcom-mmc20-test.txt'. Sysmon Event ID 11: file created at %TEMP%\dcom-mmc20-test.txt. DeviceProcessEvents shows InitiatingProcessFileName='mmc.exe' spawning FileName='cmd.exe'. DCOM-Server/Operational may log the COM activation.
- Test 2ShellWindows COM Object Shell Execution via Shell.Application
Expected signal: Sysmon Event ID 1: cmd.exe spawned with ParentImage=explorer.exe or dllhost.exe depending on Windows version and COM activation path. File created at %TEMP%\shellapp-test.txt. PowerShell ScriptBlock Log Event ID 4104 captures 'New-Object -ComObject Shell.Application' and 'ShellExecute' calls. DeviceProcessEvents records the cmd.exe creation with its initiating process context.
- Test 3DCOM Remote Execution via MMC20.Application (Lab Environment — Requires Admin on Target)
Expected signal: SOURCE: Sysmon Event ID 3 — TCP connection to 192.168.1.100:135, then ephemeral port connection. Security Event ID 4648 if alternate credentials used. TARGET: Security Event ID 4624 Type 3 (network logon) from source IP. Sysmon Event ID 1: dllhost.exe /Processid:{49B2791A-B1AE-4C90-9B8E-E860BA07F889} created, then cmd.exe spawned with ParentImage=dllhost.exe. File created at C:\Windows\Temp\dcom-remote-test.txt.
- Test 4COM Object Scheduled Task Creation via Schedule.Service
Expected signal: Sysmon Event ID 12/13 (Registry): Task Scheduler registry key creation under HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Schedule\TaskCache\. Security Event ID 4698 (Scheduled task created) in Windows Security log. PowerShell ScriptBlock Log Event ID 4104 showing New-Object -ComObject Schedule.Service invocation. DeviceProcessEvents shows only powershell.exe (no schtasks.exe child process — the entire task creation happens via COM API).
Response Playbook
Triage
- Identify the full process tree: trace what spawned dllhost.exe, mmc.exe, or the Office application using DeviceProcessEvents — was it a user interactive session, a service, a scheduled task, or an inbound network connection context? Remote DCOM activation often shows the process tree rooted under a SYSTEM or NETWORK SERVICE logon session.
- For dllhost.exe /Processid:{GUID} events: extract the CLSID and look it up in HKLM\SOFTWARE\Classes\CLSID\{GUID} on the affected host to identify which COM server was activated. Compare against known-malicious CLSIDs: 49B2791A-B1AE-4C90-9B8E-E860BA07F889 (MMC20.Application), 9BA05972-F6A8-11CF-A442-00A0C90A8F39 (ShellWindows), C08AFD90-F2A1-11D1-8455-00A0C91F3880 (ShellBrowserWindow).
- Determine source vs. target: if dllhost.exe or mmc.exe spawned the shell under a SYSTEM context or under a Type 3 (network) logon session without a corresponding interactive user session, the system is likely the DCOM target receiving lateral movement commands from an external source.
- Check Security Event ID 4624 (Type 3 — Network Logon) and 4648 (Explicit Credentials) on the target system within 60 seconds before the COM activation event. A network logon from an unexpected source IP immediately preceding dllhost.exe spawning cmd.exe is near-definitive evidence of DCOM lateral movement.
- Examine the spawned shell's command line and any subsequent child processes: encoded commands, download cradles, credential dumping tools (procdump, comsvcs.dll MiniDump), or network recon commands (net view, arp -a) confirm post-exploitation activity.
- Check for network connections from the suspicious child process: any outbound connections from cmd.exe or powershell.exe to external IPs or internal pivot targets following COM activation indicate the endpoint is being actively used as a lateral movement stepping stone.
Containment
- Isolate both the source and destination hosts via EDR network isolation or VLAN change if DCOM lateral movement is confirmed — the source host is likely compromised and the attacker may continue pivoting from it.
- Disable the affected domain user account in Active Directory, force password reset, and run klist purge to invalidate active Kerberos tickets if DCOM activation was performed under a compromised domain credential.
- Block TCP 135 (RPC Endpoint Mapper) and the associated ephemeral RPC port range (by default 49152-65535) between workstation segments using firewall rules — DCOM lateral movement is not a legitimate business requirement between standard endpoints in most environments.
- Restrict DCOM permissions on the three primary abuse CLSIDs via DCOMCNFG.exe or registry ACL hardening: HKLM\SOFTWARE\Classes\AppID\{APPID}\LaunchPermission. Remove the 'Everyone' or 'Authenticated Users' launch permission from MMC20.Application, ShellWindows, and ShellBrowserWindow where not needed.
- Terminate suspicious cmd.exe or powershell.exe processes spawned via COM activation and collect a full memory dump of dllhost.exe before termination — malicious COM servers load directly into the dllhost.exe address space and may leave artifacts recoverable from memory.
Evidence Collection
- Process creation logs: Sysmon Event ID 1 showing the full dllhost.exe invocation with /Processid:{CLSID} argument and parent process details, plus the subsequent shell spawn with complete command line.
- Network connection logs: Sysmon Event ID 3 on the source system for TCP 135 connections from unusual processes; on the destination system for ephemeral high-port RPC connections establishing after the TCP 135 endpoint mapper query.
- Authentication events: Security Event ID 4624 (Type 3 — Network Logon) and 4648 (Explicit Credentials) on destination systems — correlate user accounts and source IPs to the COM activation timestamp.
- DCOM operational log: Microsoft-Windows-DCOM-Server/Operational — Event ID 10010 (server registration timeout), 10016 (permission denied for activation) — permission denials may indicate adversary DCOM reconnaissance probing available objects before successful activation.
- COM registration artifacts: export HKLM\SOFTWARE\Classes\CLSID at the time of investigation and compare against a known-good baseline to identify newly registered or modified COM servers (InprocServer32 or LocalServer32 values).
- Memory forensics: full memory dump of the suspicious dllhost.exe process using WinPMEM or EDR memory collection — malicious COM DLLs loaded in-process leave recoverable PE artifacts, import tables, and strings even after process termination.
- Prefetch files: C:\Windows\Prefetch\DLLHOST.EXE-*.pf includes a list of loaded DLLs, which can identify which COM server DLL was activated and establish execution timestamps.
- WMI query: SELECT * FROM Win32_Process WHERE ParentProcessId=<dllhost_pid> to enumerate all child processes spawned at time of investigation; SELECT * FROM Win32_DCOMApplicationSetting to review current DCOM permissions configuration.
Escalation Criteria
- ! DCOM lateral movement to a high-value target: domain controller, file server, database server, or certificate authority — any successful COM activation on these assets requires immediate escalation regardless of payload.
- ! Multiple systems showing dllhost.exe or mmc.exe spawning shells within a 30-minute window — indicates automated DCOM-based lateral movement, impacket dcomexec.py, or worm-like propagation requiring incident response mobilization.
- ! Post-execution credential dumping: cmd.exe or powershell.exe spawned via COM then accessing LSASS memory (Sysmon Event ID 10 targeting lsass.exe) or executing known credential harvesting techniques (comsvcs.dll MiniDump, procdump, Mimikatz indicators).
- ! Known attacker CLSID confirmed: activation of CLSIDs specifically documented in DCOM lateral movement techniques (MMC20.Application, ShellWindows, ShellBrowserWindow) without a corresponding legitimate business process — these CLSIDs are rarely activated in normal enterprise operations.
- ! Privilege escalation observed: process spawned via COM activation running as SYSTEM or a Domain Admin when the activating network logon context was a lower-privileged account — indicates a privilege escalation component in addition to lateral movement.
Investigation Guide
Forensic Artifacts
- >
Registry: HKLM\SOFTWARE\Classes\CLSID\{GUID}\InprocServer32 and LocalServer32 — COM server registration values; modification timestamps and DLL/EXE paths pointing to non-standard locations indicate COM hijacking. - >
Registry: HKCR\AppID\{APPID} and HKLM\SOFTWARE\Classes\AppID\{APPID} — DCOM application configuration including LaunchPermission (binary ACL), AccessPermission, and RunAs values that control who may activate objects remotely. - >
Registry: HKLM\SOFTWARE\Microsoft\Ole\DefaultLaunchPermission — system-wide default DCOM launch permissions stored as a binary ACL; modification to grant broad access may indicate privilege escalation setup. - >
Event Log: Microsoft-Windows-DCOM-Server/Operational — Event ID 10016 (machine-default permission denied for DCOM activation) frequently generated during adversary DCOM object reconnaissance before finding a usable target. - >
Event Log: Security — Event ID 4624 Type 3 (network logon immediately preceding COM activation), 4648 (explicit credentials for DCOM remote activation), 4672 (special privileges assigned, may indicate DCOM activation by privileged account). - >
File System: C:\Windows\Prefetch\DLLHOST.EXE-*.pf — prefetch entries list all DLLs loaded by dllhost.exe instances, which can identify the specific COM server DLL and execution timestamps. - >
Network: TCP 135 connection (RPC Endpoint Mapper query) followed by data exchange on a negotiated ephemeral port (49152-65535) from source to destination in PCAP or NetFlow — the characteristic two-phase DCOM connection pattern. - >
Memory: dllhost.exe process memory may contain the loaded COM server DLL image, strings from the server's code, and heap allocations from the malicious COM object's execution — recoverable even after process termination with a memory dump.
Tuning Guidance
Baseline your environment's legitimate COM activation patterns before enabling aggressive alerting. Key exclusions to evaluate: (1) dllhost.exe spawning File Explorer sub-processes or thumbnail handlers — this is normal shell COM behavior; (2) mmc.exe spawning management helper processes as part of legitimate snap-in operations (taskmgr.exe from Task Manager snap-in, compmgmt.exe subprocesses); (3) Software deployment tools (SCCM, Intune, PDQ Deploy) that activate COM servers during software installation workflows. The highest-fidelity signal in this detection is dllhost.exe /Processid: spawning cmd.exe or powershell.exe — this parent-child relationship is extremely unusual in legitimate enterprise environments and should not be filtered. Network-based detection (TCP 135 from non-system processes) will generate significant noise in environments with COM+ applications, custom enterprise middleware, or legacy software using DCOM for IPC; scope that query to specific high-value network segments. Consider implementing preventive hardening on the three primary DCOM lateral movement CLSIDs (MMC20.Application, ShellWindows, ShellBrowserWindow) by restricting LaunchPermission to Administrators only via DCOMCNFG.exe — this eliminates the most common DCOM lateral movement paths without impacting typical workloads. Enterprises should evaluate whether DCOM is required between workstations; blocking TCP 135 between workstation VLANs at the network layer eliminates the technique entirely for that segment.
Hunting Queries
Hunt for unusual processes making DCOM connections to TCP 135 (RPC Endpoint Mapper). Non-system processes connecting to port 135 on multiple hosts are strong indicators of automated DCOM lateral movement tools (impacket dcomexec.py, CrackMapExec DCOM module) or malware using DCOM for propagation. A single source process connecting to multiple internal targets is especially high-fidelity.
// Hunt for DCOM network activity — non-system processes connecting to TCP 135 across multiple targets
DeviceNetworkEvents
| where Timestamp > ago(7d)
| where RemotePort == 135
| where InitiatingProcessFileName !in~ (dynamic(["svchost.exe", "services.exe", "lsass.exe", "msiexec.exe", "wuauclt.exe", "TrustedInstaller.exe", "SearchIndexer.exe", "MsMpEng.exe"]))
| summarize ConnectionCount=count(), UniqueTargets=dcount(RemoteIP), TargetHosts=make_set(RemoteIP), Earliest=min(Timestamp), Latest=max(Timestamp) by DeviceName, InitiatingProcessFileName, InitiatingProcessCommandLine
| where ConnectionCount > 2 or UniqueTargets > 1
| sort by UniqueTargets desc, ConnectionCount desc index=wineventlog sourcetype="XmlWinEventLog:Microsoft-Windows-Sysmon/Operational" EventCode=3 DestinationPort=135
| where NOT (Image LIKE "%\\svchost.exe" OR Image LIKE "%\\services.exe" OR Image LIKE "%\\lsass.exe" OR Image LIKE "%\\msiexec.exe" OR Image LIKE "%\\TrustedInstaller.exe" OR Image LIKE "%\\SearchIndexer.exe" OR Image LIKE "%\\MsMpEng.exe")
| stats count as ConnectionCount, dc(DestinationIp) as UniqueTargets, values(DestinationIp) as TargetHosts, earliest(_time) as Earliest, latest(_time) as Latest by host, Image, CommandLine
| where ConnectionCount > 2 OR UniqueTargets > 1
| sort - UniqueTargets ConnectionCount Hunt for all dllhost.exe CLSID activations in the environment and flag known-malicious CLSIDs used in documented DCOM lateral movement attacks. This baseline query helps identify rare CLSIDs activated from unexpected parent processes. CLSIDs appearing on multiple hosts within a short window, or CLSIDs not present in the environment's baseline, warrant investigation as potential DCOM lateral movement artifacts.
// Hunt for dllhost.exe CLSID activations — inventory all COM server activations and flag known-malicious CLSIDs
DeviceProcessEvents
| where Timestamp > ago(7d)
| where FileName =~ "dllhost.exe"
| where ProcessCommandLine has "/Processid:"
| extend CLSID = extract(@"/Processid:\{([0-9A-Fa-f\-]+)\}", 1, ProcessCommandLine)
| extend KnownMaliciousCLSID = CLSID in~ (
"49B2791A-B1AE-4C90-9B8E-E860BA07F889", // MMC20.Application
"9BA05972-F6A8-11CF-A442-00A0C90A8F39", // ShellWindows
"C08AFD90-F2A1-11D1-8455-00A0C91F3880" // ShellBrowserWindow
)
| summarize ActivationCount=count(), UniqueHosts=dcount(DeviceName), UniqueAccounts=dcount(AccountName), Earliest=min(Timestamp), Latest=max(Timestamp), KnownMalicious=max(toint(KnownMaliciousCLSID)) by CLSID, InitiatingProcessFileName
| sort by KnownMalicious desc, ActivationCount desc index=wineventlog sourcetype="XmlWinEventLog:Microsoft-Windows-Sysmon/Operational" EventCode=1
| where Image LIKE "%\\dllhost.exe" AND CommandLine LIKE "%/Processid:%"
| rex field=CommandLine "/Processid:\{(?<CLSID>[0-9A-Fa-f\-]+)\}"
| eval KnownMaliciousCLSID=if(match(upper(CLSID), "(49B2791A-B1AE-4C90-9B8E-E860BA07F889|9BA05972-F6A8-11CF-A442-00A0C90A8F39|C08AFD90-F2A1-11D1-8455-00A0C91F3880)"), 1, 0)
| stats count as ActivationCount, dc(host) as UniqueHosts, dc(User) as UniqueAccounts, values(host) as Hosts, max(KnownMaliciousCLSID) as KnownMaliciousCLSID by CLSID, ParentImage
| sort - KnownMaliciousCLSID ActivationCount Hunt for COM server registrations pointing to DLLs in user-writable or suspicious directories. Legitimate COM servers register in %SystemRoot% or %ProgramFiles%. InprocServer32 or LocalServer32 values pointing to AppData, Temp, or ProgramData indicate COM hijacking for persistence or privilege escalation via DLL search order abuse. This pattern precedes execution and provides pre-compromise detection opportunity.
// Hunt for COM server DLL registrations in user-writable locations — potential COM hijacking for persistence
DeviceRegistryEvents
| where Timestamp > ago(7d)
| where RegistryKey has_any ("CLSID", "InprocServer32", "LocalServer32")
| where RegistryValueData has_any (@"\AppData\", @"\Temp\", @"\ProgramData\", @"\Users\Public\", @"\Downloads\", @"\Desktop\")
| where ActionType in ("RegistryValueSet", "RegistryKeyCreated")
| project Timestamp, DeviceName, AccountName, RegistryKey, RegistryValueName, RegistryValueData, InitiatingProcessFileName, InitiatingProcessCommandLine
| sort by Timestamp desc index=wineventlog sourcetype="XmlWinEventLog:Microsoft-Windows-Sysmon/Operational" (EventCode=12 OR EventCode=13 OR EventCode=14)
| where match(TargetObject, "(?i)(CLSID|InprocServer32|LocalServer32)")
| where match(lower(Details), "(appdata|temp|programdata|users.public|downloads|desktop)")
| table _time, host, User, TargetObject, Details, Image, CommandLine
| sort - _time Atomic Red Team Tests
Abuses the MMC20.Application COM object (CLSID: 49B2791A-B1AE-4C90-9B8E-E860BA07F889) to spawn a command shell via the ExecuteShellCommand method. This is the classic technique documented by enigma0x3 in 2017. Locally, it creates an mmc.exe -> cmd.exe process chain — the same chain that appears on a DCOM target when this object is activated remotely. The output file confirms successful execution.
Command
powershell.exe -Command "$com = [activator]::CreateInstance([type]::GetTypeFromProgID('MMC20.Application')); $com.Document.ActiveView.ExecuteShellCommand('cmd.exe', $null, '/c whoami > $env:TEMP\dcom-mmc20-test.txt', '7')" Cleanup
Remove-Item $env:TEMP\dcom-mmc20-test.txt -ErrorAction SilentlyContinue Expected Telemetry
Sysmon Event ID 1: mmc.exe created (parent: powershell.exe), then cmd.exe spawned with ParentImage=mmc.exe, CommandLine='/c whoami > %TEMP%\dcom-mmc20-test.txt'. Sysmon Event ID 11: file created at %TEMP%\dcom-mmc20-test.txt. DeviceProcessEvents shows InitiatingProcessFileName='mmc.exe' spawning FileName='cmd.exe'. DCOM-Server/Operational may log the COM activation.
Expected Detection
Main detection fires on IsMMCSpawn=1 with IsSuspiciousChild=1. COMVector='MMC20_Application_DCOM'. CLSID hunting query identifies 49B2791A-B1AE-4C90-9B8E-E860BA07F889 as the activated COM server.
Abuses the Shell.Application COM object to invoke ShellExecute through PowerShell's New-Object -ComObject interface. This technique uses an existing Explorer.exe window reference to spawn a process, resulting in cmd.exe appearing as a child of explorer.exe — a parent process that blends with normal user activity. Demonstrates how COM provides alternative execution paths that evade detections focused on specific shell-to-shell parent-child relationships.
Command
powershell.exe -Command "$shell = New-Object -ComObject 'Shell.Application'; $shell.ShellExecute('cmd.exe', '/c whoami > $env:TEMP\shellapp-test.txt', '', 'open', 0)" Cleanup
Remove-Item $env:TEMP\shellapp-test.txt -ErrorAction SilentlyContinue Expected Telemetry
Sysmon Event ID 1: cmd.exe spawned with ParentImage=explorer.exe or dllhost.exe depending on Windows version and COM activation path. File created at %TEMP%\shellapp-test.txt. PowerShell ScriptBlock Log Event ID 4104 captures 'New-Object -ComObject Shell.Application' and 'ShellExecute' calls. DeviceProcessEvents records the cmd.exe creation with its initiating process context.
Expected Detection
May trigger COM_Surrogate_Activation if dllhost.exe intermediates the activation. CLSID hunting query identifies ShellWindows or ShellApplication CLSID in dllhost.exe activations. PowerShell ScriptBlock logging provides secondary detection of the COM object invocation pattern.
Demonstrates DCOM lateral movement by remotely activating MMC20.Application on a target host and invoking ExecuteShellCommand. Requires local administrator rights on the target system (192.168.1.100 — replace with lab target IP). On the source, generates TCP 135 followed by ephemeral RPC port connections. On the target, creates a dllhost.exe process with the MMC20.Application CLSID argument that spawns cmd.exe. This replicates the exact network and process telemetry generated by tools like impacket's dcomexec.py. Use only in authorized lab environments.
Command
powershell.exe -Command "$target = '192.168.1.100'; $com = [activator]::CreateInstance([type]::GetTypeFromProgID('MMC20.Application', $target)); $com.Document.ActiveView.ExecuteShellCommand('cmd.exe', $null, '/c whoami > C:\\Windows\\Temp\\dcom-remote-test.txt', '7')" Cleanup
# On target system: Remove-Item C:\Windows\Temp\dcom-remote-test.txt -ErrorAction SilentlyContinue Expected Telemetry
SOURCE: Sysmon Event ID 3 — TCP connection to 192.168.1.100:135, then ephemeral port connection. Security Event ID 4648 if alternate credentials used. TARGET: Security Event ID 4624 Type 3 (network logon) from source IP. Sysmon Event ID 1: dllhost.exe /Processid:{49B2791A-B1AE-4C90-9B8E-E860BA07F889} created, then cmd.exe spawned with ParentImage=dllhost.exe. File created at C:\Windows\Temp\dcom-remote-test.txt.
Expected Detection
TARGET: Main detection fires on COM_Surrogate_Activation (dllhost.exe with /Processid: spawning cmd.exe). SOURCE: Network hunting query flags TCP 135 connection from powershell.exe to non-local IP. CLSID hunting query identifies 49B2791A-B1AE-4C90-9B8E-E860BA07F889 activation. Both MDE and Sysmon telemetry confirm on target system.
Abuses the Schedule.Service COM object (CLSID: 0F87369F-A4E5-4CFC-BD3E-73E6154572DD) to create a scheduled task without using schtasks.exe or PowerShell's New-ScheduledTask cmdlets. This technique demonstrates COM-based persistence that bypasses process-level detections watching for schtasks.exe or at.exe execution, and shows how COM provides an alternative API surface for adversary actions beyond just code execution.
Command
powershell.exe -Command "$svc = New-Object -ComObject Schedule.Service; $svc.Connect(); $folder = $svc.GetFolder('\\'); $task = $svc.NewTask(0); $task.Settings.Hidden = $true; $action = $task.Actions.Create(0); $action.Path = 'cmd.exe'; $action.Arguments = '/c whoami > $env:TEMP\com-task-test.txt'; $trigger = $task.Triggers.Create(1); $trigger.StartBoundary = '2099-01-01T00:00:00'; $folder.RegisterTaskDefinition('df00tech-com-test', $task, 6, $null, $null, 3); Write-Host 'Task created'" Cleanup
powershell.exe -Command "$svc = New-Object -ComObject Schedule.Service; $svc.Connect(); $svc.GetFolder('\\').DeleteTask('df00tech-com-test', 0)" ; Remove-Item $env:TEMP\com-task-test.txt -ErrorAction SilentlyContinue Expected Telemetry
Sysmon Event ID 12/13 (Registry): Task Scheduler registry key creation under HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Schedule\TaskCache\. Security Event ID 4698 (Scheduled task created) in Windows Security log. PowerShell ScriptBlock Log Event ID 4104 showing New-Object -ComObject Schedule.Service invocation. DeviceProcessEvents shows only powershell.exe (no schtasks.exe child process — the entire task creation happens via COM API).
Expected Detection
Security Event ID 4698 fires for task creation regardless of method. COM usage is identified via PowerShell ScriptBlock logging showing Schedule.Service COM instantiation. Note that the main process-based detection does NOT fire here since no shell process is spawned — this demonstrates a COM abuse gap that requires event log-based detection rather than process tree analysis.