Archive for the ‘Cobalt Strike’ Category


Advanced Threat Tactics – Course and Notes

September 30, 2015

The release of Cobalt Strike 3.0 also saw the release of Advanced Threat Tactics, a nine-part course on red team operations and adversary simulations. This course is nearly six hours of material with an emphasis on process, concepts, and tradecraft.

If you’d like to jump into the course, it’s on YouTube:

Here are a few notes to explore each topic in the course with more depth.

0. Introduction

This is a course on red team operations and adversary simulations.

To learn more about Adversary Simulations and Red Team Operations:

Advanced Threat Actors:

Tools used in this course:

1. Operations

Advanced Threat Tactics starts with a high-level overview of Cobalt Strike’s model for distributed operations and red team collaboration.

To learn more about Cobalt Strike’s model for collaboration and operations:

  • Watch Force Multipliers for Red Team Operations. This is my favorite talk I’ve given. Here, I summarize my work and insights on the red team collaboration problem. Today, I consider this a completed research project with the following blog posts capturing lessons learned on how to build infrastructure and organize a large red team to support operations (primarily in an exercise context).
  • Read A Vision for Distributed Red Team Operations to learn more about Cobalt Strike’s model for distributed operations with multiple team servers.
  • Read The Access Management Team [Shell Sherpas]. This blog post discusses the Access Manager role in depth.
  • Read about The Post Exploitation Team. These are my notes on the folks who interact with targets to complete objectives and find interesting information.
  • Read Infrastructure for Red Team Operations. Infrastructure is the foundation of any engagement. This post is my best practices for organizing infrastructure to support a long-term op with multiple targets.

2. Infrastructure

Infrastructure is the collection of domains, servers, and software that support your operation. One of Cobalt Strike’s strengths is its variety of communication channels and the flexibility you have to configure them. This lecture goes through the HTTP/HTTPS, DNS, and named pipe channels and shows you how to use special features with each. I also take you through how to stand up redirectors and test your infrastructure before an engagement.

To learn more about payload staging:

Beacon Communication:

3. Targeted Attacks

This lecture goes through a process to execute a targeted spear phishing attack to get a foothold in a modern enterprise.

To learn more about this material:

User-Driven Attacks:

4. Post Exploitation

This lecture shows how to use Beacon for post-exploitation. If you have to operate with Beacon, this is good core material to know.

To learn more about this material:


  • Buy the Red Team Field Manual. This is a must-own for anyone working in this space. The tips and tricks here are quite applicable for all Beacon operators.

5. Privilege Escalation

Think of this lecture as post exploitation, part 2. We dive into how to elevate privileges and use these privileges to harvest credentials and password hashes.

To learn more about User Account Control and the Bypass UAC attack:

Privilege Escalation:

  • Read Windows Privilege Escalation Fundamentals. This tutorial has a number of command-line recipes to find files with credentials and other things you should look for when trying to elevate your rights.
  • Read What you know about ’bout GPP? This blog post offers a look at the Group Policy Preferences privilege escalation vector. This is one of those issues that, while patched, remains an issue because the patch does not cleanup the problems created by this feature when it was last used. I didn’t have time to cover this problem in the course [six hours is enough!]; but this is a staple thing you should always check for.



6. Lateral Movement

This lecture is the use and abuse of native Windows capability and behavior to trade-up privileges and move around a network.

To learn more about enumeration and reconnaissance in a Windows Active Directory network:

  • Watch Passing the Torch: Old School Red Teaming, New School Tactics? Here David McGuire and Will Schroeder go through their tricks to understand a Windows enterprise network the old school way (net view /DOMAIN and friends) vs. the new school way (with PowerShell).
  • Read PowerView: A Usage Guide to understand this wonderful tool from Will Schroeder to automate enumerating trusts, users, and hosts in an active directory environment.
  • Check out Netview by Rob Fuller. This tool enumerates systems using the Win32 Network Management API. I believe it was one of the original inspirations for PowerView and it certainly inspired Beacon’s net module as well.
  • Read Trusts You Might Have Missed by Will Schroeder for a quick primer on domain trusts in Windows Active Directory networks. You’ll really want to go through all of Will’s blog to understand this topic fully. He posts a lot about domain trusts and user hunting. Too much for me to keep up with here.
  • Also, read I Hunt Sys Admins by Will Schroeder (him, again!) to learn different ways to find where a particular user lives on the network. This is important for targeting systems that may have trust material that gets you closer to the data you want or to DA rights on the network.

Remote Management without Malware:



Remote Code Execution:

7. Pivoting

SOCKS, SOCKS, SOCKS! This lecture is about how to pivot with Beacon. You could also think about it as using and abusing SOCKS forwards, backwards, and any other way you want it.

More on this topic:

8. Malleable C2

Malleable C2 is Cobalt Strike’s domain specific language to change indicators in the Beacon payload. This ability to make Beacon look like other malware is arguably what makes it a threat emulation tool.

More on this topic:

9. Evasion

The Advanced Threat Tactics course concludes with a deep dive into evasion. This video is my to-the-minute notes on this topic.

To learn more about phishing and e-mail delivery:

Anti-virus evasion:

Application Whitelisting:

Egress Restrictions:

  • Read An Unnecessary Addiction to DNS Communication. I often hear from folks who insist that DNS is the only way out of their network and the only way to reach servers that are otherwise isolated from the network. This post goes into depth on the evasion options with Cobalt Strike’s DNS communication scheme and it digs into the capability available in Cobalt Strike’s other Beacon variants.
  • Read HTTP Proxy Authentication for Malware to understand how Beacon’s HTTP/S stagers react to proxy authentication failures.

Active Defenders:

  • Watch Operating in the Shadows given by Carlos Perez at DerbyCon 2015. In this talk, Carlos goes over the different advancements in blue’s ability to instrument Windows and the impact it will have on red teams and penetration testers who need to challenge them. This is a sign of things to come.
  • Read Advances in Scripting Security and Protection in Windows 10 and PowerShell V5. Windows 10 will change the security game in a big way. This post from Microsoft goes through the new logging hooks to understand PowerShell activity on a system and the hooks that allow anti-virus engines to look for malicious PowerShell.
  • Take a look at Microsoft’s Advanced Threat Analytics technology. This defense tracks which systems/users pull which active directory objects, when, and how often. It’s designed to catch that awesome stuff discussed in part 6 of this course.
  • Also, check out UpRoot, an agentless host-based IDS written in PowerShell that leverages WMI subscriptions. UpRoot reports process creates, new network connections, and other host activity. Tools like UpRoot show the scrutiny red operators will need to learn to cope with when working with a mature hunt team.

Cobalt Strike 3.0 – Advanced Threat Tactics

September 24, 2015

Cobalt Strike’s mission is to help security professionals emulate “advanced threat tactics” during their engagements. I’ve executed on this since the product’s 2012 release. Cobalt Strike 3.0 is the next iteration of this.

Cobalt Strike 3.0 is a ground-up rewrite of the client and server components in this product. Notably, Cobalt Strike no longer directly depends on the Metasploit Framework. Cobalt Strike 3.0 is a stand-alone platform for Adversary Simulations and Red Team Operations.

This release makes several strategic changes to support Cobalt Strike’s Red Team Operations and Adversary Simulation use cases. Here are the highlights…

Asynchronous Post Exploitation with Beacon

Beacon has completed its transition from stable lifeline to full-featured post-exploitation agent. This release includes features and workflows for user-exploitation at scale and a data model that populates itself with credentials and targets found with Beacon.

Logging and Reporting Designed for Red Team Operations

Logging and Reporting were completely overhauled. All logging now takes place on the team server. Each command is attributed to an operator. File uploads are hashed and the file hash is noted in the logs. Actions and output are captured whether a client is connected to the server or not. Cobalt Strike 3.0’s reports produce detailed timelines of red team activity and indicators of compromise.


Intuitive Named-pipe Pivoting

The SMB Beacon is a first-class part of Cobalt Strike’s workflows. This Beacon variant uses a named pipe to receive commands from and send output through a parent Beacon. This effectively allows you to chain Beacons to tightly control your communication path and egress systems/elevated processes through another Beacon’s channel. Cobalt Strike 3.0 supports the SMB Beacon with visualization that shows this chaining in a beautiful and intuitive way.

Target Acquisition and Lateral Movement

Cobalt Strike 3.0 also provides tools and workflows to support target acquisition and lateral movement with Beacon. The new net module uses Win32 APIs to discover and interrogate targets. Beacon also gained a port scanner that operates on target and reports intermediate results when Beacon checks in. The workflows to repurpose trust material and jump to a target are efficient and intuitive.

Advanced Threat Tactics Training

Finally, Cobalt Strike’s online training was refreshed for this 3.0 release. The Advanced Threat Tactics course is nearly six hours of material on the modern offensive process Cobalt Strike 3.0 supports.

A 21-day trial of Cobalt Strike 3.0 is available. The 3.0 release uses new infrastructure for its updates. Licensed users will need to download a trial of 3.0 and use the update program to get the licensed version of Cobalt Strike.


Rethinking Reporting for Red Team Operations

September 9, 2015

Cobalt Strike 3.0 is coming in a few weeks. This upcoming release is the result of a large engineering effort that paralleled my existing efforts to maintain Cobalt Strike 2.x. One of the big motivators for this parallel effort was to take a fresh look at logging and reporting.

Today’s Cobalt Strike produces reports that are run-of-the-mill for penetration testing tools (*yawwwwwwwwn*). That’s too bad. Cobalt Strike’s reporting engine has a lot of potential. It generates high quality PDF and editable Word Documents. The fidelity between the two is incredible. Cobalt Strike is also unique in its ability to connect to multiple team servers and merge data from all of these servers into one data model before it generates a report. This is important as any red team worth its salt operates from distributed infrastructure. No one server has the whole story.

So, here’s the question that drove this work: what do red teams and adversary simulation operators need in terms of reports? These operators are not trying to enumerate all vulnerabilities in a large enterprise. They’re working to train and exercise incident response.

If the debriefs from red team operations and adversary simulations don’t focus on vulnerabilities, what do they focus on? They focus on red team actions, the indicators these actions leave behind, and the exact timeline of the red team’s activity. This insight is where I started my re-think of Cobalt Strike 3.0’s reporting capability.

Cobalt Strike 2.x’s Hosts and Social Engineering Reports will come over to Cobalt Strike 3.0 mostly as-is. Cobalt Strike 3.0 has several new reports. Here they are:

Indicators of Compromise

Most threat intelligence report includes an Indicators of Compromise appendix at the end. These reports document hashes, IP addresses, and samples of malware command and control traffic. These appendices are a familiar format for security operations staff to consume.

Cobalt Strike 3.0 generates its own Indicators of Compromise Appendix, based on your activity. This report pulls data from all of the team servers you’re currently connected to.

This report generates and displays a traffic sample from each team server’s Malleable C2 profile.


It summarizes the MD5 hashes of files uploaded through a Beacon.


It also summarizes IP addresses and domains affiliated with your different listeners.


Like most Threat Intelligence reports, this appendix documents indicators with little context. I see this report as something you can provide mid-engagement when the Detect part of the Detection and Response game is taking longer than it should. It provides enough information to give security operations staff a start for hunting red team activity.

The (New) Activity Timeline

The Activity Report is a timeline of all red team activity that occurred during the engagement. Cobalt Strike 3.0’s Activity Report is a drastic improvement over the Activity Report in Cobalt Strike 2.x. Cobalt Strike 3.0’s asynchronous model of offense requires most actions to deploy to and execute from a Beacon. This makes it easier to summarize what happened and where it happened in a way that’s meaningful to a blue operator.


This report becomes far more interesting when you take into account the fact that Cobalt Strike 3.0 merges timelines and data from all team servers you’re connected to before it generates a report.

The Sessions Report

At the end of a security-operations focused assessment, the network defense staff is going to want to know what they should have seen and when. This information will allow them correlate your activity with their sensors and allow them to look into what they should have caught (but didn’t) or what they did catch, but didn’t understand and attribute properly. This is important information to provide and every red team I’ve worked with struggles to pull this together for their blue peers. Cobalt Strike 3.0 takes a stab at this problem with its sessions report.

The sessions report is a timeline of red team activity on a session-by-session basis. This report also summarizes the MD5 hashes of all files uploaded during that session. It  pulls out miscellaneous indicators that the team may have observed (right now, services created by Cobalt Strike’s automation [e.g., getsystem]).


This report also documents the communication path each compromised system took to reach you, the attacker. This is especially important to help blue teams understand the complex pivoting red team operators tend to execute.


Custom Reports (Cobalt Strike 3.1?)

Cobalt Strike 3.0’s Reporting Engine uses a Domain Specific Language to specify reports without exposing the intermediate markup I generate PDFs and Word Documents from. I will eventually expose this DSL and allow Cobalt Strike’s users to build custom reports and tailor the existing ones to their needs.


I hope you’ve enjoyed this preview of Cobalt Strike 3.0’s reports for Red Team Operations and Adversary Simulations. I expect to ship Cobalt Strike 3.0 by the end of this month.


The Aggressor Project (Preview)

September 2, 2015

If you’ve run into me at a conference during the 2015 calendar year, there’s a strong chance you’ve heard about or saw the Aggressor project. Aggressor is a ground-up rewrite of Cobalt Strike’s team server and client to better serve its Red Team Operations and Adversary Simulation use cases. I expect to ship this work as Cobalt Strike 3.0. It’s due for release at DerbyCon 2015 (September 2015).

At first glance, Cobalt Strike 3.0’s biggest change is the absence of the Metasploit Framework. Cobalt Strike 3.0 doesn’t depend on it. Instead, Cobalt Strike 3.0 builds its process and workflows on the Beacon post-exploitation agent. Many of my customers have moved their offensive process to the Beacon payload. Cobalt Strike 3.0 caters to this shift. Cobalt Strike 3.0 is also a fresh look at reporting and logging to aid accountability, deconfliction, and training.

If you want to know what Cobalt Strike 3.0 will look like, here’s a partial preview:

To some, this may sound very foreign. What’s the point of a penetration test without scans and exploits? Not all security assessments look like this. Adversary Simulations and Red Team Operations are security assessments that replicate the tactics and techniques of an advanced adversary in a network. While penetration tests tend to focus on unpatched vulnerabilities and misconfigurations, adversary simulations benefit security operations and incident response. There are different models/best practices for these engagements. I started this company and built this product to push these practice areas forward.

I’ve had several folks ask questions about Cobalt Strike 3.0. I wanted to take a few moments to answer them:

1) Is Cobalt Strike 3.0 available to existing customers or will I need to buy new licenses?

Cobalt Strike 3.0 is the anticipated successor to Cobalt Strike 2.5. As with other Cobalt Strike updates, Cobalt Strike 3.0 will be available to those with active Cobalt Strike licenses.

2) Will the price of Cobalt Strike go up when 3.0 hits?

The price of Cobalt Strike will not change as a result of the 3.0 release. Could the price go up in the future? Absolutely. Will it go up in the next month or two? No.

3) What will happen to browser pivoting in Cobalt Strike 3.0?

Browser Pivoting is present in Cobalt Strike 3.0.

4) How will you replace all the great things in Metasploit?

Cobalt Strike 3.0 does not replace the Metasploit Framework. Cobalt Strike 3.0 complements the Metasploit Framework as a separate platform. You can fire the Beacon payload with a Metasploit Framework exploit [demo]. You can pass accesses between the Metasploit Framework and Beacon [demo]. You can also pivot Metasploit Framework attacks [demo] and Meterpreter sessions through Beacon [demo].

5) Is Cobalt Strike’s name changing?

No. Aggressor is a codename. Cobalt Strike will still be called Cobalt Strike.

6) What will happen to Cobalt Strike 2.x and Armitage?

Armitage is its own project and will continue to stay much as it is now. I consider Armitage a mature product, but will maintain it as necessary. Cobalt Strike 2.x will be replaced by Cobalt Strike 3.0. I do not plan to maintain two lines of the Cobalt Strike product.

If you’d like to learn more about Cobalt Strike 3.0, hang tight, we only have a few weeks until DerbyCon. So far, we’re on track for a release at that time.


Cobalt Strike 2.5 – Advanced Pivoting

July 29, 2015

I spend a lot of my red time in the Access Manager role. This is the person on a red team who manages callbacks for the red cell. Sometimes, I like to grab a Beacon and drive around a network. It’s important to get out once in a while and enjoy what’s there. Cobalt Strike 2.5 is all about cruising around networks.

Lateral Movement++

This release adds native lateral movement options to Beacon. Use the psexec_psh, winrm, and wmi commands to deliver a Beacon to a target using PowerShell to avoid touching disk. For you old school types, a psexec command is available to deliver a Beacon to a target with an Artifact Kit service executable.

You’ll likely notice that Cobalt Strike’s lateral movement options do not accept credentials, hashes, or other credential material. Keeping with Cobalt Strike’s operating philosophy, these lateral movement options rely on what’s in your access token to authenticate with a remote system. If you want to pass-the-hash with Beacon; use mimikatz to create a token that passes your hash. If you need to pass credentials, use Cobalt Strike 2.5’s make_token command to create a token to pass the credentials you provide.

Named Pipe Stager

Cobalt Strike’s best payload for lateral movement is the SMB Beacon. This Beacon uses a named pipe to receive commands from and relay output through another Beacon. A named pipe is an inter-process communication mechanism on Windows. Named pipes also work host-to-host to allow two programs to communicate with each other over the network. This traffic is encapsulated in the SMB protocol.

The SMB beacon is awesome but it had a weakness. It’s too big to use with attacks like psexec_psh. Cobalt Strike 2.5 solves this problem with its named pipe stager. This tiny stager delivers the SMB Beacon to a remote target over a named pipe. This stager works well with Beacon’s new lateral movement options that don’t touch disk. This is quite an upgrade from the previous best practices.

Pivoting Process-to-Process

Red Teams pivot, not just host-to-host, but process-to-process on the same host. This need is usually driven by egress and evasion concerns. A process run as an unprivileged user may have the ability to egress. As soon as you elevate, you may run into difficulties if that elevated process can’t communicate out.

Cobalt Strike 2.5 uses the SMB Beacon to help with this problem. Beacon features to include its Bypass UAC attack and new spawnas command [use credentials to spawn a payload; without touching disk] accept the SMB Beacon as a target payload. This greatly improves Cobalt Strike’s options to work through one egress channel.

Reverse Port Forwards

Cobalt Strike 2.5 also adds reverse port forwarding. Beacon’s new rportfwd command will bind a port of your choice on a compromised target. When someone connects to this port, Cobalt Strike’s team server will establish a connection to a forward host and port of your choosing. It will then relay traffic, via Beacon, between this new connection and the client connected to your Beacon. Now, you can use compromised systems as arbitrary redirectors. ☺

Check out the release notes to see a full list of what’s new in Cobalt Strike 2.5. Licensed users may use the update program to get the latest. A 21-day Cobalt Strike trial is also available.


Cobalt Strike Penetration Testing Labs (Download)

June 4, 2015

My primary conference give away is a DVD with a self-contained penetration testing lab. This DVD covers the Metasploit Framework‘s capability to target a server. It also covers the client-side attack process in Cobalt Strike. It’s a pretty neat set of labs and they don’t take too long to go through.

Cobalt Strike Boxed Set

I’ve had several requests to put these labs online. If you’re one of those interested parties, then today is your lucky day. The Cobalt Strike Pen Testing Lab DVD material is now available for download.

To start, you’ll want to grab the necessary virtual machines:

1. Morning Catch (Phishing Target)

2. Metasploitable 2

3. Xubuntu Attack VM with CS dependencies and stuff to support the labs

Next, you’ll want to download the penetration testing lab book. Last, you’ll need to grab a trial of Cobalt Strike and install it on the Xubuntu virtual machine above.

Once you have these things, you’re ready to rock. If you get stuck, here’s a video of me going through the labs:



User-defined Storage-based Covert Communication

April 23, 2015

One of my favorite Cobalt Strike technologies is Malleable C2. This is a domain specific language for user-defined storage-based covert communication. That’s just a fancy way of saying that you, the operator, have control over what Cobalt Strike’s Beacon looks like when it communicates with you.


When I do red team work, I see the same blue audiences again and again. If the red teams I worked with were to persist the same way or have the same indicators during each engagement, the blue audiences would quickly learn these things and cease to get training value from our activity.

There’s two ways to solve this problem. One way is to use new tools during each engagement. That means the red teams either need to buy or build new tools for each repeat encounter they expect to have. This is expensive and not tractable. The other alternative is to build hacking tools that give their users flexibility to change behavior and indicators during an engagement. This line of thought is what led to Malleable C2.

Malleable C2 Profiles

The heart of Malleable C2 is a communication profile. This profile specifies what Beacon’s communication should look like on the wire. You can do the really easy stuff, like say, “I want my User-Agent to be ___________________”. That’s a simple option.

You can also dress up a Malleable C2 transaction too. The header keyword lets you add arbitrary headers to Beacon’s HTTP client requests and server replies. The parameter keyword lets you dress up Beacon’s HTTP client requests with additional parameters too.

You can also do cooler things, like say, “I want to base64 encode Beacon’s encrypted taskings and store the result inside of an HTML comment” [havex.profile] or “I want to add the encrypted Beacon tasks to a 1×1 pixel GIF file” [webbug.profile]. This is made possible by a Malleable C2 concept that I call a data transform. A data transform is a series of transforms that you may apply to data Beacon has to send. These transforms include append this string, base64 encode the data, prepend this string, and netbios encode the data.

        metadata {
            append "-.jpg";

Malleable C2 allows you to chain these transforms together into a program. This program is interpreted to transform Beacon’s data, one instruction at a time, into a string that looks like whatever you want.


Critically, each of these data transforms is trivially reversible. If I base64 encode some data, I simply need to use a base64 decode operation to recover that data. If I append a string to Beacon’s data, I just need to remove that many characters when I receive data from a Beacon to recover the original data.


The presence of an inverse operation for each transform is the magic that allows Cobalt Strike to derive how to send AND receive data from one specification.

The last piece of Malleable C2 is the ability to define where the data you transform is stored. Each data transform ends with a statement like print, which means send this data to the other end. More interesting statements include header and parameter which let you store the transformed data into an arbitrary HTTP header or parameter. The uri-append statement appends the transformed data to the requested URI.

This gives you an additional piece of flexibility. Not only can you define how to transform data that Beacon needs to send, you get to define where in the transaction this data goes.

Virtual Machines for Malware Communication

The challenge of Malleable C2 is that a Beacon needs to both send and receive information. This means Beacon, written in C, needs to transform data and recover data from a transform. The same goes for Cobalt Strike’s Java back-end that services Beacon’s HTTP requests.

To make this work I built a compiler for the C2 profiles. This compiler does all of the things you’d expect a traditional compiler to do. It parses the profile into an abstract syntax tree, it checks for errors, and it outputs a simple set of instructions that I wrote an interpreter for.

In effect, the Beacon payload and its server have built-in virtual machines to transform strings in different ways. Instead of CPU registers or a stack, this virtual machine operates on buffers. The active buffer maps directly to a part of a communication request. If I’m sending data from Beacon, there are buffers for parameters, headers, the URI, and in the case of a POST request–the data the client wants to send. Instructions in this Malleable C2 machine language allow the profile to set which buffer is the active one and populate/transform the data in this active buffer.

Likewise, to recover data, the Malleable C2 machine has instructions to populate a buffer with data from the transaction and to conduct inverse transforms on the data.

I could have built a simple XML format or made a few options to change static strings in Beacon’s communication. I went with this approach to give my users flexibility to look like other malware or legitimate traffic with very high fidelity. This isn’t possible with a few configuration options to change static strings. It really requires the ability to rewrite how the client and server expect to send and receive data from each other.

How I use Malleable C2

You may ask, what’s the use of Malleable C2? I’ve had a prototype of this technology since early 2014. I pushed it into production in July 2014. Now, after some time with it, I can offer some use cases.

I do use Malleable C2, for its stated use case, to emulate specific actors. The Malleable C2 Github repository has several example profiles that re-create the C2 traffic of known malware. I tend to use profiles tied to known malware when I want to get caught or when I want to exercise a blue team’s ability to analyze the attack.

Just as often, I will also modify a profile to make myself look like a variant of known malware. I do this to avoid getting caught with default signatures, but to make my activity identifiable as malicious for training audiences doing traffic analysis.

While Malleable C2 gives me a vote in how I want to get caught, it’s just as effective at evasion too. Once I know an environment’s browser configuration and sites users are likely to visit, I’ll load some of these sites in a VM, capture traffic, and craft profiles to look like this traffic. One time, I pulled down a PDF file from a document archive and made a profile to insert Beacon C2 into the middle of the PDF content. I do the same thing with JavaScript files that are common in an environment too. I also made favicon into a channel once. I didn’t spend days or hours crafting these. I built these on the fly, as needed, to support the engagement objectives.

When I stand up red team infrastructure, I always diversify my indicators. My long-haul persistence servers have different indicators from my staging and post-exploitation servers. If you use Cobalt Strike, I highly recommend you do this too. If one Beacon gets caught, you don’t want its traffic pattern to make it easy to identify all of your other Beacons. Malleable C2 makes it trivial to have indicator diversity with one tool.

Malleable C2 has helped defeat “blinky box” appliances as well:

One red team I worked with had to deal with a network appliance that whitelisted which sites clients could browse to. In this situation, we could use a client system to seed our access and troubleshoot our outbound communications. It was still our responsibility to figure out something that would work though. On a whim, we modified our profile’s HTTP GET and POST components to add a parameter with a whitelisted host in it:

http-get {
	client {
		parameter "q" "";

http-post {
	client {
		parameter "q" "";

And, it worked. We were able to get a fully-staged HTTP Beacon past the device. Apparently this vendor didn’t check whether or not we were visiting a whitelisted domain, they just cared that a whitelisted string existed in the URL.

I’ve seen several situations where a proxy server allows certain browsers out and denies other browsers the opportunity to leave the network. These situations represent the real power of Malleable C2. If some specific part of the Beacon payload is holding you back, Malleable C2 gives you the flexibility to do something about it. I consider that a huge win for empowering my end users to get the most out of the Cobalt Strike toolset.

Malleable C2 isn’t hard to learn. I recommend grabbing an example and tweaking it. You can also read the documentation to get a feel for what Malleable C2 can do.


Get every new post delivered to your Inbox.

Join 16,751 other followers