Yes, but the native log coverage is thin and requires correlating three separate event sources most organizations never connect. DCOM lateral movement via MMC20.Application and ShellWindows leaves traces in Security Event ID 4624 (network logon), System Event ID 10016 (DCOM permission errors), and DCOM activation logs — none of which trigger by default at sufficient verbosity to catch it reliably without tuning.
Pithy Security | Cybersecurity FAQs – The Details
Question: Can Windows Event Logs detect DCOM lateral movement via MMC20.Application without Sysmon installed?
Asked by: DeepSeek V3
Answered by: Mike D (MrComputerScience) from Pithy Security.
Why DCOM Lateral Movement via MMC20.Application Evades Default Log Coverage
DCOM-based lateral movement is attractive to attackers precisely because it abuses a legitimate Windows inter-process communication mechanism. When an attacker instantiates MMC20.Application remotely via [activator]::CreateInstance([type]::GetTypeFromProgID("MMC20.Application","<target IP>")) or the equivalent Python/CSharp call, Windows processes this as a legitimate DCOM activation request. No new service is installed. No scheduled task is created. No obvious persistence artifact lands on disk.
The native log footprint on the target machine is limited to a Type 3 (network) logon in Security Event ID 4624, which is generated for essentially every lateral movement technique and drowns in normal domain traffic noise. The DCOM activation itself may generate a System Event ID 10016 if the activating account lacks the precise DCOM launch and activation permissions configured in Component Services, but in many domain environments the activating account has sufficient rights and 10016 never fires.
What’s missing without Sysmon: there is no native Windows event that records the DCOM ProgID being activated, the remote IP initiating the activation, or the child process spawned by the DCOM server. Sysmon Event ID 1 (process creation) with its ParentImage field is what makes mmc.exe spawning cmd.exe or powershell.exe visible. Without it, that process creation is either unlogged or visible only in Security Event ID 4688 if process creation auditing is enabled with command line logging — which most environments have not turned on.
The Three-Log Correlation That Works Without Sysmon
Sysmon is the clean answer. Without it, the detection requires stitching together logs that most SIEMs are not configured to correlate by default.
Log source 1: Security Event ID 4688 with command line auditing. Enable “Audit Process Creation” under Advanced Audit Policy Configuration and set the registry key HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\System\Audit\ProcessCreationIncludeCmdLine_Enabled to 1. This makes 4688 record the full command line of every spawned process. On the target host, mmc.exe appearing as a parent process for cmd.exe, powershell.exe, or wscript.exe with no corresponding interactive session is the artifact. Filter 4688 events where ParentProcessName contains mmc.exe and SubjectLogonId matches a Type 3 logon from 4624.
Log source 2: Security Event ID 4624 Type 3 logon correlated to process creation timing. The network logon establishing the DCOM session lands in 4624 with LogonType 3. Correlate the LogonID from that event to subsequent 4688 events on the same host within a short time window. A Type 3 logon immediately followed by mmc.exe spawning a shell process is the combined indicator. Neither event alone is meaningful. Together they are high-confidence.
Log source 3: System Event ID 10016 as a pre-attack enumeration indicator. Attackers frequently probe DCOM activation permissions before committing to a target account. Failed activation attempts from an account without sufficient DCOM rights generate 10016 in the System log with the specific AppID and the requesting account. A 10016 from an account that has no business activating DCOM objects remotely, followed later by successful activation from a different (higher-privileged) account, is a sequenced indicator of permission enumeration. Most SIEM deployments do not ingest System logs at all. This is a gap worth fixing specifically for this technique.
When Native Windows DCOM Logging Actually Catches Lateral Movement
The one scenario where native logs provide clean coverage without Sysmon or 4688 tuning: environments that have enabled the “Audit DCOM Activity” subcategory under Object Access in Advanced Audit Policy. This subcategory generates Event ID 4779 and related DCOM-specific events that record activation requests including the ProgID and source address. It is not enabled by default. It is not mentioned in most hardening guides. CIS Benchmark Level 2 for Windows Server recommends it, which means it exists in CIS-compliant environments and almost nowhere else.
If your organization uses Microsoft Defender for Identity, lateral movement using DCOM is covered under the “Remote code execution attempt” alert category. MDI correlates network logon events against known DCOM execution patterns and fires on the MMC20.Application and ShellWindows techniques specifically. It requires no additional log source configuration beyond the standard MDI sensor deployment on Domain Controllers and monitored hosts.
For pure Sigma-based detection without MDI, the SIGMA rule targeting this technique (contributed to the SigmaHQ repository under windows/process_creation/proc_creation_win_mmc_spawn_shell.yml) targets exactly the mmc.exe parent / shell child process creation pattern in 4688 events. That rule is your fastest path to coverage if you enable command line process auditing today.
MITRE ATT&CK maps this to T1021.003 (Remote Services: Distributed Component Object Model). The detection notes there confirm that native Windows logging requires process creation auditing and command line capture to be useful, and recommend Sysmon as the preferred implementation. That recommendation is correct. But if Sysmon deployment is blocked by operational constraints, the three-log correlation above is the next best available option.
What This Means For You
- Enable “Audit Process Creation” with command line logging via Advanced Audit Policy and the
ProcessCreationIncludeCmdLine_Enabledregistry key on all Windows hosts, because Event ID 4688 without command lines is forensically near-useless for DCOM detection. - Ingest System Event ID 10016 into your SIEM if it is currently excluded, and alert on activation failures from accounts with no legitimate DCOM administration role, since this catches permission enumeration before the lateral movement succeeds.
- Correlate Type 3 logon events (4624 LogonType=3) against subsequent 4688 process creation events on the same host within a 60-second window, filtering specifically for
mmc.exe,dllhost.exe, andsvchost.exeas parent processes spawning interactive shells. - Enable “Audit DCOM Activity” under Object Access in Advanced Audit Policy on high-value servers and Domain Controllers, since this subcategory provides ProgID-level visibility that no other native log source captures.
- Deploy the SigmaHQ rule
proc_creation_win_mmc_spawn_shell.ymlagainst your 4688 pipeline as an immediate coverage gap closure while longer-term Sysmon deployment is planned.
Related Questions
- 1
- 2
- 3