Red Team Archives - Page 5 of 7 - Cobalt Strike Research and Development

The Post Exploitation Team

I often get asked about red team skills and training. What should each team member know how to do? For exercises or long running attack simulations, I believe it’s fruitful to put junior members into the post-exploitation role first. This post describes the post-exploitation team, where they fit into the overall engagement, and their core tasks and skills.

Context

Before we dig into the post-exploitation team, let’s go big picture for a moment. The following diagram is from my 2012 Dirty Red Team Tricks II talk at DerbyCon. It shows the model for hand-off from persistent access to post-exploitation that I saw evolve during the 2011 and 2012 CCDC seasons.

teamprocess_updated2

This diagram isn’t far off from the infrastructure and access hand-off model that I recommend today. The main difference is that I recommend the use of staging servers. These servers act as an intermediary between the servers for long-haul persistence and interactive post-exploitation.

The workflow from the above diagram is still the same.

Getting to Post Exploitation

An access team works to get a foothold into a target network. There’s a lot that goes into getting a foothold–especially when it’s important to not get caught.

The next step is to escalate privileges on the network, ideally to domain administrator. Domain administrator is not always required to accomplish a specific goal. It’s a stepping stone to easily accomplish a goal on a network.

It’s important to also setup persistent payloads through the network so that the red team may regain a foothold, with privileges. These payloads should call home to the long-haul infrastructure.

These steps to get a foothold, elevate access, and execute a persistence plan are (potentially) hard. These steps depend on the target environment and may require custom code to succeed. You want your strongest people available for these tasks.

Post Exploitation

As sexy as it is to break in, take the terrain, and hold it, no one breaks into networks and holds them for no anticipated purpose. It’s important to have objectives. Depending on the engagement, these objectives may mirror those a likely adversary would go after or they should satisfy training criteria for a network defense team.

Conducting post-exploitation activity and working on objectives is something well-trained, but potentially junior, red team members can do.

What should the post-exploitation team know how to do? What are their core skills? These team members should know how to task an asynchronous agent into interactive access. I arbitrarily define interactive access as a payload that calls home on a one minute interval or faster.

Interactive control should always happen on infrastructure that is separate from the infrastructure used to receive low and slow callbacks. This helps protect the red team’s operational security. If an interactive access gets caught, you do not want to lose all of your persisted access because of it. Ideally, the tool for interactive access is different from the tool for low and slow access [or, at least, different indicators!].

Once a team member has access to a system, they have to work from that access. They must know how to navigate a file system, download files, log keystrokes, take screenshots, hijack browser sessions, and otherwise grab whatever satisfies the objective they’re out to meet. They should also know how to interpret the output from each of these tasks and act on this information. They must also know how to triage sources of information and find what’s interesting, quickly.

Team members should know lateral movement, cold. They must know how to work with credentials, tokens, and Kerberos tickets. They should know their options to touch other systems with these things. If they need to use a payload (NOT always the right answer); they should know how to bootstrap the payload with PowerShell when it’s possible. If they have to fall back to an executable, they should know how to generate an anti-virus safe artifact.

Concretely, I expect post-exploitation team members to know how to start a remote process with psexec, at, schtasks, wmic, and sc. This skill also requires the team member to understand the nuances of which artifacts they can and can’t use with each of these. For example, if I try to schedule a plain executable with sc it will fail. Why? Because sc expects an executable that responds to Service Control Manager messages. If I schedule an executable that doesn’t do this, Windows will kill it very quickly.

All red team members should have judgement. They should know that the direct route isn’t always the best way to fulfill a requirement.

Team members should understand that some post-exploitation actions will fail depending on several contextual factors. Troubleshooting these contextual factors comes with experience. It’s helpful to have a senior lead on hand to step in when a junior member gets stuck.

All red team members should know how to tunnel external tools through any interactive post-exploitation tools in use. SOCKS and proxychains are good topics of study. All red team members should also have strong knowledge of the standard clients that interact with common services.

Finally, red team members should know how to clean up after themselves. If they’re done with an interactive access, they should know to drop it.

These core skills cover most of the work a post-exploitation team will do. Train several junior members with these skills, assign them to a senior lead, and you’ll get a lot of use out of them. They’ll grow during the engagement too.

Tradecraft, parts 4 through 9, covers these topics.

Infrastructure for Ongoing Red Team Operations

Recently, I’ve had several questions about how to set up infrastructure for long running red team operations with Cobalt Strike. This is an ideal use case for Cobalt Strike. In this post, I will reiterate the advice I’ve shared with these users.

System Requirements

You will need to set up infrastructure to use for your engagement. I recommend that you host each piece of attack infrastructure on a VPS. I’ve used Linode and Amazon’s EC2 for this purpose. Make sure you factor the cost for multiple VPSs into your assessment budget.

I do not recommend that you setup a reverse port forward through your office’s NAT device. It’s in your best interest to minimize the number of devices and weird configurations between you and your target. It’s enough effort to guess what their network is doing, you don’t want to add troubleshooting your devices into the mix.

Attack infrastructure, for the purpose of this blog post, comes in two flavors: team servers and redirectors.

Team Servers

A team server is the server component of Cobalt Strike. It wraps the Metasploit Framework, connects to the database, and manages Cobalt Strike’s features. Multiple people may connect to a team server at one time. I also make the Cobalt Strike client available for Windows, MacOS X, and Linux.

You will want to follow the Cobalt Strike system requirements when you spec out a team server. I recommend 2GB of RAM, but you can get away with 1.5GB or more. On Amazon’s EC2, I use the c1.medium instance with 1.7GB of RAM. I like to set it up with a 64-bit flavor of Ubuntu 12.04.

Cobalt Strike’s quick-msf-setup script makes it very easy to set up the dependencies for a team server. This script is distributed with the Cobalt Strike Linux package. Run quick-msf-setup, choose your install preference, and everything else is taken care of for you. I use quick-msf-setup’s Git option to stage my dependencies.

distops2

Redirectors

A redirector is a system that proxies all traffic from your target’s network to a team server system. Redirectors give you IP diversity. You may configure listeners for Meterpreter and Beacon that call home through different redirectors. Beacon will phone home through multiple redirector addresses if you tell it to. I get away with low powered servers for my redirectors. An EC2 micro instance is fine here.

I also recommend that you obtain several domain names to use for your engagement. You will want to assign A records that point to each of your redirectors and team servers. If you choose to use the DNS Beacon, you will want to make its team server authoritative for multiple domains.

redirectors_t

Use Multiple Team Servers

I’ve seen attack infrastructure proposals that rely on one team server supported by multiple redirectors. This could work, but Cobalt Strike lets you take it one step further. The Cobalt Strike client connects to multiple team servers at one time. Each server may have its own listeners supported by its own set of redirectors.

I recommend that you designate a role for each team server that you stand up. When I setup infrastructure, I group my servers into three categories: long-haul, staging, and post-exploitation.

Long-Haul Servers

Long-haul servers catch callbacks from hosts that you’ve setup persistence on. I call these servers long-haul because they’re meant to maintain long-term access into your target’s network.

I use Cobalt Strike’s Beacon payload for long-term persistence. Beacon will call home to multiple servers, it speaks multiple protocols, and it’s designed for asynchronous “low and slow” operations. These are nice characteristics in a persistent agent.

Cobalt Strike’s Beacon does not have a turn-key persistence mechanism. If I put one in, everyone would know what to look for. You may export Beacon, without a stager, in a variety of formats though. I recommend that you architect a persistence strategy that makes the most sense for your engagement.

Long-haul servers require discipline to use effectively. These servers are your crown jewels as an embedded attacker. If they’re found out–you may find that your engagement is over. Here are a few tips to get the most of your long-haul infrastructure:

1. Never pass a session to a long-haul server

Every access on a long-haul server should come from a persistence mechanism. This allows you to monitor the status and health of your compromised systems. If a system isn’t calling back, it means it’s down or something is wrong with the persistence. This is your cue to investigate.

2. Use high callback times

Long-haul servers are designed for long-term access to a target’s network, not necessarily convenient access. I recommend that you configure your Beacons with high callback times. Consider a 24-hour callback interval with some randomization.

3. Use unique profiles

If a staging or post-exploitation action gets caught, you don’t want an indicator from that communication to lead to your long-haul infrastructure. Cobalt Strike’s Malleable C2 is a boon for these situations.

Malleable C2 lets you redefine the indicators in Beacon’s communication for each team server. Profiles take five minutes to write and test. Make sure your long-haul profile looks different from other profiles you use.

You may configure a default sleep time and jitter [randomization] factor through Malleable C2 as well.

4. Take Advantage of Protocol Diversity

I like to run two long-haul servers. I use a DNS Beacon on one server. I use an HTTP Beacon on another. I find that the DNS Beacon with a high sleep time and multiple domains offers a great challenge to professional network defense teams. The DNS Beacon uses one A-record request to an attacker controlled domain to “phone home”. One A-record request every 24-hours is quite benign.

5. Have a Persistence Strategy

The purpose of the long-haul servers is to keep a foothold in a target network or enclave. You do not want every compromised system to call home to this infrastructure. I recommend that you architect two persistence strategies. Let workstations beacon home to your attack infrastructure. Come up with something else to maintain access to compromised servers. You do not want high-value compromised servers calling out to your long-haul infrastructure.

Staging Servers

Staging servers are an intermediate level of infrastructure between long-haul persistence and interactive post-exploitation. I use staging servers as a convenient place to hold access to systems I plan to work with in a short period of time.

I use Beacon on staging servers with a sleep time that’s high enough to avoid detection but low enough that it’s convenient to use.

When I task access from a long-haul server; I almost always task the access to a staging server. Tasking an access means asking Beacon to spawn a session on another server when it checks in next. This is something built into Cobalt Strike’s workflow.

I recommend that you set up one staging server with its own redirectors to start with. If it gets caught, that’s OK. Spin up another one in its place.

Post-exploitation Servers

Post-exploitation servers are for interactive access to a compromised host. By interactive access, I mean a payload that calls home every minute or faster. This is Meterpreter and Beacons with a low sleep time.

Interactive access has its uses. You can pivot third-party tools into your target’s network and you get immediate feedback on your actions.

Request interactive accesses from your staging servers.

When I use a post-exploitation server; I tend to tunnel my Meterpreter sessions through Beacon rather than rely on the Metasploit Framework’s native handlers.

Updates

During your long engagement you will need to manage software updates carefully. I recommend that you never update a production team server during an engagement.

I work a lot on Beacon and I regularly break backwards compatibility with Beacons from previous releases. Be aware of this!

If a Metasploit Framework or Cobalt Strike update includes compelling features; feel free to introduce new software to your engagement. Just do it through a separate team server. Post-exploitation and staging servers are very transient and there’s no reason for these to stay the same for the length of your engagement.

Make sure you’re careful with those long-haul servers! If you need to update these, create new infrastructure with updated software, and reapply your persistence with the new long-haul servers as the target. Keep the old infrastructure available until you’re 100% confident that everything is moved over.

Licensing

I get asked about licenses and team servers. Cobalt Strike is typically licensed to X users in an organization. Users with a Cobalt Strike license are allowed to use the software on as many systems as necessary to do their job. Team servers count in this. Team servers are not a new user. So, if you have one license and one user, you’re welcome to spin up as many team servers as you need. If you have thirty licenses [you’re awesome!] and thirty users, you’re welcome to spin up as many team servers as you need.

Summary

These are my notes on setting up long-running attack infrastructure with Cobalt Strike. You’ll notice a lot of Cobalt Strike features play into this scenario. The distributed operations capability allows you to manage multiple servers. Beacon is a flexible agent that works as a persistent agent, acts as a placeholder for interactive accesses, and even offers an alternate communication layer. Better–you can customize Beacon’s C2 so each of these uses have their own indicators. This isn’t by accident. Managing accesses across distributed infrastructure in a team friendly way is Cobalt Strike’s bread and butter.

Tradecraft, part 9, speaks to some of the concepts in this post.

Puttering my Panda and other Threat Replication Case Studies

Cobalt Strike 2.0 introduced Malleable C2, a technology to redefine network indicators in the Beacon payload. What does this mean for you? It means you can closely emulate an actor and test intrusion response during a penetration test.

In this blog post, I’ll take you through three threat replication case studies with Cobalt Strike. In each case study, we will emulate the attacker’s method to get in, we will use a C2 profile that matches their malware, and we will analyze what this activity looks like in Snort and Wireshark.

Putter Panda

Putter Panda is an actor described by a June 2014 Intelligence Report from CrowdStrike. In this video, we replicate Putter Panda’s HTTP CLIENT malware and use a Document Dropper attack to deliver it.

String of Paerls

String of Paerls is an intrusion set described by Sourcefire’s Cisco’s VRT. In this video, we replicate the actor’s C2 with Beacon and use a macro embedded in a Word document to attack a target. We also reproduce the attacker’s phish as well.

Energetic Bear / Crouching Yeti / Dragonfly

This actor, known by many names, allegedly targets the energy sector. The best information on this actor came from pastebin.com without a slick PDF or PR team to back it up. In this video, we replicate this actor’s havex trojan with Beacon and use a Java drive-by exploit to attack a target.

With the right technologies, threat replication isn’t hard. Read about and understand the actor’s tradecraft. Craft a profile that uses the actor’s indicators. Launch an attack and carry out your assessment. Threat Replication is a way to exercise intrusion response and see how well a security program stands up to these actors.

Pass-the-Golden-Ticket with Cobalt Strike’s Beacon

Back in May, I wrote up some impressions about Meterpreter’s Kiwi extension. It’s Mimikatz 2.0, complete with its ability to generate a Kerberos “Golden Ticket” with domain-admin rights offline.

I’ve had a very positive experience with this capability since May. My best practice is to create a Golden Ticket catalog. When you capture a domain controller, get the krbtgt hash, and store it in this catalog. Keep this catalog for the duration of the engagement.

Golden Ticket Catalog

= Network Name =
1. DOMAIN NAME
2. Domain Administrator User
3. DOMAIN SID
4. krbtgt hash

If someone cleans you out of their systems: just phish another user, use the catalog information to generate a ticket, apply the ticket, and you’re right back at domain admin. It’s nice. The Golden Ticket capability really is a “persistent” attacker’s dream.

This assumes that the network owners don’t follow steps to re-roll the krbtgt user’s password. I suspect this will become part of a post-attack cleanup process, but it’ll take time for this practice to disseminate.

I recommend that you keep a catalog of ticket information over a collection of pre-made tickets. Here’s why: You may create a ticket for a user. If that account gets disabled, the ticket will no longer work. If you end up in this situation–use the net group command to query for the new domain admins and update your catalog accordingly.

To apply a self-generated Kerberos ticket to my current session: I have to either drop something to disk (mimikatz 2.0) or I have to switch to interactive command and control with Meterpreter. Those who’ve worked with me know that I dislike interactive C2. It has its place, but it’s also an opportunity to attract attention from a good network defense team. I’m also not a fan of touching disk–unless I really have to.

So, what does a hacker do when caught between two unlikeable choices? Make a third.

I’ve added support for self-generated Kerberos tickets to Cobalt Strike’s Beacon. Now, you may inject a Golden Ticket into a Beacon session and use it for lateral movement. This is a natural marriage.

Beacon’s lateral movement workflow requires its user to generate an artifact, copy it to a target host, and schedule it to run. I’ve built a minimal set of tools into Beacon (e.g., privilege escalation, token stealing, and now ticket injection) to support this. The rest of these steps happen using native tools on the target’s system. I’m a big fan of doing lateral movement with native tools as it’s less likely to look like hacker activity.

Seriously, if I have to answer for one more service named XtAx754A running a malicious ApacheBench–I’m going to scream!

Here’s a video that shows pass-the-ticket with Cobalt Strike’s Beacon:

If you’re headed to Las Vegas for BlackHat USA or DEF CON–you have an opportunity to hear more on Kerberos abuse at both conferences. Benjamin Delpy and Alva “Skip” Duckwall will deliver Abusing Microsoft Kerberos: Sorry You Guys Don’t Get It at BlackHat USA. Chris Campbell will deliver The Secret Life of KRBTGT at DEF CON. I expect that these talks will give this subject the authoritative treatment and depth it deserves. Be sure to check them out.

Use Cobalt Strike’s Beacon with Veil’s Evasion

The Veil Framework is a collection of  red team tools, focused on evading detection. The Veil Evasion project is a tool to generate artifacts that get past anti-virus. It’s worth getting to know Veil. It has a lot of capability built into it.

Cobalt Strike 2.0’s Payload Generator includes an option to output a Cobalt Strike payload in a format that’s Veil-ready. Go to Attacks -> Packages -> Payload Generator to open it. Choose your listener and set veil as the output type. Save the file it generates.

generator

Now, go to Veil and choose the type of artifact you want to create. Veil will ask if you want to use msfvenom or supply your own shellcode. Select the option to supply your own shellcode. Paste in the contents of the veil file made by Cobalt Strike. Congratulations–you have made a Veil artifact with a Cobalt Strike payload.

Here’s a video that shows this process:

Before Cobalt Strike 2.0, there were ways to deliver Beacon with Veil. Cobalt Strike’s Beacon is compatible with the Metasploit Framework’s reverse_http and reverse_https stagers. You had the option to use the Metasploit Framework’s stagers to deliver Beacon. That said, Cobalt Strike’s Beacon has its own stagers that are not available to the Metasploit Framework. Cobalt Strike’s DNS stager will download Beacon over DNS and inject it into memory. Cobalt Strike’s HTTP/S stagers account for proxy restrictions that other HTTP/S stagers do not. This new option in Cobalt Strike’s Payload Generator lets you use these custom stagers with Veil.

The Access Management Team [Shell Sherpas]

When I participate in an exercise, with multiple target networks and a large red team, I favor splitting the team up into cells. Each cell owns a target network and is responsible for any objectives that must occur in that target network. These cells are supported by an access management team.

The access management team is a global support role and it’s the only team that touches all of the networks. Access managers offer red cells stable access to key assets in their target’s network. This enables on-going post-exploitation. This is their job.

I refer to access managers as shell sherpas, because they protect and herd shells.

In this post, I’d like to offer details on what an access management team does.

Payload Configuration

An access management team has to configure payloads that will walk through whatever static defenses are in play. They take a guess at all of the things the available payloads do, they reason about things that look strange on the wire, and they try to figure out how to adapt the available tools to get around these things.

Some target networks will not require this support. Others will. I see advanced payload configuration (and development) as a specialized skill, one that’s rarely co-equally available to all cells.

[I’m working to make payload modification accessible to non-developers though. I have a prototype language that offers fine-grained control over the indicators and behaviors of my Beacon payload. This will allow access managers to creatively bypass content filters, design communication schemes that blend in with the target’s environment, and exercise a blue team’s attribution process by replicating known malware.]

Manage Callback Infrastructure

Once we have a way out of a network and past static defenses, our second task is to make sure we have survivable communication. This involves diversifying our access and making sure each payload calls back to multiple hosts. If some of our hosts get blocked, it’s nice to know our access can still survive. Better, it’s best to avoid drawing attention to our access where possible. For this, we rely a lot on low and slow beaconing over DNS to maintain a lifeline to a host when no one is using it. As an access management team, we usually setup and manage this callback infrastructure.

Survivable Access

Third, we have to make sure that our payloads live in processes that are survivable. If we know that a defense team is good at host-based anomaly detection, we have to gear up to play in this space. Once we have survivable communication, our next priority is to find a process we can live inside of without drawing too much attention. notepad.exe is not the best option.

Survivable access is an interesting problem and the best answers to it are not always obvious. There’s a tendency to want malware that can survive any scrutiny and stay on any host no matter what. When I wear my access manager hat, I know I don’t have this magical malware. We get creative and think about other ways to survive in a network. We don’t need to survive on each host. We just need a way to regain access to key hosts at will.

On-disk Persistence

Fourth, we have the opportunity to worry about on-disk persistence and how to survive a reboot. This is its own can of worms though. Let’s say we land a user-level access. What do we do with it? We could stick an executable in a startup folder for the current user or schedule a process to kick off when the user is idle. If it’s an exercise, we’re probably dealing with application white-listing, so that won’t work. We could try to schedule a task with a PowerShell one-liner to avoid dropping an artifact. That might work, in some cases. Or… we could try to escalate privileges on the systems we land on. If these systems are a newer patch level of Windows 7 and there is little evidence the system is lived in (e.g., no installed software with configuration issues); our chances to escalate, without 0-day, are probably nil. We can try though. If we do escalate privileges somehow, then we have more options to fortify and secure access on the host.

I’ve participated in a number of exercises, both with and without an access management team concept. The access management team is the keystone of a large-scale red team operation. An access management team takes on tasks that are easy to execute on all networks at once, saving each cell this extra work. The access management team also serves as a clearing house for solutions to problems other teams had to solve. An access management team, given their control of long-haul infrastructure, is also a tool to provide red team leadership a sense of target health/difficulty across the board.

Tradecraft, part 9 discusses red team operations with Cobalt Strike and how a shell sherpa would fit into a team construct.

The Beachhead

I see egress as one of the biggest pains in the offensive space. If your target has zero egress controls—don’t worry about anything I have to say here. If you’re up against a harder target, read on—I think I’m close to cracking this problem.

You need different payloads for different phases of your engagement. I wrote Beacon for the beginning of the assessment. The time when you have a beachhead, but not much else. This is the most vulnerable time for an attacker. If you’re caught here, you have nothing to fall back on. You’re back at the beginning. If you can fortify your access and spread to other systems, you stand a fighting chance to make the network yours.

Beacon is an asynchronous payload that’s designed to call home to multiple hosts. I use asynchronous command and control because it’s harder to detect. Asynchronous command and control means your payload acts like a bot. It phones home every so often, requests tasks, and then goes back to sleep. I phone home to multiple hosts because this is resilient. If one of my callback hosts gets caught, I still have a fighting chance to keep my access.

beachhead

Much like Meterpreter, Beacon is a staged payload. This makes weaponization easier. Stagers are small and there are well set patterns to integrate stagers with different client-side exploits and user driven social engineering packages. The downside of stagers is that they’re fragile. They’re usually written in hand-optimized assembly and they’re optimized for a small size above all else.

The staging process is a vulnerable point for an attacker. I pay attention to this. If I can’t stage my Beacon payload, I’m not going to get very far. Beacon has a resilient DNS TXT record stager. This stager is designed to detect failure and recover from it. The end result is a reliable way to download a payload over DNS and inject it into memory.

Beacon also has a custom HTTP stager. This stager pays attention to the details that I warn about. This stager makes its requests look like they came from Internet Explorer. This is important as most proxy servers have a feature to whitelist which browsers are allowed out. A blank User-Agent doesn’t cut it. Beacon and Meterpreter are both proxy aware. These payloads use WinINet to communicate. This API provides transparent NTLM authentication and it pulls its proxy settings from Internet Explorer.

Automatic NTLM authentication doesn’t do much good against a proxy server that requires something other than domain credentials to get out. Beacon’s HTTP stager detects a proxy authentication error and prompts the user for credentials when it can’t get out. This prompt is the same one Internet Explorer uses. Once the user types their credentials once, the current process is good to egress until it dies.

I worry about networks with tough egress restrictions. It’s not unheard of to isolate workstations or key servers from the internet altogether. Their only channels out are through a proxy server or their local DNS server. Worse, sometimes systems are isolated from the DNS system altogether. They rely on their proxy server to resolve hostnames for them. In these cases, the only direct way out is the proxy server. Eep!

The Beacon stagers I’ve described are enough to get out of a network via DNS or through a tough proxy server. Still, counter-measures exist to defeat my technologies. A proxy server may only allow an application to visit sites that are in a white list. Or, the proxy server may require the user to respond to some sort of challenge before they can access an unknown site. Let’s assume neither of these things are in play.

At this point, we have a foothold, a beacon in our target’s network that phones home over HTTP or DNS. Let’s assume this Beacon is phoning home over DNS.

I’ve built a toolset into Beacon to escalate privileges, steal tokens, and execute commands. These tools allow you to grab an access token and use it to copy a file to another system and schedule it to run. I’ve even built a peer-to-peer Beacon that uses named pipes to communicate and egress through a parent Beacon. You can spread laterally with Beacon without resorting to interactive communication or worrying about egress with the other hosts.

Eventually, you will have multiple equities in your target’s network. At that point, it’s time for some heavy post exploitation. Right now, we’re communicating over DNS and named pipes because we continue to live with tough egress restrictions. How do we get our tools into the target’s network?

Pick a system that you’ve compromised. Pick one that isn’t patient zero (your beachhead). Look to see which processes are running. Do you see a 32-bit Internet Explorer process or a 32-bit Java Updater? Use Beacon’s inject command to inject an HTTP Beacon into that process.

When you inject an HTTP Beacon into a process, the user will see a prompt for the username and password of their restrictive proxy. This assumes a proxy authentication failure happens in the first place. You’re dealing with some strong egress restrictions if this is the case.

The prompt will come from the application that you injected into. If it’s Internet Explorer, the payload should inherit the user’s cached proxy credentials. If it’s the Java Updater, the user will see that the Java Updater is prompting them. Pretty sneaky, right?

When you inject an HTTP Beacon, take care to inject one from another team server. Cobalt Strike is designed to connect to multiple servers and manage them from one client. There’s a reason for this. You want different sets of command and control infrastructure for different phases of your engagement. When you’re ready to do noisy post-exploitation, you want to spawn accesses to alternate infrastructure. If the alternate infrastructure gets caught, it doesn’t blow the access you’ve worked to gain in your target’s network.

Once we get an HTTP Beacon on an alternate team server, we’re ready for post-exploitation. Since we’re here to do heavy lifting, we want to bring Meterpreter and other tools into this environment. Speed up Beacon’s communication with the command sleep 0. Then, request a meterpreter session, tunneled through Beacon: type meterpreter and press enter. When the Beacon checks in next, its communication will speed up and in approximately ten seconds—we will have a Meterpreter session.

Our current Meterpreter session exists because it’s tunneled through our Beacon. A lot of Metasploit Framework post exploitation actions create new Meterpreter sessions. If we can’t get these sessions out, we’re dead in the water. Not to worry though.

Cobalt Strike exposes obscure Metasploit functionality that forces a payload handler to set up a port forward on a host with a Meterpreter session. In Cobalt Strike, I call this a pivot listener. It’s a reverse listener that connects to you through a Meterpreter session. Right-click a host, go to Meterpreter -> Pivoting -> Listener… to set one up.

Once you have a pivot listener, the world opens up. Now you can run bypassuac, current_user_psexec, and other Metasploit Framework modules that allow you to escalate and expand your access. When you need to spawn a new session—point the module to your pivot listener. Pivot listeners are integrated into Cobalt Strike’s workflow the same way Beacon is.

At this point, all of the actions you take have a path out to the internet—through your Meterpreter session tunneled through an HTTP Beacon.

Once you get a beachhead, your first job is create a safe channel out of your target’s network. Once you have that channel, the next job is to spread to other systems. You don’t need to take the whole network at this point. Your goal is multiple systems that you may use as beachheads if one gets caught. Once your position is safe, then comes the heavy post-exploitation. I’ve discussed how Meterpreter can tunnel through Beacon to benefit from some of the extra features to defeat tough egress restrictions. With pivot listeners, you gain the freedom to work in your target’s network as if the egress restrictions didn’t exist at all.

Yes, there’s a method to all of this madness.

Covert Lateral Movement with High-Latency C&C

High latency communication allows you to conduct operations on your target’s network, without detection, for a long time. An example of high-latency communication is a bot that phones home to an attacker’s web server to request instructions once each day.

High latency communication is common with advanced threat malware. It’s not common in penetration testing tools. I designed Cobalt Strike’s Beacon to provide penetration testers with a robust payload for high-latency communication. Today, you can conduct much of your engagement through Beacon.

In this post, I’ll show you how to abuse trust relationships to move laterally with Beacon. You will learn how to find targets with built-in Windows commands, escalate privileges, impersonate access tokens, and use the rights a token holds to run code on a remote system. I’ll show you how to carry out each of these steps from a Beacon configured with a high sleep time.

Reconnaissance

Beacon’s shell command will run a command on a host and post its output back to you. You can do a lot with this command alone. For example, to find out which domain you’re on:

shell net view /DOMAIN

To see Windows hosts on the same domain with some sort of sharing enabled, use:

shell net view /DOMAIN:domain

At this point, we have a few targets to work with. The next step is to check if the current user is a local administrator on any of these systems. To check your rights, try to access an admin-only share on a target host:

shell dir \\host\C$

If you get a directory listing, then your user is a local admin. You’re ready to get code execution.

Privilege Escalation

If your current user isn’t a local admin on a target system, then you will need to escalate your privileges to go further. To start this process, I like to use whoami /groups to find out which groups my current user is in. You can do this with the shell command too.

shell whoami /groups

If I’m living in a standard user context (a medium integrity process), but my user is a local admin on the current host—there’s an opportunity to escalate. Beacon includes its own version of the bypassuac attack that’s built for this situation. Bypass UAC elevates you from a medium integrity context to a high integrity context. The command to do this in Beacon is bypassuac.

bypassuac beacon listener

At this point, you will get a new Beacon. If all went well, this Beacon will show a * next to the username. This * is Beacon’s way to tell you that it’s running in a high integrity context. Remote Access Tools built for an XP world tend to omit this information. On a modern target, you have to know whether you’re in a high or medium integrity process.

Token Stealing

Now that we’re in a high integrity process, we can look for tokens to steal. An access token is a data structure that tracks the user’s rights and, if applicable, other information needed for single sign-on to work. There are different types of tokens, but I’d like to call your attention to impersonation and delegation tokens. An impersonation token allows a process or thread to carry out actions as the identified user on the current system. A delegation token allows a process or thread to carry out actions as the identified user on remote systems on the same domain.

We will use Beacon to steal a token from a process. Run the tasklist program to list processes on the system:

shell tasklist /v

Each process will have a user associated with it. If you see a process run by another domain user, use Beacon’s steal_token command to impersonate that token.

steal_token pid

You may now execute commands with the security context of the stolen token. Try to see if the impersonated user is a local admin on other systems within your reach. If the user is an admin elsewhere, we’re in luck and we can try to get code execution.

Generate Artifact

How do we get code execution on a remote host? Copy a file to the remote host and schedule it to run. These steps raise a question though. What do we want to copy and run? You could export an executable for Beacon that talks to your command and control server. I will caution you against this though.

As an attacker, you do not want every compromised system to call home to your command and control infrastructure on the internet. Some hosts can’t talk out to the internet. Other hosts (e.g., domain controllers) may get more attention from a network security monitoring team.

Not all Beacons have to connect to the internet. You may link Beacons together in a way that allows each Beacon to get its tasks and send output through its parent Beacon. Cobalt Strike’s Beacon uses named pipes to do this.

If you want to stay quiet, I recommend that you export a fully staged SMB Beacon and copy it to your target’s host and schedule it to run. A staged artifact is beneficial as it does not need to connect to us over the internet to download the rest of itself. Go to Attacks -> Packages -> Windows Executable (S) to export a fully staged Beacon. Choose the SMB Beacon as your Beacon type and select the type of output you would like. You may export a (staged) Beacon as a PowerShell script, DLL, executable, or Windows service executable. Press Launch and save the artifact.

File Copy

To copy a file, change Beacon’s current working directory to a folder that you can write to. If you’re a local admin in a high integrity context, try c:\windows\temp.

Use Beacon’s cd command to change the current directory:

cd c:\windows\temp

Use Beacon’s upload command to select a file from your local system and upload it to the current directory:

upload

To copy the uploaded file to the remote system, use the shell command. This command will copy foobar.exe to c:\windows\temp on the remote host.

shell copy foobar.exe \\host\C$\windows\temp

Beacon queues its commands. If you have a high sleep time, don’t worry about typing one command at a time and waiting for output. Issue every command that you can think of. When Beacon checks in next, it will grab its tasking, execute the actions you gave it, and show the output to you.

Remote Code Execution

We need to to run foobar.exe on our target. There are many ways to do this. Here are four methods that I recommend that you learn about.

#1: WMIC

You may use wmic to run a process on a remote host. Here’s the syntax to do it:

shell wmic /node:host process call create “c:\windows\temp\foobar.exe

#2: AT

You may also schedule a program to run with at. The at command is deprecated by Windows 8. You will not be able to use this option from or against a Windows 8 target. That said, the syntax for this option is easy to remember.

First, find out what time it is on the remote system:

shell net time \\host

Next, use at to schedule foobar.exe to run sometime in the near future.

shell at \\host HH:MM c:\windows\temp\foobar.exe

#3: SCHTASKS

Another option to run code on a target system is schtasks. The syntax for schtasks is a little more complicated, but why not:

shell schtasks /create /tn foobar /tr c:\windows\temp\foobar.exe /sc once /st 00:00
           /S host /RU System
shell schtasks /run /tn foobar /S host

You should clean up your task after it executes. Here’s the syntax to do that:

shell schtasks /F /delete /tn foobar /S host

#4: SC

A fourth option to execute a program on a remote host is to create a service and start it. You may use the sc command to do this:

shell sc \\host create foobar binpath= “c:\windows\temp\foobar.exe”
shell sc \\host start foobar

The sc command requires an executable that responds to Service Control Manager commands. If you do not provide such an executable, your program will run, and then immediately exit. Cobalt Strike’s dialog to generate a staged executable gives you the option to generate a Service Executable. Make sure you pay attention to this detail.

Here’s the syntax to delete your service after it runs:

shell sc \\host delete foobar

Establish Control

Once an SMB Beacon is run on a remote system, you may gain control of it with Beacon’s link command. From Beacon, use:

link host

This command will instruct the current Beacon to link to the remote Beacon over the SMB protocol. You will see a new Beacon show up in the Beacon console with the parent Beacon listed as its external address. From here, you may repeat this entire process. Look for tokens, impersonate them, see where you’re an administrator, and try to take those systems. That’s it.

Part 7 of Cobalt Strike’s Tradecraft course covers lateral movement as well.

User Account Control – What Penetration Testers Should Know

UAC is User Account Control. Introduced in Windows Vista, UAC is a collection of technologies that make it convenient possible to use Windows without administrator privileges and elevate your rights when needed. UAC has a lot of moving parts and encompasses a lot of things.

This post focuses on Windows Integrity levels and UAC elevation prompts. I will first explain some UAC concepts and then dive into three attacks to get past UAC.

Process Integrity Levels

In Windows Vista and later, processes run at three different levels of integrity: high, medium, and low. A high integrity process has administrator rights. A medium integrity process is one that runs with standard user rights. A low integrity process is very restricted.

A low integrity process can not write to the registry and it’s limited from writing to most locations in the current user’s profile. Protected Mode Internet Explorer runs with low integrity. The idea is to limit the amount of damage an attacker may do if they exploit the browser.

Most desktop applications run in a medium integrity process, even if the current user is a local administrator. Use Process Explorer to see which Integrity level your programs are running at.

procexp

UAC Settings

To perform a privileged action, a program must run another program and request the high integrity level at that time. If the user is an administrator, what happens next will depend on their UAC settings. There are four UAC settings:

Always Notify. This setting is the highest UAC setting. It will prompt the user when any program, including a built-in Windows program wants higher privileges.

Notify me only when programs try to make changes to my computer. This is the default UAC setting. This setting does not prompt the user when some built-in Windows program want higher privileges. It will prompt the user when any other program wants higher privileges. This distinction is important and it plays into the UAC bypass attack that we will cover in a moment.

Notify me only when programs try to make changes to my computer (do not dim my desktop). This is the same as the default setting, except the user’s desktop does not dim when the UAC elevation prompt comes up. This setting exists for computers that lack the computing power to dim the desktop and show a dialog on top of it.

Never notify. This option takes us back to life before Windows Vista. On Windows 7, if a user is an administrator, all of their programs will run with high integrity. On Windows 8, programs run at the medium integrity level, but anything run by an Administrator that requests elevated rights gets them without a prompt.

If the user is not an administrator, they will see a prompt that asks for the username and password of a privileged user when a program tries to elevate. Microsoft calls this “over the shoulder” elevation as someone is, presumably, standing over the shoulder of the user and typing in their password. If the UAC settings are set to Never Notify, the system will automatically deny any requests to elevate.

Who Am I?

When I get a foothold from a client-side attack, I have a few questions I like to answer right away. First, I like to know which user I’m currently executing code as. Second, I like to know which rights I have. With UAC this becomes especially complicated.

One way I like to sort myself out is with the Windows command: whoami /groups.

This command will print which groups my current user belongs to.

This command will also print which integrity level my command ran with. If my command ran in a high integrity context, I will see the group Mandatory Label\High Mandatory Level. This means I have administrator rights.

17.26.20 cmd_exe_2320_2

If my command ran in a medium integrity context, I will see the group Mandatory Label\Medium Mandatory Level. This means I have standard user rights.

17.26.31 cmd_exe_3588_1

RunAs

If I find myself in a medium integrity process run by a user in an administrators group, there is potential to elevate from standard user rights to administrator user rights. One option is to use the ShellExecute function with the runas verb. This will run a program and request elevated rights.

If UAC is set to anything other than Never Notify, the user will see a prompt that asks them if they would like to allow the action to happen. This is not completely implausible. Oracle’s Java Updater randomly prompts me all of the time.

The Metasploit Framework’s exploit/windows/local/ask module by mubix implements this attack for you. Make sure you set EXE::Custom to avoid anti-virus!

javaupdater

If the user accepts the prompt, the system will run my program in a high integrity context. Remember, medium integrity is standard user rights. High integrity is administrator rights and this is what we’re after.

Bypass UAC

The RunAs option prompts the user and that’s an opportunity to get caught. We want a way to spawn a high integrity process from a medium integrity process without a prompt. Fortunately, there is a way to do this, it’s the bypass UAC attack.

This attack comes from Leo Davidson who made a proof-of-concept for it in 2009. David Kennedy and Kevin Mitnick popularized this attack in a 2011 DerbyCon talk. They also released the exploit/windows/local/bypassuac Metasploit Framework module that uses Leo’s proof-of-concept for the heavy lifting.

The bypass UAC attack requires that UAC is set to the default Notify me only when programs try to make changes to my computer. If UAC is set to Always Notify, this attack will not work. This attack also requires that our current user is in an administrators group.

Bypass UAC: How It Works

This is a fascinating attack whose inner workings are taken for granted. Please allow me the blog space to describe it in depth:

Our story starts with COM, the Component Object Model in Windows. COM is a way of writing components that other programs may use and re-use. One of the benefits of COM is that it’s language neutral. I find it extremely complicated and unappealing to work with. I suspect others share my feelings.

Some COM objects automatically elevate themselves to a high integrity context when run from a program signed with Microsoft’s code signing certificate. If the same COM object is instantiated from a program that was not signed by Microsoft, it runs with the same integrity as the current process.

The COM distinction between Microsoft and non-Microsoft programs has little meaning though. I can’t create a COM object in a high integrity context  because my programs are not signed with Microsoft’s certificate. I can spawn a Microsoft-signed program (e.g., notepad.exe) and inject a DLL into it though. From this DLL, I may instantiate a self-elevating COM object of my choice. When this COM object performs an action, it will do so from a high integrity context.

Leo’s Bypass UAC attack creates an instance of the IFileOperation COM object. This object has methods to copy and delete files on the system. Run from a high integrity context, this object allows us to perform a privileged file copy to any location on the system.

We’re not done yet! We need to go from a privileged file copy to code execution in a high integrity process. Before we can make this leap, I need to discuss another Windows 7 fun fact.

Earlier, we went over the different UAC settings. The default UAC setting will not prompt the user when some built-in Windows programs try to elevate themselves. More practically, this means that some built-in Windows programs always run in a high integrity context.

These programs that automatically elevate have a few properties. They are signed with Microsoft’s code signing certificate. They are located in a “secure” folder (e.g., c:\windows\system32). And, they request the right to autoElevate in their manifest.

We can find which programs autoElevate themselves with a little strings magic:

cd c:\windows\
strings –s *.exe | findstr /i autoelevate

Now, we know which programs automatically run in a high integrity context AND we have the ability to perform an arbitrary copy on the file system. How do we get code execution?

We get code execution through DLL search order hijacking. The public versions of the bypass UAC attack copy a CRYPTBASE.dll file to c:\windows\system32\sysprep and run c:\windows\system32\sysprep.exe. When sysprep.exe runs it will search for CRYPTBASE.dll and find the malicious one first.

Because sysprep.exe automatically runs in a high integrity context (when UAC is set to default), the code in the attacker controlled CRYPTBASE.dll will execute in this high integrity context too. From there, we’re free to do whatever we like. We have our administrator privileges.

Holy Forensic Artifacts Batman!

I mentioned earlier that the Metasploit Framework’s bypassuac module uses Leo Davidson’s proof-of-concept. This module drops several files to disk. It uses Leo’s bypassuac-x86.exe (and bypassuac-x64.exe) to perform the privileged file copy from a medium integrity context. It also drops a CRYPTBASE.dll file to disk and  the executable we want to run.

This module, when run, also creates a tior.exe and several w7e_*.tmp files in the user’s temp folder. I have no idea what the purpose of these files are.

When you use this module, you control the executable to run through the EXE::Custom option. The other artifacts are put on disk without obfuscation. For a long time, these other artifacts were caught by anti-virus products. A recent commit to the Metasploit Framework strips several debug and logging messages from these artifacts. This helps them get past the ire of anti-virus, for now.

bewareav

A better approach is to use a module that has as little on-disk footprint as possible. Fortunately, Metasploit contributor Ben Campbell (aka Meatballs) is here to save the day. A recent addition to the Metasploit Framework is the exploit/windows/local/bypassuac_inject module.  This module compiles the UAC bypass logic into a reflective DLL. It spawns a Microsoft-signed program and injects the UAC bypass logic directly into it. The only thing that needs to touch disk is the CRYPTBASE.dll file.

Bypass UAC on Windows 8.1

In this post, I’ve focused heavily on Windows 7. Leo’s proof-of-concept and the bypassuac modules in the Metasploit Framework do not work on Windows 8.1. This is because the DLL hijacking opportunity against sysprep.exe does not work in Windows 8.1. The Bypass UAC attack is still possible though.

A few releases ago, I added bypassuac to Cobalt Strike’s Beacon. I do not invest in short-term features, so I had to convince myself that this attack had a viable future. I audited all of the autoElevate programs on a stock Windows 8.1 to find another DLL hijacking opportunity. I had to find a program that would load my DLL before displaying anything to the user. There were quite a few false starts. In the end, I found my candidate.

Beacon’s Bypass UAC command is similar to Ben Campbell’s, it performs all of the UAC bypass logic in memory. Beacon’s UAC bypass also generates an anti-virus safe DLL from Cobalt Strike’s Artifact Kit. Beacon’s UAC bypass checks the system it’s running on too. If it’s Windows 7, Beacon uses sysprep.exe to get code execution in a high integrity context. If it’s Windows 8, it uses another opportunity.

If you’re having trouble with the alternatives, Beacon’s version of this attack is an option.

Bypass UAC on Windows Vista

The Bypass UAC attack does not work on Windows Vista. In Windows Vista, the user has to acknowledge every privileged action. This is the same as the Always Notify option in Windows 7 and later. The UAC settings in Windows 7 came about because UAC became a symbol of what was “wrong” with Windows Vista. Microsoft created UAC settings and made some of their built-in programs auto-elevate by default to prompt the user less often. These changes for user convenience created the loophole described in this post.

Lateral Movement and UAC

The concept of process integrity level only applies to the current system. When you interact with a network resource, your access token is all that matters. If your current user is a domain user and your domain user is a local administrator on another system, you can get past UAC. Here’s how this works:

You may use your token to interact with another system as an administrator. This means you may copy an executable to that other system and schedule it to run. If you get access to another system this way, you may repeat the same process to regain access to your current system with full rights.

You may use the Metasploit Framework’s exploit/windows/local/current_user_psexec to do this.

Summary

These UAC bypass attacks are among my favorite hacker techniques. They’re a favorite because they take advantage of a design loophole rather than a fixed-with-the-next-update memory corruption flaw. In theory, we will have these attacks for a long time.


Interested in Trying Cobalt Strike?

REQUEST A QUOTE

CCDC Red Teams: Ten Tips to Maximize Success

The CCDC season is upon us. This is the time of year when professionals with many years of industry experience “volunteer” to hack against college students who must defend computer networks riddled with security holes.

For the second year, my company is making Cobalt Strike available to members of the National CCDC and Regional CCDC red teams. In this post, I’d like to share a few tips for red team members who plan to use Cobalt Strike at their event.

0x01: Learn how to use Cobalt Strike

Most offensive security professionals are instantly productive with Cobalt Strike. It leverages the Metasploit Framework, which most CCDC red teamers have had some exposure to. Cobalt Strike builds on Armitage which has a positive reputation for ease of use.

These things are deceptive though. Cobalt Strike is built for power users and it has a lot of depth. To get the most from the tool, it really requires some time spent to learn how to use it. You could stop reading now and sum up this post as “read the manual” and “learn to use the tool” before hand.

I publish all of my company’s training, for free, on the Cobalt Strike website. This is a great way to get a start with the tool. I will also mail a DVD with penetration testing labs to any CCDC red team member that asks for one (the announcement sent to the red teams has the link to request one).

0x02: Have a persistence strategy

Cobalt Strike does not ship with a persistence kit. Once you get on a system, you will need a strategy to fortify your access. If you do not persist, students will kick you out with the next reboot and likely, you’ll find it hard or impossible to get back in.

Good persistence is hard. It’s easy to make a mistake with a persistence mechanism. If you persist in a way that does not work, expect to spend most of your CCDC event without access.

Cobalt Strike’s scripting language, Cortana, is an opportunity to automate your persistence. This is a task that also makes sense for a local Metasploit module. Either way you go–make sure you prepare and test something before the event. Dirty Red Team Tricks I and II at DerbyCon both address past persistence strategies for CCDC.

0x03: Learn to use Beacon

Beacon is the star feature in Cobalt Strike. I built it to provide a low and slow lifeline to spawn Meterpreter sessions, as needed. It’s grown far beyond this original task. You can use Beacon to pivot into a network, to conduct post-exploitation on a host, and even as a named-pipe backdoor that you can use and re-use at will.

Spawning new sessions with Beacon is easy. Someone who has never seen Cobalt Strike or Beacon can understand how to do it after thirty seconds of training. The other use cases are power user features and require time spent with the tool and its documentation to take advantage of. Imagine sitting in front of a meterpreter> prompt for the first time. How to get the most out of the tool isn’t intuitive. It’s the same with Beacon.

0x04: Learn to Setup Beacon Infrastructure

Beacon is a multi-protocol remote access tool. It speaks HTTP, DNS A records, DNS TXT records, and it talks over SMB named pipes. There’s a time and place for each of these features (or they wouldn’t exist). If you use Beacon to egress a compromised network, you will want to set up infrastructure to receive your connections.

Let’s start with Beacon’s HTTP mode. Sure, you can configure Beacon to call home to your IP address. A few clicks and it’s setup. If you want to make your Beacon resilient to blocks and harder to detect–you will want it to call home to multiple IP addresses. In a CCDC environment, you can bind multiple IP addresses to a system and tell Beacon to use them. If your event has internet access, you can set up “redirectors” in Amazon’s EC2 to act as a proxy between your Cobalt Strike system and your blue networks. Either way, multiple addresses are a must.

DNS Beacon requires some setup as well. You need to own several domains and understand DNS well enough to delegate these domains or sub-domains to your Cobalt Strike system. DNS Beacon also has its nuances. By default, it stages over HTTP, but it is also possible to stage DNS Beacon over (go figure) DNS. The Beacon lecture in the Tradecraft course dives deep into how to set this up.

DNS Beacon is amazing for long-haul low and slow command and control. It’s very survivable and few blue teams look for abuse of DNS. If you’re not using this, you’re missing out on a great tool to challenge the strongest blue teams.

0x05: Plan an opening salvo

The best time to get access at a CCDC event is in the beginning, when the systems are most vulnerable. I don’t pre-script an opening salvo anymore. I do it by hand. Here’s my process to hook all Windows systems:

I run a quick nmap scan for port 445 only. I do db_nmap –sV –O –T4 –min-hostgroup 96 –p 445 [student ranges here]. I have this command pasted into a window and I press enter the moment I hear the word go.

Once the scan complete I highlight all hosts in the Cobalt Strike table view (Ctrl+A). If I know the default credentials, I launch psexec against all of the hosts.

If I don’t know the default credentials, I launch ms08_067_netapi. Once I get my first session, I run mimikatz to get the default credentials and I launch psexec against all of the hosts again.

These steps are simple enough that I can do them by hand. Doing these steps by hand also gives me flexibility to adapt, if I quickly notice something isn’t working.

I recommend that the red team lead designate someone to go through these steps. This same person should have a script ready to install persistence on the Windows hosts that they get access too. Ideally, you should have a similar process for the *NIX side too.

0x06: Decide how you want to organize your red team

What kind of experience do you want the students to get at your CCDC event? This question will drive how you organize your red team.

Do you want the students to experience a variety of attacks against all aspects of the networks they must defend? If so, I would organize your red team by function. Have a team that’s going after websites. Have a team that’s attacking Windows systems. Have another team that’s attacking wireless stuff.

Do you want the students to gain experience hunting a well embedded adversary? I would split your red team up into cells that each focus on an individual blue team. These teams will focus on maintaining access to blue systems and, in sync with the other cells, occasionally causing something catastrophic to happen (e.g., putting customer credit card information on the company’s website).

This model works well when each red cell has the support of one global cell in charge of an opening salvo and persistence. This way all teams are compromised the same way and each cell has a fallback to regain access to a network if they need it.

This model also solves another critical issue: feedback. If two red team members focus on one blue team, they will become an expert in that team’s strengths and weaknesses. At the end of the event, you can send your red team members out to their blue team for a very educational dialog.

It’s important to have a model in mind. Without a model, the red team will devolve into organized chaos with ad-hoc cells chasing targets of opportunity rather than deliberate actions that create educational value for the students.

0x07: Build infrastructure to support your red team’s organization

Once you decide how you will organize your red team, make sure you have infrastructure setup to support it. Cobalt Strike’s team servers are a convenient way to share access to systems and networks. This isn’t the whole picture though.

Your team will need a way to exchange information in real-time. Cobalt Strike’s team server has a chatroom, but in all the events I go to, I have never seen the Cobalt Strike (or Armitage) chatroom become the primary place to exchange information. IRC and Etherpad both work well for this purpose.

When you setup Cobalt Strike’s team servers, make sure you have enough to support your model. If you choose to organize your red team into cells that each focus on a blue team, have one team server per blue team. Also, provide your global access management team with two team servers to manage persistent Beacons through.

Whatever you do, do not run all red team activity through one team server.

0x08: Have a backup plan for persistence

I mentioned earlier that you should have a persistence plan. Whatever your plan is, it probably isn’t enough. Create a backup persistence plan. It’s dangerous to rely on one tool or method to stay inside of ten very closely watched networks.

I like configuration backdoors for persistence, a lot. These backdoors work, especially well, if you never have to use them. If you don’t use something, a blue team doesn’t get a hint that leads them to it.

If someone on your team is familiar with another persistent agent (or they wrote one)–move them to the persistence/access management cell and have them manage it for all of the blue teams.

A persistence plan that consists of Beacon, a few choice configuration changes, and an alternate agent is very robust.

0x09: Learn to pass sessions and connect to multiple servers

Distributed Operations is one of three force multipliers for red team operations. In February 2013, Cobalt Strike gained a way to manage multiple team servers from one client. The idea is this:

One Cobalt Strike client can connect to multiple team servers. Switching between active servers is easy. When the client tries to pass a session or task a Beacon, it sees listeners from all of the servers it has a connection to.

This simple concept makes it possible for cells on a red team to overlap and work with each other. For example, let’s say my job is access management and persistence. I have low and slow Beacons for all Windows systems at my disposal. If a cell needs a session from me, I connect to their team server (or perhaps, I was already on it) and I simply task the appropriate Beacons to send a session to the listener that they setup. That’s it.

Tradecraft, lecture 9, talks about the mechanics of session passing and distributed ops in detail.

0x0A: Learn how to interoperate between Cobalt Strike and non-Cobalt Strike users

If you run a red team–I do not recommend that you force-feed one toolset to your team. If you want to do this, do it with a toolset other than mine. It’s possible to derive 95% of Cobalt Strike’s sharing and distribution benefits–even if some red teamers don’t use Cobalt Strike.

To share network footholds, become familiar with how to set up a Metasploit and Beacon SOCKS server. These SOCKS servers will allow someone else on your red team to tunnel their tools into your network. They can do it through the Proxies option in Metasploit or with the proxychains command on Linux.

You may also pass accesses to another Metasploit user with great ease. The way to do this is hacky, but it works. Create a dummy team server and connect to it. On this team server, create listeners with host, port, and payload values that match payload handlers that your other teammates use. The team server will start a handler for the listener you define, but, when you task it–the session will go to the teammate not using Cobalt Strike.

The Key Ingredients

Despite the joke in the opening paragraph, CCDC is hard. It’s easy to get into networks early on. It’s hard to stay in those networks and challenge the student teams throughout the event.

In this post, I brought up a number of things to consider for red team success at a CCDC event. With or without Cobalt Strike, a successful engagement requires a strategy and an active commitment to prepare for and follow through on that strategy. I hope these tips will help you prepare for your event.

Good luck!