Detecting Lateral Movement via DCOM

Uncategorized

A Purple Team Approach

Background

It is no secret that there are a plethora of APIs in the Windows Operating System that allow developers to harness their power for application development. Just take a look at the official Win32 API list. It is also no secret that many of these APIs could allow malicious threat actors to harness their power and leverage different attack tactics and techniques.

In this post, I will discuss a recent TTP exercise our team ran to leverage a fairly uncommon attack technique using the Windows Distributed Component Object Model (DCOM) to make a remote execution call to another computer system and gain lateral movement throughout the network. There are a few requirements that must be satisfied in the environment before this attack is successful and we declare victory. I will also discuss those details later in this post.

On Purple Teaming

As the title implies, the exercise would not have been as successful without the superb collaboration of both our Red and Blue Teams, or should I just say our “Purple Team”. Purple Teaming is a fairly recent concept in cybersecurity where Red Teams (Offensive) and Blue Teams (Defensive) work together during adversary emulation exercises to improve the people, processes, and overall security posture of an organization in real-time. Yes, this truly captures the essence of our Purple Team at Code42. My colleague, Zach Godec, wrote an excellent post on the same topic titled, Red + Blue = Purple.

Now, let’s get into the details of this attack technique, including the tools used during the exercise to improve the process and documentation efforts.

Lateral Movement via DCOM

During research for this exercise, I reviewed several Windows administration tools used to remotely manage systems. It became apparent that tools like PsExec, WMI, WinRM, RDP, and the like are some of the common ones used in pen test engagements and by threat actors. I eventually came across an interesting technique that wasn’t among those mentioned but could hold similar weight in value, depending on how it is exploited. Distributed Component Object Model (DCOM) is a proprietary Windows component that allows for software applications to interact over the network via the RPC protocol. Let’s take a look!

In PowerShell, the Get-CimInstance cmdlet allows enumeration of the various Win32_DCOMApplications. Specifically, the application of interest is the Microsoft Management Console (MMC) Application Class, since this provides administrators access to scripting and management functions across the network. You can read more about MMC at this Microsoft Doc Link.

In the screenshot below, I used Get-CimInstance with the -Query parameter to filter the list of DCOM applications. Alternatively, the ClassName parameter could have been used and piped to findstr.exe “MMC”.

We can get more information for this class by using the Get-WMIObject cmdlet to then query the AppID. This part is necessary, as we need to find the MMC’s Program ID (circled in red below) to create a remote instance of that object.

Now that we have some basic information, we can use it to create a remote DCOM object. In PowerShell, we can use the CreateInstance method and specify a Type using the VersionIndependentProgId we collected from the previous example while also passing it a remote IP address. Take a look at the example below. We’ll create a remote instance and pipe it to the Get-Member cmdlet to view all the properties of the MMC20.Application class.

Notice the “ExecuteShellCommand” method circled in red below. This method will execute a remote command in a separate process, passing it the four arguments it expects. You can read more on this method here.

Now, let’s put all this information together and gain lateral movement. The example below will simply open the cmd.exe program and execute the command ipconfig and redirect the output to the specified file. Note: the command must be available on the remote host for this technique to work. Since this is a void method, it will not return a value on the origin host.

[activator]::CreateInstance([type]::GetTypeFromProgID("MMC20.application","X.X.X.X")).Document.ActiveView.ExecuteShellCommand("cmd.exe",$null,"/c ipconfig > c:\tester.txt","Minimized")

If the PowerShell command ran successfully, we should see a newly created file located at C:\tester.txt with output from the ipconfig command on the remote host. This is a very simple example use case. In a realistic setting it can be leveraged to cause severe damage to critical systems.

Prerequisites

I’m identifying a few conditions that need to exist in the local and remote environment for this technique to be successful. It is important to fully grasp the PowerShell command behind the technique first. Also, this should be easily reproducible when running a similar exercise.

  • Remote Windows system or network-based firewall must allow DCOM Inbound (TCP 135)
  • Remote Windows system firewall must allow MMC.exe
  • Local/Remote EDR/AV must not block command execution
  • Attacker account must have admin privileges to run Win32_DCOMAppplication in PowerShell

Bringing it Together

How can we detect this behavior within our network? I mentioned the prerequisite conditions above because if they were already being enforced, this attack could not take place as easily. TCP Port 135 is a standard port for systems to communicate over the Remote Procedure Call protocol and could be open for legitimate applications. System administrators may use MMC over the network to manage other remote systems. That seems like normal behavior, right? If those examples do not apply to your environment, then simply block them and prevent any potential attacks.

Detection and Response (Purple Teaming It!)

As a Purple Team, we conducted our scheduled TTP (Tactic, Technique, Procedure) brief to scope out this exercise. The idea here is to present the MITRE ATT&CK Tactic that will be used in the exercise with minimal technical details, but give our detection engineers enough information to conduct a deep analysis of the compromised systems. An example exercise brief may include the below bullet points. The actual technique ID was not given during the brief as it was part of the analysis.

  • MITRE ATT&CK Tactic: T0008 Lateral Movement
  • Technique: The technique used for this exercise abuses a service typically used for interaction between two software objects, or executable code that implements one or more interfaces. The service could be used to execute malicious software remotely.
  • Systems/Environment in Scope: HOST_A, HOST_B (For the purpose of this example, both hosts are Windows OS)
  • Red Team will deploy the technique on <date/time> and run for X days.
  • Blue Team will conduct deep analysis using EDR and SIEM log analysis and detection processes.
  • On X Day/Time we will meet as a Purple Team and discuss our findings and recommended course of action following the exercise.
  • We will document the TTP and Analysis/Detection Results in VECTR for improved communication and metrics.

After the attack technique is deployed, our detection engineers are sifting through logs looking for the compromised systems. If there aren’t any triggered alerts by current EDR or other security controls in place, chances are that it will be more difficult to detect because it may look like normal behavior.

Let’s take a look at some key indicators that could help us get a better idea of malicious behavior using this attack technique.

  • Review PowerShell and Event Logs: The attacking host’s PowerShell logs show a suspicious command not typically used under normal activity. Review historical events for “MMC20.Application”. Is it commonly used in your environment? The command could also be encoded in Base64 or Hex to try and evade detection. PowerShell commands that are encoded could be used to evade detection, this is a clear indicator of malicious activity.
  • Reviewing EDR/SIEM Events: Review the attacking hosts process tree. Does it look normal? Could there be a C2 agent spawning processes and executing malicious commands, while trying to remain undetected? Create a baseline of normal process behavior. This could take time in certain dynamic or hybrid environments (cloud/on prem, multi-OS), but could also prove to be beneficial for scenarios like this.
  • Reviewing EDR/SIEM Events: Review the target’s process tree, specifically for the Service Host (svchost.exe) process. It’s a legitimate Windows service that handles shared resources as new services are started. One of the svchost.exe processes will start the MMC service. The call to svchost.exe will look something like,
C:\Windows\system32\svchost.exe -k DcomLaunch

Notice the -k DcomLaunch argument used to execute the DCOM object.

Following that same process tree, svchost.exe will execute MMC. The call to MMC will look something like,

C:\Windows\system32\mmc.exe -Embedding

Although, MMC is a signed Windows binary, it can be abused, such as in this case. Monitor this process and command-line arguments for suspicious or malicious activity.

Final Thoughts

Running this exercise as a Purple Team truly captures a cohesive and better prepared SOC environment. During our debrief, we discussed our lessons learned and ways to improve the process for the next exercise. Communication is key to ensuring the process continues to work for everyone on the team. Ultimately, your organization will benefit by having more knowledgeable and better prepared security professionals protecting your critical systems.

The idea for the TTP exercise was largely inspired by Matt Nelson’s Blog post on the same topic. Lateral Movement using the MMC20.Application COM Object