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 ream. 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. I am one of these mean red teamers.

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 larger club or just a bunch of students 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 can be called up to take their place. Also, please note that teams have a limit of 2 graduate level students allowed. Once you have a team, start attending practice sessions until competition day!

When are the competitions?

Well, it depends on your region, and what events your team leadership decides to participate in. For the Midwest region, we have invitational competitions in the fall, followed by State Qualifier competitions in January and February. Then, the Wildcard competition is held in late February or early March followed by the Regional competition in March. If you make it to the National Competition, that's usually in April. Additionally, some other regions may have invitationals available to schools outside their respective regions. For instance, Western has a few 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, stress test your teams, and find weak points that you can improve upon. Practice sessions are held by your school's team and should allow you to get hands-on experience with some of the technologies that may appear in a competition.

If you are in the Midwest, Mid-Atlantic, or Rocky Mountain regions, about a week before competition day your team will receive a Team Packet. Team packets look something like this. The Team Packet listed there is one for the Midwest Qualifier competition from 2025. 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 Qualifier competitions have been similar historically year over year. Team Packets are essentially your Holy Book on how the competition is run, and contain the National CCDC rules, regional CCDC rules, competition topology, 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.

I want to highlight a few pro tips:

• You can bring printed material into competition rooms.
• Internet resources that are generally available to the public free of charge are okay to use! So long as they aren't torrents.
• GitHub and scripting are allowed!

Starting the Grind

As previously mentioned, practices should be offered by individual schools' teams should allow team members to better understand how scored services and their underlying operating systems work, and how they are used in both a benign and malicious way. 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 a million different ways that exploits take advantage of vulnerabilities, but being able to see and respond to a successful is an entirely different ballgame. In my opinion, the entire point of the technical side of the competition is so you have a deep understanding of the following:

• Learning how various types of vulnerabilities present themselves
• Understanding how we as the red team can take advantage of those vulnerabilities to perform malicious actions against your systems
• Demonstrating how you as the blue team can detect and respond to us

Therefore, this is what your technical practice should be focused on. However, I also understand that there's some prerequisite knowledge required to get to the point of identifying vulnerabilities. That's where training your junior team members comes in. Install an OS, study what it comes with by default. What's running on it? How do you administer it? Next, install an app from a previous competition on top of your box. Play with the configuration, break it. How can you recover a broken config? Does it just need a settings tweak and a service restart? Or does it need to be reinstalled? Did you brick the OS in the process? Practice sessions should answer these questions. Understanding the technology stack helps establish a baseline that you can use, regardless of which box you are assigned in the competition. 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.

Some Notes on Scripting and GitHub

Your team is allowed to have a GitHub repo to use in the competition. There are rules regarding how contributions are allowed and how your GitHub contents can be utilized in the competition. There is one major catch however, In the Midwest, Mid-Atlantic, and Rocky Mountain regions (maybe others), the GitHub sites are also shared to all competition teams and the red team. Some teams mitigate this by keeping their repos private outside of competition day, but in my opinion this should be discouraged if not outright banned.

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? Even worse, the red team??". Well, information sharing amongst professionals is almost always a good thing. This rings true regardless if you're on the offense or defense side of the screen. Sharing tactics, techniques, and procedures makes the collective of the security industry better at our main job, keeping the bad guys out. Most importantly, to me, the competition is more about preparing students to enter the industry with some seasoning on them than it is about who takes 1st. Sharing information also establishes you as someone who knows something and is willing to share that knowledge and this behavior will eventually pay dividends. The infosec community rewards those who contribute back. Some of the most awesome people I've ever met and stuff I have done in my career have come directly as a result of publishing these blogs, as an example.

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 reincorporate into your implementations. Learning from other students and professionals must be encouraged, because that's how you get better. I would recommend looking through those repos and checking out if there's anything in there you can use. There might be some ideas that your team hasn't thought of yet.

I want to stress that while scripting is amazing, it can be a crutch if you aren't careful. You still need to understand what the scripts are doing and why they do it. Otherwise, when they fail you will be completely lost. Even worse, they'll hamper your learning. If all you understand about scripts you are running in the competition is "I run it and it makes my box 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, you'll have some jumping off points to research, which helps you learn more. Approaching scripting in this manner will also help you professionally for years to come.

Okay, what should my scripts contain?

Some ideas for scripts include configuring your basic firewall rules, changing default credentials, and applying specific hot patches to fix easily exploitable vulnerabilities. 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 if you are just picking them up and reading, they might be a little confusing as they were intended mostly for me to jot down some helpful notes. There was a method to the madness though.

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 template this out and change the ports to the ones 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. Scripting has become more important in recent years.

Some other scripting ideas include automating Sysmon and Splunk forwarder installation or deployment of threat hunting tools. Really you can let your imagination go wild here.

Other Training Goals

In addition to the technical side of the competition, teams should have a documentation template that's used to speed up inject and IR submissions. Your Writer should pre-write some common responses to injects and red team intrusions that have been detected in years past, and get them in your GitHub repos. If any of your teammates know an English or Communications major willing to help out, I would also recommend bringing them in for a practice session to help your Writer get their wording and templates leveled up. The goal is to save the Writer as much time as possible in the competition so they can focus on the managing the team. Finally, MWCCDC has a document with some additional training goals. It's a few years old, but this can be used by Captains to evaluate where their team is at training wise.

Competitions

Okay so the school year has begun, your team has some practice time under their belts. After a few weeks or 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. As mentioned before, these usually take place in the fall, and in the Midwest region the invitational competitions usually use the State Qualifier 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 this

In Midwest, Mid-Atlantic, and Rocky Mountain, you will receive access to the environment ahead of time. Take some time as a team and enumerate your services. Understand how they are deployed in the competition, and how they differ from deployments you've made as a team. Look though your OS, do you see stuff that looks different from your team labs? 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 don't 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.

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 deliberately stressful. 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 will get worked up. At the beginning of the competition, you need to 2 things*.

First 15

First, change your default credentials on everything. Start with the credentials shown in the Team Packet, then any additional OS admin creds, next any other application admin creds. Make sure that you get everything that's exposed outside your environment, not just the ones given to you in the team packet. You will have to hunt down rogue administrative accounts, which you should have enumerated when you had pre-competition access to the environment. There are often rogue services exposed outside your environment. Take time before the competition to understand what your environment's security footprint is and get a baseline of what 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 the 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 ZeroLogon, PwnKit, IIS Raid, 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 to keep your uptime strong.

I would also recommend standing up mitigations against vulnerabilities without patching them, if possible. 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

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 around 40% of your total points, so it's imperative that these are done 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. However, I also found MWCCDC's guidance for a business memo. Use that if you aren't familiar with business-style emails. 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 in some competitions red team will get informed stay its hand, so we would leave that machine alone for while before we are authorized to hit it again.

Invitational Competitions

Phew. Now that a "normal" competition is done, I want to highlight some changes in Invitational competitions. Invitational competitions are optional competitions which allow teams a "dry run" before the State Qualifier. The rules of engagement are a little more loose, but should allow teams to get a better understanding of their 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, and provide advice to technical members of the team. Additionally, if you can find an English student or a Communications student to have them join, take advantage of their skills! Your Writer will thank you.

In the Midwest region, the Invitational competition is a half-day event, but they run a few of them. Other regions like Western may also allow teams from outside their region to participate. If you think your team is performing well, I would highly recommend attempting a Western invitational. They are significantly more challenging than other regions, and can really help stress-test your team.

Wildcards

Wildcard competitions are essentially an in-between for a State Qualifier and regional competition. To qualify for a wildcard, you nee to take 2nd or 3rd at the State Qualifier. They often use the State Qualifier infrastructure, but will have an increased inject pace, and a more aggressive red team. There's not a whole lot to say about them.

Regional Competitions

Topology

The regional competition is a significant step up from the state environments. They often entirely change the regional environment, and/or add a few new elements. The Regional competition is also typically a 2-day competition. I participated in 2019 and 2020 Midwest Regional competitions, with the environments changing substantially between years. 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.

Regional competitions up the stakes significantly. Most years there's a secondary environment. There's also Orange team, who will be end users harassing you about service outages, there may be an audit, and there will be changes to scoring, which will be covered more in-depth here.

Audit

In the Regional competitions, you may have to face an audit mid-competition. I never really learned how to handle an audit in school, but after being on the receiving end of 4 of them simultaneously a few years ago, I can tell you that while they aren't hard to do, they are incredibly time consuming. Your Captain and Writer are going to want to be familiar with NIST 800-171, NIST 800-53, or whatever the Team Packet says you are being audited against. 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 tell them you don't meet the requirement. In the real world there are legal and reputation repercussions for you and your company 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 to award points later.

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 document deficiencies in security programs to management. If this happens, you can use the audit results to get your initiatives prioritized. Having documented gaps in your controls is likely to capture leadership's attention. What's better is sometimes management could be required to address it by law, else your company may lose out on revenue or be boxed out of certain markets. This is why you usually see a lot of people freaking out around changes in compliance requirements.

Audit Example

I want to give an example of an audit requirement, and a good response to it.

Looking at this requirement, your auditor is going to ask what controls are in place to ensure privileged accounts are not used unless necessary. Since you will want to abide by it, the proper control is offer 2 types of accounts. A normal user and and an administrator account. Admin accounts would only be provisioned to administrators and appropriately scoped to their role. Now, assuming you meet this requirement, a good way to respond to this is by 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.

Orange Team

Regional level competitions also often have an Orange Team. Orange Team acts as the end users that use your infrastructure as it's actively on fire. They will attempt to authenticate to services, use them to perform tasks like sending emails, visiting websites, and buying stuff. If they can perform these actions successfully, they will log it and your team will get points. If they cannot perform their jobs, they will start calling or messaging you to demand information, remediation timelines, or just to complain. Orange team members will often overplay what a typical end user would. They will be annoying and you have to address their concerns professionally. If you aren't professional, they will dock points on the interaction. It's best to use your customer service voice with them. The primary person who interacts with orange team is either your Captain or Writer.

Wrapping up

This post is meant to cover the basics of the competition at it's various levels. I have plenty more articles covering other aspects of the competition located located here. Additionally there's many current and former CCDC competitors in the Unofficial CCDC Discord server, in addition to volunteers and red team members. I would highly recommend checking it out!

Changelog

2026-03-25: Updated contents for 2026.

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

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

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

2024-03-09: Initial post.