What CISA’s Two-SOC Red Team Report Means for Your Next Penetration Test

If you commission one red team penetration test this year, base it on CISA’s latest advisory. The agency ran identical attack tradecraft against two US critical infrastructure organisations. It published exactly what worked, what got caught, and what made the difference. For any business planning its own test, that is a rare gift. It is a real-world answer key.

The advisory is AA26-237A, “A Tale of Two SOCs”. It came out on 25 August 2026. CISA calls the two targets Organisation A and Organisation B. Organisation A sits in the government services and facilities sector. Organisation B is a water and wastewater operator. Both were fully compromised at the domain level. Only one of them noticed. If the difference between this kind of exercise and a standard scoped engagement is not obvious, our guide to red team assessments covers it.

The attack chain your test should cover

CISA’s red team did not use anything exotic. They got in through a web application still running on default credentials. From there they sent convincing phishing emails from inside the network. Next they escalated privilege two ways. First, by abusing a Machine Account Quota left at its factory default. Second, by exploiting a misconfigured Active Directory Certificate Services template. That let a low-privilege account request a certificate that authenticates as a domain administrator.

Credential harvesting came next. They found passwords stored in plain text inside configuration files. They also found AWS access keys configured never to expire. In the cloud, they stole Primary Refresh Tokens. They rode Entra ID applications that held far more permission than their job required, and used that access to read the security team’s own inbox.

Did your last test check for default credentials on internet-facing web apps? Did it check Machine Account Quota settings, AD CS template permissions, plaintext credential storage, or over-permissioned cloud identity apps? If not, it did not test what CISA’s red team actually used. Ask your provider directly whether these sit in scope.

What separated a clean catch from a silent breach

Organisation A’s SOC saw none of it. CISA’s report points to three causes. Alert volume from routine business activity buried the real signal. Several disconnected security tools gave no shared view of the network. Analysts who did spot something lacked the authority or the ownership records to act on it. One genuine warning, tied to SCCM server activity, was dismissed because nobody could quickly confirm who owned the system.

Organisation B told a different story. Its SOC isolated the initial phishing payload within twenty minutes and severed the attacker’s command-and-control before it could spread. CISA then switched to an assume-breach approach. The same underlying weaknesses turned up, including plaintext service account credentials and a route to a DCSync attack. But tight controls on outbound network traffic stopped the red team from getting back in or reaching operational technology.

Turning this into a red team penetration test plan

Three things are worth asking your penetration testing provider before the next engagement. First, confirm the test covers Active Directory misconfiguration, not just external perimeter scanning. ESC1-style certificate template abuse and a default Machine Account Quota are common, and automated tools rarely catch them alone. Second, ask for a cloud identity component. It should cover token theft paths and Entra ID or Azure AD application permissions, since that is where CISA’s team did some of its most damaging work in both cases.

Third, run a detection exercise alongside the technical test, because that is the part it will not cover. A red team penetration test tells you whether an attacker can get in. A parallel detection and response drill tells you whether your SOC would notice. It also tells you whether the analyst who spots something has the authority to act before the attacker reaches sensitive systems. CISA’s report shows that gap, not the technical one, usually decides the outcome.

A short pre-test checklist

Run through this list before your next red team penetration test, or use it to sense-check the scope your provider has proposed:

• Are any internet-facing web applications still running default or vendor credentials?
• Is Machine Account Quota set above zero without a documented reason?
• Do any AD CS certificate templates allow low-privilege enrolment with dangerous extended key usage?
• Are any credentials stored in plaintext configuration files or scripts?
• Do any cloud access keys have no expiry or rotation policy?
• Do any Entra ID or Azure AD applications hold permissions beyond what they use?
• Can your SOC trace an alert back to a system owner within minutes, not hours?

Answer no to all seven and you sit in better shape than Organisation A did. Answer yes to even two or three, and a scoped test built around this exact path will beat a generic scan.

Reading the report afterward

A good test report does more than list findings. Ask your provider to grade each weakness by how it fits into a realistic attack chain, not just by CVSS score. A medium-severity misconfiguration that unlocks certificate abuse can matter more than a high-severity finding sitting on its own. CISA’s advisory makes the same point: it shows an attacker chaining several ordinary weaknesses into full domain compromise. A report that treats each finding as isolated will undersell the real risk.

Set a remediation deadline for anything on the CISA list specifically. These are the techniques attackers are using right now against organisations your size and sector, not theoretical risks. Then schedule a lighter follow-up check in three to six months to confirm the fixes held. Do not wait for next year’s full red team penetration test to find out they did not.