A Tale of Two SOCs: CISA Ran the Same Red Team at Two Critical-Infrastructure Orgs — One Detected It, One Never Did

What this advisory is//

On 2026-08-25, CISA published AA26-237A, "A Tale of Two SOCs: Insights From Two Red Team Assessments" (full report PDF, MITRE ATT&CK v19 mapped). The setup is rare in government intel: CISA's red team ran simultaneous assessments at two critical-infrastructure organizations using similar tradecraft, and published both outcomes side by side. Both orgs ended with full domain compromise, with sensitive business systems and cloud resources accessed. One org never detected or contained the activity. The other detected the first hits in minutes.

The two orgs, per the advisory's technical details: Organization A is in the Government Services and Facilities sector. Organization B is in the Water and Wastewater Systems sector, the same sector we walked through in this year's water-sector joint advisory, so the stakes should be familiar.

Organization A: the attack that never registered//

The red team's path through Org A, in the order CISA published it:

• Recon found a web application with default credentials on multiple built-in accounts. The team sent phishing from an internal email address, and four workstations clicked.
• A modified BloodHound collector, customized to avoid static EDR signatures, scraped Active Directory: users, computers, groups, ACLs, OUs, GPOs.
• One compromised workstation had the default Machine Account Quota of 10: any unprivileged user could add up to 10 computer accounts to the domain.
• ADCS was misconfigured with ESC1 certificate templates, letting any user request certificates for any account, including highly privileged ones. Create a machine account, request its certificate, move laterally as pretty much anyone.
• SCCM (the Tier-0 endpoint manager) provided user-to-device mapping to find the workstations holding credentials for the sensitive systems. Then cleartext credentials on user workstations did the rest.
• In the cloud, an Entra ID application with elevated Application permissions operated outside traditional Conditional Access, and let the team add a client secret and read SOC staff emails. The purpose? To check whether the SOC had noticed. They also captured screenshots, ran a keylogger on a SOC workstation, and pulled Teams messages.

And the detection story is the cringe: the SOC did receive medium- and low-severity EDR alerts about the red team's activity. They just didn't respond. Thousands of false-positive alerts, many at higher severity, were drowning them out. The org ran multiple SOCs that didn't communicate with each other and had no visibility into each other's tools. At one point the red team literally watched defenders try and fail to identify the owner of an SCCM system, then watch the alert get flagged as a false positive.

Organization B: detected in minutes, then the assume-breach gauntlet//

Org B got hit with spearphishing; three users clicked. Each payload execution generated a medium-severity alert — "An executable file loaded an unexpected DLL file." SOC staff triaged and isolated all three workstations within 10, 2, and 20 minutes. That effectively killed the team's C2.

So the red team moved to an assume-breach model: Org B's trusted agents ran a red-team-provided payload on a designated internal host, replicating the access the team would have had if it hadn't been caught. And from there:

• Org B's MAQ was 1,000 for all domain users: any user could create a machine account.
• Enumerating SCCM distribution points surfaced an XML file with cleartext credentials for a domain service account that had AllExtendedRights over a domain controller: a resource-based constrained delegation path straight to DCSync. The first account DCSynced was krbtgt — a Golden Ticket factory for impersonating any user in the domain.
• With that, they compromised a sensitive-systems web server via Kerberos ticket abuse, then moved to a bastion host in the OT DMZ using FTP credentials over SSH. The bastion's egress block stopped the C2 payload, an alert fired, and the SOC quarantined the host.
• In the cloud: cleartext credentials for the Entra ID sync account (no MFA) got them into the Azure portal. An automated Microsoft alert got them blocked there, and then Seamless SSO abuse (DCSync'd hashes, Rubeus asktgs) let them sign in as any AD-synced account without MFA. A disabled account owned an application with read-write email permissions for all users. The team re-enabled it, DCSynced it, added a client secret, and could read every user's email from the public internet.

Org B's custom detections did real work here: "Unfamiliar sign-in properties" and "Suspicious API traffic" alerts caught the AzureHound user agent and Graph API request volumes above the org's own thresholds.

The three lessons CISA writes down//

1. Untuned detection tools lead to missed threats. Org A received the same alerts Org B received. Without a baseline, false positives drown the real thing.
2. Organizational silos and bureaucratic hurdles prevent effective incident response. Org A's SOC staff had no escalation procedures and limited authority — the default became "wait and see." Org B's defenders had the authority to act, and used it.
3. Cloud environments are an underestimated risk. Both orgs had excessive application permissions, no Conditional Access for workload identities, and no mature process for revoking access/refresh tokens after a cloud compromise.

The four key actions (translated for a two-person SOC)//

1. Establish and continuously maintain a baseline, and reduce alert noise by fine-tuning. For you: one dashboard, a defined "normal," and alerts you actually act on. A Grafana that pings you 400 times a day is functionally identical to Org A's EDR.
2. Break down silos and empower network defenders. In writing: when can you act without approval? If the answer is "never," you are Org A.
3. Implement Conditional Access policies for workload identities, and monitor for excessive or unused permissions. This is the gap both orgs shared — the one that would have closed the cloud path for the red team.
4. Establish and regularly review procedures for detecting, remediating, and revoking access/refresh tokens in a cloud compromise. "We kicked them out of on-prem" is not the same as "they're out" while their refresh tokens are still valid.