{ "id": "1dbf313e-1f8e-4846-b74d-ac4747efbf8f", "created_at": "2026-04-06T00:21:23.781876Z", "updated_at": "2026-04-10T13:12:33.131778Z", "deleted_at": null, "sha1_hash": "5e950e6100f9bd9f333f359fb2c0af6bda9c4a36", "title": "Lateral Movement via DCOM: Round 2", "llm_title": "", "authors": "", "file_creation_date": "0001-01-01T00:00:00Z", "file_modification_date": "0001-01-01T00:00:00Z", "file_size": 1611814, "plain_text": "Lateral Movement via DCOM: Round 2\r\nPublished: 2017-01-23 · Archived: 2026-04-05 15:54:34 UTC\r\nMost of you are probably aware that there are only so many ways to pivot, or conduct lateral movement to a\r\nWindows system. Some of those techniques include psexec, WMI, at, Scheduled Tasks, and WinRM (if enabled).\r\nSince there are only a handful of techniques, more mature defenders are likely able to prepare for and detect\r\nattackers using them. Due to this, I set out to find an alternate way of pivoting to a remote system.\r\nThis resulted in identifying the MMC20.Application COM object and its “ExecuteShellCommand” method, which\r\nyou can read more about here. Thanks to the help of James Forshaw (@tiraniddo), we determined that the\r\nMMC20.Application object lacked explicit “LaunchPermissions”, resulting in the default permission set allowing\r\nAdministrators access:\r\nYou can read more on that thread here. This got me thinking about other objects that have no explicit\r\nLaunchPermission set. Viewing these permissions can be achieved using @tiraniddo’s OleView .NET, which has\r\nexcellent Python filters (among other things). In this instance, we can filter down to all objects that have no\r\nexplicit Launch Permission. When doing so, two objects stood out to me: “ShellBrowserWindow” and\r\n“ShellWindows”:\r\nhttps://enigma0x3.net/2017/01/23/lateral-movement-via-dcom-round-2/\r\nPage 1 of 17\n\nAnother way to identify potential target objects is to look for the value “LaunchPermission” missing from keys in\r\nHKCR:\\AppID\\{guid}. An object with Launch Permissions set will look like below, with data representing the\r\nACL for the object in Binary format:\r\nThose with no explicit LaunchPermission set will be missing that specific registry entry.\r\nThe first object I explored was the “ShellWindows” instance. Since there is no ProgID associated with this object,\r\nwe can use the Type.GetTypeFromCLSID .NET method paired with the Activator.CreateInstance method to\r\ninstantiate the object via its AppID on a remote host. In order to do this, we need to get the AppID CLSID for the\r\nShellWindows object, which can be accomplished using OleView .NET as well:\r\n[Edit] Thanks to @tiraniddo for pointing it out, the instantiation portions should have read “CLSID” instead of\r\n“AppID”. This has been corrected below.\r\nhttps://enigma0x3.net/2017/01/23/lateral-movement-via-dcom-round-2/\r\nPage 2 of 17\n\n[Edit] Replaced screenshot of AppID wit CLSID\r\nAs you can see below, the “Launch Permission” field is blank, meaning no explicit permissions are set.\r\nhttps://enigma0x3.net/2017/01/23/lateral-movement-via-dcom-round-2/\r\nPage 3 of 17\n\nNow that we have the AppID CLSID, we can instantiate the object on a remote target:\r\nWith the object instantiated on the remote host, we can interface with it and invoke any methods we want. The\r\nreturned handle to the object reveals several methods and properties, none of which we can interact with. In order\r\nto achieve actual interaction with the remote host, we need to access the WindowsShell.Item method, which will\r\ngive us back an object that represents the Windows shell window:\r\nhttps://enigma0x3.net/2017/01/23/lateral-movement-via-dcom-round-2/\r\nPage 4 of 17\n\nWith a full handle on the Shell Window, we can now access all of the expected methods/properties that are\r\nexposed. After going through these methods, “Document.Application.ShellExecute” stood out. Be sure to follow\r\nthe parameter requirements for the method, which are documented here.\r\nhttps://enigma0x3.net/2017/01/23/lateral-movement-via-dcom-round-2/\r\nPage 5 of 17\n\nAs you can see above, our command was executed on a remote host successfully.\r\nNow that the “ShellWindows” object was tested and validated, I moved onto the “ShellBrowserWindow” object.\r\nOne of the first things I noticed was that this particular object does not exist on Windows 7, making its use for\r\nlateral movement a bit more limited than the “ShellWindows” object, which I tested on Win7-Win10 successfully.\r\nSince the “ShellBrowserWindow” object was tested successfully on Windows 10-Server 2012R2, it should be\r\nnoted as well.\r\nI took the same enumeration steps on the “ShellBrowserWindow” object as I did with the “ShellWindows” object.\r\nBased on my enumeration of this object, it appears to effectively provide an interface into the Explorer window\r\njust as the previous object does. To instantiate this object, we need to get its AppID CLSID. Similar to above, we\r\ncan use OleView .NET:\r\n[Edit] Replaced screenshot of AppID wit CLSID\r\nhttps://enigma0x3.net/2017/01/23/lateral-movement-via-dcom-round-2/\r\nPage 6 of 17\n\nAgain, take note of the blank Launch Permission field 🙂\r\nWith the AppID CLSID, we can repeat the steps taken on the previous object to instantiate the object and call the\r\nsame method:\r\nhttps://enigma0x3.net/2017/01/23/lateral-movement-via-dcom-round-2/\r\nPage 7 of 17\n\nAs you can see, the command successfully executed on the remote target.\r\nSince this object interfaces directly with the Windows shell, we don’t need to invoke the “ShellWindows.Item”\r\nmethod, as on the previous object.\r\nWhile these two DCOM objects can be used to run shell commands on a remote host, there are plenty of other\r\ninteresting methods that can be used to enumerate or tamper with a remote target. A few of these methods include:\r\nDocument.Application.ServiceStart()\r\nDocument.Application.ServiceStop()\r\nDocument.Application.IsServiceRunning()\r\nDocument.Application.ShutDownWindows()\r\nDocument.Application.GetSystemInformation()\r\nDefenses\r\nYou may ask, what can I do to mitigate or detect these techniques? One option is to enable the Domain Firewall,\r\nas this prevents DCOM instantiation by default. While this mitigation works, there are methods for an attacker to\r\ntamper with the Windows firewall remotely (one being remotely stopping the service).\r\nThere is also the option of changing the default “LaunchPermissions” for all DCOM objects via dcomncfg.exe by\r\nright clicking on “My Computer”, selecting “Properties” and selecting “Edit Default” under “Launch and\r\nActivation Permissions”. You can then select the Administrators group and uncheck “Remote Launch” and\r\n“Remote Activation”:\r\nhttps://enigma0x3.net/2017/01/23/lateral-movement-via-dcom-round-2/\r\nPage 8 of 17\n\nAttempted instantiation of an object results in “Access Denied”:\r\nYou can also explicitly set the permissions on the suspect DCOM objects to remove RemoteActivate and\r\nRemoteLaunch permissions from the Local Administrators group. To do so, you will need to take ownership of the\r\nDCOM’s HKCR AppID key, change the permissions via the Component Services MMC snap-in and then change\r\nthe ownership of the DCOM’s HKCR AppID key back to TrustedInstaller. For example, this is the process of\r\nlocking down the “ShellWindows” object.\r\nFirst, take ownership of HKCR:\\AppID\\{9BA05972-F6A8-11CF-A442-00A0C90A8F39}. The GUID will be the\r\nAppID of the DCOM object; finding this was discussed above. You can achieve this by going into regedit, right\r\nclick on the key and select “permissions”. From there, you will find the “ownership” tab under “advanced”.\r\nhttps://enigma0x3.net/2017/01/23/lateral-movement-via-dcom-round-2/\r\nPage 9 of 17\n\nAs you can see above, the current owner is “TrustedInstaller”, meaning you can’t currently modify the contents of\r\nthe key. To take ownership, click “Other Users or Groups” and add “Administrators” if it isn’t already there and\r\nclick “Apply”:\r\nNow that you have ownership of the “ShellWindows” AppID key, you will need to make sure the Administrators\r\ngroup has “FullControl” over the AppID key of the DCOM object. Once done, open the “Component Services”\r\nhttps://enigma0x3.net/2017/01/23/lateral-movement-via-dcom-round-2/\r\nPage 10 of 17\n\nMMC snap-in, browse to “ShellWindows”, right click on it and select “Properties”. To modify the Remote\r\nActivation and Launch permissions, you will need to go over to the “Security” tab. If you successfully took\r\nownership of AppID key belonging to the DCOM object, the radio buttons for the security options should *not*\r\nbe grayed out.\r\nTo modify the Launch and Activation permissions, click the “edit” button under the “Launch and Activation\r\nPermissions” section. Once done, select the Administrators group and uncheck “Remove Activation” and “Remote\r\nLaunch”. Click “Ok” and then “Apply” to apply the changes.\r\nhttps://enigma0x3.net/2017/01/23/lateral-movement-via-dcom-round-2/\r\nPage 11 of 17\n\nNow that the Remote Activation and Launch permissions have been removed from the Administrators group, you\r\nwill need to give ownership of the AppID key belonging to the DCOM object back to the TrustedInstaller account.\r\nTo do so, go back to the HKCR:\\AppID\\{9BA05972-F6A8-11CF-A442-00A0C90A8F39} registry key and\r\nnavigate back to the “Other Users and Groups” section under the owner tab. To add the TrustedInstaller account\r\nback, you will need to change the “Location” to the local host and enter “NT   SERVICE\\TrustedInstaller” as the\r\nobject name:\r\nhttps://enigma0x3.net/2017/01/23/lateral-movement-via-dcom-round-2/\r\nPage 12 of 17\n\nClick “OK” and then “Apply” to change the owner back.\r\nOne important note: Since we added “Administrators” the “FullControl” permission to the AppID key belonging\r\nto the DCOM object, it is critical to remove that permission by unchecking the “FullControl” box for the\r\nAdministrators group.  Since the updated DCOM permissions are stored as “LaunchPermission” under that key, an\r\nattacker can simply delete that value remotely, opening the DCOM object back up if not properly secured.\r\nAfter making these changes, you should see that instantiation of that specific DCOM object is no longer allowed\r\nremotely:\r\nKeep in mind that while this mitigation does restrict the launch permissions of the given DCOM object, an\r\nattacker could theoretically remotely take ownership of the key and disable the mitigation since it is stored in the\r\nregistry.\r\nThere is the option of disabling DCOM, which you can read about here. I have not tested to see if this breaks\r\nanything at scale, so proceed with caution.\r\nAs a reference, the three DCOM objects I have found that allows for remote code execution are as follows:\r\nMMC20.Application (Tested Windows 7, Windows 10, Server 2012R2)\r\nAppID: 7e0423cd-1119-0928-900c-e6d4a52a0715\r\nhttps://enigma0x3.net/2017/01/23/lateral-movement-via-dcom-round-2/\r\nPage 13 of 17\n\nShellWindows  (Tested Windows 7, Windows 10, Server 2012R2)\r\nAppID: 9BA05972-F6A8-11CF-A442-00A0C90A8F39\r\nShellBrowserWindow (Tested Windows 10, Server 2012R2)\r\nAppID: C08AFD90-F2A1-11D1-8455-00A0C91F3880\r\nIt should also be noted that there may be other DCOM objects allowing for similar actions performed remotely.\r\nThese are simply the ones I have found so far.\r\nFull Disclosure: I encourage anyone who implements these mitigations to test them extensively before integrating\r\nat scale. As with any system configuration change, it is highly encouraged to extensively test it to ensure nothing\r\nbreaks. I have not tested these mitigations at scale.\r\nAs for detection, there are a few things you can look for from a network level. When running the execution of this\r\ntechnique through Wireshark, you will likely see an influx of DCERPC traffic, followed by some indicators.\r\nFirst, when the object is instantiated remotely, you may notice a “RemoteGetClassObject” request via\r\nISystemActivator:\r\nFollowing that, you will likely see “GetTypeInfo” requests from IDispatch along with “RemQueryInterface”\r\nrequests via IRemUnknown2:\r\nWhile this may, in most cases, look like normal DCOM/RPC traffic (to an extent), one large indicator of this\r\ntechnique being executed will be in a request via IDispatch of GetIDsofNames for “ShellExecute”:\r\nhttps://enigma0x3.net/2017/01/23/lateral-movement-via-dcom-round-2/\r\nPage 14 of 17\n\nImmediately following that request, you will see a treasure trove of useful information via an “Invoke Request”,\r\nincluding *exactly* what was executed via the ShellExecute method:\r\nhttps://enigma0x3.net/2017/01/23/lateral-movement-via-dcom-round-2/\r\nPage 15 of 17\n\nThat will immediately be followed by the response code of the method execution (0 being success). This is what\r\nthe actual execution of commands via this method looks like:\r\nCheers!\r\nMatt N.\r\nhttps://enigma0x3.net/2017/01/23/lateral-movement-via-dcom-round-2/\r\nPage 16 of 17\n\nSource: https://enigma0x3.net/2017/01/23/lateral-movement-via-dcom-round-2/\r\nhttps://enigma0x3.net/2017/01/23/lateral-movement-via-dcom-round-2/\r\nPage 17 of 17\n\n https://enigma0x3.net/2017/01/23/lateral-movement-via-dcom-round-2/ \nMMC snap-in, browse to “ShellWindows”, right click on it and select “Properties”. To modify the Remote\nActivation and Launch permissions, you will need to go over to the “Security” tab. If you successfully took\nownership of AppID key belonging to the DCOM object, the radio buttons for the security options should *not*\nbe grayed out. \nTo modify the Launch and Activation permissions, click the “edit” button under the “Launch and Activation\nPermissions” section. Once done, select the Administrators group and uncheck “Remove Activation” and “Remote\nLaunch”. Click “Ok” and then “Apply” to apply the changes. \n Page 11 of 17", "extraction_quality": 1, "language": "EN", "sources": [ "MITRE" ], "origins": [ "web" ], "references": [ "https://enigma0x3.net/2017/01/23/lateral-movement-via-dcom-round-2/" ], "report_names": [ "lateral-movement-via-dcom-round-2" ], "threat_actors": [], "ts_created_at": 1775434883, "ts_updated_at": 1775826753, "ts_creation_date": 0, "ts_modification_date": 0, "files": { "pdf": "https://archive.orkl.eu/5e950e6100f9bd9f333f359fb2c0af6bda9c4a36.pdf", "text": "https://archive.orkl.eu/5e950e6100f9bd9f333f359fb2c0af6bda9c4a36.txt", "img": "https://archive.orkl.eu/5e950e6100f9bd9f333f359fb2c0af6bda9c4a36.jpg" } }