Cobaltstrike Over External C2 via Dropbox

Nov 5, 2018 · 5 minute read

Introduction

After completing the OSCP, I wanted to really learn python and create a tool that would be useful to the InfoSec community. A while back, I saw a few awesome tools leveraging command and control for Cobaltstrike via the external c2 specification. Specifically, the post from Rhino Security Labs caught my eye since it was built specifically for Cobaltstrike using the Externalc2 specification and most importantly it was made using python. I wanted to see if I can use dropbox using their APIs as malware command and control specifically by leveraging Cobaltstrike externalc2 specification.

Dropbox as a C2 channel using the Dropbox APIs

Dropbox is an awesome cloud service. I won’t really go into detail about all the major advantages Dropbox offers but just to mention a few, it’s HTTPS enabled and it’s a trusted cloud service. Therefore Dropbox isn’t categorized as a malicious domain right off the bat. Dropbox also has a rich and well documented API which is fantastic. The official dropbox python module allows for easy and fast implementation of communication over the APIs.

Cobalt Strike and the External C2 Specification

Cobaltstrike is a threat emulation tool made by Raphael Mudge (@armitagehacker) to aid pentesters in targeted attacks against modern enterprises. Cobalttrike has two components: Beacon and Team Server. Beacon is the malicious part that runs in the victim machine. Beacon is also responsible for setting up communications with the team server to receive and execute further attack commands from an operator. The Team Server is responsible for administering each Beacon that calls home for further commands from the operator.

A While back the External Command and Control (External C2) interface was added to Cobaltstrike. This feature allows third-party programs to act as a communication layer between Cobalt Strike and its Beacon payload. This allows for reduction to zero, the number of malicious domains and servers required to redirect to your Team Server.

Abstracting the Specification Using Frameworks

Ever since its release there have been frameworks created by members of the InfoSec community, to act as wrappers for the externalc2 specification. The framework we will use in this post is Jonathon Echavarria’s (@Und3rf10w) external_c2_framework and with a ton of guidance from final one from Rhino Labs github This framework was chosen for two reasons:

1. Python

Since I had taken time to study python over the past 4 weeks, I wanted to see if I can go BIG and try and implement it in python. The only functionality missing from Echavarria’s framework was multi-client support. As noted from the RhinoLabs the time of this article, the framework only supported one Beacon to one Team Server. I decided to closely follow the RhinoLabs blogpost as a guide, to expand this capability and enable for support multiple Beacons on the Team Server.

2. Modularity

The external specification is broken into an encoding and transport mechanism, making the implementation straightforward. This part really required little to no modifications.

Overview of Dropbox as a Communication Channel

The Team server and beacon both communicate with each other through Dropbox APIs by creating and deleting files in Dropbox.

When the custom beacon generated by the framework executes on the victim (or client) machine, it registers itself in dropbox by creating a file with a unique staging key. This key is comprised of two parts – a static prefix that notifies the Team Server the Beacon is ready to be staged and receive the full payload, and a unique identifier that the underlying external C2 server can use to identify commands that need to be sent to the Beacon.

The External C2 Server is responsible for translating data between your external communication channel, in this case the Dropbox API, and the Team Server itself. The External C2 Server will poll Dropbox for the staging key and extract the agent’s unique identifier. It then forwards the request up to the Team Server to receive the full payload to execute on the client.

To notify the client that a new task is ready for it to execute the External C2 Server creates a new file in Dropbox. This file’s key is comprised of the Beacon’s unique ID generated from above and a static suffix, ‘TaskForYou’. The contents of this file contain the encoded command (encoded by the encoding module) for the Beacon to execute.

After initial registration, the beacon will periodically poll for tasks from Dropbox looking for the task key corresponding to itself. It will then download and delete the file, decode the contents and execute the command. Once executed, it will encode the output of the command and create a new file in dropbox with the response key and the encoded results.

The External C2 Server then polls until it receives a response from the agent, pulls and deletes the file, and sends the results up to the Team Server.

Diagram Showing the Overview of the Process

Drawbacks of Dropbox as a C2 Channel

You need to distribute the API token to the beacon executable.
Further, while we tackled the problem of multi-client beacon functionality it still lacks task sequencing, as per the RhinoLabs post. Without this the client can only receive one command and submit one response at a time.
Be wary of API rate limiting from Dropbox. This should be taken into consideration when determining the number of clients per Team server and how many requests need to be taken into account per client and Team server.

Demo Proof Of Concept

The fork of external_c2_framework, along with the Dropbox transport module, have been uploaded to my Github:

Conclusion

This was a simple a blogpost to introduce using the External C2 specs for Cobaltstrike via Dropbox. The approach mentioned in this blogpost and other references below should work for other cloud services. The blogpost from RhinoLabs has a good overview of how to improve security defenses including knowing your network topology and communication habits and implementing several robust host based protections.

Special thanks to Dwight Hohnstein (@djhohnstein) for encouraging me to see this project to completion and also for being just an all around nice guy. Hopefully this inspires more researchers to explore new ways for C2 research opportunities.