Cobaltstrike Over External C2 via Dropbox

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. The post from Rhino Security Labs specifically caught my eye since it was built specifically for Cobaltstrike using the Externalc2 specification and it was created using python. I wanted to see if I can use Dropbox as malware command and control specifically by leveraging Cobaltstrike’s 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 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 the number of malicious domains and servers required to redirect to your Team Server to be reduced to zero.

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 the framework by Rhino Labs. 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 post by RhinoLabs at 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 and also in creating this blopost too.

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

Dropbox-C2-Malware-beacon.png

Drawbacks of Dropbox as a C2 Channel

  1. You need to distribute the API token to the beacon executable. This may lead to your c2 channel being tampered with by sufficiently advanced attackers. There’s also potential of your c2 server being vulnerable to a Denial of Service Attack.
  2. Further, while we tackled the problem of multi-client beacon functionality it still lacks task sequencing, as per the post from RhinoLabs. Without this, the client can only receive one command and submit one response at a time.
  3. 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:

https://github.com/Truneski/external_c2_framework

Caveats

The main challenge I faced was using an old version of Cobaltstrike which supported External c2 (version 3.6). Hopefully this project will work on the latest versions of Cobaltstrike. Also I used a trial version of Cobaltstrike mainly due to the fact that I can’t afford it. I had to go the cheap route (me being an african played a part in this). If you can’t even try to attempt such a project for cheap should you even try at all? The magic is in the skills you pick up along the journey.

Conclusion

This was a simple a blogpost to introduce the use of External C2 specs for Cobaltstrike via Dropbox. The approach mentioned in this blogpost and other references below should work for other cloud based 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. Also correlating processes with their respective communications, process creation and execution of unsigned code should provide indicators of malicious activity for blue teams looking to begin threat hunting.

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.

References

  1. https://rhinosecuritylabs.com/aws/hiding-cloudcobalt-strike-beacon-c2-using-amazon-apis/
  2. https://www.insomniacsecurity.com/2018/01/11/externalc2.html
  3. https://github.com/Und3rf10w/external_c2_framework
  4. https://github.com/RhinoSecurityLabs/external_c2_framework/
  5. https://github.com/bluscreenofjeff/Red-Team-Infrastructure-Wiki#domain-fronting
  6. https://labs.mwrinfosecurity.com/blog/tasking-office-365-for-cobalt-strike-c2
  7. https://www.cobaltstrike.com/help-externalc2