Auditing DCOM for Lateral Movement: The Windows RPC Surface Attackers Love

When responders reconstruct a breach, the jump from "one compromised laptop" to "the whole subnet" almost never uses an exploit. It uses a feature. DCOM—Distributed COM, the RPC-over-network layer that lets one Windows box instantiate a COM object on another—is one of the quietest of those features. It's on by default, it runs over ports you can't realistically close on a Windows network, and several built-in COM objects expose methods that run arbitrary code. For an attacker holding local-admin credentials, DCOM is a clean, signed, log-poor way to execute on a remote host without ever dropping a service binary like PsExec does.

Why DCOM is such a comfortable path for attackers

Lateral movement tooling has moved steadily toward "living off the land," and DCOM fits the doctrine perfectly. The traffic is legitimate MSRPC. The launching binary is svchost.exe hosting the DCOM Server Process Launcher. No new service is registered. On the target, the malicious command is spawned as a child of a trusted COM host, so naive parent-process allowlists wave it through.

The technique works because certain COM classes were designed to do things—open documents, run scripts, execute shell verbs—and DCOM happily marshals those method calls across the wire. The classic abuse primitives include:

• MMC20.Application — its Document.ActiveView.ExecuteShellCommand method runs an arbitrary process.
• ShellWindows and ShellBrowserWindow — expose Document.Application.ShellExecute, reachable by CLSID.
• Excel.Application and other Office automation objects — Run and DDE-style method calls that execute macros or commands.
• Outlook / ShellExecute-capable scripting objects that quietly launch payloads under the user's context.

An operator with valid credentials simply activates the object remotely and invokes the method:

$c = [activator]::CreateInstance([type]::GetTypeFromProgID(
        "MMC20.Application","10.0.0.25"))
$c.Document.ActiveView.ExecuteShellCommand(
        "cmd.exe",$null,"/c calc.exe","Minimized")

That single call maps to MITRE ATT&CK T1021.003 (Remote Services: Distributed Component Object Model). No exploit, no CVE—just a permission and a method.

What to actually audit

DCOM hardening is a permissions-and-inventory problem, and it rewards a methodical sweep rather than a single registry flip. Concretely, look at four things on every host:

1. Machine-wide launch and access limits

The MachineLaunchRestriction and MachineAccessRestriction security descriptors under HKLM\SOFTWARE\Microsoft\Ole define who may launch or access any DCOM object. If these permit Everyone or ANONYMOUS LOGON to activate remotely, that's your finding. Baseline them and alert on drift.

2. Per-AppID overrides

Individual COM apps can override the machine default with their own launch/access ACLs under HKCR\AppID\{clsid}. Attackers (and sloppy installers) sometimes loosen these. Enumerate AppIDs whose LaunchPermission grants remote activation to non-admins.

3. The known-abusable CLSIDs

Track whether MMC20.Application, ShellWindows ({9BA05972-F6A8-11CF-A442-00A0C90A8F39}), and ShellBrowserWindow ({C08AFD90-F2A1-11D1-8455-00A0C91F3880}) are reachable, and whether local firewall rules let their MSRPC/DCE endpoint dynamic ports through from arbitrary hosts.

4. Telemetry coverage

Enable auditing so the activation is visible. DCOM launches leave breadcrumbs—DistributedCOM events (10016 for permission denials), unusual svchost.exe or mmc.exe parentage spawning cmd.exe/powershell.exe, and RPC endpoint mapper traffic (TCP 135) from non-management hosts. Sysmon Event ID 1 with parent-image filtering catches most of it.

Hardening without breaking the box

You can't simply "turn off DCOM"—too much of Windows depends on it. But you can shrink the remote-activation surface hard:

1. Restrict MachineLaunchRestriction so remote activation is limited to Administrators and specific service accounts—never Everyone or authenticated-users-at-large.
2. Enforce packet-level RPC authentication (raise the DCOM authentication level to Packet Integrity via the "RPC endpoint mapper client authentication" and DCOM hardening GPOs shipped after the 2023 KB5004442 rollout).
3. Segment TCP 135 and the high RPC range so only management jump hosts can reach workstations—lateral DCOM dies when peer workstations can't open the endpoint mapper on each other.
4. Deny local-admin sprawl. DCOM lateral movement needs admin on the target; LAPS-rotated, unique local admin passwords remove the shared-credential pivot entirely.

DCOM abuse isn't a vulnerability you patch once—it's a configuration posture you keep. The moment a new installer relaxes an AppID ACL or a machine falls off your firewall policy, the door reopens.

Where WinSentinel fits

This is exactly the kind of check that's tedious by hand and trivial to let rot. On any single machine, WinSentinel's free tier audits the full DCOM posture—all 33 modules, no limits—flagging permissive machine-wide launch restrictions, loosened per-AppID ACLs, reachable abusable CLSIDs, and weak DCOM authentication levels, then mapping each finding to its ATT&CK technique so you know why it matters. You get the same depth on one workstation that a commercial scanner charges per seat for.

Across an organization, the harder problem is consistency: one of your 80 machines quietly regains a wide-open MachineLaunchRestriction after a bad install, and nobody notices for a month. That's where WinSentinel Pro's fleet orchestration earns its keep—a central node collects every agent's DCOM findings, rolls them into compliance summaries, and fires a drift alert the moment one host regresses from your hardened baseline. The single-machine audit is fully free and fully powered; the fleet-wide rollup and drift alerting are the org-scale layer on top.

Lateral movement is where an incident stops being an incident and becomes a breach. Auditing the DCOM surface—on every machine, continuously—is one of the cheapest ways to make that jump expensive for an attacker.