So, you've decided to take the plunge. You want to get your hands dirty and learn a thing or two. Welcome to CCDC! CCDC is the Collegiate Cyber Defense Competition, an intense real-world(ish) competition designed to get students hands-on with technologies that are used to protect organizations from threat actors. The competition pits an 8-person team of students against other schools, and a Red Team. The Red Team is made up of industry professionals trying to get into your environment to deface your websites, take down functional services, and frustrate you. On a Saturday nonetheless.

That doesn't deter you? Awesome! The first thing you will want to do is find out if your school already has a team. Whether it's part of a club or just a bunch of students who are trying their best, how it's structured is dependent on your school. Team composition contains 8 students on the Primary Team, with up to 4 backups called Alternates. Should there be something that prevents one of the Primary team members from participating, an Alternate should be called up to take their place. Also, please note that teams have a limit of 2 Graduate students allowed. Once you have a team, start attending practice sessions until competition day!

So, when is competition day? Well, it depends on your region, and what your team leadership decides to do. In the Midwest region, we have an invitational competition in November, followed by State Qualifier competitions in January and February. Then, the Wildcard competition is held in late February followed by the Regional competition in March. If you make it to the National Competition, that's in April. Additionally, some other regions may have invitationals available outside their respective regions. For instance, the Western region has 3 invitationals which allow outside participants, so you could sign up for those as well. These invitational competitions are an awesome opportunity to determine if your practice sessions are working well. Practice sessions are held by your school's team and should allow you to get hands-on with some of the technologies that may appear in the competition, but I want to give some ideas as to what they may contain.

About a week before competition day your team will receive a Team Packet, which will look something like this. The Team Packet listed there is one for the Midwest Regional competition from 2019. Most schools that have competed before will archive these Team Packets and use them to base future practice sessions on. Especially if you are in a competition managed by the Midwest Region, the State (or Qualifier, they are interchangeable titles) competitions are very similar year after year. Team Packets are essentially your Holy Book on how the competition is run, including the National CCDC rules, regional CCDC rules, topologies, tech stack, and other important information. Your Team Packet is critically important. Read it, become intimately familiar with it, print it out, sleep with it under your pillow, whatever you need to do to understand everything inside it. The topology changes between various levels of competition as well, getting more complicated as you progress.

There are a few things I want to call out as "pro tips":

• You can bring printed material into competition rooms.
• Public (even authenticated) internet resources are okay to use! So long as they aren't torrents.
• GitHub and scripts are allowed!

Starting the Grind

As previously mentioned, practices should be offered by individual schools' teams should allow team members to better understand scored services, how they work, and how they are used. The core of what makes CCDC so great is that it forces students to apply theories that are learned in the classroom. A professor can tell you for weeks that exploits take advantage of vulnerabilities, but being able to see and respond to it happening is an entirely different ballgame. Learning how the vulnerabilities present themselves, how Red Team takes advantage of it, and how Blue Teams can detect and respond, this is the heart of the competition. Therefore, this is what your practice time should be primarily focused on.

Secondly practice sessions should allow some time to develop scripts to help harden the OS and services, while allowing automation of common tasks like installing Splunk Forwarders or installing Nessus. A few other notes on scripting, this means that you can have a team GitHub. There are some rules regarding how it's used so please be cognizant of that. However (at least in Midwest) the GitHub sites are also shared to all teams, as equal internet access is a common focus for keeping the competition fair.

Now you may be thinking, "Why would I want to make these scripts if they are just going to be shared to other schools anyways?". Well, information sharing amongst blue teams is always a good thing. The number one goal for the competition is to get students prepared for cybersecurity positions in the real world. No cybersecurity professional worth their salt operates without sharing some ideas with others, and that spirit should be fostered amongst Blue Teams. Secondly, as more teams embrace scripting, it's going to become more and more critical for your team to do the same. Does this run the risk of another team taking your scripts and using them? Absolutely. However, they are likely to make tweaks of their own, which then you can take and re-incorporate. Learning from each other should be something embraced across teams, in my opinion.

I want to harp one more time on that while scripting is amazing, it can be a crutch if you aren't careful. You need to understand the underlying what and why the scripts do what they do. Otherwise they will actively be in the way of your learning. If all you understand about scripts you are running in the competition is "I run it and it makes it secure", you're missing the point. Take the time to really understand what they are doing, and why. It'll be infinitely easier to troubleshoot, and you'll learn a ton more, and these skills will serve you for years to come.

Competitions

The school year has begun, your team has started practicing. After a few months, you have some scripts developed, you have a baseline understanding of your OSes and Services, and you want to test your mettle. The first opportunity to do so is with an invitational competition. For Midwest, it usually uses the State competition environment. So what does the competition actually look like? Now, this is going to be fairly Midwest focused, as that's where I have my experience. However, I can interject a little here and there from other regions from little tidbits I have learned. Additionally, I am starting with a normal state-level competition structure here, before highlighting differences in tiers of competition.

State Competition Structure

I'm using the Minnesota and Indiana State Qualifier competition as the baseline here, as it is easier to start here then discuss deviations between levels of competition. Your competition begins when you receive your Team Packet, usually about 4-5 days before the competition. This time is critical since it's the same environment you use on competition day. Part of the Team Packet contains the topology and version numbers for some services. The topology section will look something like so:

Take some time as a team and enumerate your services. Understand how they are deployed in the competition, and how that differs from deployments you've made as a team. Look though your OS, do you see stuff that looks weird? Any users which have more permissions than they need? Any ports that are open that you don't expect? Install Nessus on one of your boxes, scan your environment with administrator credentials. You dont want to use Nessus? Then at least use nmap NSE Scripts. Do you see any major vulnerabilities that need to be addressed? Keep notes of this stuff, and prepare to address it in the competition.

Scoring

Scoring in CCDC is relatively clear cut, despite what the Team Packet says. Scoring breakdowns hit 3 categories: Uptime, Inject Responses, and Red Team. The Team Packet gives ranges which are a bit nonsensical, but this is done so the individual Chief Judges can make adjustments to score weights. Additionally, it's important to understand that when you have multiple states competing simultaneously, they are scored on a per-state basis, as the winners per-state are the ones which move into the regional competitions. The typical scoring breakdown looks like this:

• Uptime = 40%
• Inject Responses = 40%
• Red Team = 20%

Uptime Scoring

Uptime scoring is exactly what it says on the tin. It's measuring the relative performance of teams in terms of uptime percentage. Uptime scoring is determined by the Scoring Engine, which is going to check the services for specific information. Say for instance, a string in a webpage, the existence of a DNS record, a hash, or something else. This score is typically influenced by Blue Teams taking their scored services down, followed by Red Team taking scored services down.

In any competition I have participated in either as Red Team or Blue Team, Blue Teams have always been their own worst enemy here. I have no idea how many times I've seen Blue Teams taking down their own services, and blaming us for it. I am definitely guilty of doing this myself! There's been numerous times where my backup person rebooted a box without telling me, which made me think Red Team took it down. Even when we can't start exploitation, we will have teams report Red Team caused outages. Sorry Team X, I didn't take down all your scored services 10 minutes in. Talk to your firewall admin, they are probably rebooting.

Inject Scoring

Inject Responses are likely where teams struggle the most. The best team in Minnesota in the 2025 competition season scored a 58% on their Inject score. Taking that as a percentage grade, that's still an F. Inject Responses are where most teams struggle the hardest, and I would argue is the biggest opportunity for improvement. Fortunately, I have an article on Injects which should help provide some guidance. Ensuring that you have a solid Writer is critical, and some teams even use 2. If you want to know what a Writer is/does, check this article out. They are probably your most important team member to get right, as they can influence more points than the rest of the team can.

Red Team Scoring

The final scoring pool is Red Team scoring. This is where, at least in Minnesota and Indiana, I have direct control over and can explain exactly how it works. Red Team scoring is done entirely on new access. We start with the following placeholder values based on what level of access we achieve:

• 25 points for Information Disclosure, or a low privilege user within an application context.
• 50 points for an Admin user within an application context, or a low privilege shell.
• 100 points for an admin/root shell.

Something to keep in mind here, the entire exploit chain is evaluated holistically. So if we compromise a low privilege user, and they have sudo rights, I count that as an admin compromise as I can escalate to root. Same if we used a privilege escalation exploit too. I then look at incident responses and award points back based on the quality and relevance of the reports. Teams can earn back 100% of the points Red Team takes away based on their Incident Response reports.

I then take the team with the highest number of points (the team that performed the worst against Red Team), and use that number as the denominator for the whole Red Team points pool. So for example if we have a team with 400 placeholder points (after grading incident reports) and we have 10,000 points in the Red Team pool, (10,000/400) = 25. That gets us what I call the "multiplier". I then take those placeholder points, multiply them by the multiplier, then subtract the result from 10,000 to obtain the final scores.

This effectively means that the team which does the worst against Red Team will earn a 0 on Red Team scoring, however this means that for the rest of the teams, Red Team points score based on relative performance across teams. Something to keep in mind here, despite this being the largest section of scoring by word count, it's because I can directly control and explain how it works. This is the smallest possible point pool, and therefore I would highly suggest teams keep that in mind. Red Team points have never been the make or break for winning in Minnesota. I can't speak for Indiana as I haven't ever seen their final scoring results outside Red Team scoring.

Competition Day

Okay. Now that I have lore-dumped a bunch of information for you, what does competition day look like? Well first off, you're going to be stressed. As awesome as it is, 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 experience, you get worked up. Red Team also has 15-30 minutes in which we are not allowed to touch anything. In that time, you need to 2 things*.

First, change your default credentials on everything. Start with the credentials shown in the Team Packet, then OS admin creds, all other 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, which you should be doing when you have pre-competition access to the environment. There are applications that have APIs that we are able to access in the competition, and Cockpit servers exposed that we get into with default creds. Take time before the competition to 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. 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, 135, 137, 139 443, 445, and 8443? Secondly, configuring host based firewalls kills some 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 (and therefore Red Team) 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 15.

Finally, if everything goes smoothly on the first 2 points, then begin patching, if you actually need to. If you used your pre-competition environment access well, you should have a good idea as to what vulnerabilities exist on each of your boxes. You can take those results and look into the exploitability of those vulnerabilities. If you see EternalBlue, ZeroLogon, PwnKit, or other easily exploitable vulnerabilities, then patch those asap. Reboot if you have to as well. If you don't see anything that's easy to exploit, then don't bother patching that box.

You may also be able to put up mitigations against vulnerabilities without patching them. For instance, we have had a lot of success with ZeroLogon in recent years. If teams were to block ports 135-139 at their firewall, this kills our ability to run the exploit. Now, any possibility of mitigation is entirely dependent on the exact vulnerability, but you may want to investigate this if you have time. I understand that between Injects, stress, Red Team, and other pop-up issues you may not have time.

Injects are given to teams during the competition. Injects essentially simulate asks from management for your team to do something and report findings. Injects make up 40% of your total points, so it's imperative that these are done reasonably well. You'll typically have ~30 injects in a state competition, with the time to complete being varied between injects. Some are as short as 30 minutes, some go as long as multiple hours. These are meant to be responded to in a "business memo" format. This means email. Reply to it like you would reply to an email in a business context. It's also important to understand what exactly the inject is asking for, as sometimes it's looking for a specific implementation, sometimes it's a plan. Treat them like open-ended test questions. Really read and determine what exactly they are looking for. There's much more information on injects here.

The last major points based point I want to 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 are authorized to hit it again.

Scripting

Now, I harp on this because it's so important. 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 15 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 handled. 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.

I have a feeling that this is going to become more and more important over time to remain competitive. The teams that did well this year took advantage of scripting for some of the basic administration and hardening tasks. This is quickly becoming a core strategy amongst teams. As a final add-on here, I understand that I was using the Term First 15, and those who read the previous version of this article may remember that I was advocating to a change to First 30. I have reverted to First 15 due to how quickly we were given permission to be let off our leash and start hitting teams this year.

After the First 15 is over, you can start locking things down harder, help with Injects, 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.

Invitational Competitions

Phew. Now that a "normal" competition is done, I want to highlight some things about Invitational competitions. Invitational competitions are optional competitions which allow teams a "dry run" before the State Qualifier. The rules on them are a little more loose, but should allow teams to get a better understanding of strengths and weaknesses. During invitationals, you may be allowed to have outside help in the form of advisors, alumni, or others. The goal here isn't to have those folks be hands-on-keyboard, but instead help the Captain direct the team effectively.

In the Midwest region, the Invitational competition is a half-day event, but they run 2 of them. Other regions may also allow outside teams to participate. For instance, the Western region holds 2-3 invitationals where they allow schools from any region to participate. If you think your team is performing well, I would highly recommend attempting a Western invitational. They are significantly more mean than other regions, and can really help stress-test your teams.

Midwest Regional

Topology

Sorry folks this is Midwest specific, since I have never participated outside it. However there may be some good nuggets of information in here for you. The Midwest regional competition is a significant step up from the state environments. They often entirely change the regional environment, and add a few new elements. The Regional competition is also a 2-day competition, which is exciting. I participated in 2019 and 2020 Midwest Regional competitions, with the environments changing substantially between them. The 2019 environment was essentially a slightly modified state environment, with a few IoT devices in the form of Raspberry Pis.

The 2020 environment was significantly larger, and included the state environment as a sub-component of the larger regional competition. My apologies on the poor resolution of this stitched image, it's just the best one I have. It's essentially 2.5 state competitions, with the addition of physical networking devices like routers and switches, as well as a physical ESXi server.

In 2020 we also had very little time beforehand with the environment. I'm not sure if this was due to when the environment was finalized, or if this is an artifact of COVID. Additionally we had significantly (intentionally) more broken systems at the start of the 2020 Regional than we did in 2019. We also had to stand up scoring services mid-competition via an inject.

Scoring

Scoring works essentially the same, however the Midwest Red Team handles that side of things, not me. Also, there are a few tweaks to be aware of. First off, is you are likely to have an SLA for your scored services. Essentially, the way uptime normally works is that they check if your service is up. If it is, they score it. If not, then it isn't scored. Now with an SLA there's a temporal element. If your service has been down past a certain amount of time, then White Team will start subtracting points on your uptime score. A second note on uptime scoring, it's likely to include more strict requirements from the scoring engine at a Regional level, and may include credentials to work, or other checks. It's your job as Blue Team to figure out what that is.

Additionally, they start including an Orange Team. Orange Team are volunteers which act as users of your systems, and will start calling to complain when services don't work as expected. These folks will grade based on the customer service they receive, as well as how the experience of using your services is. Another fun fact mostly because I don't know where else to put it, but you can migrate scored services across boxes in the regional competition.

Finally since the competition is a second day, there are more Injects. The first day of competition is more like a half day, but the second is a full day. Keep in mind though, you'll have about double the number of Injects, so you'll have a faster pace of Injects to respond to. Combining this with more than doubling the size of the environment, you're going to have a lot more to worry about in the competition in Regionals. Sorry Wildcard folks, I unfortunately have no experience with how the Wildcards are run so I have nothing to add here at this time.

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, 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. 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.

Audit Example

I want to give an example of an audit 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. A good way to respond to this is saying "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.

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 covering other aspects of the competition. These are located here. My hope is that this series of posts becomes an excellent 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!

Changelog

2024-03-09: Initial post.

2024-11-20: Cleaned up some grammar and soften up some language. Also updated a document to change an alias.

2024-07-16: Reworded the end of the reverts paragraph.

2024-02-18: Updated to a V2 version.