Before continuing, below are references for utilizing Distributed Component Object Model (DCOM) objects for lateral movement in a Windows environment. The reading is required to understand how an adversary could potentially abuse DCOM to pivot through a Windows network.
References:
- https://enigma0x3.net/2017/09/11/lateral-movement-using-excel-application-and-dcom/
- https://enigma0x3.net/2017/01/23/lateral-movement-via-dcom-round-2/
The intent is to be able to see what DCOM objects are available to whom. From there, you can go about figuring how to develop detection for these activities. The aforementioned references only talk about lateral movement, but I have a few ideas on how this could be used to check for/and maintain persistence. If I get time, I'll write up some examples.
So, what the hell is DCOM? Well, it's an extension of COM, which essentially allows COM objects to communicate over a network via Remote Procedure Calls.
Well, crap, what the hell is a COM object? In layman's terms, it's just a process that allows other processes to interact with it. Think about it, when you start a process, how do you access it from another process? Well you go through the Windows API.
Whether it's third-party software or software native to the Windows OS itself, when the program is developed, if it wants to partake in inter-process communication (talk to other processes on the same system), it exposes methods through an interface and in order for other processes/COM objects to access them they go through the Windows API. By adhering to the COM standard, the DCOM capability is inherently available.
The gist? Basically, you can call methods/functions on a remote system that you would be able to call locally. As an intermediary, Microsoft's security mechanisms can/do act as a central security checkpoint for any COM/DCOM object. So, what that means is that any system calling a method/function on a remote host must be on an ACL.
When these ACL's are set, they're rarely (at least to my knowledge) ever tweaked. One reason, I would imagine, is to avoid the ass-pain of breaking functionality. The other is probably due to most people not knowing that they can be configured.
Access to the object is control via ACLs that are contained in the registry at the following keys:
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\AppID\{AppID_GUID}
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\OleEach objects that can be accessed has it's own CLSID (Class ID or App ID) as an identifier. When you boot up, these configurations are loaded into memory and can be enumerated via WMI in the following classes:
Win32_DCOMApplicationAccessAllowedSetting Win32_DCOMApplicationLaunchAllowedSetting
I wrote the following script to enumerate the security settings for each DCOM application. This can be used to determine what potential vectors and adversary may use to pivot throughout a network.
Essentially what it does is show you the permission settings and who is on that ACL by translating the Security ID's (SID).
Below is the Github link and Gist.