The child of explorer.exe nobody clicked: detecting DCOM lateral movement

Distributed COM is one of those lateral-movement routes that survives precisely because it doesn’t look like lateral movement. There’s no service creation, no PsExec binary, no scheduled task. An operator instantiates a COM object on a remote machine and drives one of its methods to execute a command, and on the target the command shows up parented to a normal desktop process. The two objects that made this popular are ShellWindows and ShellBrowserWindow, and both leave the same tell.

How the execution actually lands

The mechanics, briefly, because the detection depends on them. An attacker with the right rights instantiates a registered COM object on the remote host, reaching for its CLSID, and then calls a method that ends up running a program. With ShellWindows and ShellBrowserWindow, the chain runs through the shell’s ShellExecute, so the process you asked for spawns as a child of explorer.exe on the target. Other DCOM objects land elsewhere: MMC20.Application puts the child under mmc.exe, the Office objects under excel.exe or outlook.exe. The family is Remote Services: Distributed Component Object Model, T1021.003.

The important part is that nobody logged in interactively to make explorer.exe spawn a shell. On a normal workstation, explorer.exe spawns children because a human double-clicked something in a session that’s actually present. In the DCOM case there’s no session at the console, the launch arrived over the network, and yet here’s explorer.exe giving birth to cmd.exe or powershell.exe. That contradiction is the detection.

The rule

I build this in two joined halves, because either one alone has too many false positives to live with.

The first half is the parent-child anomaly. Sysmon Event ID 1 where the ParentImage is explorer.exe, mmc.exe, or one of the Office hosts, and the child is a command interpreter or a script engine. On its own this fires on legitimate desktop activity all day, so it isn’t shippable yet.

The second half is the logon context. Right before the DCOM execution, the target records a network logon, a 4624 with logon type 3, from the attacker’s host, and there is no interactive (type 2) or RemoteInteractive (type 10) logon that would explain a human being present to drive explorer.exe. Join the two: a suspicious parent-child spawn that coincides with a network logon and no matching interactive session. Now it’s quiet, because the legitimate version of the parent-child pair almost always comes with a real interactive session, and the DCOM version never does.

You get a third corroborating signal for free if you collect it: the DCOM activation itself leaves an RPC and network trail, and Sysmon EID 3 will show the network connection into the target’s DCOM/RPC surface from the source host in the same window.

Where it gets noisy, and what I do about it

The honest caveat is that some management and deployment software drives COM in ways that resemble this, and a few of them run without an interactive session by design. You’ll find them fast because they’re consistent: the same source host, the same handful of parent processes, the same target program. Tune those out by that tuple, once, the way you’d tune any legitimate automation, and keep the rule scoped to the interpreters and script engines that attackers actually launch rather than every possible child.

The other honest caveat is scope. This catches the objects whose execution routes through the shell, which is most of the commodity tooling. A bespoke object that lands its child somewhere unexpected won’t match a rule keyed on explorer.exe. That’s the argument for writing the logon-context half generically, a network logon with no interactive session followed closely by any anomalous process launch, so the rule degrades toward the broader lateral-movement signal rather than failing silent. That broader signal is the same one I lean on in the 2026 lateral-movement writeup, and it pairs well with watching for the named-pipe pivoting that a lot of the same tooling uses for its comms.

What to deploy

Collect EID 1 with parent tracking, make sure you’re forwarding 4624 with logon types, and write the join: anomalous shell-family parent spawning an interpreter, correlated to a type-3 logon with no interactive session on the same host in the same minute. That single correlation covers ShellWindows, ShellBrowserWindow, and most of their cousins, and it does it without you having to enumerate every CLSID an operator might reach for. The behavior is small and stubborn. The object catalog is not.