Injects are consistently called out as the weakest part for teams within the Minnesota State Competition. In 2025, the best team only earned a 58% on inject scoring, which at least within the Minnstate College system, is still an F. Given that they are worth ~40% of your total points, that's a ton of points that teams are leaving on the on the table. So it's important to understand how to submit a good inject response. Communicating effectively is critical for any security role, and the competition's vehicle for this are injects. Injects are meant to emphasize how important it is to communicate to management or executives. This means get your point across, clearly explain rationale for decisions and how they'll be executed.

What Is An Inject, Anyways?

Backing up a bit, I want to reiterate what an Inject is supposed to simulate. Injects simulate requests from leadership that you are expected to fulfill. Often times, these are changing business requirements that your team now must become compliant with, even if it's at the expense of "better" security. Injects show who is giving orders at the bottom of the page. If you pay attention, they are almost always management or executives. In most organizations, it's expected that management makes decisions usually with individual contributor, team, or stakeholder input. However, the final call is usually up to management. Once the call has been made, that's what you'll work with whether you like it or not. The competition reflects this reality in a fairly harsh manner. You'll want to follow the prompts to the letter and make sure you understand what the White Team is looking for. Finally, at least in the Midwest region, the White Team specifies that they want Injects in "Business Memo" format. It essentially means an email. If you want more specifics, the Midwest region has this handy document outlining what they are looking for. Injects, especially at Regionals come fast and hard. They give you far less time than you realistically would to accomplish the goal, but that's kind of the point. To throw students into a crucible and ready them to become seasoned cybersecurity professionals.

Anatomy of An Inject

Next I want to cover what an Inject looks like with a few examples. These are from the Midwest Regional Competition in 2019. I won't be supplying the entire repo I have since it was taken down by request from the competition organizers, but I got it from a guy who knows a guy and so on.

Inject 9 - Required Services

I highlighted all the relevant information for this Inject. Injects contain instructions that must be completed, proof shown of completion, and your Writer must respond to the requests listed here. Fortunately, Injects often contain tasks that are helpful in locking down your environment. Especially in the case of this one, where essentially the competition directors are mandating that you get your firewall rules locked in. You can see with the highlights that the request is pretty straightforward, if you break it down.

1. Create a table of services by host that can be reached externally (scored and customer/orange team accessed services)
2. Block services that are not in that table by port and transport protocol, or by application protocol
3. Take screenshots showing that you did it

That's really it. This can easily be done in 90 minutes. You were given the team packet ahead of time, which contains the list of scored services. Most firewall admins would likely have the table handy for rule creation anyways, so make any final adjustments to your documentation and you'll be off to the races. Especially, given scripting is allowed nowadays. I also want to note that the inject has a person who "sent" it to you, in this case an IT Director. Directors usually sit just under executives in the management chain, so this person is relatively important. In an actual business a Director may be asking this to hand to an auditor, or to try to obtain backing for some sort of internal initiative to harden firewalls.

Inject 23 - Org Chart

This one is again, pretty straight forward. It's looking for an org chart that explains what it is that the people on your team do in their roles, and the skills required to fulfill the duties of the role. You can use something like Visio, Draw.io, or Obsidian.md to create this chart and fill out most of this information here. When your team is assigning roles for the competition season, making an org chart can help identify chain of command and clearly define what people on the team should be working on, hopefully mitigating interpersonal issues before they arise. Here's an intentionally poorly done example of an org chart.

The reason this is intentionally poorly done is so you can't just take what I wrote here and submit it without any work yourself, however it still gets the idea across in a fundamental sense.

This chart shows the leadership structure, but you can improve on what I have here. Listing the number of current positions, for instance. Maybe you want to move the backups into the memo instead of on the chart itself. You may want more positions on here. The documentation should reflect however your team is structured. So the Inject response should have the following info:

1. The actual, not crappy org chart
2. A list of skills that are needed to succeed in that role (think of it like a job description)
3. Any positions that back up other positions
4. Any additional personnel you have on standby
5. Stating if you are adequately staffed in your response

Everything that isn't point 1 should probably be done in the memo itself, rather on the org chart. But, at the end of the day, it's up to your Writer on how they want to proceed. This inject comes from the CIO, who in a real company may ask for something like this from lower-level managers. The idea here is they may be finalizing budgets and trying to figure out where they can make a hire to help plug some organizational gaps. ...Or they could be looking to downsize.... Onto the final Inject I want to analyze.

Inject 37 - Email Security

This Inject covers email security, specifically anti-spoofing measures that can be performed with DNS. This inject is essentially a test question in disguise. Also, what's interesting here is that they don't specifically call out a need to implement, just come up with a plan. So a little research can tell you what all 3 of these records are for, how they work, and how to implement them. Given that Regionals contains actual users who may click on Red Team payloads to the email boxes, it's still probably a good idea to implement them, even if it's not required. So you'd want the following in your reply:

1. An explanation of how DKIM/SPF/DMARC help prevent spoofing emails
2. An explanation on how to implement these records

This inject comes from the "IT Directory". I want to say this is a typo and is meant to say "IT Director" but it says "IT Directory" on the bottom too, so maybe it isn't? Regardless, an actual business scenario that would use this is to push whoever owns email and/or DNS to start hardening the DNS config. This will reduce bounce rate in your outbound emails and increase chances that it will actually land in an inbox.

Inject Responses

So I grabbed 3 different Injects to show some variety and show how they need to be completed in different ways. Injects tend to be similar year after year, but there are some that change. The biggest thing you can do to make responses faster is to create a template that can be used for all your inject responses. This also ensures consistent reporting and generally increases the quality of Inject responses overall.

I also want to make a point regarding using AI services for submitting Inject responses. Large Language Models are incapable of true reasoning, and therefore are not suitable to properly compose an Inject response, or any other fact based document on their own. They "hallucinate", which is excellent an PR term for the LLM coming to the wrong conclusions. If the competition organizers think your Inject response is generated via an LLM, they are going to throw it out. AI can be useful, but because it's inherently unreliable you cannot use it as a source of truth.

You still need to know and understand the subject matter to be able to verify it's output. Additionally, anything that is said or processed by these AI services is typically fed back into the model. If you use these services for work, you are feeding data, potentially confidential data back into to these systems. This can have massive repercussions for you and the organization you work for. This isn't me trying to say "AI Bad. Fearmongering grumble grumble.", but I want to note that you have to be diligent on how you use it. LLMs are awesome for helping brainstorm ideas and helping you get started with basic tasks. However, I would not recommend using it for anything sensitive. Anyways, tangent over. Back to what I was talking about before. The first inject response example I want to show is the password policy Inject.

Inject 18 - Password Complexity Requirements

Note that this is different than the first one linked in the previous section. The reason being is that since I am not in the competition environment, my firewall rules at home are different than what you would see in the competition. For this Inject, I have both a good and bad response to show as examples.

Terrible response

Here is a response that's just plain bad. I have, unfortunately seen something like this before, but in the context of an incident report.

You will gain very few points for type of inject response, if the competition judges are feeling generous. This is a waste of time for all involved. Don't be this team.

Acceptable Response

Here is a good response, using my Homelab password requirements as the example. This can still be improved, of course. I could actually have the policy implemented in a manner that's compliant with CIS benchmarks or some other compliance framework. This response may should get you most, if not all points. At the very least is that you will get more points than the previous response.

Another thing that I like about this inject response template is that it's clear who the memo is from, who it's going to, and what it's about. Most importantly though, it's straight to the point with proof of technical implementation. I've reported directly to senior managers and a CISO, and if there's 1 lesson I learned it's that extremely busy people with infinite demand on their time greatly appreciate someone who can get straight to the point. If they are asking for information, give them that information, answer any follow-up questions and then give them space to make the call. If you are trying to get them to make a decision, come with the relevant information, then make the pitch. Don't waste their time.

Inject 23 - Org Chart

Like the previous example, this is directly taken from the overview section, just sans highlights. This one doesn't really have a technical component to it, just personnel. That makes it both easier and harder to answer, in different ways.

Inject Response

Note for this Inject response, I am going to use the abridged org chart I was showing off earlier as the guide for how I respond. When you submit a response for this Inject, you will want to have the complete team mapped out. Here is the response I would submit for this. It directly answers the questions that are posed by the Inject, and contains the org chart requested. It may not be a beautiful response, but it should get the job done. Some room for improvement is better defining the job roles. I would recommend treating them like you are filling that job out on your resume. Be specific about what the expectations are.

Inject 37 - Email Integrity

Once again, I will answer this one with my Homelab. This is the same Inject as the second one in the previous section.

Repeating what I said earlier, this Inject covers anti-spoofing measures that can be performed with DNS. Essentially a test question in disguise. To respond to this, you will want the following:

1. A high-level plan explaining the goals and outcomes of implementing these DNS records.
2. A high-level plan explaining the implementation of these DNS records.
3. Explain why these records are being implemented.

Good Inject Response

Here is the response I have written for this Inject. This response is significantly better than either of the previous ones. It's clear about what DNS records need to be implemented to perform which portion of the anti-spoofing measures, the screenshots plainly show which portions of the implementation are relevant, there's a brief and high level overview of what each piece of the anti-spoofing puzzle accomplishes, and finally the response opens the door for additional conversation and adjustment, if required. This is a good Inject response. One that I managed to put together in about 15 minutes at most. Realistically it would have been faster if I was sharper with email security fundamentals. When the competition organizers are talking about getting high quality Injects, this is what you should be using as a standard. Like anything else, this can of course be improved and is subject to opinion. Onto the last Inject response.

Inject Response Guiding Principals

So, the recipe for a good Inject response is pretty simple. First off, create a response template. I am not supplying one here as this should be a team discussion, but having a template will save you a few precious minutes per inject. Secondly, analyze what the Inject is asking for and answer based on the those asks. Thirdly I want to introduce something which is championed by BB King of Black Hills Information Security that I think we as an industry need to do better. Taking the written word and moving the goal from "Easy to understand" to "Hard to misunderstand".

I first heard this concept in early 2024 and I have since taken it to heart. "Hard to misunderstand" is the guiding principle for how I write nowadays, because it cuts down on the amount of required follow up and prevents confusion from happening in the first place. This results in saved time for everyone involved in communications. Now that doesn't mean I get it perfect every time, but "hard to misunderstand" is the goal I generally shoot for and I hope that it comes through in my Inject responses.

Finally, I want to provide some resources which can be used to help assist teams with writing. These aren't inject specific, but they help. This talk and part two by BB King serve as awesome resources for report writing. These talks are geared towards writing pentest reports, however enough of the material is applicable in other areas that I feel it's worth sharing regardless. These presentations, and his Reporting for Pentesters class through Antisyphon Training are excellent resources to learn how to level up reports, of any kind. Note that this is a paid class however.

I hope that teams use this post in the future as a guide on how to improve Inject submissions. I'm tired of hearing competition organizers complain about bad Inject responses. If you found value in reading this, and would like to meet and network with other CCDC competitors, please join The Unofficial CCDC Discord server! I am there alongside students, alumni, coaches, and other CCDC volunteers to help students succeed in the competition and in their careers once they finish their time in the competition.

Changelog

2026-03-27: Updated for 2026 content

2025-02-24: Added some external resources to level up your reporting game

2025-02-21: Updated one of the inject responses and gave some light touches to modernize the rest of the article

2024-07-16: Removed references to a now-canceled post

2024-05-17: Added content about AI generated Inject Responses

2024-06-05: Added link to Red Team article

2024-11-20: Fixed some grammar issues, and removed references to my old domain in documentation