Thursday, 7 February 2019

Threat Hunting #16 - Lateral Movement via DCOM - ShellWindows & ShellBrowserWindow

Windows Distributed Component Object Model (DCOM) is transparent middleware that extends the functionality of Component Object Model (COM) beyond a local computer using remote procedure call (RPC) technology. COM is a component of the Windows application programming interface (API) that enables interaction between software objects. Through COM, a client object can call methods of server objects, which are typically Dynamic Link Libraries (DLL) or executables (EXE).

Permissions to interact with local and remote server COM objects are specified by access control lists (ACL) in the Registry. By default, only Administrators may remotely activate and launch COM objects through DCOM.

Adversaries may use DCOM for lateral movement. Through DCOM, adversaries operating in the context of an appropriately privileged user can remotely obtain arbitrary and even direct shellcode execution through Office applications as well as other Windows objects that contain insecure methods.

In this post we will be mainly focusing on key indicators of detection related to the use of the following two COM objects:

  • ShellWindows (ClsID = {9BA05972-F6A8-11CF-A442-00A0C90A8F39})
  • ShellBrowserWindow (ClsID = {c08afd90-f2a1-11d1-8455-00a0c91f3880})

The advantage of using those COM objects is that from a parent and child process relationship it looks legit because anything executed remotely by the attacker (i.e. cmd.exe, powershell.exe etc.) will be a child process of explorer.exe (which is very common). Upon the execution of those 2 methods, we've observed that the only solid indicator we can rely on is the facts that explorer.exe will bind to a listening local tcp port (RPC dynamic tcp-port >=49152). Which is very suspicious (rarely explorer.exe will have network connections, and if it dose it will be tied to a Microsoft IP range and not high tcp-port to high tcp-port).

Below an example of how it looks like when executing cmd.exe remotely using DCOM\ShellBrowserWindow COM object:



process_name:explorer.exe and ipport:[49152 TO *] and netconn_count:[1 TO *]

We can use security event 5158 to detect the same behavior:

IBM AQL hunting query:

select sourceport, destinationport from events where eventid=5158 and UTF8(payload) IMATCHES '(?i)(.*explorer\.exe.*)' last 30 DAYS

Above query executed on a real environment, for 1 moth period returned nothing (few false positives, -->  good for us):



  1. Hi Menasec

    Thanks a lot for this blog, great detection techniques.

    I have a question around "Threat Hunting #16 - Lateral Movement via DCOM - ShellWindows & ShellBrowserWindow". I can't find Event ID 5158 with "Destination Port", did you mean to say 5156? Please advice, Thank You.

    1. Thanks! You can use both 5158 (SourcePort) for fist time connection (explorer.exe will bind to a high port) and 5156 for existing connection. most important is to verify that explorer.exe is not doing any connection from internal IP to an internal IP.