Beacon is Cobalt Strike’s payload for red team actions. Beacon is a stable lifeline that can serve as a communication layer. Meterpreter is a fantastic post-exploitation agent with a lot of features.  Used together, Beacon and Meterpreter give you a lot of options for stealth and indirection. In this post, I’ll take you through different ways to use Beacon to get the most out of Meterpreter and the Metasploit Framework.

Option 0. No Beacon

Let’s start by describing life without Beacon. In this situation, you have to use Meterpreter for everything. Meterpreter becomes your payload for the first foothold. Meterpreter is your payload for persistence. And, Meterpreter is your payload for remote control of the compromised system. Meterpreter is also the payload you pivot through.

If you use Meterpreter for your foothold into a network, chances are your first action is to spawn several backup Meterpreter sessions. You do this, because if you lose your session without a backup, you’ve lost your access. This isn’t the best option for stealth, but it’s a necessity. Meterpreter sessions do drop and it’s important to fortify your access to protect against this.

Option 1. Beacon as a Lifeline

There is another option though. Use Beacon for your foothold into a network. Beacon is designed to work like any other Metasploit Framework payload. You may deliver it with a Metasploit Framework memory corruption exploit or a Cobalt Strike social engineering package. Once Beacon is in memory, it will check-in over HTTP or DNS for tasks.

Beacon tasks are commands that you’d like Beacon to execute. For example, the spawn command will request a Meterpreter session for you. Used in this way, Beacon is a quiet lifeline to gain a new Meterpreter session when you need it. If stealth is important to you, don’t request a session until you have to interact with the host.

Option 2. Beacon for Egress

Meterpreter gives you the option to egress a network as a reverse TCP connection, HTTP, or HTTPS. Meterpreter always egresses to one host. If this host is blocked or watched by a network defense team, you may find yourself on the losing end of a game of whack-a-mole. This isn’t fun.

For these situations, use Beacon as a pivot point to egress traffic out of your target’s network. Beacon gives you the option to egress a network over DNS or HTTP. You may even change between HTTP and DNS communication while you use your Beacon. This gives you the flexibility to use the right protocol for your needs at any time during the engagement.

Beacon will also egress to multiple hosts. When you setup Beacon, you provide a list of multiple domains and hosts Beacon should call back to. Beacon will rotate through these hosts in a round-robin fashion. A network defense team must block all of these hosts to disrupt your communication with their network.

Beacon exposes a SOCKS proxy server that allows you to use a beaconing host as a pivot point. This SOCKS proxy server will tunnel Metasploit Framework attacks, Meterpreter, and external tools through Beacon.

To use Beacon as a pivot point, you must ask your Beacon to check-in multiple times each second. If you try to tunnel traffic through a Beacon with a high sleep time, you will find most tools will timeout due to the artifically high communication latency.

Beacon as a pivot point will help you walk your toolkit past a lot of border defenses. Once you’re inside of a network, with a stable channel to tunnel through, you have a lot of freedom to work without interruption.

Option 3. Beacon as a Communication Layer

Not all systems that you compromise can or should beacon out to hosts on the internet. There are times when you will want to control a system that can’t connect to you. To control these systems you might use a bind Meterpreter payload or a reverse TCP payload through a Meterpreter session. As usual, if your Meterpreter session dies, you have to re-compromise the system to run Meterpreter on it.

Optionally, you may deliver Beacon as a bind payload to gain control of these systems too. A bind Beacon payload, also called a Beacon peer, is an in-memory backdoor that you may run on a compromised system. A bind Beacon is a backdoor because you may connect to it whenever you like, disconnect from it, and reconnect to it later.

This backdoor is available as an SMB pipe. To connect to this backdoor, you must link another Beacon to it. Linked Beacons communicate over SMB, which blends in well with normal network traffic. Traffic tunneled through a Beacon peer will go through its parent Beacon to communicate with you.

On any host that has a Beacon, you may issue one command to request a Meterpreter session that stages and tunnels its traffic through that Beacon. Used this way, Beacon becomes a replacement communication layer for Meterpreter.

If you lose a Meterpreter session tunneled through a Beacon peer, you may request a new one in its place. You do not need to recompromise the target and the target does not need to connect to the internet. A Beacon peer can act as a pivot point and a lifeline to a host deep inside of a network.

Option 4. Beacon as a Remote Administration Tool

Sometimes, you will find it’s difficult to get a stable Meterpreter session out of a target’s network. A host-based defense may disrupt it. Or, your attempts to tunnel traffic into a target network may stand out—leading to the whack-a-mole game. In this situation, you’re stuck with Beacon as a remote administration tool.

If you do not tunnel traffic through Beacon, you can use it with a high sleep time. You may ask Beacon to check in once every ten minutes, every hour, or even once a day. Used in this way, Beacon will queue all commands you provide, download them on check-in, and execute them one by one after a check-in.

Beacon has some remote administration tool features. You may upload and download files through it. Beacon will track all file downloads and grab a piece of each file with each check-in. This makes it possible to exfil a large file to multiple callback hosts in a low and slow way. You may also use Beacon to execute commands.

The Metasploit Framework spoils us with a common interface for most hacking actions. That said, most of the things we do in the Metasploit Framework are do-able with a stand-alone executable or a built-in Windows command. If you have an arsenal of obfuscated post-exploitation tools and you’re comfortable doing things by hand—you can execute a majority of your engagement through Beacon without lowering the sleep time.

If you only use Beacon with a high sleep time to control compromised hosts—you will make it very hard for a network defense team to notice you.

Advanced Threat Tactics?

Each of these options represents different levels of sophistication. When you read about “advanced persistent threat” activity, try to match what you’re reading with these options. When you read about an actor’s use of an extremely simple beaconing RAT, ask—what does this actor use for post-exploitation? When you read about an actor’s use of Poison Ivy, ask—what does this actor use for their foothold and persistence? When you read about a campaign that lasted several years, ask—how did this actor preserve their freedom to regain control of any host, at any time, without raising suspicion? When you hear the tales of suspense about the actors that never get caught, ask—how did they do it? And finally, when you read about an advanced threat actor, ask “How can I help my customers understand their ability to detect and respond to this?” 

Beacon is my payload for low and slow control of a compromised system. Recently, I added peer-to-peer communication to Beacon. When two Beacons are linked, the child Beacon will get its tasks from and send its output through its parent. Linked Beacons use SMB pipes to communicate. This is a big win for stealth. If a workstation Beacon communicates with a domain controller Beacon over SMB, who would notice?

I invested in this feature for several reasons: I wanted the ability to control an internet isolated host with Beacon. I also wanted to control many compromised systems through one or two egress hosts. And, I thought it would be really cool to tunnel a Meterpreter session over SMB. These things are all doable now.

Cobalt Strike‘s Beacon isn’t the only offensive tool to use named pipes in this way. The Red October malware (see the Kaspersky report) has this feature. The Duqu malware that Symantec analyzed has this ability too. If you want to replicate the C&C styles of advanced threats, Cobalt Strike has you covered.

SMB Named Pipes

Let’s go through how this communication mechanism works. It’s actually pretty easy. A named pipe is an inter-process communication mechanism on Windows.

The CreateNamedPipe function will set up a named pipe. The PIPE_ACCESS_DUPLEX flag makes the named pipe into a bi-directional channel.

HANDLE server;
server = CreateNamedPipe("\\\\.\\pipe\\crack", PIPE_ACCESS_DUPLEX, ...);

The CreateFile function connects to a named pipe.

HANDLE client;
client = CreateFile("\\\\.\\pipe\\crack", GENERIC_READ | GENERIC_WRITE, ...);

Use the ReadFile and WriteFile functions to read data from and send data through a named pipe.

Named pipes become interesting when they communicate between processes on separate hosts. Change the period in the pipe name to an IP address. Now the client will communicate with the pipe on the remote system.

HANDLE client;
client = CreateFile("\\\\192.168.95.18\\pipe\\crack", GENERIC_READ | GENERIC_WRITE, ...);

Named pipe communication between hosts is encapsulated in SMB. Here’s what it looks like in Wireshark.

This communication method is not without its constraints. Any system I link to must have port 445 open. If I use a Beacon peer to control a key server, like a domain controller, this isn’t unreasonable. Any Beacon that connects to another Beacon must have an access token or it must establish an SMB session with the target first. This is because Beacon does not create an anonymous pipe. An anonymous pipe would require a change in the registry.

In-Memory Backdoor

For Beacon users, this peer-to-peer technology isn’t just a new data channel. It’s also an opportunity to use Beacon as an in-memory backdoor for Windows hosts.

Once you deliver a Beacon peer to a host (or use mode smb to turn a Beacon into a peer), it creates a named pipe and waits for a connection from another Beacon. You may link to it right away. You don’t have to though. After you link to a Beacon, you may unlink it at any time. When you unlink a Beacon peer, it waits for a connection from another Beacon.

Flexible Tunnels

Tunneling traffic through linked Beacons works like you’d expect. If I create a Meterpreter session, tunneled through a Beacon peer, that traffic will reach Cobalt Strike through the peer’s parent Beacon.

Let’s say I unlink a Beacon peer while tunneling a Meterpreter session through it. Then I quickly link that Beacon peer to another Beacon. What happens to my tunneled session? Nothing. My tunneled session will continue to work. Its traffic will go through the new parent Beacon. This is quite neat. You’re redefining a tunnel’s egress host, on the fly.

There’s a lot of possibility here.