The Component Object Model, or COM, is how Windows software objects call each other. Distributed COM (DCOM) stretches that idea across the network using remote procedure calls. It is old, built in, and still enabled on most Windows systems.
MITRE tracks abuse of it as Distributed Component Object Model, technique T1021.003, in the Lateral Movement tactic. It applies to Windows.
How attackers use it
The adversary needs a valid account with enough rights. By default, only Administrators may remotely activate and launch COM objects through DCOM, so the attacker usually works as an admin. Access to local and remote COM server objects is controlled by access control lists stored in the Registry.
Once connected, MITRE says an adversary can get remote code execution through Office applications and other Windows objects that contain insecure methods. DCOM can also run macros inside existing documents. It can trigger Dynamic Data Exchange (DDE) through a COM-created instance of an Office application, which removes the need to deliver a malicious document at all. And it can be used to interact with Windows Management Instrumentation remotely.
The point for defenders: this is not a vulnerability to patch. It is a legitimate remote management path that an attacker reuses.
How to detect it
MITRE's detection strategy (DET0285) describes a behavioral chain. First, a remote DCOM invocation by a privileged account over RPC, which uses port 135. Second, abnormal process creation or module loading on the remote system that points to code execution.
Practical ways to watch for that:
- Alert on inbound connections to TCP 135 from hosts that are not management servers.
- On the target, watch for Office applications or the Microsoft Management Console starting with no user at the keyboard, and for those processes spawning command interpreters.
- Pair network logon events with process creation events on the same host within a short window.
- Record the source and the account. A privileged account touching a machine it has never touched is worth a look.
How to reduce the risk
MITRE lists four mitigations.
- Disable DCOM where you can. Consider turning it off through the Dcomcnfg.exe tool if nothing in your environment needs remote COM.
- Keep COM alerts and Protected View enabled for Office applications.
- Keep the Windows firewall on. MITRE notes it prevents DCOM instantiation by default, so a firewall that someone switched off removes a safeguard.
- Tighten COM permissions. Process-wide security for individual COM applications lives under the AppID keys in HKEY_LOCAL_MACHINE\SOFTWARE\Classes. System-wide defaults for applications that set nothing of their own live under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Ole. Both can be edited directly or through Dcomcnfg.exe.
Check your own environment
Read-only checks on a Windows host:
# Is the Windows firewall on for every profile?
Get-NetFirewallProfile | Select-Object Name, Enabled
# Which processes are listening on the RPC endpoint mapper port?
Get-NetTCPConnection -State Listen -LocalPort 135
You can also open Dcomcnfg.exe to view the current default DCOM permissions without changing anything. Compare what you see against what your administrators actually use.
Quick check
Who can remotely activate COM objects through DCOM by default?
Only Administrators. That is why DCOM lateral movement usually needs a privileged account, and why limiting the spread of admin credentials helps.
What two things make up the DCOM detection pattern in MITRE's strategy?
A remote DCOM call by a privileged account over RPC on port 135, followed by abnormal process creation or module loading on the target.
Sources
- MITRE ATT&CK, Distributed Component Object Model (T1021.003)
