Command And Control – C2 Framework

This is notes from Holo room. https://www.tryhackme.com/room/hololive

Covenant

Installation and setup

From the Covenant GitHub, “Covenant is a .NET command and control framework that aims to highlight the attack surface of .NET, make the use of offensive .NET tradecraft easier, and serve as a collaborative command and control platform for red teamers.”

For more information about Covenant, check out the Covenant GitHub wiki, https://github.com/cobbr/Covenant/wiki

The Covenant installation is relatively straightforward, with a few quirks and areas that may need troubleshooting. The installation requires two separate central installs: .NET Core SDK and downloading Covenant itself.

To begin setting up Covenant, we will begin with installing the .NET Core SDK. Covenant requires .NET Core SDK 3.1.0. You can download the SDK from either the .NET downloads page or adding the .NET repositories and downloading via apt.

For more information about downloading via the downloads page, check out this link, https://dotnet.microsoft.com/download/dotnet/3.1.

For more information about downloading via the repositories, check out this link, https://docs.microsoft.com/en-us/dotnet/core/install/linux-ubuntu

Follow along with either of the methods and install .NET Core SDK 3.1.0. This will be the utility we use to build and run Covenant.

Once you have the SDK installed, you can clone the Covenant repository from GitHub. Find an example below.

Command used: git clone --recurse-submodules https://github.com/cobbr/Covenant

Since Covenant is written entirely in .NET Core, all dependencies are already handled when building with the SDK.

Now that both the SDK and Covenant are installed, we can start up Covenant for the first time. Covenant will start on localhost port 7443. Find example syntax below.

Command used: sudo ./dotnet run --project /opt/Covenant/Covenant

Once you navigate to 127.0.0.1:7443 you will be greeted with a user creation screen. Create a user and sign in to Covenant. Find an example of the sign-in page below.

Liseners

When operating with Covenant, there are four main stages: creating a listener, generating a stager, deploying a grunt, utilizing the grunt. All stages of operation can already be done using other tools like MSFVenom, Netcat, Metasploit, etc. however, Covenant gives you a way to operationalize them all under one platform allowing for easier management and collaborative operations.

Covenant is an extensive and diverse command and control framework with many different functionalities. We will only be covering the basics of operating with Covenant. For more information, check out the SpecterOps blog, https://posts.specterops.io/, and the SoCon talk on “Operating with Covenant” by Ryan Cobb and Justin Bui https://www.youtube.com/watch?v=oN_0pPI6TYU.

The first step in operating with Covenant is to create a listener. Listeners are built off profiles; you can think of profiles like HTTP requests/pages that will serve as the channel that will handle all C2 traffic. There are four default profiles that Covenant comes with, outlined below.

  • CustomHttpProfile Custom profile that does not require any cookies.
  • DefaultBridgeProfile Default profile for a C2 bridge.
  • DefaultHttpProfile Default HTTP profile.
  • TCPBridgeProfile Default TCP profile for a C2 bridge.

Covenant offers an easy way of editing the listeners along with a GUI. There are many parameters present; we will only be going over a quick overview of each parameter outlined below.

  • Name Name of profile to be used throughout the interface.
  • Description Description of profile and its use cases.
  • MessageTransform Specify how data will be transformed before being placed in other parameters. 
  • HttpUrls list of URLs the grunt can callback to.
  • HttpRequestHeaders List of header pairs (name/value) that will be sent with every HTTP request.
  • HttpResponseHeaders List of header pairs (name/value) that will be sent with every HTTP response.
  • HttpPostRequest Format of data when a grunt posts data back to the profile.
  • HttpGetResponse HTTP response when a grunt GETs data to the listener.
  • HttpPostResponse HTTP response when a grunt POSTs data to the listener.

We will be going further in-depth with editing and creating profiles in Task 26.

Once you have decided what profile you would like to use, we can begin creating the listener. We recommend using the DefaultHttpProfile, to start with, but we will be changing this in later tasks when dealing with AV evasion.

To create a listener, navigate to the Listeners tab from the side menu and select Create Listener.

You will see several options to edit; each option is outlined below.

  • Name (optional) will help to identify different listeners.
  • BindAddress Local address listener will bind on, usually 0.0.0.0.
  • BindPort Local port listener will bind on.
  • ConnectPort Port to callback to, suggested to set to 808080, or 8888.
  • ConnectAddresses Addresses for the listener to callback to, hostname portion of the URL.
  • URLs Callback URLs the grunt will be connected directly back to.
  • UseSSL Determines whether or not the listener uses HTTP or HTTPS.
  • SSLCertificate Certificate used by the listener if SSL is set to true.
  • SSLCertificatePassword Password being used by the SSLCertificate.
  • HttpProfile Profile used by the listener and grunt to determine communication behavior.

To create a basic listener for this network we only suggest editing the NameConnectPort, and ConnectAddresses

Once created, the listener should appear within the Listeners tab. You can now start and stop the listener as needed.

Grunts

Now that we have a listener in Covenant, we can create a launcher to deploy a grunt. Again, this will be helpful later when you get onto a Windows box and need to deploy a grunt quickly.

From the Covenant GitHub, “Launchers are used to generate, host, and download binaries, scripts, and one-liners to launch new Grunts.”

There are ten different launchers to choose from within Covenant, each launcher will have its requirements, and some may not be supported on modern operating systems. Launcher types are outlined below.

There are several options for each launcher, with some launchers having specific options. For this task, we will be focusing on the binary launcher and its options. The configuration options are outlined below.

  • Listener Listener the grunt will communicate with.
  • ImplantTemplate Type of implant launcher will use.
  • DotNetVersion .NET version launcher will use, dependent on ImplantTemplate.
  • Delay Time grunt will sleep in-between callbacks. A larger delay can aid in stealthy communications.
  • JitterPercent Percent of variability in Delay.
  • ConnectAttempts Amount of times grunt will attempt to connect back to the server before quitting.
  • KillDate Date specified grunt will quit and stop calling back.

To create a basic launcher for this network, we only suggest editing the Listener and ImplantTemplate

Once created, the launcher will be downloaded or output a one-liner that can be copied. You can then use the launcher as needed to deploy grunts.

To deploy a grunt, you will only need to transfer your launcher to your target machine and execute the payload using your preferred method; this will change based on what launcher you decide to use.

Once executed, the grunt should check back into the server and appear within the Grunt tab.

Note: This is only an example of executing a grunt; you will not need to execute a grunt until later tasks.

If you navigate to the grunt to interact with it, you will be given an interaction menu. From here, you can remotely control the grunt and execute shell commands and modules. This will be covered further in-depth in Task 29.

Powershell-Empire with Starkiller

PoshC2

GodGenesis

Meterpreter

Havoc C2

Install

1. Installation.md | Havoc Documentation (havocframework.com)

Havoc source code avaliable on github and can be cloned using git clone:

git clone https://github.com/HavocFramework/Havoc.git

After cloning Havoc we are going to need to change the current directory to the cloned repository.

cd Havoc

Install the dependencies

After following the steps above we need to install the needed dependecies for the teamserver and compile it to our final executable. Be aware that the teamserver requieres golang 1.18 to be able to compile and run.

Ubuntu 20.04 / 22.04

You must enable Python 3.10 in your APT repositories before you can run the Client successfully.

sudo add-apt-repository ppa:deadsnakes/ppa
sudo apt update
sudo apt install python3.10 python3.10-dev

Kali and other Debian based Distros only.

The immediate following is for Debian based Distros only.

sudo apt install -y git build-essential apt-utils cmake libfontconfig1 libglu1-mesa-dev libgtest-dev libspdlog-dev libboost-all-dev libncurses5-dev libgdbm-dev libssl-dev libreadline-dev libffi-dev libsqlite3-dev libbz2-dev mesa-common-dev qtbase5-dev qtchooser qt5-qmake qtbase5-dev-tools libqt5websockets5 libqt5websockets5-dev qtdeclarative5-dev golang-go qtbase5-dev libqt5websockets5-dev python3-dev libboost-all-dev mingw-w64 nasm

Debian 10/11

You must setup the bookworm repo for Python 3.10.

echo 'deb http://ftp.de.debian.org/debian bookworm main' >> /etc/apt/sources.list
sudo apt update
sudo apt install python3-dev python3.10-dev libpython3.10 libpython3.10-dev python3.10

Building the Teamserver

Install additional Go dependencies:

cd teamserver
go mod download golang.org/x/sys
go mod download github.com/ugorji/go
cd ..

Build and Run:

# Install musl Compiler & Build Binary (From Havoc Root Directory)
make ts-build

# Run the teamserver
./havoc server --profile ./profiles/havoc.yaotl -v --debug

All files created during interaction with the Teamserver are stored within the /Havoc/data/* folder.

Building the Client

Now that we successfully compiled the teamserver we now should install the dependencies for the Client and compile it.

Build and Run:

# Build the client Binary (From Havoc Root Directory)
make client-build

# Run the client
./havoc client

After we finished compiling the teamserver and client we can start the teamserver and client from the havoc executable.

$ ./havoc
              _______           _______  _______
    │\     /│(  ___  )│\     /│(  ___  )(  ____ \
    │ )   ( ││ (   ) ││ )   ( ││ (   ) ││ (    \/
    │ (___) ││ (___) ││ │   │ ││ │   │ ││ │
    │  ___  ││  ___  │( (   ) )│ │   │ ││ │
    │ (   ) ││ (   ) │ \ \_/ / │ │   │ ││ │
    │ )   ( ││ )   ( │  \   /  │ (___) ││ (____/\
    │/     \││/     \│   \_/   (_______)(_______/

  	 pwn and elevate until it's done

Havoc Framework [Version: 0.4.1] [CodeName: The Fool]

Usage:
  havoc [flags]
  havoc [command]

Available Commands:
  client      client command
  help        Help about any command
  server      server command

Flags:
  -h, --help   help for havoc

Use "havoc [command] --help" for more information about a command.

Client

Havoc connection dialog

The Name field can be any profile name (like Death Star or Teamserver).

In the fields, Host and Port should contain the teamserver host address/domain and port.

In the fields, User and Password should contain the username and password specified in your Yaotl profile.

If you are seeing this following error then it most likely means that you passed the wrong username and or password.