A number of researchers have recently been looking at lateral movement methods that leverage Microsoft’s Distributed Component Object Model (DCOM), with some great articles put together by @enigma0x3 at https://enigma0x3.net/. These articles walk through the overall approach of discovering DCOM based lateral movement techniques as well as demonstrating a number of examples.
In this post, we will analyze another DCOM based lateral movement technique that I have recently discovered.
COM / DCOM Overview
COM is described by Microsoft as:
“The Microsoft Component Object Model (COM) is a platform-independent, distributed, object-oriented system for creating binary software components that can interact. COM is the foundation technology for Microsoft’s OLE (compound documents), ActiveX (Internet-enabled components), as well as others.” Source
COM can be leveraged for a variety of uses including interprocess communication and programmatic interaction with applications. Distributed Component Object Model (DCOM) facilitates the use of COM in a client / server architecture, meaning we can interact with COM objects through interfaces on remote systems through the use of DCOM. DCOM objects are exposed through the DCOM Service Control Manager (RPC Endpoint Mapper) listening on port tcp/135.
The following are important to bear in mind:
- Not all COM objects are exposed through DCOM
- DCOM objects with non-default permissions may not be accessible remotely
- Local administrator access is required on the remote system in order to initialize and interact with a DCOM object
James Forshaw has released oleviewdotnet, this tool can be used to investigate COM / DCOM objects, associated permissions, enumerate interfaces, and instantiate / invoke methods.
Why COM / DCOM for Lateral Movement?
While there are a number of other known methods for lateral movement to Windows based systems, DCOM based techniques are relatively new. For this reason, it is more probable that endpoint security controls will not detect the use of these techniques for some time.
DCOM + PowerShell
DCOM objects can be instantiated and invoked through PowerShell. While I’m sure it has been mentioned elsewhere, @enigma0x3 documents a nice one-liner to instantiate a DCOM object through .NET’s System.Activator.CreateInstance method:
$com = [activator]::CreateInstance([type]::GetTypeFromProgId("PowerPoint.Application", "10.10.10.10"))
In the above code snippet, we create an activator type object ($com) that is an instance of the DCOM object. We cast the result of GetTypeFromProgId to type in order to provide an argument type expected by CreateInstance(). In this particular example, we are instantiating the PowerPoint.Application object on a remote system with IP address 10.10.10.10.
PowerPoint DCOM Methods
We can explore PowerPoint COM objects by piping $com in to Get-Members:
$com | Get-Member
We can see the results below:
You can explore what you see above or look at Microsoft’s documentation on PowerPoint Object Models.
While exporing, I came across the PowerPoint.AddIns object. This object exposes a number of methods to manipulate PowerPoint AddIns, of most interest being the Add() method. With PowerPoint.AddIns.Add we can specify a PowerPoint Add-In (*.PPA / *.PPAM) to be added to the COM instance. We can achieve this by invoking the following:
$addin = $com.AddIns.Add("c:\testfile.ppam")
If we execute the above code snippet, it will fail. @enigma0x3 found that this was due to the lack of profile for the local system user. Take a look at his blog post for more information. The following folders need to exist on the remote system:
Once we have created the folders and executed the above code snippet again, we will have successfully added the add-in to the remote PowerPoint instance, however the add-in is not still loaded. We can load the Add-in by invoking the following:
$addin.Loaded = 1
At this point the add-in is both added to the PowerPoint instance and loaded.
Weaponizing PowerPoint Add-Ins
There are a number of crafty ways we can weaponize PowerPoint Add-Ins, however for the purposes of this blog we will be looking at a straight-forward approach to demonstrate Proof-of-Concept (PoC).
PowerPoint Add-ins support macros. We can simply create a PowerPoint Addin with our payload embedded in the auto_open() function.
In this PoC, we are simply using the Shell function to open calc.exe. In order to create a PowerPoint add-in from this content, you must save as either a PPA / PPAM file. Bear in mind that PPA / PPAM files cannot be edited through PowerPoint after saving.
To help automate and streamline this lateral movement technique, I’ve created a PowerShell cmdlet based off of @enigma0x3’s Invoke-ExcelMacroPivot. The cmdlet will execute the following:
- Verify office is installed
- Create profile folders as required by architecture
- Upload your payload PPA / PPAM
- Execute the above technique
- Remove profile folders
- Remove the payload PPA / PPAM
You can download the cmdlet from https://github.com/attactics/Invoke-DCOMPowerPointPivot