← Writing Postmortem by

NECCDC 2026: what we got right, what stung

A first-person NECCDC 2026 blue team postmortem: two days defending Active Directory against a professional red team, what worked, what failed, and what we would do differently.

In March I competed at NECCDC regionals in Lowell as the Domain Controller administrator for the St. John’s blue team. Two days, two Active Directory domains, a professional red team, and a scoring engine that charges you for every minute a service is down. These are the notes I wrote afterward: what went well, what didn’t, and what we’d do differently. The runbooks we used are on GitHub, rough edges left in.

What we got right

OU structure and least privilege. We built out the OU hierarchy early on day one and pushed users into the right buckets. Made GPO application predictable. Worth the time investment.

Persistence hunt before hardening. Running the four-command check before touching configs caught two scheduled tasks we would have hardened around otherwise. Always hunt first.

Black Team ticket templates. When the POS went down, having a pre-written ticket template saved time and kept the question competent enough that we weren’t charged points for it.

What we got wrong

Tried to build a trust from one side only. First attempt at the cross-domain trust failed because we only had RDP to one DC. Should have confirmed both DCs were accessible before starting. Lost time we didn’t have.

Didn’t access Keycloak until day two. Keycloak federates auth for multiple scored services. It should have been a day-one priority alongside the DC. Lesson: identity infrastructure first, services second.

Under-documented day-one GPO changes. We configured PowerShell logging GPOs but didn’t screenshot the gpresult output on multiple hosts. Same exact mistake the quals feedback called out. Documentation has to happen in real time, not after the fact.

Lost the POS for too long. Once it was compromised we spent too long trying to recover it ourselves before submitting the Black Team ticket. There should be a hard time limit: fifteen minutes of self-recovery attempts, then ticket. The point cost of the ticket is less than the lost service score.

What surprised us

The red team adjusted between days. Day-two attacks were different from day one. They had watched our hardening and targeted what we hadn’t gotten to yet. Obvious in retrospect.

Scoring-engine timing matters. Restarting ADFS to apply a config change caused a service-check failure during the restart window. Plan service restarts during quieter scoring windows if you can predict them.

Business-continuity scoring is significant. Five points per failed employee-access check adds up. We were too aggressive on one firewall rule and locked out a check. Less hardening would have scored higher than the hardening that broke the check.

What we’d do differently

Pair on the trust. Two people on the trust setup at once, one on each DC. Don’t try to do it serially across two RDP sessions.

Identity stack first. Keycloak, then DC, then services. Anything that authenticates anything else gets priority.

Document before hardening. Open a screenshot folder and a notes file before touching anything. Every change gets a before/after pair. Doesn’t matter if it looks excessive. The IR points come from documentation.

Pre-write inject responses. Have templated executive-summary openings ready. The technical work is easy. The professional writing under time pressure is what kills scores.

Don’t trust your day-one hardening on day two. Re-verify everything in the first ten minutes of day two. The red team works overnight.

What I wish I’d known going in

Most of the points are in two places: documentation quality and business-impact communication. The technical work is necessary but not sufficient. The teams that score highest can articulate why what they did matters to a non-technical executive.

If I had to put one piece of advice on a sticky note for next year’s team: screenshot everything with a visible timestamp, write the executive summary first, fill in the technical work as you go.