This is notes from Holo room. https://www.tryhackme.com/room/hololive
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.
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.
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.
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.
CustomHttpProfileCustom profile that does not require any cookies.
DefaultBridgeProfileDefault profile for a C2 bridge.
DefaultHttpProfileDefault HTTP profile.
TCPBridgeProfileDefault 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.
NameName of profile to be used throughout the interface.
DescriptionDescription of profile and its use cases.
MessageTransformSpecify how data will be transformed before being placed in other parameters.
HttpUrlslist of URLs the grunt can callback to.
HttpRequestHeadersList of header pairs (name/value) that will be sent with every HTTP request.
HttpResponseHeadersList of header pairs (name/value) that will be sent with every HTTP response.
HttpPostRequestFormat of data when a grunt posts data back to the profile.
HttpGetResponseHTTP response when a grunt GETs data to the listener.
HttpPostResponseHTTP 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.
BindAddressLocal address listener will bind on, usually
BindPortLocal port listener will bind on.
ConnectPortPort to callback to, suggested to set to
ConnectAddressesAddresses for the listener to callback to, hostname portion of the
URLsCallback URLs the grunt will be connected directly back to.
UseSSLDetermines whether or not the listener uses
SSLCertificateCertificate used by the listener if SSL is set to true.
SSLCertificatePasswordPassword being used by the
HttpProfileProfile used by the listener and grunt to determine communication behavior.
To create a basic listener for this network we only suggest editing the
Once created, the listener should appear within the Listeners tab. You can now start and stop the listener as needed.
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.
BinaryGenerates a custom binary to launch grunt, does not rely on a system binary.
ShellcodeConverts binary to shellcode using donut, https://github.com/TheWover/donut
PowerShellGenerates PowerShell code to launch a grunt using
MSBuildGenerates an MSBuild XML file to launch a grunt using
InstallUtilGenerates an InstallUtil XML file to launch a grunt using
MshtaGenerates an HTA file to launch a grunt using
Regsrv32Generates an SCT file to launch a grunt using
WmicGenerates an XSL file to launch a grunt using
CscriptGenerate a JScript file to launch a grunt using
WscriptGenerate a JScript file to launch a grunt using
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.
ListenerListener the grunt will communicate with.
ImplantTemplateType of implant launcher will use.
DotNetVersion.NET version launcher will use, dependent on
DelayTime grunt will sleep in-between callbacks. A larger delay can aid in stealthy communications.
JitterPercentPercent of variability in
ConnectAttemptsAmount of times grunt will attempt to connect back to the server before quitting.
KillDateDate specified grunt will quit and stop calling back.
To create a basic launcher for this network, we only suggest editing the
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
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.
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
You must setup the
bookwormrepo 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
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.
The Name field can be any profile name (like
Death Star or
In the fields,
Port should contain the teamserver host address/domain and port.
In the fields,
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.