The organization that missed the intrusion was not blind. Its EDR fired alerts on the red team's activity. They were rated medium and low, they sat in the queue, and nobody acted on them.
The tools worked.
What Happened?
In August 2026, CISA published advisory AA26-237A, "A Tale of Two SOCs," on red team assessments at two critical infrastructure organizations.
Organization A sits in Government Services and Facilities. Organization B is in Water and Wastewater Systems. At Organization A, the red team progressed from initial access to elevated domain privileges, sensitive business systems, and cloud resources without effective containment. Organization B detected and isolated the initial compromise within minutes, forcing CISA to continue the assessment using an assume-breach host.
How Did the Red Team Get In?
At Organization A, the team found a web application using default credentials for a built-in account. That gave them an internal email address to phish from. At Organization B, spearphishing emails led three users to click a malicious payload, giving the red team access to three workstations.
Across the two assessments, CISA found familiar identity and configuration weaknesses, including AD CS ESC1 at Organization A, permissive Machine Account Quotas, cleartext credentials, excessive service-account permissions, and weak cloud application controls.
- Machine Account Quota was risky in both environments: Organization A had the Windows default of 10, while Organization B allowed domain users to create up to 1,000 machine accounts
- At Organization B, an overprivileged service account with AllExtendedRights over a domain controller enabled resource-based constrained delegation abuse and DCSync
- Both organizations had cloud identity weaknesses, including excessive application permissions and missing Conditional Access protections for workload identities
Nothing here required a zero-day. Every item is a configuration decision.
What Made the Difference?
Organization B triaged the payload alerts and manually isolated the three workstations within 10, 2, and 20 minutes, cutting command-and-control. Later in the assume-breach assessment, Organization B blocked outbound C2 from an OT bastion host and isolated it. A suspicious Azure login also generated an automated alert, leading defenders to block that account, although the red team later found another route into Entra ID.
Organization A received medium and low severity EDR alerts on similar activity and did not act. CISA attributed this to thousands of false positives drowning real signals, SOCs operating in silos, analysts without clear authority, and no escalation path.
CISA used similar tradecraft in both assessments. The major difference was how effectively defenders triaged, escalated, and acted on alerts.
Why Does It Matter?
CISA's conclusion is blunt: detection tools are only as effective as the people, processes, and procedures supporting them.
Both organizations here had detection capability. The gap was tuning, ownership, and permission to act.
The alerts that mattered at Organization A were medium and low. A queue triaged by severity alone deprioritises exactly the signals that were real.
Common Mistakes
- Leaving detection untuned. Thousands of false positives are not coverage. Real alerts get buried.
- Splitting responsibility across silos. Unclear boundaries slowed response to zero.
- Withholding authority from analysts. Detection without permission to act is observation.
- Treating cloud as out of scope. CISA identified weak cloud token-response processes in both environments. It also found long-lived AWS IAM credentials at Organization A and excessive cloud application permissions across the assessments.
How to Reduce the Risk
- Baseline normal activity and tune alerts continuously, not just at deployment
- Define who can isolate a host, and let them act without waiting for approval
- Write escalation paths down, then test whether people follow them
- Set Machine Account Quota to zero where it is not required, and remediate insecure AD CS templates such as ESC1 by restricting enrollment and subject-supply permissions
- Remove cleartext credentials from files and move them into a managed vault
- Replace long-lived cloud keys, apply Conditional Access to workload identities, and build a token revocation procedure
What Should Security Testing Cover?
Ask your testers to establish:
- Whether simulated attack activity generates alerts, and at what severity
- Whether anyone triages those alerts, and how long it takes
- Who has authority to isolate a host, and whether they use it
- Whether escalation works outside business hours
- What an attacker reaches before containment
How OraSec Can Help
OraSec runs red team engagements built around the question this assessment answers. We simulate a full attack chain and measure what your SOC sees, what it escalates, and how long containment takes. You get evidence of whether detection turns into response.
Conclusion
If you take one thing from AA26-237A, take this: the failing SOC had alerts. Ask whether yours would be read, escalated, and acted on tonight.
FAQs
What is CISA advisory AA26-237A? Published in August 2026 as "A Tale of Two SOCs," it documents red team assessments at two critical infrastructure organizations with very different detection outcomes.
Did the organization that missed the attack have security tools? Yes. Its EDR generated alerts rated medium and low. The failure was in triage and response, not detection capability.
How quickly did the effective SOC respond? Organization B isolated three workstations within 10, 2, and 20 minutes of the initial alerts.
What is the fastest improvement to make? Tune out false positives and confirm someone has the authority and procedure to isolate a host quickly.
