I will initially focus on the Rules and Team Packet, before pivoting to some "Insider Baseball" knowledge I have from being on the other side of the fence, that I wish I had as a competitor. Note that this is going to be coming mostly from the perspective of Minnesota State and Midwest Regionals, as I have no experience at the National level of competition... Yet. If you want to read the rest of the articles, click here.

Competition Rules - Abridged

Note that I am covering the 2024 rules as defined by National CCDC. I will summarize them here, but please read the full list.

Eligibility

A full time student who has not competed in the competition for more than 5 years. You can only participate at 1 school at a time.

Team Composition

Teams consist of 12 students total, plus a staff coach. 8 of those 12 students can be participating in competition at any time, and 2 of them can be grad students. The next term thrown around is is for Team Representatives. This will almost always be your coach.

Code of Conduct - Abridged

1. Don't be an ass, behave yourself. It's not hard.
2. Let White Team into your room when needed.
3. Don't touch hardware (or mess with cloud services you aren't allowed to).
4. Don't steal from the competition rooms.
5. Don't use an outside person to help in the competition.
6. You can bring in printed reference material.
7. Don't talk Red Team during the competition.
8. Don't attack anything that isn't yours.
9. Active response to attacks is cool, but if it breaks something it's on you.
10. If you have questions, bring them to White Team.

Internet Usage Guidelines - Abridged

1. Public internet resources are okay to use!
2. Private (paid, authenticated, etc) internet resources are a no go.
   1. P2P is also not allowed.
3. Scripting is allowed! (biggest change since I competed.)
   1. So long as it was available for 3 months prior to the start of the CCDC season.
   2. No modifications starting from 30 days prior to the start of the season, through the end of your season.
   3. Will be shared with other teams.

Team Packet

Now, I am going to skip the admin paperwork stuff that needs to be filed with the good folks at the CCDC organization, but Team Captains and Coaches should know what needs to be done there. In the Midwest, the competition season starts in the fall, with an invitational competition in November, followed by a state competition in late January into February, Regionals in March and Nationals in April.

Prior to the competition, you will receive a Team Packet. Read this, become intimately familiar with it, print it out, sleep with it under your pillow, whatever you need to do. Know it well and plan around it. You should also receive access to the environment prior to competition day. I cannot stress enough how important it is to use that time to enumerate the weird and develop a plan. More to come in a future post on practice strategy. Here is the Team Packet from 2019 Midwest Regionals. There will be some pictures of the 2023 Minnesota/Indiana State Competition and 2020 Regional Competition thrown in there for comparison purposes.

Topologies

Depending on which competition you are in, you will have some changes to the scope and scale of the environment. The higher the level of the competition, the more complicated the environment becomes. So for example, the 2023 Minnesota state competition.

And here is the regional CCDC Environment for Midwest in 2019.

And finally, the environment of the 2020 Midwest Regional competition. My apologies for the poor resolution of the image, it's the best one I still have.

So, if you note that there are more services in both of the Regional environments as compared to the state level ones. In 2020, the environment was roughly double the size of the 2019 Regional competition. The Regional environments also contained hardware devices such as Cisco switches and physical VMware ESXi boxes. I also remember that we had significantly less time beforehand in the environment to practice for the regional competition than we did for state, so you will want to ensure that you can collect information quickly. Additionally, we noticed that the Regional competition has systems that are significantly more broken, and you even had to stand up a new scored system mid-competition via inject. More to come on injects.

Scoring

Scoring is a lot more straightforward than it shows in the Team Packet. It's ~40% uptime, ~40% Inject scoring, and ~20% Red Team activities. I think this is something that the competition organizers need to better communicate, but I think they are vague in order to allow wiggle room in case there are exceptionally bad Inject responses or something. Red Team scoring is also weighted relative to the other teams in your competition. In situations like Minnesota and Indiana, where the same Red Team is hitting both competitions at the same time, the relative weights are applied per state. So, if we have a team in Indiana that does a really good job at keeping Red Team out, but Minnesota does generally poorer across the board, scoring does not punish the Minnesota teams based on Indiana's performance. Keep in mind that incident reports come back to Red Team and if they are good, we will award half the lost points back. More on that coming in a future post too.

Another thing to note is that as you continue up the competition ranks, the scoring criteria changes, and becomes more stringent. The Scoring Engine is checking if that page is up on that port, and comparing the hashes between the expected page and the received page. In the case of something that isn't web based, it will try to use that service with a script of some kind and expect a certain response. Also, keep in mind that there are some authenticated checks performed. If the user that the Scoring Engine expects to be there has it's creds changed, or deleted, you won't be scored despite the page being up or service being functional. I learned that the hard way. If you have cred updates that need to be done on scoring users, let the competition organizers know however it's called out in the Team Packet.

The last major points based point I want discuss is reverts. In the competition, you have the option to revert a system if it's fubar. The competition judges like to spook you by saying that it has a point hit, and it does. However, the point hit is worth it if not reverting means that your system will be down for more than an hour without a fix. It's likely less time, but I cannot remember for the life of me the points ratios, so I will update in the future when I learn it again. Anyways, if you accidentally dd your drive, you can request a revert, and Red Team will get informed stay its hand, and leave that machine alone for while before we hit it again.

Audit

In the Regional competitions, you will likely have to face an audit mid-competition. Audits are something that school never really taught me, but after having to do 4 simultaneously through $dayjob, I can tell you they aren't too terrible to go through. They can time consuming depending on the auditor however. Your Captain and Writer are going to want to be familiar with NIST 800-171, or whatever the Team Packet says you are being audited against. Now, I will tell you the dirty secret of audits, is that they are really simple to respond to. When the auditor shows up, they are going to want one thing. Proof that you are following the requirements outlined in the compliance framework.

The auditor will ask you questions about your controls. Your job is to respond truthfully, but give them the absolute minimum necessary to prove you achieved the outcome desired in the requirement. If you do not meet the requirement, then do not say you do. In the real world there are potential legal repercussions if you lie to auditors, so DON'T DO IT. If an audit is performed in your competition, the auditor will also keep notes on the way the team responds. If you overshare, or don't meet the requirements outlined in the framework, your team will be docked points. Your best bet is to have your Writer or Captain handle the auditor. If you are unfamiliar with what a Writer in a CCDC context, it's outlined here. The whole point of the audit is to ensure that you have documented policies and procedures, and make sure that you are actually following them. Auditors can be a pain in the butt, but they’re also your friend. They allow you to show deficiencies in security programs to management and you can use them to get help with initiatives to address issues in a way that captures their attention and sometimes requires them to address it.

Example

So, an example of a requirement and a good response to it.

If you look at this requirement, your auditor is going to ask what controls are in place to ensure privileged accounts are not used unless necessary. The way you respond to this is say "We have multiple accounts for administrative personnel. Our policy states they are to use an unprivileged account for day to day tasks, and privileged accounts when they need to perform administrative tasks." Then, show the auditor the policy document and proof of the control. In this case a screenshot of the language in the policy that shows that personnel are to meet the requirements outlined within the compliance framework. Secondly, you want to show a screenshot to the auditor 2 distinct, clearly labeled accounts for an administrative user.

Hands on Keyboard

First 30

CCDC is a stressful environment. In your rooms you will be high strung, on edge and worried about a ton of things. Take a deep breath, and calm yourself down. You are your own worst enemy in CCDC, not Red Team. We mostly exist as a boogeyman for you to get worked up over. Speaking from extensive experience, you get worked up. Red Team also has 30 minutes in which we are not allowed to touch anything. In that 30 minutes, you need to 2 things*.

First, change your default credentials on everything. OS admin creds, all application admin creds. Make sure that you get everything that's exposed, not just the ones given to you in the team packet. You will have to hunt down rogue administrative accounts. There are applications that have APIs that we were able to access in the 2024 state competition, and Cockpit servers exposed on the mail server that we got into around 14:30 with default creds. Understand what the application's security footprint is and what normal looks like.

The second thing you need to do is get your firewalls up, on both host and network asap. This reduces attack surface immensely. Which system is Red Team more likely to go after? The one with port 22 open? Or the one with port 22, 80, 443, 445, and 8443? Secondly, configuring host based firewalls kills chances at lateral movement, and restricting outbound connections kills a lot of our options for C2. Your job is to make it suck for us as much as possible. The only services that are available to the internet should only be the scored services. There should be absolutely no reason to have SMB open to the internet if it's not scored. Outbound connections should only be established connections. Doing those 2 things alone makes attacking you significantly harder. Which gets me to the last thing to do in the First 30.

If everything is going smoothly, and you have done your credential rotation and firewall rules, then begin patching, if it's actually needed. Additionally, use your access to the environment prior to the competition to run a credentialed Nessus scan or enumerate with nmap NSE scripts and find vulnerabilities. If they are serious and exploitable (Like EternalBlue and ZeroLogon, PwnKit), patch them. Otherwise, leave them alone. You can also mitigate vulnerabilities in other ways too, depending on the vulnerability. This is something you want to do if you have an exploitable vulnerability and have the time, but between injects and other fires you may be pressed for bandwidth.

Final note, we used to call this the "First 15" in my team, but I changed it to First 30 because it's more accurate to the amount of time you have. That's why you see "First 15" on the documents I link in the next paragraph.

Scripting

CCDC competitors today have something I could only dream of when I was competing. The ability to write and deploy scripts. This should mean that you have the ability to get that first 30 done quickly, since you can wget and execute bash or PowerShell scripts now. This should make your lives so, so much easier for keeping us out. The ability to write a bash script to add base firewall rules, then allowlisting the specific ones needed for scored services is huge. Changing creds in applications should also be much easier, but that also depends on the application, and how creds are done. I want you to take a look at this, this, and this. These are some of my notes from when I competed. They are mostly unchanged, with the exception of redacting names. So they are a little garbage if you are just picking them up and reading, but there was in fact a method to the madness at the time. Some of my assumptions in the documents may be incorrect, but the point of linking these is to show you something.

Do you see how most of the notes are just basically a script on a page? With the exception of knowing what ports need to be open, you can boilerplate this out, then open the ports required for scoring. I would also highly recommend writing scripts to automate other common tasks too, like ones that show up in injects for instance. There's a lot of ways to get creative here. If you have an orchestration tool that shows up in the competition, attempt to learn it and take advantage of it! It can save you a ton of time if you are able to use it effectively. Having the ability to execute scripts should save you a ton of time since you don't have to spend the first hour or so of the competition just locking things down.

Managing The Rest of The Day

After the First 30 is over, you can start locking things down a little harder, and threat hunt. You should be able to see Red Team activity, especially on a system ahead of the firewall or when you have a switch you can set up a SPAN port on it. Hunt us, and tell me what you find with an incident report.

Wrapping up

This post is mostly meant to cover the competition at a high level and the bare minimum things that need to be done to get you started on the right foot. I have plenty more articles coming covering a other, specific aspects of the competition including team dynamics, how to handle Red Team, proper responses to incident reports, and effective practice strategies. My hope is that this series of posts becomes the leading primer on how to run an effective CCDC team. Finally, the last thing I want to cover is that alongside the publication of this page, I have created a Discord server for CCDC participants. While I have mostly focused on my experiences with the competition and therefore this comes mostly from the Midwest point of view, CCDC participants of all areas are welcome to join the server. I think there is a wonderful community of brilliant students that can be built, and I would love to have you join.