March and April are CCDC season. This is the time of the year when teams of college students get to compete against each other as they operate and defend a representative enterprise network from a professional red team.

CCDC events are the most interesting for the blue teams and red teams when the red team plays the role of an embedded attacker. Getting embedded into student networks doesn’t come for free though. Most CCDC events do not allow the red team to touch the networks before the students do. Often times, the students and the red team get access to the networks at the same time. Here’s a clip from one of the regional events last year:

Once the event starts, the first minutes are critical. To ensure a good competition, the red team needs to discover the vulnerable systems (or find out the default credentials), get access to these systems, and install persistence on them. These actions have to happen across 10+ networks and they have to happen before the student teams take their vulnerable systems off of the network for hardening.

I’ve seen events where the above goes off without a hitch. I’ve seen events where disaster struck right away. Last year at National CCDC, the hotel staff plugged a mini-fridge into the red team’s circuit at the start of the event. We lost all power and had a good five to ten minute setback because of it.

I’ve also seen scripts fail causing each individual red team member to scramble, gain what access they can, and try to persist or do anything they possibly can in those critical minutes.

I used to rely on scripts to scan for systems, exploit them, and install persistence. Sometimes these scripts would work great. Other times I’d miss a detail and squander the precious starting minutes troubleshooting the script. Now, I do many things by hand, but still try to stay efficient.

Here’s my process:

To quickly discover interesting hosts in a CCDC event, I run an nmap scan for two ports: 445 and 22. I setup my command to run this scan and wait until the red team lead yells go to press enter.

db_nmap -sV -O -T4 -p 22,445 [student ranges here]

Once the scan completes, the Metasploit Framework will import the results into its database. In Cobalt Strike, these hosts will show in the target area at the top of the tool. I almost always work with the table view at a CCDC event. To do this, go to Cobalt Strike -> Set Target View -> Table View.

From the table view, I can sort my discovered hosts by any of the columns. The far left column is the operating system icon. If you sort by this column, you will find that like-operating systems are now sorted together. This makes mass exploitation, without a script, rather easy.

To mass exploit the UNIX systems, I simply highlight all like UNIX systems in the interface. I right-click, go to Login -> SSH. I then put in what I think are the default credentials. The launch button will launch the Metasploit Framework’s ssh_login module against all highlighted hosts.

One pro-tip: hold down shift when you click Launch. Cobalt Strike will keep the dialog open allowing you to quickly try another username and password combination. I repeat this process until something works.

To mass exploit Windows systems, I do the same thing, except I use psexec to get my Windows accesses. When you launch psexec in Cobalt Strike, I recommend that you set it up to deliver a Beacon payload. This is Cobalt Strike’s asynchronous payload and it’s very resilient to network latency and other interruptions. You will have no shortage of either of these in the beginning of a CCDC event.

Now at this point, you should have access to some Windows and UNIX systems on all teams. The next task is to lay down persistence on these systems. This is the part I script with Cortana.

UNIX systems are easy to work with in Cortana. Cortana provides functions to issue commands and upload files through a shell. When I built these functions, I did my best to make sure each command happens in order before proceeding on to the next step. UNIX persistence scripted with these commands tends to work reliably. To build UNIX persistence scripts and backdoor droppers, I borrow heavily from int128’s infect.cna script.

What about Windows persistence? This is a sad tale of woe. In 2012 and 2013, I would use Cortana to script my Windows persistence through Meterpreter. Last year, Meterpreter would consistently crash when I issued all of my persistence commands to it. Stuck in a pickle, I put together an emergency API to automate a few things in Beacon. This API isn’t a substitute for a real Beacon scripting API (it’s coming!), but it worked in a pinch.

This emergency API allows a script to task Beacon to execute commands, upload files, and timestomp files. Beacon executes each of its task in one thread and it doesn’t move on to the next task until the previous task has had reasonable time to complete. This makes it easy to build a very reliable persistence script through Beacon. I wrote a blog post on this emergency API two weeks ago.

Another key to success is good infrastructure. I never know what to expect at a CCDC event. If the event is isolated from the internet, I make do with binding multiple IP addresses to my team server Linux boxes in red space. If the competition systems have internet access, I leverage Amazon’s EC2 quite heavily. I’ve seen some teams, knowing this factoid, block all of Amazon’s space. I think this is outside the spirit of the competition, but that’s white cell’s call and not mine. When I setup infrastructure in EC2, I tend to follow the team server organization scheme described in my infrastructure for on-going red team operations post.

And, that’s the process I use. If you’re curious about what the first hour looks like on my end, here’s my screen recording from RIT SPARSA’s ISTS event two weeks ago. In it, you’ll see the opening salvo and then my process to account for accesses, fix my scripts on the fly, and work to get into systems that I wasn’t able to get access to initially.

I’ll close this blog post with one question: should it be this way? CCDC and other events like it usually give students dated operating systems to allow the red team an easy foothold. Outside of this community, I’ve seen events where blue players defend larger networks with modern operating systems and pre-existing defenses in place. In these scenarios, the red team pre-seeds their access or relies on a click from a “user” who has access to the target’s environment. We use the access we have to play the role of an embedded attacker and execute actions or capture flags that satisfy blue training requirements. The blue teams work to detect, understand, and mitigate our activity. These types of games exercise blue team work, technical skills, and analysis in a security operations context. When I think about how I’d like to see CCDC evolve, this is a model I’m favorable to. What’s the right way forward? I’m not certain, but so long as CCDC and events like it continue to motivate students to practice critical security skills, I’m happy to work with the current model.