Detecting Sliver C2: When Advanced Beaconing Tries to Hide in Plain Sight

March 23, 2026
Lucie Cardiet
Cyberthreat Research Manager
Detecting Sliver C2: When Advanced Beaconing Tries to Hide in Plain Sight

Security teams might miss the moment an attacker gets in, but they eventually see the traffic that follows.

A compromised system begins reaching out to something it should not be talking to. The connection repeats, waits and repeats again. This is the role of command-and-control infrastructure.

In a previous article, I explained how attackers use Brute Ratel to maintain covert command channels inside compromised environments. Tools like Brute Ratel deliberately shape their traffic to blend into legitimate web activity and avoid traditional detection methods.

Another tool built with the same philosophy is Sliver, an open-source command-and-control framework that introduces additional layers of randomization into beacon traffic to make detection even more difficult.

From initial access to command and control

Attackers rarely deploy a command-and-control framework directly. They first need an entry point.

In many intrusions, that foothold begins with a vulnerability in an internet-facing service. A recent example is React2Shell (CVE-2025-55182), a critical flaw affecting React Server Components used in frameworks like Next.js. Exploiting the vulnerability allows an attacker to execute code on a vulnerable server using a crafted HTTP request.

Once code execution is achieved, attackers move quickly to establish persistence and remote control.

This is where post-exploitation frameworks come into play.

Instead of building custom malware, attackers often rely on mature open-source tools that provide a full operational toolkit for managing compromised hosts. These frameworks handle the difficult parts of intrusion operations: secure communications, tasking infected systems, transferring files, and coordinating activity across multiple compromised machines.

Sliver is one of those tools.

Diagram showing the different attacker payloads using React2Shell. Source: Wiz

What Sliver is and why attackers use it

Sliver has quickly become one of the most widely used open-source post-exploitation frameworks. Originally developed for adversary simulation and red-team operations, the project provides a mature platform for managing compromised systems and coordinating intrusion activity.

Screenshot: Sliver on GitHub

Several factors explain its growing adoption:

  1. Sliver is fully open source and actively maintained, which lowers the barrier for attackers compared to commercial frameworks. Operators can easily generate customized implants, modify communication profiles, and integrate the framework into automated intrusion workflows.
  2. The framework was designed with operational flexibility in mind. Sliver supports multiple Operating Systems,  communication protocols and transport mechanisms, allowing operators to adapt the command channel to the environment they are targeting. HTTP and HTTPS transports are particularly common because they blend naturally into normal enterprise traffic.
  3. Sliver incorporates built-in traffic obfuscation techniques intended to make command traffic difficult to identify. The framework can introduce timing variation between beacon requests, alter the size and structure of transmitted data, and rotate encoding mechanisms that reshape the appearance of the network traffic.

These design choices make Sliver attractive to attackers who want a capable command-and-control platform without writing custom malware. At the same time, they create a more complex detection challenge for security teams trying to identify command channels hidden within encrypted traffic.

Why beaconing is normally easier to detect

Traditional command-and-control frameworks tend to produce predictable network patterns.

If an implant checks in every 60 seconds and sends roughly the same amount of data each time, the resulting traffic pattern becomes easy to identify.

Security tools can detect these patterns by analyzing:

  • consistent timing between connections
  • repeated communication with the same destination
  • similar payload sizes across requests

To evade detection, more advanced frameworks introduce randomness into those patterns. They may vary the timing between connections or alter the size of the data transmitted in each request. These techniques create what is known as evasive beaconing, where the communication pattern still exists but becomes harder to recognize.

Many modern post-exploitation tools support these techniques out of the box.

Sliver takes the idea further.

What makes Sliver harder to detect

Most command-and-control frameworks rely on two basic evasion techniques.

The first is time jitter, where the implant randomly adjusts the delay between beacon requests. Instead of checking in every 60 seconds, it might check in after 48 seconds, then 72 seconds, then 63 seconds.

The second is data jitter, where the size of each request is slightly different. A small amount of random data may be appended to the beacon message so that the network traffic does not appear identical each time.

Sliver introduces a more sophisticated approach known as procedural data jitter.

Example of data jitter with a random amount of data appended which is easily clustered together based on only the data transfer amounts

Rather than changing just one element of the request, Sliver modifies several parameters simultaneously. Each beacon request may use a different HTTP path, a different encoding method, and a randomized value that alters the request structure.

An example of idling Sliver in HTTP beacon mode with the data jitter clustering algorithm applied (and no time jitter).

The framework supports multiple encoders, including Base64, hexadecimal encoding, gzip compression, and even encodings that transform binary data into English text or valid PNG files. Each encoding method changes the compression efficiency of the transmitted data, which produces different payload sizes across requests.

Instead of creating a single cluster of similar beacon messages, Sliver produces multiple distinct patterns in network traffic.

For detection systems that expect beacon messages to look similar, this variability breaks the pattern.

Evidence attackers are already using Sliver

Sliver is not just a red-team tool.

Security researchers have documented campaigns where attackers deployed Sliver implants after gaining access to exposed infrastructure.

One example comes from research by CtrlAltIntel, which uncovered a campaign targeting internet-facing FortiWeb appliances. After exploiting exposed systems, the attackers deployed Sliver implants disguised as system update utilities. The compromised devices began beaconing to attacker-controlled infrastructure, allowing operators to maintain remote control of the affected servers.

The investigation revealed dozens of compromised hosts communicating with the command server, illustrating how quickly open-source post-exploitation frameworks like Sliver can move from red-team tooling into real intrusion activity. These cases reflect a broader trend in intrusion activity.

Open-source post-exploitation frameworks allow attackers to operate quickly without developing custom malware. The tools provide mature command-and-control capabilities while blending in with legitimate network traffic.

For defenders, this makes identifying the command channel a critical step in detecting an active intrusion.

Why traditional detection methods struggle

Many command-an-control detection techniques rely on identifying regular communication patterns, where beacon messages occur at consistent intervals and often transmit similar amounts of data.

If most requests contain roughly the same number of bytes, the traffic pattern can be grouped into a single cluster and identified as beaconing behavior.

Sliver’s encoder rotation disrupts this assumption because each encoding method produces a different compression ratio, the resulting beacon messages fall into several distinct size ranges rather than one dominant cluster. This multi-band pattern can evade algorithms that expect beacon messages to remain similar.

In encrypted traffic, where payload inspection is not possible, these variations make detection significantly more difficult.

Attackers also frequently modify Sliver implants or deliver them through custom shellcode loaders designed to evade antivirus and endpoint detection systems. These techniques allow the payload to execute entirely in memory, reducing the chance of detection on the host. However, once the implant establishes its command channel, the beaconing communication still produces observable patterns on the network.

Detecting Sliver through behavioral analysis

Even when payloads are encrypted and unreadable, command-and-control traffic still leaves behind behavioral patterns.

The Vectra AI Platform analyzes those patterns to identify command-and-control frameworks like Sliver, even when attackers attempt to disguise their traffic with jitter, encoder rotation, or other evasion techniques.

Rather than relying on signatures or payload inspection, the platform applies deep learning models trained on large volumes of real network telemetry. These models evaluate sequences of network activity such as packet lengths, timing intervals, and communication direction between hosts to detect behavioral patterns consistent with beaconing.

Because attackers must maintain communication with the systems they compromise, that command channel remains one of the most reliable places to identify an active intrusion.

When Sliver beaconing blends into normal web traffic, those behavioral signals still stand out.

To see how the Vectra AI Platform identifies command-and-control activity like Sliver in real environments, watch the self-guided demo.

FAQs