Incoming DCOM Lateral Movement with MMC
Identifies the use of Distributed Component Object Model (DCOM) to run commands from a remote host, which are launched via the MMC20 Application COM Object. This behavior may indicate an attacker abusing a DCOM application to move laterally.
Elastic rule (View on GitHub)
1[metadata]
2creation_date = "2020/11/06"
3integration = ["endpoint", "windows"]
4maturity = "production"
5updated_date = "2026/05/03"
6
7[rule]
8author = ["Elastic"]
9description = """
10Identifies the use of Distributed Component Object Model (DCOM) to run commands from a remote host, which are launched
11via the MMC20 Application COM Object. This behavior may indicate an attacker abusing a DCOM application to move
12laterally.
13"""
14from = "now-9m"
15index = [
16 "winlogbeat-*",
17 "logs-endpoint.events.process-*",
18 "logs-endpoint.events.network-*",
19 "logs-windows.sysmon_operational-*",
20]
21language = "eql"
22license = "Elastic License v2"
23name = "Incoming DCOM Lateral Movement with MMC"
24references = ["https://enigma0x3.net/2017/01/05/lateral-movement-using-the-mmc20-application-com-object/"]
25risk_score = 73
26rule_id = "51ce96fb-9e52-4dad-b0ba-99b54440fc9a"
27severity = "high"
28tags = [
29 "Domain: Endpoint",
30 "OS: Windows",
31 "Use Case: Threat Detection",
32 "Tactic: Lateral Movement",
33 "Data Source: Elastic Defend",
34 "Data Source: Sysmon",
35 "Resources: Investigation Guide",
36]
37type = "eql"
38
39query = '''
40sequence by host.id with maxspan=1m
41 [network where host.os.type == "windows" and event.type == "start" and process.name : "mmc.exe" and source.port >= 49152 and
42 destination.port >= 49152 and source.ip != "127.0.0.1" and source.ip != "::1" and
43 network.direction : ("incoming", "ingress") and network.transport == "tcp"
44 ] by process.entity_id
45 [process where host.os.type == "windows" and event.type == "start" and process.parent.name : "mmc.exe"
46 ] by process.parent.entity_id
47'''
48
49note = """## Triage and analysis
50
51### Investigating Incoming DCOM Lateral Movement with MMC
52
53#### Possible investigation steps
54
55- Which Timeline source events define the target MMC instance, spawned child, and remote source?
56 - Why: this asymmetric sequence links incoming "mmc.exe" network activity to a child process, and the alert may not preserve one reliable process identity.
57 - Focus: recover the target MMC network event and child process event, recording target MMC and child `process.entity_id`, `source.ip`, and child `process.command_line`.
58 - Implication: escalate if the chain does not resolve to one incoming MMC process spawning one child; lower suspicion only when it fits a recognized MMC administration source and child, then continue to command and network interpretation.
59- Does the network event fit remote DCOM or RPC traffic into MMC?
60 - Focus: the recovered "mmc.exe" network event: `source.ip`, `source.port`, `destination.port`, `network.direction`, and `network.transport`.
61 - Implication: DCOM-style remote execution is supported by incoming TCP from a non-loopback `source.ip` with both ports in the high RPC range; concern rises when the source is a peer workstation, unrelated server, or unknown management origin.
62- What did MMC execute through MMC20.Application COM automation?
63 - Focus: recovered child `process.executable` and `process.command_line`.
64 - Implication: escalate when MMC launches cmd.exe, PowerShell, script hosts, LOLBins, loaders, or download cradles; lower suspicion only when the exact child command is a recognized MMC snap-in helper or management binary and the source context also fits.
65- Is the child binary identity consistent with the behavior, without treating signer trust as clearance?
66 - Focus: child `process.hash.sha256`, `process.pe.original_file_name`, `process.code_signature.subject_name`, `process.code_signature.trusted`, and entity context.
67 - Implication: mismatched PE metadata, user-writable paths, unexpected publishers, or quick follow-on LOLBin execution increases concern; a trusted signer confirms identity only and does not clear remote command execution.
68- Does the target-side user and session fit remote administration from the recovered source?
69 - Focus: child `user.id`, `user.name`, and `user.domain`, compared with the recovered source and target host.
70 - Implication: escalate when the user, service context, or session is unexpected for that target or cannot explain administrative access from the source; lower suspicion when source, identity, and session match a recognized admin or jump-host path.
71- Did the MMC-spawned child launch descendants after execution?
72 - Focus: same-host process events from the child, checking child-of-child `process.parent.entity_id`. $investigate_2
73 - Implication: escalate when the child launches more execution chains; absent descendants keeps the case centered on the recovered remote command, not benign.
74- Did the child make DNS or connection activity?
75 - Focus: same-host network events, checking DNS `dns.question.name` and connection `destination.ip`. $investigate_3
76 - Hint: separate DNS events from connection events and keep the pivot bounded to the alert window. Missing network telemetry is unresolved, not benign.
77 - Implication: escalate when the child resolves rare domains or connects to staging or command infrastructure.
78- Does the recovered source or child command appear on other hosts after local triage stays suspicious?
79 - Focus: same-host alerts for `host.id`. $investigate_0
80 - Hint: if the same account is suspicious, compare same-`user.id` alerts for lateral-movement or credential-access patterns across other hosts. $investigate_1
81 - Hint: broaden only after local evidence remains suspicious or unresolved; use `source.ip` for spread and a distinctive child `process.command_line` fragment for tool reuse.
82 - Implication: expand scope when the same source touches more targets, the same child command appears elsewhere, or same-host alerts show lateral movement or defense evasion; keep the case local when the pattern stays confined and the workflow is otherwise explained.
83
84- Escalate when source identity, incoming high-RPC network shape, child intent, identity/session, or descendant/DNS/destination evidence supports unauthorized MMC20.Application execution; close only when recovered evidence, with external confirmation when telemetry cannot prove intent, binds one exact recognized MMC administration workflow with no contradictory follow-on evidence; mixed or incomplete evidence means preserve and escalate.
85
86### False positive analysis
87
88- Remote MMC, server-management automation, or vendor/internal tooling can legitimately trigger this rule when a management host uses DCOM to drive MMC snap-ins or support commands. Confirm the recovered `source.ip` is a recognized admin, jump, or tooling host; child `process.executable` and `process.command_line` show the exact console/helper action; `user.id` or `user.name` fits that path; child `process.hash.sha256` or `process.code_signature.subject_name` is stable when tooling is involved; and descendant, DNS, and connection evidence stays quiet. If inventory or change records are unavailable, telemetry-only closure still requires current evidence to prove the exact workflow; prior recurrence of the same `source.ip`, child command, and `host.id` pattern is corroboration, not closure by itself.
89- Before creating an exception, anchor it on the minimum confirmed workflow pattern: recognized `source.ip`, child `process.executable`, stable `process.command_line`, expected `user.id` or `user.name`, and the relevant `host.id` scope. Avoid exceptions on `process.parent.name` of "mmc.exe" or high RPC ports alone.
90
91### Response and remediation
92
93- If confirmed benign, record the recovered `source.ip`, child `process.executable`, child `process.command_line`, `user.id` or `user.name`, and target `host.id` that established the management workflow, then reverse any temporary containment. Create an exception only if the same pattern recurs consistently across prior alerts.
94- If suspicious but unconfirmed, preserve a case export of the Timeline source events, the target MMC and child process instance IDs, child command line, source socket, and DNS/destination indicators before containment or cleanup.
95- If suspicious but unconfirmed, apply reversible containment tied to the evidence, such as temporary DCOM/RPC restrictions from the recovered `source.ip` to the target `host.id`; isolate the host only when the child command or follow-on activity indicates payload execution and the host role can tolerate it.
96- If confirmed malicious, first preserve the target MMC instance, child command, recovered source, descendant processes, and malicious DNS or destination indicators. Then isolate the target host and contain the recovered source system if it is in response scope; terminate processes or delete artifacts only after preservation and scoping.
97- Review other hosts touched by the same recovered `source.ip` or child `process.command_line` pattern before terminating additional processes or removing artifacts so scoping completes before evidence is destroyed.
98- Eradicate only scripts, binaries, persistence, or configuration changes identified during the investigation, then remediate the account, source host, or remote administration path that allowed the DCOM execution.
99- Post-incident hardening: keep Windows Firewall enabled, disable unnecessary Microsoft Management Console inbound access, restrict DCOM/RPC between workstations, limit remote administrative rights to recognized jump hosts, and record the evidence and control changes for future triage."""
100
101setup = """## Setup
102
103This rule is designed for data generated by [Elastic Defend](https://www.elastic.co/security/endpoint-security), which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules.
104
105Setup instructions: https://ela.st/install-elastic-defend
106
107### Additional data sources
108
109This rule also supports the following third-party data sources. For setup instructions, refer to the links below:
110
111- [Sysmon Event ID 1 - Process Creation](https://ela.st/sysmon-event-1-setup)
112- [Sysmon Event ID 3 - Network Connection](https://ela.st/sysmon-event-3-setup)
113"""
114
115[rule.investigation_fields]
116field_names = [
117 "@timestamp",
118 "host.id",
119 "host.name",
120 "user.id",
121]
122
123[transform]
124
125[[transform.investigate]]
126label = "Alerts associated with the host"
127description = ""
128providers = [
129 [
130 { excluded = false, field = "event.kind", queryType = "phrase", value = "signal", valueType = "string" },
131 { excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" }
132 ]
133]
134relativeFrom = "now-48h/h"
135relativeTo = "now"
136
137[[transform.investigate]]
138label = "Alerts associated with the user"
139description = ""
140providers = [
141 [
142 { excluded = false, field = "event.kind", queryType = "phrase", value = "signal", valueType = "string" },
143 { excluded = false, field = "user.id", queryType = "phrase", value = "{{user.id}}", valueType = "string" }
144 ]
145]
146relativeFrom = "now-48h/h"
147relativeTo = "now"
148
149[[transform.investigate]]
150label = "Processes spawned by MMC on this host"
151description = ""
152providers = [
153 [
154 { excluded = false, field = "event.category", queryType = "phrase", value = "process", valueType = "string" },
155 { excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" },
156 { excluded = false, field = "process.parent.name", queryType = "phrase", value = "mmc.exe", valueType = "string" }
157 ]
158]
159relativeFrom = "now-1h"
160relativeTo = "now"
161
162[[transform.investigate]]
163label = "Network events for MMC on this host"
164description = ""
165providers = [
166 [
167 { excluded = false, field = "event.category", queryType = "phrase", value = "network", valueType = "string" },
168 { excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" },
169 { excluded = false, field = "process.name", queryType = "phrase", value = "mmc.exe", valueType = "string" }
170 ]
171]
172relativeFrom = "now-1h"
173relativeTo = "now"
174
175[[rule.threat]]
176framework = "MITRE ATT&CK"
177
178[[rule.threat.technique]]
179id = "T1021"
180name = "Remote Services"
181reference = "https://attack.mitre.org/techniques/T1021/"
182
183[[rule.threat.technique.subtechnique]]
184id = "T1021.003"
185name = "Distributed Component Object Model"
186reference = "https://attack.mitre.org/techniques/T1021/003/"
187
188[rule.threat.tactic]
189id = "TA0008"
190name = "Lateral Movement"
191reference = "https://attack.mitre.org/tactics/TA0008/"
192
193[[rule.threat]]
194framework = "MITRE ATT&CK"
195
196[[rule.threat.technique]]
197id = "T1218"
198name = "System Binary Proxy Execution"
199reference = "https://attack.mitre.org/techniques/T1218/"
200
201[[rule.threat.technique.subtechnique]]
202id = "T1218.014"
203name = "MMC"
204reference = "https://attack.mitre.org/techniques/T1218/014/"
205
206[rule.threat.tactic]
207id = "TA0005"
208name = "Defense Evasion"
209reference = "https://attack.mitre.org/tactics/TA0005/"
210
211[[rule.threat]]
212framework = "MITRE ATT&CK"
213
214[[rule.threat.technique]]
215id = "T1559"
216name = "Inter-Process Communication"
217reference = "https://attack.mitre.org/techniques/T1559/"
218
219[[rule.threat.technique.subtechnique]]
220id = "T1559.001"
221name = "Component Object Model"
222reference = "https://attack.mitre.org/techniques/T1559/001/"
223
224[rule.threat.tactic]
225id = "TA0002"
226name = "Execution"
227reference = "https://attack.mitre.org/tactics/TA0002/"
Triage and analysis
Investigating Incoming DCOM Lateral Movement with MMC
Possible investigation steps
-
Which Timeline source events define the target MMC instance, spawned child, and remote source?
- Why: this asymmetric sequence links incoming "mmc.exe" network activity to a child process, and the alert may not preserve one reliable process identity.
- Focus: recover the target MMC network event and child process event, recording target MMC and child
process.entity_id,source.ip, and childprocess.command_line. - Implication: escalate if the chain does not resolve to one incoming MMC process spawning one child; lower suspicion only when it fits a recognized MMC administration source and child, then continue to command and network interpretation.
-
Does the network event fit remote DCOM or RPC traffic into MMC?
- Focus: the recovered "mmc.exe" network event:
source.ip,source.port,destination.port,network.direction, andnetwork.transport. - Implication: DCOM-style remote execution is supported by incoming TCP from a non-loopback
source.ipwith both ports in the high RPC range; concern rises when the source is a peer workstation, unrelated server, or unknown management origin.
- Focus: the recovered "mmc.exe" network event:
-
What did MMC execute through MMC20.Application COM automation?
- Focus: recovered child
process.executableandprocess.command_line. - Implication: escalate when MMC launches cmd.exe, PowerShell, script hosts, LOLBins, loaders, or download cradles; lower suspicion only when the exact child command is a recognized MMC snap-in helper or management binary and the source context also fits.
- Focus: recovered child
-
Is the child binary identity consistent with the behavior, without treating signer trust as clearance?
- Focus: child
process.hash.sha256,process.pe.original_file_name,process.code_signature.subject_name,process.code_signature.trusted, and entity context. - Implication: mismatched PE metadata, user-writable paths, unexpected publishers, or quick follow-on LOLBin execution increases concern; a trusted signer confirms identity only and does not clear remote command execution.
- Focus: child
-
Does the target-side user and session fit remote administration from the recovered source?
- Focus: child
user.id,user.name, anduser.domain, compared with the recovered source and target host. - Implication: escalate when the user, service context, or session is unexpected for that target or cannot explain administrative access from the source; lower suspicion when source, identity, and session match a recognized admin or jump-host path.
- Focus: child
-
Did the MMC-spawned child launch descendants after execution?
- Focus: same-host process events from the child, checking child-of-child
process.parent.entity_id. $investigate_2 - Implication: escalate when the child launches more execution chains; absent descendants keeps the case centered on the recovered remote command, not benign.
- Focus: same-host process events from the child, checking child-of-child
-
Did the child make DNS or connection activity?
- Focus: same-host network events, checking DNS
dns.question.nameand connectiondestination.ip. $investigate_3 - Hint: separate DNS events from connection events and keep the pivot bounded to the alert window. Missing network telemetry is unresolved, not benign.
- Implication: escalate when the child resolves rare domains or connects to staging or command infrastructure.
- Focus: same-host network events, checking DNS
-
Does the recovered source or child command appear on other hosts after local triage stays suspicious?
- Focus: same-host alerts for
host.id. $investigate_0 - Hint: if the same account is suspicious, compare same-
user.idalerts for lateral-movement or credential-access patterns across other hosts. $investigate_1 - Hint: broaden only after local evidence remains suspicious or unresolved; use
source.ipfor spread and a distinctive childprocess.command_linefragment for tool reuse. - Implication: expand scope when the same source touches more targets, the same child command appears elsewhere, or same-host alerts show lateral movement or defense evasion; keep the case local when the pattern stays confined and the workflow is otherwise explained.
- Focus: same-host alerts for
-
Escalate when source identity, incoming high-RPC network shape, child intent, identity/session, or descendant/DNS/destination evidence supports unauthorized MMC20.Application execution; close only when recovered evidence, with external confirmation when telemetry cannot prove intent, binds one exact recognized MMC administration workflow with no contradictory follow-on evidence; mixed or incomplete evidence means preserve and escalate.
False positive analysis
- Remote MMC, server-management automation, or vendor/internal tooling can legitimately trigger this rule when a management host uses DCOM to drive MMC snap-ins or support commands. Confirm the recovered
source.ipis a recognized admin, jump, or tooling host; childprocess.executableandprocess.command_lineshow the exact console/helper action;user.idoruser.namefits that path; childprocess.hash.sha256orprocess.code_signature.subject_nameis stable when tooling is involved; and descendant, DNS, and connection evidence stays quiet. If inventory or change records are unavailable, telemetry-only closure still requires current evidence to prove the exact workflow; prior recurrence of the samesource.ip, child command, andhost.idpattern is corroboration, not closure by itself. - Before creating an exception, anchor it on the minimum confirmed workflow pattern: recognized
source.ip, childprocess.executable, stableprocess.command_line, expecteduser.idoruser.name, and the relevanthost.idscope. Avoid exceptions onprocess.parent.nameof "mmc.exe" or high RPC ports alone.
Response and remediation
- If confirmed benign, record the recovered
source.ip, childprocess.executable, childprocess.command_line,user.idoruser.name, and targethost.idthat established the management workflow, then reverse any temporary containment. Create an exception only if the same pattern recurs consistently across prior alerts. - If suspicious but unconfirmed, preserve a case export of the Timeline source events, the target MMC and child process instance IDs, child command line, source socket, and DNS/destination indicators before containment or cleanup.
- If suspicious but unconfirmed, apply reversible containment tied to the evidence, such as temporary DCOM/RPC restrictions from the recovered
source.ipto the targethost.id; isolate the host only when the child command or follow-on activity indicates payload execution and the host role can tolerate it. - If confirmed malicious, first preserve the target MMC instance, child command, recovered source, descendant processes, and malicious DNS or destination indicators. Then isolate the target host and contain the recovered source system if it is in response scope; terminate processes or delete artifacts only after preservation and scoping.
- Review other hosts touched by the same recovered
source.ipor childprocess.command_linepattern before terminating additional processes or removing artifacts so scoping completes before evidence is destroyed. - Eradicate only scripts, binaries, persistence, or configuration changes identified during the investigation, then remediate the account, source host, or remote administration path that allowed the DCOM execution.
- Post-incident hardening: keep Windows Firewall enabled, disable unnecessary Microsoft Management Console inbound access, restrict DCOM/RPC between workstations, limit remote administrative rights to recognized jump hosts, and record the evidence and control changes for future triage.
References
Related rules
- Execution via TSClient Mountpoint
- Incoming DCOM Lateral Movement via MSHTA
- Lateral Movement via Startup Folder
- Potential Remote Desktop Shadowing Activity
- Suspicious Kerberos Authentication Ticket Request