External C2, IE COM Objects and how to use them for Command and Control

Background

Cobalt Strike 3.6 introduced a powerful new feature called External C2, providing an interface for custom Command and Control channels.

Being a fan of custom C2 channels I started exploring ExternalC2. In this blog post, I will briefly describe the ExternalC2 specification, IE COM Objects, how to use them for Command and Control and what opsec benefits this can introduce to your operations.

External C2 Primer

As mentioned earlier, External C2 allows third-party programs to act as a communication channel between Cobalt Strike and its beacon implant.

External C2 consists of the following components:

• External C2 Server: the service provided by the Cobalt Strike team server that allows the third-party controller to send and receive data to the teamserver
• Third-party Controller: the “server side” element of the custom C2 channel. This component is responsible for communicating with the third-party client and relaying the data to the External C2 server
• Third-party Client – the “client side” of the custom C2 channel. This component is responsible for spawning the beacon, connecting to that beacon using a named pipe and relaying the data to the third-party controller

The following image is a high-level overview of the External C2 Specification:

Now that we have a basic understanding of how ExternalC2 works let’s dive into our implementation, Browser-C2.

Browser-C2 Architecture

Browser-C2 is an External C2 implementation that allows the beacon and teamserver to communicate through a legitimate browser.

The following image shows the architecture of Browser-C2:

The third-party client local HTTP server has the following endpoints which are available on the compromised workstation:

• /inject – executes shellcode in the current process
• /send – sends data to the local beacon
• /receive – receives data from the local beacon
• /relay – serves an HTML file which relays data from the third party client to the third party controller through Internet Explorer
• /ping – used to check the status of the HTTP Server

The third-party HTTP server has the following endpoints:

• /arch/{architecture} – delivers the architect specific beacon shellcode
• /send – sends data to the External C2 server
• /receive – receives data from the External C2 server

The following table summarises the implementation of each component in the BrowserC2 architecture:

The third-party client is the component that initializes the BrowserC2 communication channels. Firstly, it creates an instance of Internet Explorer then starts a local HTTP server to handle communications from the browser. All communication between the third-party controller and the third-party client is performed through Internet Explorer as the above table explains.

Although this architecture may initially seem overly complex, it brings with it a number of benefits over the traditional approach of injecting in to a running iexplore.exe process as we described in our previous post on tradecraft. Next, we will examine these benefits in greater detail and outline the advantages this brings to an operator.

Parent Process Creation

In our previous blog post on tradecraft, we described how process spawn relationships may provide an indicator of suspicious behaviour for blue teams. For example, chrome.exe spawning powershell.exe is probably a clear indicator for bad behaviour. We also described how parent process spoofing could in some cases be used to evade these detections.

The benefit of this technique is that when iexplore.exe spawns, it is done through COM and as such its parent process is not winword.exe, wscript.exe or equivalent. Indeed, it is actually spawned using svchost.exe as shown below. Threat hunters may want to add this to their detection rules if it’s not being checked for already.

Aside from detection, environments configured with Microsoft ASR (Attack Surface Reduction) rules may also pose a problem for child process creation. If you are using a payload that targets the Office Suite (e.g. a macro) ASR will likely pose an issue. ASR provides rules to block execution of child processes, injection to other processes and many more as can be seen in the image below:

To test if ASR will block the spawned Internet Explorer, we used PowerShell to enable the following rule:

Block all Office applications from creating child processes    - d4f940ab-401b-4efc-aadc-ad5f3c50688a

Add-MpPreference -AttackSurfaceReductionRules_Ids d4f940ab-401b-4efc-aadc-ad5f3c50688a -AttackSurfaceReductionRules_Actions Enabled

After enabling this rule we can verify it is being enforced by trying to run a process from inside Office; it will fail as can be seen below:

When using a COM object, Internet Explorer will be started under the DCOM services process (svchost.exe) as previously mentioned and as such will bypass this rule.

Process Injection

Process injection has come under close scrutiny from the defensive community, and many EDR and anti-virus solutions now block or alert on attempts to inject in to other processes.

To overcome this issue, we are going to use COM to spawn a browser object and avoid the need for injection. By referencing an Internet Control COM object, you can create an instance of iexplore.exe that communicates with the third party client; example code for this is shown below:

When we run the above code, an instance of Internet Explorer will start that will navigate to the website of our choosing, in this case https://google.com/.

With this in mind, our implementation uses the IE COM object to navigate to the /relay endpoint on the third-party client local HTTP server and IE will start relaying data between the third-party client and controller providing a means to initiate and communicate with Cobalt Strike beacon without any form of process injection.

Setting Up Browser-C2

The source code for Browser-C2 is available on the MDSec ActiveBreach github.

After loading Browser-C2 project in to Visual Studio, edit the ControllerURL variable with your URL. In this example, we’ll use the internal lab IP of where the controller is running:

After loading the Aggressor script , the external C2 server will start on port 2222:

The next step is to run server.py script which is the third-party controller and everything is ready for the beacon to connect.

Conclusions

The blogpost walked through an example of how ExternalC2 can be used and how to get around some issues that may increase your risk of detection during a red team operation. It should be noted that the current implementation supports only a single beacon but it should not be too complex to expand beyond proof of concept.

References

• https://www.cobaltstrike.com/downloads/externalc2spec.pdf
• https://www.cobaltstrike.com/help-externalc2
• https://blog.xpnsec.com/exploring-cobalt-strikes-externalc2-framework/
• https://github.com/ryhanson/ExternalC2
• https://docs.microsoft.com/en-us/windows/security/threat-protection/windows-defender-exploit-guard/enable-attack-surface-reduction

This blog post was written by Rio Sherri.