Most of us started by manually enumerating and threat hunting on our machines. We found a backdoor here and there, along with some domain users with DCSync rights (Recycle Bin, haha). We used OpenCode more and more as the invitational went on. The room got quieter too, since we were spending less time typing commands ourselves and more time reading what the agents were doing.

It was quite frightening. By the end of the competition, we all kind of sat back and discussed what we had done. We came to the conclusion that two possible paths lay in front of us:

1. Refuse to use AI in subsequent invitationals and competitions, and attempt to learn everything by hand.
2. Commit to the dark side and accept that the future of cyber competitions, and perhaps cybersecurity as a whole, hinges on practical applications of AI.

Such a realization is quite a grim one, but indeed it seems that’s where things are going. In The CTF scene is dead, Kabir Acharya, a CTF competitor who has played with TheHackersCrew, writes:

Teams that refused to use AI were not just missing a convenience; they were playing a slower version of the competition.

This trend isn’t limited to CTFs. I believe refusing AI in RvB competitions where it’s allowed puts you at a competitive disadvantage, and orchestration itself has become a competitive skill.

Where we go from here requires some reflection. Our team leads and I are becoming AI-pilled, and we’re thinking about what we could create to compete in this new RvB landscape.

The Dark Solution

Our plan is to build a lightweight harness around OpenCode, orchestrating a swarm of instances running on the student competitors’ machines to harden a CCDC environment. Since we can’t use paid AI services, we’d use free models available through OpenCode. The orchestrator would itself be an OpenCode instance, with access to the scoring website, service dashboards, and inject portal.

The main features we brainstormed are:

1. Injects. The orchestrator would complete injects using a template we’d created, gathering relevant findings from the agents. We’d review and submit the responses ourselves to ensure they’re valid.
2. Service-specific skills and playbooks. Each OpenCode instance would have skills geared toward its assigned systems: Windows, AD, Linux, routers, etc. It would also have playbooks for tasks like rotating credentials at the beginning of competition. We’d run the instances in VMs, taking advice from Krauq’s AI Power User Guide, so their tools and working files stay off our main machines.
3. Scoreboard monitoring. The orchestrator would scrape the scoreboard to see which services are down and direct the relevant agents to investigate and restore them.
4. A shared discussion board. Agents would share findings and coordinate changes, since some services rely on others. A Linux service using AD authentication, for instance, would need its agent to coordinate with the AD agent before changing the account it uses.
5. Credential management. A shared credential manager would be updated whenever an agent rotated credentials, keeping the team and other agents working with the current passwords.

High-level architecture, admittedly drawn by AI

References

• OtterSec: Announcing the Save CTFs Fund
• Kabir Acharya: The CTF scene is dead
• Krauq’s AI Power User Guide

We’re also trying to get Cornell project team status. Last year, our application was denied in favor of CSalt, a team focused on “marine energy solutions.” I still have a hard time understanding that decision, given that we’re Cornell’s only cybersecurity organization. The emphasis on project-based work has made CCDC a harder sell. I find that frustrating given how much work goes into preparing for it, including building this lab.

We bought our first server for Cybear Day 2026, our first public event. We’d planned our own red-vs-blue (RvB) competition, but we hadn’t prepared enough or recruited enough participants, so it didn’t really work out. I will say, I still enjoyed seeing a group of students spend the afternoon together because they were interested in security.

The server barely got used during the event, so afterward we decided to turn it into a practice environment. Members could set up the services they’d eventually defend and get some experience managing the infrastructure themselves.

That server and the PCs donated by CCRA make up our entire infrastructure setup at the Radio Club tower. Thanks to CCRA for the PCs and to the Radio Club for giving us somewhere to put them.

[IMAGE: the racks at the Radio Club]

The Windows Side

Bill, our vulnerability research and CTF lead, and I handle all of the Windows work. Most of the team works on Linux. I’d prefer working on Linux as well—everything feels so much more intuitive—but someone has to handle Active Directory (AD), and there weren’t many people willing to touch Windows at all.

Last year, I barely had any experience hardening Windows, especially in the rhythm of an RvB competition. My experience centered on some red teaming I’d done at a past job, which I really enjoyed. At our last CCDC, we made the mistake of using heavily AI-generated hardening scripts with cool interfaces and stuff. We barely tested them, and they ended up shooting us in the foot. Some changes disabled compatibility features that services relied on, and we lost availability points as a result. While I don’t think using AI to write scripts is necessarily wrong, a player should be deeply familiar with how their scripts work and should test them thoroughly in a running lab environment.

With that in mind, this year I want to know what each change does before we deploy it. We’ll run the scripts against a domain and check the services afterward. We also need to be able to undo whatever breaks.

I decided on GOAD-Light, a vulnerable Active Directory lab with three Windows machines. It’s kind of similar to what we see in a real CCDC environment, except without the command-and-control implants (C2s) and registry madness. It’s small enough for our hardware and gives us a domain with misconfigurations to fix. It also supports Proxmox, which our server was already running.

Running It

Remote access was limited at first, so I used the Proxmox API to stage the installer ISOs directly on the host, then added an SSH forward for shell access.

Packer installed Windows Server 2019 into a template. Terraform then created linked clones, and Ansible configured the domains and services. To be honest, I was expecting a pretty painful process of fixing every Ansible step. A previous attempt to run GOAD on my own machine had been very frustrating.

The template took about 72 minutes to build on our 1.6 GHz Xeons. Once it was ready, Terraform gave me this plan:

Plan: 3 to add, 0 to change, 0 to destroy.

The resulting lab looked like this:

Waiting for Windows

It wasn’t all sunshine and rainbows, so I’ll sprinkle in some of the issues I faced. The setup was far more involved than this shows, but I’d rather not bore you with every detail. The first Ansible run failed with:

No route to host

Provisioning had started about two minutes after the clones booted. On our hardware, Windows took roughly fifteen minutes to apply its network configuration. I needed to wait for networking and WinRM to become reachable before starting Ansible.

Later, SQL Server Management Studio sat installing for close to five hours. I wasn’t sure whether it was just our really slow hardware or something else interfering with the installation. I realized Defender’s real-time protection was scanning every new file on that lab machine, leading to crazy overhead. Once I disabled it, the installation finished within minutes. GOAD’s configuration called for it to be disabled anyway, but I hadn’t caught that before waiting on the installer.

I also wanted to follow proper homelabbing practices, so I put the VMs on vmbr1, a bridge with no physical ports. A small container at 192.168.56.1 provides DNS, DHCP, and NAT for internet access. The vulnerable machines stay off the physical LAN.

The lab VMs and scoring container in Proxmox.

Checking the Services

Once the domain was fully up and running, I wanted to make the lab feel more like a competition environment, so I looked into scoring engines. I know most RvB competitions use Quotient for scoring, but I found another option that seemed more actively maintained: CCDC ScoringEngine. I deployed it in another container. We have ten checks covering DNS, LDAP, RDP, MSSQL, WinRM, IIS (HTTP), and ICMP, running every 180 seconds.

Getting those checks green took some debugging too. The LDAP checks failed until I used the accounts’ CN-based distinguished names in the bind configuration. Another failure came from an inline YAML mapping: an unquoted comma cut off the base DN in DC=sevenkingdoms,DC=local.

Reading the individual check output helped separate scoring configuration errors from problems on the Windows machines. Eventually, all ten checks passed.

All ten checks passing in the scoring dashboard.

I saved the working VMs with a snapshot named working-state. To reset a VM between sessions:

qm rollback <vmid> working-state

We now have a baseline to test our scripts against. In the next post, I’ll discuss what went into creating our Windows hardening scripts.