Putting KC7 Experience on Your Resume Without Making It Sound Like a Game

Part of why KC7 exists is to solve the chicken and egg problem we have in cybersecurity. You can't get the experience without having the job but you can't get the job without the experience.

And I get this question all the time…now that I've played KC7, how do I translate that experience to something I can use on a resume?

It's hard because most cyber training fits better as a bullet point that highlights an achievement rather than demonstrated evidence of what you've done in a given role.

I want to help fix that. First, let me tell you what I think KC7 actually is, and then we'll talk about how to write about it like an analyst writing about real analyst work.

KC7 is real experience. Treat it that way.

When I was starting out, I had no idea what real experience in cyber even looked like because I didn't have any. What I had was KC7, a bunch of CTFs, and whatever other hands-on platforms I could get my hands on. And to a lot of people in the industry, that didn't count because it wasn't a job and so it wasn't real.

But it was real to me. I never treated these like games. They were fun, sure, but every time I logged on I assumed the role of a security analyst and I approached every challenge like it was the real thing. I wrote up findings like someone was going to read them. I took notes on what I tried and what didn't work. I worked through the hard parts instead of skipping past them. That's what turned it into experience. It wasn't just the platform, but also the way I was using it.

I want to be clear about this because I see people question KC7 on resumes and in interviews, and they shouldn't. KC7 is built on real attack scenarios inspired by real world threat actors. You get valuable experience investigating the full attack chain, something many entry level roles won't give you. Why does this matter? It helps you develop contextual awareness. You start to see how each piece of data connects to another. They aren't just alerts, they're events in a full chain and by playing KC7 you develop an understanding of all the events that led up to the alert and all the possible events that can come after it.

That last part is what I want you to really think about when you describe your experience on KC7, because it's the thing that separates someone who has just learned a tool or completed a lab from someone who can actually hunt. A lot of entry-level work is alert-driven. You get a ping, you triage, you close or escalate. KC7 gives you the thing that's hard to get without years on a team: reps of pivoting from one indicator to the next, building a narrative across logs that don't obviously belong together and not stopping at the first interesting thing you find but seeing the entire intrusion from end-to-end. That's the kind of thinking you build playing the game and that's the story your resume should tell. Not just "I played a game." but something closer to, "I can follow an intrusion across the kill chain using the same tooling and methodology a threat hunter uses."

Describe the work, not the platform

When you describe KC7, write about it the way you'd write about an internal investigation, an internship, or a project at a real company. The platform is the environment. The work is the work.

Here's a thing I did on my resume that's worth mentioning…I labeled this section "Experience" instead of "Work Experience." I think omitting that one word makes a difference. Under it, I included paid roles, KC7 work, conference talks, and other things I'd actually done that demonstrated the skills the job wanted. Calling it "Experience" let me put all of that in one place without claiming any of it was something it wasn't. The KC7 work sat alongside the paid work because it was still "Experience". You can do the same thing.

Okay, so how you do you actually do it? Here's how I take a KC7 scenario and turn it into a resume bullet point.

Compare these two:

Practiced threat hunting in KC7's training scenarios using KQL and Azure Data Explorer.

vs.

Reconstructed a multi-stage intrusion across email, DNS, and endpoint telemetry using KQL in Azure Data Explorer, identifying initial access via spearphishing and pivoting through all stages of the kill chain to map the actor's full TTPs.

The first one shows that you can use a tool on a guided learning platform. The second one shows that you can do the work. Same activity but very different way of framing it.

Notice what the second bullet actually does: it names the data sources you pivoted across, names the tooling, anchors to the kill chain, and ends on an outcome, which is a mapped set of TTPs. None of that is an exaggeration. If you finished a KC7 scenario, you did all of those things. You just didn't write them down that way.

A useful tip is to write the bullet point, then ask "why does this matter?" If the answer is "I can use a tool or know a framework," go back and work on it some more. If the answer is "I have this proven skill that I can provide to your team," then you're good.

Andrew Thompson has a really great blog post on writing resumes that gives this idea a name, ARM (Action, Result, Measurement). What did you do, what came of it, and how do you measure the impact? It's a version of the STAR framework most people learn for interviews but trimmed down for the limited space a resume gives you. The "why does this matter?" test is basically asking whether you've gotten to the R and the M yet, or if you've stopped at the A.

Here's what that looks like in practice. Take a bullet point I had on an early version of my resume:

Hunted across multiple datasets, pivoting with each piece of evidence to establish comprehensive attack narratives.

It's not that bad really. It names the activity but read it carefully and you find that it's all A and no R or M.

Now compare:

Pivoted across email, DNS, and endpoint data to trace a phishing lure back to its sender, then forward to the actor's C2 infrastructure, uncovering two additional compromised users that weren't in the original alert.

Same underlying work. But now you can see what I went after (the lure -> attacker infrastructure), where I went with it (backward to sender, forward to C2), and what came of it (the two extra users). The first one tells them you did something, while the second one tells them how you did something and what the result of that was.

Build a master list, then tailor it

Here's the other thing I really want you to take from this post, and it's helpful when you're applying to a lot of different roles. Create a master list and don't send the same resume twice.

This idea came to me in two pieces. The first was from Waymon Ho, who told me to take everything I'd learned and make a list of it. But specifically, what I had actually learned from each thing. Be detailed. Not "worked on KC7 scenarios," but the specific skills, the specific lessons, the specific moments where something clicked. The second piece was from Black Hills Information Security's Jason Blanchard and his "Job Hunt Like a Hacker" series, which is about applying OSINT and a hacker's mindset to your job search, including how you build and tailor a resume.

Putting those two together gave me the version I actually used. I kept a master document with every bullet I'd ever written about myself, organized loosely by the kind of work it represented like security analysis, incident response, CTI, threat hunting, content development, and public speaking. When a job came up, I'd read the posting, figure out which two or three of those buckets the role actually cared about, and pull from the matching sections.

I had several versions of my KC7 bullet points in particular. One that emphasized the threat intel or scenario design side, one that emphasized hands-on hunting and KQL, one that emphasized leading other contributors. Same underlying work, three different angles depending on what the job wanted to hear.

This sounds like more effort than it is but once you have a master list, tailoring takes maybe ten minutes per application. And the resumes you send are sharper, because every bullet point on the page is there for a targeted reason.

Same investigation, three different bullets

Here's an example of how the master list works. Take the KC7 work I described earlier, pivoting across email, DNS, and endpoint data to trace a phishing lure and finding extra compromised users along the way. That's one investigation. But depending on what role I was applying for, I'd write it three different ways.

For a security analyst role, the job wants to see that you can work an alert, pivot across datasets, and surface things like initial access and post-exploitation behavior.

Pivoted across email, DNS, and endpoint data to trace a phishing lure back to its sender and forward to the actor's C2 infrastructure, uncovering two additional compromised users that weren't in the original alert.

The emphasis is on the investigation itself like data sources, pivots, and what got found.

For an incident response role, the framing shifts to scope, severity, and reconstruction. Timeline of the incident, root cause, lateral movement, and a report an IR team would use to brief stakeholders.

Reconstructed the timeline of a phishing-driven intrusion across email, DNS, and endpoint telemetry, identifying initial access, lateral movement to two additional systems beyond the initial alert, and the C2 infrastructure used for persistence, producing a write-up suitable for leadership briefing.

Same investigation. Different framing.

For a threat intelligence role, the job wants actor focus and analytic reasoning. KC7 scenarios are built on real adversary tradecraft, so if you've worked through enough of them you've spent serious time mapping behaviors to ATT&CK, identifying IOCs and IOAs, and enriching what you find with sources like passive DNS to get a better picture of the actor's infrastructure.

Tracked a phishing campaign from initial lure through C2 infrastructure, mapping the actor's TTPs against MITRE ATT&CK and enriching findings with passive DNS to identify additional infrastructure. Findings were used to extend detection coverage against the same actor.

Same investigation again but this time it points to CTI work and focuses on the actor, TTPs, enrichment, and downstream impact on detection.

Same hours of investigation, three different ways to put it on your resume. Each one passes the "why does this matter?" test for the role it's written for. None of them oversell. Every claim is something I actually did with the difference being which part of the work I chose to highlight to better fit the role.

A Skills Section

Most resumes have a skills section. Mine does.

Think of this section as just an index, not the proof. The skills that actually matter, the ones you want a hiring manager to believe you have, should also show up in your experience, because that's where you've shown evidence of using them. If KQL is an important skill for the role, it shouldn't only live in a list at the bottom of the page. It should be in a bullet near the top, attached to something you found with it.

What goes in the list itself? Same test as the bullets. Did you actually do this enough to talk about it in an interview? KC7 gives you real reps with KQL, Azure Data Explorer, OSINT and the MITRE ATT&CK framework. Those belong on the list because you can defend them but things you saw once in a scenario and never really used don't.

KC7 actually makes this part easy for you. There's a page that tracks your progress through the scenarios and the skills you've built along the way. If you're staring at a blank skills section wondering what's fair to put on it, that page is a good place to start. It's not your final list but it's a record of what you've done and it'll help remind you of things you forgot you knew.

And then, like everything else, tailor it. Your master list of skills doesn't need to live on every resume. If the job is CTI-heavy, lead with ATT&CK, OSINT, actor tracking, and infrastructure analysis. If the job is analyst work, lead with KQL, ADX, log analysis, and the kill chain. Same person, same skills, different ordering, and a few entries swapped in or out depending on what the job posting actually asks for.

A short skills list that matches the role beats a long one that tries to cover everything.

A small note on honesty

Please don't oversell. If you played one scenario, that's a project not experience. If you've been steadily playing for a year, that's something else. The framing in this post works because it describes work I actually did and can defend in an interview. Investigating, pivoting, reconstructing, reporting. If you didn't do those things, don't write them. The point isn't to make yourself sound good, it's to show that you put in the work and have the experience.

It's why I intentionally didn't load this post up with more bullet points or more details than I did. Everyone who plays KC7 will have a different experience and a different way they can frame it. That's what makes security analysis so much fun in the first place. We all take our own paths to answer the same questions and the way you think and the details you find interesting are what you should be putting on your resume.

This is the post I wish I'd had

When I was breaking in, I had a really hard time talking about the work I'd done because it was outside of a paid role and a lot of people told me it wasn't the same thing. They were either wrong or lying or both lol. The truth is that the mechanics of an investigation are the mechanics of an investigation, whether that data is from your employer's tenant or from a scenario built to mirror one. Hiring managers who get it will recognize the work when you describe it well. The ones who don't, you probably don't want to work for anyway :)

It took me a lot of trial and error and a lot of versions of my resume before it looked and sounded the way I wanted it to. Expect that. I was second-guessing myself the whole time, mostly because of the people I just mentioned. It helped a lot to have someone outside my own head reading it back to me. Simeon Kakpovi and Mary Ellen Kennel both looked through more drafts of mine than we probably want to count and every round made it better. If you have someone in your corner who'll do that for you, ask them. If you don't, find one. It matters more than any framework in this post.

Write the bullet. Ask "so what?" Build the master list. Tailor every time. And put KC7 on your resume like it's the real experience it is, because it is.