Overview

Red teams are always looking for ways to better blend into target networks. Since many organizations use GitHub, I developed a GitHub C2 Profile that allows agents to perform command and control (C2) communication over GitHub. Mythic is an open source C2 platform written and maintained by @its_a_feature_ that greatly supports custom agents and C2 mechanisms. At the time of writing, Athena written by @checkymander is the only Mythic agent to support the GitHub C2 profile.

GitHub C2 Profile: https://github.com/MythicC2Profiles/github/

Background

Traditionally, red teams have used redirectors to avoid agents communicating directly with the C2 server. However, redirectors can be challenging to maintain for numerous reasons including TLS certificates, domain reputation, and anomaly detection. That said, many teams use legitimate websites and services to perform external C2 communications. In the ATT&CK Framework, the T1102 Web Service technique documents a few examples of threat actors in the wild abusing legitimate services such as Dropbox, Microsoft Graph API, and Google Docs.

GitHub is one of the most widely used platforms for software development and collaboration, making it a perfect candidate for external C2. Many organizations heavily rely on GitHub for their day-to-day operations, and its traffic is often allowed through firewalls and proxy servers without scrutiny. By leveraging GitHub for C2, red teams can:

  1. Blend into Normal Traffic: Communication with GitHub is unlikely to raise red flags in environments where development teams frequently interact with the platform.
  2. Leverage an Existing API: GitHub’s API provides a wealth of capabilities, such as file uploads, comments, and issue tracking, which can be repurposed for C2 operations.
  3. Use Encrypted Communications: All interactions with GitHub occur over HTTPS, adding an extra layer of protection against interception.

Mythic C2 Profiles

The Mythic C2 platform is deployed as a collection of docker containers. Each Mythic agent and C2 profile that is installed runs in its own container which makes developing new capabilities straight forward. C2 profile developers have the option of connecting their container to the core Mythic stack with either GoLang or Python. Since I wrote the actual C2 code in Python, I used Python to bind my container to Mythic.

A C2 profile is, essentially, a basic server that receives a message from an agent, blindly passes it to Mythic, and returns the Mythic response to the agent. Typically, an agent communicates directly to the C2 Profile via a protocol like HTTP. However, the scenario gets more complicated when implementing external c2 and incorporating a service.

GitHub for C2

To be a viable C2 Profile for Mythic, an external service should meet the following requirements:

  • Write data to the service
  • Read data from the service
  • Generous rate limiting for frequent communication
  • Write 1MB messages of data to the service (optional, but really really nice to have)

Looking at these requirements, GitHub easily completes these requirements! Due to the feature-rich GitHub API, data can be written, read, and deleted via numerous ways including issue comments, pushing to repos, and Gist pages. Additionally, with a valid account, users can make 5,000 API requests per hour which is sufficient for C2 communication. Finally, the GitHub API allows users to push files with a maximum size of 25MB to a GitHub repo which allows large messages to be sent.

GitHub and Mythic

What does it look like when Mythic and GitHub come together? The sequence diagram below shows all of the communication between Mythic (the C2 profile), GitHub, and an agent.

github c2 comms

Initial Checkin

When an agent is newly deployed on a target computer, Mythic requires an initial checkin where it registers the agent and assigns it a unique ID. To perform this initial checkin, I used GitHub issue comments since the message size is small. Once the comment is posted, GitHub automatically sends a HTTP webhook notification to the GitHub C2 Profile which is it’s cue to look for a new message. The C2 profile then pulls the GitHub comment with the checkin message and tosses it to the Mythic server to process. Mythic then does the actual processing of the message and gives a respones to the C2 profile to send back to the agent. The C2 profile then returns the message to the agent by posting the initial checkin response to a new GitHub issue comment. Once the agent retrieves this respone, the agent is operationally ready.

Operational C2

The initial checkin process involves small messages which is why it can be done via GitHub issue comments. However, messages sizes can be much larger during red teaming when uploading or downloading files, socks proxying, and running ls in the system32 folder. Therefore, the C2 communication then switches from issue comments to pushing files to Git repos after the initial checkin is complete. To ensure multiple agents can simultaneously communicate using the GitHub C2 profile, each agent communicates over a unique branch. Once the new branch is created, the agent sends a message in the form of a new file pushed to a git repo. Just like the GitHub issue mechanism, a webhook notification is sent to the C2 profile indicating that a new file has been pushed and is ready for Mythic. The C2 profile takes the file from the GitHub repo and tosses it to Mythic for processing. Mythic returns a response to the C2 profile which sends the response back to the agent by pushing a new file to the GitHub repo. The agent reads the contents of the file and repeats this process over and over.

Conclusion

Developing my first Mythic C2 Profile was a great experience and I learned a lot about external C2. Download Mythic, install Athena, and try out my GitHub C2 Profile! Message me @scottctaylor12 on Twitter if you have any questions or want to talk about the project with me :)