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!