A Tale of Two SOCs: CISA's AA26-237A and the Control Your Audit Cannot Test

On August 25, 2026, CISA released AA26-237A, “A Tale of Two SOCs: Insights From Two Red Team Assessments.” It documents two red team engagements run simultaneously, with similar tradecraft, against two US critical infrastructure organizations: Organization A, in the Government Services and Facilities Sector, and Organization B, in the Water and Wastewater Systems Sector.

The headline result is the same for both. In CISA’s words: “In both environments, the red team achieved full domain compromise and accessed sensitive business systems (SBSs) and cloud resources.” Prevention failed twice, comprehensively, at organizations of very different size, funding, and regulatory posture.

The difference — the entire point of the advisory — is what happened next. Organization A failed to detect or contain any of it. The red team was so undisturbed that it moved onto SOC analysts’ own workstations, took screenshots, ran keyloggers, pulled their Teams messages, and read the SOC’s email through a compromised cloud application, specifically to check whether anyone had noticed. Nobody had.

Organization B detected the intrusion in minutes. SOC staff triaged the initial payload alerts and isolated the three compromised workstations in 10, 2, and 20 minutes respectively — killing command and control so effectively that CISA abandoned the covert phase and restarted under an assume-breach model, with trusted agents hand-placing a payload to simulate the access the team would have had if defenders had been asleep. Later, when the team reached a bastion host in the OT DMZ, egress filtering blocked the callback and the SOC quarantined the host. When it logged into the Azure portal with a compromised sync account, an automated alert fired and staff blocked the account.

Same techniques, same paper outcome, opposite results in practice. What separated these two organizations is precisely the control that compliance programs are worst at proving to an auditor, a board, or a regulator.

What Actually Happened: The Techniques Are Not Exotic

Nothing CISA did required a zero-day.

Organization A. Reconnaissance found a web application with default credentials [T1589.001] on built-in accounts, which let the team send mail from an internal address. Phishing from that address [T1566] landed on four workstations. A modified BloodHound collector — tuned to evade static EDR signatures — scraped AD users [T1087.002], computers [T1018], groups [T1069.002], ACLs, OUs, and GPOs [T1615]. The domain’s Machine Account Quota (MAQ) was left at the default of 10, so unprivileged users could add machine accounts [T1136.002]. Certificate templates carried the ESC1 misconfiguration (CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT enabled, low-privileged enrollment permitted), letting the team request certificates for arbitrary accounts [T1649]. That is full domain privilege from a phishing click and two configuration defaults.

The team then queried SCCM to map users to workstations [T1033], moved laterally, and harvested credentials for three sensitive business systems from unsecured files [T1552, T1552.001] — including long-lived static AWS IAM credentials configured never to expire. In the cloud, it enumerated Entra ID with AzureHound and ROADrecon [T1526, T1588.002], found applications holding sweeping Graph Application permissions (Mail.ReadWrite, Files.Read.All, Application.ReadWrite.All, AppRoleAssignment.ReadWrite.All), stole an application owner’s primary refresh token, minted a new client secret, and impersonated the application [T1550.001] to read mail [T1114]. CISA notes that Conditional Access for workload identities would have blocked this — and that “the red team never observed an organization using Conditional Access for workload identities.”

Organization B. Spearphishing from harvested public addresses [T1589.002] got three users to click [T1204]. Each payload threw a medium-severity alert — “An executable file loaded an unexpected DLL file” — and the SOC quarantined, analyzed, and reimaged all three hosts. Under assume-breach, the team found MAQ set to 1,000 for all domain users, then an XML file on an SCCM distribution point holding cleartext credentials for a service account with AllExtendedRights over a domain controller — enabling a resource-based constrained delegation attack, DCSync [T1003.006], and the krbtgt hash. Kerberos ticket abuse [T1558] reached an SBS web server; an RDP file named ics-[redacted]-org led to a bastion host in the OT DMZ, reachable with FTP credentials over SSH [T1021.004]. ADConnectDump [T1003] yielded cleartext MSOL and Entra sync credentials for an account with no MFA, and Seamless SSO abuse via Rubeus let the team authenticate as any AD-synced account lacking MFA — including the owner of an application that could read and send mail for the whole tenant from the public internet.

Organization B’s failures are real. Its detections still made the difference between an assessment and a catastrophe.

”We Passed Our Audit” and “We Would Have Caught That” Are Different Claims

Almost every control that failed at Organization A gets marked effective in the ordinary course of an audit. The SOC existed — multiple SOCs, in fact. EDR was deployed, more than one product. Alerts fired. Logs were collected. An auditor sampling that environment would find a documented monitoring process, evidence of alert review, ticket records, and tool configuration screenshots. The control would pass.

And yet: “The red team observed that the SOC received medium- and low-severity EDR alerts related to the red team activity but did not respond to them. Thousands of false positive alerts corresponding to normal business operations, many with a higher severity, obscured the alerts triggered by red team activity.”

Map that to the frameworks:

• SOC 2 CC7.2 requires monitoring system components for anomalies indicative of malicious acts. Organization A monitored. It did not notice. Tests of design and of operating effectiveness based on alert-review samples do not catch that difference.
• SOC 2 CC7.3 and CC7.4 cover evaluating events to determine whether they constitute an incident, and responding. Organization A’s SOC discussed an SCCM alert in chat, could not identify the system’s owner or purpose, and closed it as a false positive. That is CC7.3 operating — and producing the wrong answer, with no exception an auditor would sample into.
• ISO/IEC 27001:2022 Annex A 8.15 (logging), A 8.16 (monitoring activities), and A 5.25 (assessment and decision on information security events) describe the chain that broke. The logs existed. The monitoring existed. The assessment-and-decision step ran and decided “false positive.” A certification audit sampling event records finds A 5.25 in place.
• NIST CSF 2.0 DE.CM (continuous monitoring) and DE.AE (adverse event analysis) are the functional home of this failure; CSF 2.0’s GV function is where the organizational half lives. Organization A’s pathologies — multiple SOCs with no cross-tool visibility, no communication between SOC staff and system owners, no escalation SOPs, analysts with “limited personnel authority” — are governance failures (GV.RR, GV.PO, GV.OC), not detection-engineering failures. As CISA puts it: “Detection tools are only as effective as the people, processes, and procedures supporting them.”
• NIST SP 800-53 gives the same picture across SI-4 (system monitoring), AU-6 (audit record review, analysis, and reporting), and IR-4 (incident handling). All three can be implemented, documented, and assessed as satisfied while an adversary walks the domain unremarked.

The gap is not that these controls are badly written. It is that they are evidenced by artifacts of process — policies, procedures, tool configurations, sampled tickets — and not by outcomes. The only 800-53 controls above that test outcomes are CA-8 (penetration testing) and, at a stretch, RA-5. CA-8 is what AA26-237A actually exercises, and in most matrices it is satisfied by an annual scoped pentest whose report nobody maps back to DE.CM.

So: “we passed our audit” is a claim about the existence and documented operation of controls. “We would have caught that” is a claim about how a socio-technical system behaves under adversarial pressure. Organization A could truthfully make the first claim on the morning CISA read its SOC’s email.

The Water Sector Problem: Organization B Is the Good News, and It Is Still Hard

That the detecting organization is a water and wastewater utility is worth sitting with, because the sector’s reputation runs the other way: tens of thousands of systems, most small, many with no dedicated IT staff, funded by rate bases voters resist raising. And the sector’s compliance scaffolding is thinner than it looks:

• America’s Water Infrastructure Act (AWIA) 2018, Section 2013 requires community water systems serving more than 3,300 people to conduct risk and resilience assessments and prepare or revise emergency response plans within six months of certifying each assessment, on a five-year cycle. It covers “electronic, computer, or other automated systems (including the security of such systems)” — but mandates assessment and planning, not any particular control, and certainly not a tested detection capability.
• EPA sanitary survey cybersecurity expectations have had a turbulent history: the 2023 interpretive memorandum requiring cybersecurity evaluation within sanitary surveys was withdrawn after litigation, leaving guidance and voluntary assessment support rather than an enforceable detection requirement.
• The WaterISAC 12 Fundamentals remain the most practical sector-specific baseline, and several map directly onto this advisory: minimize control system exposure, enforce user access controls, develop and enforce cybersecurity policies and procedures, implement threat detection and monitoring, and plan for incidents and emergencies.
• CISA’s Cross-Sector Cybersecurity Performance Goals (CPGs) are the baseline AA26-237A’s mitigations cite: CPG 1.A/1.B, 3.F (phishing-resistant MFA), 3.G, 3.H (least privilege), 3.I (IT/OT segmentation), 6.A (IR exercises).

None of that adds up to a mandate to detect. Organization B detected anyway, and what it had was not a 24/7 fusion center. A realistic minimum viable SOC looks like this:

1. One EDR product, tuned, with alerts routed somewhere a human reads them. Organization B’s saving alert was a medium-severity DLL-load detection — an out-of-the-box signature, visible rather than buried.
2. A defined baseline of normal — installed tools, software, account behavior, network traffic — continuously maintained. Without it, tuning is guesswork.
3. Egress filtering that actually blocks. Organization B’s OT DMZ bastion host had no outbound internet access. The payload ran; the callback died. That control is cheap and deterministically testable.
4. Authority to isolate a host without a change advisory board. Two minutes to quarantine is a delegation achievement, not a tooling one.
5. Cloud alerts that reach the same analysts. Organization B’s custom Entra ID Risky User detections for “unfamiliar sign-in properties” and “suspicious API traffic” — firing on the AzureHound user agent and on accounts exceeding Graph API request thresholds — are the advisory’s most transferable artifact.

The sector’s exposure to real adversaries is documented in the CyberAv3ngers PLC campaign against water and wastewater systems and CISA’s AA26-097A update on Iranian targeting; the enforcement consequence of getting it wrong, in the ICO’s £963,000 fine against South Staffordshire Water.

The Federal Side: Organization A Sits Inside a Compliance-Heavy Regime

Organization A very likely operates under a FISMA authorization with a NIST SP 800-53 control baseline, a system security plan, a POA&M, and an authorizing official who signed an ATO. It is, by construction, the more heavily audited of the two. It detected nothing.

That is not an argument against FISMA but about what its implementation habits reward. An assessment package documents control implementation at a point in time; continuous monitoring under the RMF was meant to close that gap, and CDM (Continuous Diagnostics and Mitigation) to instrument it. CDM dashboards answer “what is on the network and is it patched” well, and “did anyone act on the alert” badly.

The directive layer has the same shape. CISA’s binding operational directives — the BOD 22-01 KEV remediation regime, BOD 25-01’s secure cloud configuration baselines, the patching mandates behind the BOD 26-04 August 7 deadline for Fortinet and Arista KEV entries — are structurally prevention and hygiene mandates. They tell agencies to close doors. AA26-237A is about what happens after a door opens anyway. No BOD says “prove your SOC can see a DCSync.”

BOD 25-01 is nonetheless directly implicated. Its SCuBA secure configuration baselines for Microsoft 365 and Entra ID, assessable with CISA’s free ScubaGear tool, address exactly the application-permission and Conditional Access failures exploited in both organizations — the highest-yield hour available from this advisory. The same cloud-identity blind spot appears in our analysis of FISMA major incident determinations after the FBI DCSNet compromise.

Turning the Advisory Into an Audit Instrument

The productive use of AA26-237A is as a question set for internal audit or a board risk committee — questions a control matrix structurally cannot answer, phrased so that “yes, we have a policy for that” is not a valid answer.

On detection performance:

• What was our mean time to detect in the most recent live purple-team scenario, measured from first adversary action to analyst acknowledgement? If we have never measured it, say so on the record.
• For the last simulated intrusion: did an alert fire, and did a human action it? Two separate answers — Organization A’s alerts fired.

On evidence and retention:

• How many alerts per analyst per shift, what share are dispositioned false positive, and is any severity tier auto-closed by policy? Organization B’s saving grace was a medium-severity alert.
• Does log retention exceed our dwell-time assumption? If median dwell time exceeds the retention window, we cannot investigate what we detect late.
• Are the logs evidencing this advisory’s techniques — AD certificate enrollment, machine account creation, DCSync replication requests, Graph application-permission grants, new client secrets on service principals — collected at all, and searchable?

On the identity plane:

• Is the identity plane monitored as a detection surface, or only as an access-control surface? Do we alert on machine account creation, ADCS issuance with a supplied subject, AppRoleAssignment.ReadWrite.All grants, and client secrets added to existing applications?
• Do we use Conditional Access for workload identities? CISA states its red team has never observed an organization that does — a defensible finding for a board paper.
• Are AD-synced service accounts exempt from MFA, and if so, can they reach the cloud portal?

On scope of visibility:

• Do cloud and OT telemetry reach the same analysts who see endpoint telemetry, in the same queue? Organization A had multiple SOCs with no cross-visibility; that is an architecture, not an accident.
• Who owns every Tier 0 asset — domain controllers, ADCS, SCCM/Jamf/BigFix — and can the SOC find that owner at 2 a.m.? Organization A’s could not, which is why its alert was closed as a false positive.
• Can an analyst isolate a production host without prior approval? Name the policy clause and the maximum time to execute.

Building Evidence That Detection Works

The conclusion follows: adversary emulation is the only credible evidence of DE.CM effectiveness, and it must produce auditable artifacts rather than a PDF nobody maps to a control. CISA’s “Validate Security Controls” section supplies the method: select an ATT&CK technique from the advisory’s tables, align your security technologies against it, test, analyze detection and prevention performance, repeat across all technologies, and tune people, processes, and technology on the resulting data — continually, at scale, in production. To make that auditable rather than anecdotal, each execution should produce a record with a fixed schema:

Field	Example
Scenario ID and date	PT-2026-014, 2026-09-18
ATT&CK technique	T1003.006 — OS Credential Dumping: DCSync
Target system / tier	Domain controller, Tier 0
Alert fired?	Yes / No, with timestamp
Analyst acknowledged?	Yes / No, timestamp, analyst ID
Ticket reference	INC-88213
Time to detect / contain	00:06 / 00:41
Outcome	Detected, not contained
Control mapping	CC7.2, CC7.3, A 8.16, DE.CM-09, SI-4(4), IR-4
Remediation task	JIRA SEC-2291, owner, due date

That table is the artifact: samplable, trendable quarter over quarter, mapping a real event to a real control identifier. Ten rows a quarter is a working continuous-validation program, and unlike a narrative pentest report it is something a board can read as a metric. A negative result — “alert fired, nobody acknowledged” — is a control deficiency you found yourself, a far better position than having a regulator or an adversary find it.

Use purple teaming rather than covert red teaming for evidence purposes — it produces more control-mapped data points per hour — and let scenarios cross the boundaries the org chart draws: the path here ran endpoint → AD → SCCM → SBS → Entra ID → Graph API, and at Organization A each segment had a different owner.

If You Suspect You Are Organization A

A list ordered by risk reduction per unit of effort:

1. Set MAQ to 0 unless a documented business need exists. Both organizations were compromised through this setting — one at the default of 10, the other at 1,000.
2. Audit ADCS templates for ESC1. Disable CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT where not required, restrict enrollment, strip FullControl/WriteDacl/Write from domain users on template objects, and enforce manager approval (see CISA’s joint guidance Detecting and Mitigating Active Directory Compromises).
3. Run ScubaGear against your M365/Entra tenant, remediate to the SCuBA baselines, and inventory Graph Application permissions. Remove what is not needed — Mail.ReadWrite, Files.Read.All, Application.ReadWrite.All, AppRoleAssignment.ReadWrite.All — and find every application owned by a disabled or orphaned account.
4. Implement Conditional Access for workload identities, and alert on new client secrets and certificates added to existing service principals.
5. Kill long-lived static credentials. Audit AWS IAM access keys, disable unused ones, and move human access to SSO-issued temporary credentials.
6. Scan shares, workstations, and jump servers for plaintext credentials — including OT jump servers, where Organization B’s were found — and vault them.
7. Write and exercise a token revocation runbook for cloud compromise; both organizations lacked one, which means eviction from on-prem does not evict the adversary.
8. Declare Tier 0 explicitly — domain controllers, ADCS, SCCM/Jamf/BigFix, PAM vaults — with named owners and dedicated monitoring.
9. Fix the authority problem, then the silos, then the noise. Write down who may isolate a host, block traffic, or disable an account without escalation, and rehearse it (CPG 6.A). Give every SOC visibility into the others’ telemetry. Track alerts per analyst per shift and false-positive rate as board metrics. An analyst drowning in higher-severity false positives is not a monitoring control; it is the appearance of one.

Conclusion

The most quotable detail in AA26-237A is that CISA’s operators read Organization A’s SOC email to see whether the SOC knew. The most useful is that Organization B’s defenders isolated a host in two minutes on a medium-severity alert.

Neither is a control you can screenshot, or test by sampling a policy document or a quarter of closed tickets. Yet the entire difference in outcome between a heavily audited government agency and a chronically under-resourced water utility lived in that gap.

The correct response is not to add a row to the control matrix. It is to accept that the matrix cannot answer the question, and to build the instrument that can: a recurring, control-mapped, artifact-producing adversary emulation program whose outputs are timestamps and ticket numbers rather than prose. Prevention will fail — it failed identically in both organizations here, at the hands of default settings and cleartext passwords. What separates a bad quarter from a reportable catastrophe is whether anyone is watching, and whether the watcher is allowed to act. Those are auditable facts, and most organizations have never audited them.

Sources: CISA — AA26-237A: A Tale of Two SOCs, The Hacker News — CISA Red Team Compromised Two Critical Infrastructure Orgs, One Detected Nothing, Security Affairs, Cybersecurity News — CISA Red Team Breaches Critical Infrastructure, CISA — Cross-Sector Cybersecurity Performance Goals, CISA — SCuBA Project, SpecterOps — Certified Pre-Owned, WaterISAC — 12 Cybersecurity Fundamentals

This article is provided for informational purposes only and does not constitute legal advice.