Archive for the ‘Cobalt Strike’ Category


Appropriate Covert Channels

November 24, 2015

As a product vendor, I regularly receive suggestions from my users. It’s easy to break these suggestions up into different categories. One such category would be Beacon communication channels. I get requests that ask when I will look into various protocols or third-party services as communication channels.

I see communication options as very important. But, not all channels are created equal. In this blog post, I’d like to share the rubric I use to decide if a channel is right for Beacon.

Rule #1: A native Windows API must exist

When I build a channel into Beacon, I look for channels that I can implement with the APIs Windows provides. I like Windows APIs because they give me a lot for free. Right now, Beacon uses the WinINet API for its HTTP and HTTPS channel. This API provides a simple way to make RFC compliant HTTP requests to my web server. It also pulls the proxy settings for the system and transparently handles proxy authentication for me. The more I can offload to tried and true Windows APIs, the better.

Rule #2: Staging must be possible

Implementing a channel as a Windows API has the benefit of keeping my implementation simple and small. This plays directly into my next rule: Whichever channel I implement, it must be feasible to write position-independent assembly code to stage Beacon over that same channel.

Staging is an important part of Cobalt Strike’s workflow. Most payload stages, by themselves, are too big to pair well with most attacks. The work-around is to break payload delivery up into stages. The first stage (also called the stager) connects to the attacker and downloads the second stage (also called the payload stage). The stager creates a place in memory to store the payload stage and passes execution to the stage once the download is complete.

Small stagers embed well into Cobalt Strike’s built-in attack packages. Small stagers also allow me to use a PowerShell one-liner, during lateral movement, to bootstrap a payload into memory without putting a binary on disk. One of my favorite Cobalt Strike demos is the one where I embed a DNS TXT record stager for Beacon into a Word macro.

Staging isn’t important for all payloads. Some payloads are designed to persist on disk and maintain access over a long period of time. By the time you’re ready to drop tools on disk, it’s probably safe to assume that you have some other channel to upload your persistence payload and run its installer through. For Beacon, this isn’t the case. I assume that Beacon is the payload you will use for your first foothold into a network. Because of this assumption, staging matters a great deal.

Rule #3: No third-party services

A lot of folks like to demonstrate payloads that use Gmail, Twitter, and other social media tools as a communication intermediary. Great stuff! I don’t expect that I will build features into Beacon that rely on specific third-party services.

I worry that a third-party service could change in a way that breaks my payload. As the developer of a paid and supported product, this is not a headache I want to take on.

I don’t want to be too much of a curmudgeon on this topic. Third-party service-based C2 offers a red teamer [and adversary] many benefits. A well-executed implementation will make it hard for a network monitoring staff to pick out legitimate activity from malicious activity. Some environments use reputation-based indicators to allow users unhindered access to well-known sites, but to make it harder for malware to connect to controllers on the Internet. The use of third-party services is a way to deal with this pain.

Rule #4: Must work from a user-level context, without special rights

A persistent agent has the luxury of assuming SYSTEM-level rights. An agent designed for an initial foothold and post-exploitation does not. I very much see Beacon as a stable lifeline and a post-exploitation agent. Because of this assumption, it’s important that the communication options I implement will work from a user-level context.

Rule #5: The protocol must (commonly) egress, if it can’t, it’s a peer-to-peer protocol. The server component of peer-to-peer protocols must follow these rules.

Beacon has two types of channels. It has channels meant to egress (HTTP/S and DNS) and it has a channel meant for peer-to-peer communication. If a channel cannot egress (e.g., the SMB channel) then it’s a peer-to-peer channel. Peer-to-peer channels require that Beacon hosts the server component too. In these cases, the server component must meet these criteria before I consider the channel appropriate.

A good example is ICMP. Eventually, I will probably build an ICMP channel for Beacon. It fits these rules. There’s a Windows API to send ICMP echo requests and receive the response. This is something that I could build a stager for. It doesn’t depend on a third-party service. I can use the ICMP API without special rights. And, ICMP is a protocol that’s allowed to egress some situations. ICMP passes these tests.

Keep in mind, these are the rules I use for Beacon. These rules are not applicable to all payloads and all use cases. Beacon is a user-land lifeline and a post-exploitation payload. These use cases require that I meet their needs and constraints. The design decisions for these use cases are sometimes counter to the decisions I would make for a payload built for other purposes (e.g., persistence). When you look at payloads, it’s important to think about what the payload is originally built for and to use it in those contexts. This will help you get the most from the capability.


How do I psexec without an initial Beacon?

November 3, 2015

Here and there, I’m getting questions that are variants of this post’s title. The inquiry usually goes like this:

Dearest Raphael,
I do a lot of internal engagements. I don’t expect that I will always have a Beacon on target due to a phishing or client-side attack. How do I launch a psexec attack directly from the Cobalt Strike team server.


uLTRA tHANG 31337, Certified Professional Cyber Tester

I love these emails. First, the inquiry has a simple answer. Second, it’s an opportunity to explain Cobalt Strike’s model of offense. If you’re used to the Metasploit Framework or another penetration testing framework, it’s a little different.

Vulnerability Verification – It’s all about Modules

Many penetration testing tools offer a pile of offensive capability as modules on the attacker’s system. You either launch these modules directly from your system OR you tunnel these modules through a remote access tool.

This model has some benefits. Namely, the attacker’s system controls the protocol stack for each way it can interact with a target. This gives the attacker full control over these interactions and this is necessary for many memory corruption scenarios.

This model is fine and has few drawbacks for an internal actor working to quickly find and demonstrate the risk of misconfigurations and vulnerable services. If you do not need to pass through border defenses and try to evade an active defender, why would you care about operating “low and slow”?

Cobalt Strike’s Model of Offense

With Cobalt Strike, I always assume that you’re a remote actor with a foothold in your target’s network. I provide tools to help get this foothold, but post exploitation and lateral movement is when Cobalt Strike becomes really interesting.

The Cobalt Strike team server has no remote attacks or built-in offensive capability [with the exception of spear phishing]. Instead, Cobalt Strike pushes all of its offensive actions down to the Beacon payload. The Beacon payload then executes these things on your behalf.

This method of offense plays well with asynchronous communication. I can push a port scanner down to a Beacon and it will run in between check ins. Each time the Beacon checks in, it will communicate intermediate results to me. There’s no need to be in constant contact with my target to perform a scan.

Cobalt Strike’s capabilities to touch targets are built on native Windows APIs and not a third-party protocol stack. If I want to spread laterally, I use Windows APIs to create an access token from the credential material on hand and run my payload on a remote target. I don’t need to worry about whether or not my third-party SMB stack supports SMB signing and this environment requires it. Things just work. I can also task an asynchronous payload to perform these actions. I don’t have to speed up my communication and tunnel a capability through my foothold.

If your goal is to evade defenses and validate an organization’s detect and respond capability, asynchronous control of your targets is table stakes.

So, how do I psexec without an initial Beacon?

Let’s revisit the original question that drove this blog post in the first place. How do you perform Cobalt Strike’s offensive actions without a foothold from a client-side attack?

If you can touch targets and have trust material, then Cobalt Strike is a fine option to start with. Run a Beacon on a red Windows system that you control. Use make_token or pth to create a Windows access token with the desired trust material. Attack the targets you want to use as your initial footholds.

The last part of the Pivoting lecture in the Advanced Threat Tactics course shows how to do this over an SSH tunnel.


Connection Refused Error in Cobalt Strike

October 26, 2015

I’ve had several folks write to me asking about the Connection Refused error when they try to use Cobalt Strike. This one:


Cobalt Strike 3.0 requires you to start a team server before you attempt to connect a client to it. If you connect a client to and no server is present, you will see the error: Connection Refused. Cobalt Strike presents this error because there is no team server waiting to accept your connection.

The Starting Cobalt Strike section of the Cobalt Strike Support page discusses the process to start a Cobalt Strike team server and connect a client to it. Here’s a video as well:

This behavior is a change from previous versions of Cobalt Strike. Previously, if you tried to connect to and nothing was listening, Cobalt Strike would prompt you and ask if it should start a server for you.

Cobalt Strike 3.1 will accompany the Connection Refused error with information describing the need for a team server and pointing users at the exact piece of documentation to look at.


You’re not out of the woods yet…

Beyond starting a team server, Cobalt Strike 3.0 is a significant change over Cobalt Strike’s predecessors [hence the 3.0 version]. I recommend spending some time with 3.0’s resources to understand these changes.

The Advanced Threat Tactics course is a nine-part course on Red Team Operations and Adversary Simulations. All said, this course is nearly six hours of material! I released Advanced Threat Tactics with Cobalt Strike 3.0. I consider this material the go-to resource to become familiar with Cobalt Strike 3.0 and the process it supports.

If you’re not too into videos, that’s cool. Give the Cobalt Strike 3.0 manual a read. This manual describes Cobalt Strike’s features in depth. It’s not the Great American Novel, but it’ll do.

Finally, if you’re in a real hurry, keep the Cobalt Strike Support page open as you use the tool. This page has references for most Cobalt Strike features. At a minimum these references describe the feature and its use. Most of these reference pages have a short video demonstration too. Either way, this information is the best way to learn about what you’re immediately interested in.

Whatever your learning style, there are resources to help you get up to speed with Cobalt Strike 3.0 and later.


The Cobalt Strike Trial’s Evil Bit

October 14, 2015

RFC 3514 proposes an IPv4 flag to allow traffic to flag itself as malicious or not. This RFC’s authors reason that if malicious programs opt into this standard, it will become easier for IDS and other security products to distinguish between packets with good and evil intent. Naturally, this RFC was written in jest.

If the evil bit were real, the Cobalt Strike 3.0 trial would set it. In this post, I’d like to clarify some things about the trial that I’ve already had a few email exchanges about.

The Cobalt Strike 3.0 trial is the full Cobalt Strike product with one [significant] difference. The Cobalt Strike 3.0 trial inserts several “tells” to get caught by standard security products. This change is made possible by Cobalt Strike’s flexibility to change its indicators and artifacts.

What are the “tells”?

Cobalt Strike generates its executables and DLLs with the help of the Artifact Kit. The Artifact Kit is a source code framework to generate executables and DLLs that smuggle payloads past some anti-virus products. The Cobalt Strike 3.0 trial ships with the template Artifact Kit build. The template build embeds Cobalt Strike’s stager shellcode into executables and DLLs with no steps to disrupt an anti-virus sandbox.

The Cobalt Strike trial loads and uses Malleable C2 profiles. This is a feature that allows users to change the network indicators in the Beacon payload. Each HTTP GET transaction, from the trial, includes an X-Malware header with the EICAR string as its content.

The Java Signed Applet Attack in the Cobalt Strike trial has some differences too. This attack ships with an EICAR file inside of the JAR.

Finally, the trial removes Cobalt Strike’s primary payload encoder. Many security products flag traffic as malicious if they see a PE header in it. I use a Cobalt Strike-specific encoder to obfuscate the Beacon stage as it goes over the wire. This gets Beacon’s stage past many scenarios. Without an encoder, the staging process is much more likely to get caught.

What does this mean for me?

If you have a valid Cobalt Strike license key, you should always use the licensed version of the product in your production infrastructure. This means running the update program with your license key to get the licensed product.

The licensed version of the Cobalt Strike product does not have these deliberate tells. I’ve taken steps to make sure the trial team server can’t talk to a licensed client and vice versa. I did this to make sure customers don’t accidentally use a trial component in their production infrastructure.

If you’re a trial user, you should be aware that the Cobalt Strike 3.0 trial has these deliberate tells. I would use the trial as a first-pass of the product. Try it out in a lab. Go through the videos. Make a good decision about whether or not the product does something you need. If you have questions about Cobalt Strike while evaluating the trial, email me, and we can discuss them.


Named Pipe Pivoting

October 7, 2015

One of my favorite features in Cobalt Strike is its ability to pivot over named pipes. A named pipe is a way for two programs on a Windows system to communicate with each other. From a programming perspective, working with a named pipe is a lot like working with a file.

I use named pipes to allow a beacon to receive its commands and send its output through another Beacon. In this way, a parent Beacon becomes the egress channel for its child Beacons.

This has some utility on the same host. Let’s say a target network tightly controls egress. Each system that wants to make an outbound web request must go through a proxy and authenticate to it. A Beacon that lives in user space will likely get out. An elevated Beacon run in a SYSTEM context will probably not get out. In these situations the named pipe Beacon has utility. An elevated Beacon can use the user-level Beacon’s channel to communicate with me. Sweet.

That’s not all though. Windows allows two programs to communicate, host-to-host, over named pipes. This communication is encapsulated within the SMB protocol. In this way, a named pipe pivot is not just communication on the same host, it’s also a way to control systems that can’t reach the internet with port 445 as a control channel. This is especially useful for lateral movement. It’s strange to make a domain controller egress to your internet-based infrastructure. A semi-mature security posture will detect and act on this very quickly. That said, it’s OK and expected for a workstation to connect to a domain controller or file server over port 445. A named pipe pivot is a way to blend in if you want to control these types of assets.


Cobalt Strike’s named pipe pivoting capability has had a long journey. I first introduced this feature in Cobalt Strike 1.48 (November 2013). At that time, this feature was just the named pipe channel and a few workflow flourishes to stage the SMB Beacon with a Metasploit Framework bind/reverse TCP stager.

This was a start, but it wasn’t enough to make great use of pivoting over a named pipe. I wanted the ability to deliver a Beacon to a target and control it entirely over port 445. This desire drove the implementation of the stageless Beacons in Cobalt Strike’s January 2014 release. A stageless artifact is one that contains the entire payload. It does not use a stager. A stageless SMB Beacon, exported as a service executable, would allow me to use the Metasploit Framework’s PsExec to deliver an SMB Beacon without a bind/reverse TCP stager. I considered this a good win for using the SMB Beacon for lateral movement.

While the Metasploit Framework’s PsExec module was nice, I wanted a way to conduct lateral movement through the Beacon payload. The February 2014 release of Cobalt Strike added token stealing and basic privilege escalation capability to Beacon. This capability, paired with several native commands, was enough to use Beacon for lateral movement.

If you ran into me at a conference in 2014, you probably saw a demonstration similar to this one:


In my 2014 demonstrations, I would show folks how to use Beacon as an operating capability. Lateral movement always makes a good demonstration. Sadly, the tools in Cobalt Strike didn’t do the job and sell the story. I had to rely on etherape in the target’s network, to show egress over one channel and peer-to-peer communication over another.

This demonstration crutch was my first signal that the named pipe pivoting required some sort of visualization. My use of Cobalt Strike was the second kick in the rear. Several times, I’ve found my teammates and I in a special ring of hell. Tracking 5+ levels of named pipe pivoting in a table is painful.


Which Beacon is linked to which? [Follow the chains in the external field!]

When I wrote the functional specification for Cobalt Strike 3.0, I knew I would need better tooling support to make named pipe pivoting useful to more of my users.

The first problem to solve was simple workflow. Cobalt Strike features that spawn a new payload always target a listener. Listeners are Cobalt Strike’s way to tie payload configuration information [and a promise to start that payload’s handler] to an easy-to-remember alias. It’s a simple abstraction, but it’s critical feature that allows one person to set up infrastructure and others to use it with fewer mistakes. I would need a way to make the SMB Beacon into a useful Cobalt Strike listener. This required solving a problem I did everything I could to avoid: staging.

I didn’t have a way to stage the SMB Beacon over a named pipe. I opted to implement a half-measure to solve this problem. I built a windows/beacon_smb/bind_tcp payload into an early build of Cobalt Strike 3.0. This listener would only work with Beacon actions that spawned a payload from the current session (privilege escalation, spawn, inject, etc.). To support a bind listener in Beacon, I instrumented Beacon’s implementation to follow any use of bind listener with a special Beacon task to deliver the Beacon stage. In this way, I could have a Beacon calling home, once every five minutes, inject a bind TCP stager into memory and complete the staging process without tunneling something through the Beacon.

Since the February 2014 release of Cobalt Strike, I’ve had folks ask: why don’t you add lateral movement automation to Beacon? I couldn’t. All Cobalt Strike features target listeners. If I were to add lateral movement automation, I would need to solve the staging problem for the SMB Beacon or have lateral movement automation without the SMB Beacon [not acceptable]. Eventually, I put together a named pipe stager for Beacon and built the lateral movement automation so many folks asked for. The windows/beacon_smb/bind_tcp payload became windows/beacon_smb/bind_pipe. I shipped this work as part of Cobalt Strike 2.5 in July 2015.

Named Pipe Pivoting… Today

Cobalt Strike 3.0 completed the journey for the SMB Beacon feature. In 3.0, I added visualization for the SMB Beacon. Here’s what it looks like:


I no longer have to use etherape to visualize or describe my pivoting. ☺ Cobalt Strike’s workflows and dialogs expose the automation in Cobalt Strike’s Beacon for lateral movement. It’s now just as easy to deliver and use a named pipe payload in CS 3.0 as it was to deliver a bind_tcp meterpreter payload in Armitage:

Named pipe pivoting is one of my favorite features in Cobalt Strike. With the release of 3.0, the tooling support for this feature is now complete. It took nearly two years to get this feature to this point, but good things take a while. As you spend time to become familiar with Cobalt Strike 3.0, this is one feature I recommend spending some time with.


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.
  • Watch Flying a Cylon Raider. This talk is a platform agnostic look at how to conduct post-exploitation and lateral movement without the Metasploit Framework. Understanding the concepts in this talk will help you get the most from the material in this course.

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.
  • Watch Infocyte‘s video on Enterprise Hunt Operations. While this is a product advertisement, listen closely for the information it collects. As a red operator, you need to understand what your actions look like to analysts who use these hunt platforms. Your job is to figure out how to craft your activity to grow and challenge these analysts.

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.


Get every new post delivered to your Inbox.

Join 17,486 other followers