RED TEAM SERIES

Red Teaming in the Cloud: Installing Mythic C2 on Azure VM

Nairuz Abulhul

Follow

Published in

R3d Buck3T

9 min readDec 26, 2023

--

C2 Deployment and Operations — Infrastructure

A Command and Control (C2) server is a server that communicates with compromised targets. During a red teaming assessment, testers use social engineering techniques like phishing or vishing to send a payload to the targets, enticing them to click on it and establish a connection with a C2 server they set up at the beginning of the operation.

There are several C2 tools available in the market, open-source and commercial options. Some popular open-source C2s are Havoc, Sliver, Mythic, Covenant, and Caldera, while commercial options include Cobalt Strike, Nighthawk, Brute Ratel, and others. Commercial C2 tools generally operate on a licensing model, allowing companies to purchase enterprise licenses that grant them access to all the tool’s functionalities.

In this article, we will continue setting up the red team infrastructure by installing the open-source Mythic framework on the Azure VM we set up in the previous post. The steps involved will include installing the agents and the C2 profile, configuring the service, and accessing the web interface.

Getting Started

Get the code

First, we need to SSH into the Azure virtual machine (VM) created in the first part of this series titled “Red Teaming in the Cloud: Deploying Azure VMs for C2 Infrastructure.”

#Access the machine
ssh -i mythicC2_key.pem azureuser@IPaddress

Figure 01 — shows the sshing to the Azure VM. r3d-buck3t, azure, VM, SSH — Figure 01 — shows the sshing to the Azure VM.

After connecting to the VM, run the apt-get update command to update it and clone the Mythic repository from GitHub.

#update the VM
apt-get update

#clone the repo
git clone https://github.com/its-a-feature/Mythic.git

Figure 02 — shows updating the VM and cloning the Mythic repo. r3d-buck3t, azure, mythic, GitHub, github — Figure 02 — shows updating the VM and cloning the Mythic repo.

After cloning, move to the Mythic directory. The framework provides three (3) bash scripts for different Linux distributions to automate the installation process of Docker and other dependency packages:

install_docker_ubuntu.sh
install_docker_kali.sh
install_docker_debian.sh

Since we have Ubuntu installed on our VM, we’ll need to run the install_docker_ubuntu.sh script.

#Mythic directory 
cd Mythic

#run the Ubuntu bash script
sudo ./install_docker_ubuntu.sh

Figure 03 — shows the available scripts and running the Ubuntu script. r3d-buck3t, azure, VM, ubuntu, kali, debian — Figure 03 — shows the available scripts and running the Ubuntu script.

The script begins by checking the root permissions necessary to install the required packages. It then proceeds to install the HTTPS-required packages, apt-transport-https , and ca-certificates, with the apt tool to ensure secure downloading of docker and its plugins.

Then, it installs curl , if not installed by default, gnupg-agent, which manages GPG keys, and software-properties-common, which manages software repositories and package sources.

#Checking for root permissions 
if [ "$EUID" -ne 0 ]
  then echo "[-] Please run as root"
  exit
fi


#Installing the required Packages with APT tool
apt-get install -y \
    apt-transport-https \
    ca-certificates \
    curl \
    gnupg-agent \
    software-properties-common

The curl command downloads the GPG keys for docker from the provided URL with the -fsSL flag for silent mode, secure connection, and following redirects. Once the keys are downloaded, they get added to the trusted keys list in the APT package manager with the apt-key command.

# download the GPG key from docker and add the keys
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key add -

💡 We can check the listed keys by running the apt-key list command.

#list trusted keys 
apt-key list

Figure 04 — shows the lists of trusted keys. r3d-buck3t, azure, VM, GPG keys — Figure 04 — shows the docker key in the trusted keys list.

Next, the script adds the docker repository with the command add-apt-repository to the APT source list so that docker packages can be installed later using the apt tool.

#adding the docker repo to the apt source list
add-apt-repository -y \
   "deb [arch=amd64] https://download.docker.com/linux/ubuntu \
   $(lsb_release -cs) \
   stable"

Lastly, the script updates the VM again. Then, it installs the docker engine with the docker-ce package and docker-compose-plugin for managing multi-container applications using the apt tool.

#Update the VM
apt-get update

#apt-get docker packages.
apt-get install -y --no-install-recommends docker-ce docker-compose-plugin

Here is the entire script for the Ubuntu system.

#! /bin/bash
if [ "$EUID" -ne 0 ]
  then echo "[-] Please run as root"
  exit
fi

#pre-requisites
# install the required services, pull docker the right docker for debian
apt-get install -y \
    apt-transport-https \
    ca-certificates \
    curl \
    gnupg-agent \
    software-properties-common

curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key add -

add-apt-repository -y \
   "deb [arch=amd64] https://download.docker.com/linux/ubuntu \
   $(lsb_release -cs) \
   stable"

apt-get update

#apt-get install -y docker-ce docker-ce-cli containerd.io
apt-get install -y --no-install-recommends docker-ce docker-compose-plugin

Create the Mythic-CLI binary

After installing the Mythic framework, the next step is to set up the mythic-cli command-line interface. This tool is used to manage and interact with the Mythic framework, which includes starting and stopping the Mythic service, installing new modules and extensions, and accessing logs and reports.

To build the mythic-cli binary, we need to run the make command from the main Mythic folder with the sudo root permissions. If the make command is unavailable on your machine, you can install it using the apt-get install make command.

#install make
sudo apt-get install make

#create the binary file
sudo make

Figure 05 — shows installing make with apt-get command. r3d-buck3t, azure, make, apt — Figure 05 — shows installing the make package with apt-get command.

Figure 06 — shows creating the mythic-cli binary file. r3d-buck3t, binary, mythic-cli, mythic, c2 — Figure 06 — shows creating the mythic-cli binary file.

Then, to verify the command ran successfully, we run -ls -la to list the contents of the Mythic directory; as seen below in Figure 07, the mythic-cli file was created in a binary form.

Figure 07 — shows the compiled mythic-cli file. azure, mythic, c2 , agent — Figure 07 — shows the compiled *mythic-cli file.*

Configuration

Install the agents

Mythic utilizes different agents to interact with target systems depending on their operating systems. Currently, the framework supports seventeen (17) agents written in various programming languages such as .Net, Golang, Rust, PowerShell, and Python. It also supports different C2 channels like HTTP, SMB, and Websockets.

For this demo, we will install the Apollo and Athena agents, written in C# (.NET 6). Apollo is a Windows-based agent, while Athena is a cross-platform agent that works on Windows, Mac, and Linux.

We will use them later to create our payloads and deliver them to the target.

#Apollo agent
sudo ./mythic-cli install github https://github.com/MythicAgents/Apollo

#Athena agent
sudo ./mythic-cli install github https://github.com/MythicAgents/Athena

Figure 08- shows installing the Apollo agent. mythic, c2, azure, r3d-buck3t, infrastructure — Figure 08— shows installing the Apollo agent.

Figure 09 — shows installing the Athena agent. r3d-buck3t, azure,c2, infrastructure, red teaming — Figure 09 — shows installing the Athena agent.

Once the installation is complete, the agents get added to the Installed Services directory.

Figure 10 — shows the location of the installed agents. r3d-buck3t, azure, mythic, apollo, athena, VM — Figure 10 — shows the location of the installed agents.

Install C2 Profile

The C2 profile is a configuration file used to customize the C2 communication between the testers (attackers) and the compromised systems. Mythic provides six (6) different C2 profiles: HTTP, DNS, Discord, Slack, Websocket, and dynamic HTTP. All of these profiles can be customized by editing the JSON configuration file called config.js.

We will install the HTTP profile using the mythic-cli tool.

#installing the HTTP profile
sudo ./mythic-cli install github https://github.com/MythicC2Profiles/http

Figure 11 — shows installing the HTTP C2 profile.

After installation, we check the InstalledServices directory again to verify that the profile has been added.

Figure 12 — shows the HTTP profile installed in the Installed Services directory.

Start Mythic Service

After the installation process, we need to initiate the Mythic service, the service relies on the environment variables saved in the .env file, which stores configuration parameters and sensitive information required for the proper functioning of the framework.

These parameters include the portal username, password, secrets, allowed IPs, port numbers, and other settings. The .env file is not created by default, but it will be auto-generated when the mythic service starts for the first time. If you wish to modify any variable, you can open the file and make the necessary changes.

Figure 13 — shows the content of the .env file. environment variables, r3d-buck3t, azure, VM, mythic — Figure 13 — shows the content of the .env file.

To start the service, run the mythic-cli as root and use the start command; the initiation process takes a few seconds to complete.

#starting the mythic service
sudo ./mythic-cli start

Figure 14 — shows the starting mythic service. r3d-buck3t, azure, mythic, c2, red team — Figure 14 — shows the starting mythic service.

After completing the setup process, we can verify the status of the service by running the status command. If the services are running, we should be able to see them listed under the Mythic Main Service section, as shown in Figure 15. If the service has stopped, we won’t be able to see any services listed, as seen in Figure 16.

Figure 15 — shows the list of the running services when Mythic starts. r3d-buck3t, azure, cloud, vm, c2, red team — Figure 15 — shows the list of the running services when Mythic starts.

Figure 16 — shows the mythic service status when the services are stopped. r3d-buck3t, azure, mythic, c2, red team — Figure 16 — shows the mythic service status when the services are stopped.

To stop the Mythic service, we can run the mythic-cli with the command stop.

#stopping the mythic service
sudo ./mythic-cli stop

Figure 17 — shows stopping the mythic service. r3d-buck3t, azure, VM, infrastructure, cloud, pentesting — Figure 17 — shows stopping the mythic service.

Access

Mythic Web Interface

The web interface can be accessed through the default port of 7443. To avoid opening a port in the VM firewall to access the interface, we can use the local port forwarding trick to access it locally from our testing machine.

This approach is better from an operational security perspective to avoid getting detected by internet scanners and flagged for suspicious activities. The only port that should open to the public is port 22 for SSH.

To set up local port forwarding, we can either exit the current SSH session and re-SSH with the -L flag or use the SSH command on the current session. The command-L 7443:127.0.0.1:7443 creates a tunnel that forwards connections from port 7443 on our local machine (Kali) to port 7443 on the remote server’s loopback interface (127.0.0.1).

This means that any traffic sent to 127.0.0.1:7443 on our local machine will be redirected through the SSH tunnel to the remote server’s 127.0.0.1:7443.

#SSH to the VM with the local port forwarding
ssh -i mythicC2_key.pem azureuser@IPaddress -L 7443:127.0.0.1:7443

#Local Port Fowarding
Local_Port:127.0.0.1:Remote_Port

Figure 18- shows setting up a local port forwarding to access the Mythic web interface. r3d-buck3t, azure, VM, mythic — Figure 18— shows setting up a local port forwarding to access the Mythic web interface.

Once this is done, we can access the web portal in our Kali machine in the browser by navigating to https://127.0.0.1:7443.

Figure 18- shows setting up a local port forwarding to access the Mythic web interface. mythic, azure, cloud, red team, r3d-buck3t — Figure 19— shows the Mythic web interface on the localhost port 7443.

The portal username and password are in the .env file; you can use the grep command to extract them quickly.

#extract admin crednetials
grep -B 1 mythic_admin .env

Figure 20 — shows the .env file with the Mythic web portal admin credentials.

Mythic Dashboard

After logging in to the portal, we can view the agents that were installed during the installation step under the Agent/C2 overview section.

The audio icon shows the available payload types — Apollo and Athena (agents), and the C2 profiles (http). If the C2 profile is green, it indicates it accepts connections from the agents, and if it is red, it means that the profile has stopped and is no longer accepting connections.

We will create the payloads and use the http profile in the following posts.

Figure 22 — shows the HTTP profile is active.

Figure 23— shows the HTTP profile is not active.

With that, we’ve reached the end of this post. Today, we learned how to install the Mythic C2 framework on an Azure virtual machine and configured its services to be ready when we create our payload in future articles.
If you’re interested in setting up an Azure VM, you can refer to the first part of this guide titled “Red Teaming in the Cloud: Deploying Azure VMs for C2 Infrastructure.”

Thanks for stopping by!