TL;DR - On 25 August 2026 CISA published AA26-237A, "A Tale of Two SOCs: Insights From Two Red Team Assessments." Two critical-infrastructure organisations were hit with the same tradecraft. Organisation A had the SOC, the EDR, the SIEM, and the alert budget, and detected nothing for the entire assessment. Organisation B caught the initial phish within hours and forced CISA into an assume-breach posture. Same tooling profile, different outcome. What you need to do: (1) audit your ADCS templates for ESC1 in the next fortnight, (2) enforce Conditional Access for workload identities, not just humans, and (3) rehearse the PRT revocation procedure so the playbook is muscle memory before you need it.
I was on a call with a customer SOC team on Wednesday morning when someone asked the question I hear more than any other. "We have EDR on every endpoint, our SIEM ingests the right logs, and our alerts fire every day. But are we actually catching the attacks, or just the noise?"
It is the right question, and almost nobody can answer it from inside their own SOC. You get telemetry, you get alerts, you get a queue, you work the queue. Whether the queue contains the attack that actually landed or only the noisy proxy of an attack that did not land is the harder problem. CISA answered it for two organisations last Tuesday in a 19-page advisory that anyone running Microsoft Entra ID and ADCS should read this week.
By The Numbers
| Metric | Detail |
|---|---|
| Advisory | CISA AA26-237A, "A Tale of Two SOCs: Insights From Two Red Team Assessments" |
| Published | 25 August 2026 |
| Organisations assessed | 2 critical-infrastructure orgs, same red team, same tradecraft |
| Organisation A outcome | Detection gap across the full assessment; no alert fired during the tradecraft chain |
| Organisation B outcome | Initial phish detected inside hours, host isolated, attacker forced into assume-breach posture |
| Tradecraft stage one | Spearphish landing on a user mailbox |
| Tradecraft stage two | ADCS ESC1 template abuse for machine-cert issuance |
| Tradecraft stage three | MS-DS-Machine-Account-Quota (MAQ) abuse for new machine account creation |
| Tradecraft stage four | Application-permission pivot through Microsoft Entra ID |
| Tradecraft stage five | Lateral movement leveraging PRT (Primary Refresh Token) theft |
| Tradecraft stage six | Domain dominance or cloud-equivalent persistence |
| Lessons published | 3 (detection engineering, Conditional Access for workload identities, PRT revocation) |
The two organisations were not that different on paper
This is the part that makes AA26-237A worth reading carefully. The two organisations CISA ran the play against were not the canonical "good SOC versus bad SOC" comparison. Both had endpoint detection and response on the device fleet. Both had a SIEM ingesting domain controller, firewall, identity provider, and EDR telemetry. Both had a SOC team with detection engineering capacity and an incident response runbook.
The red team used the same five-stage chain against both. The chain started with a spearphish that landed a credential-harvesting payload. From there it escalated to ADCS (Active Directory Certificate Services) template abuse, specifically the ESC1 misconfiguration that lets a low-privileged user enroll for a certificate that grants domain-equivalent rights. The chain then used the MS-DS-Machine-Account-Quota attribute to spin up a new machine account in Active Directory, which gave the red team a second identity that the SOC's behavioural baselines had never seen. The final pivot was through Entra ID Application permissions, where the chain moved from on-prem identity to cloud identity using the kind of OAuth scope abuse that Microsoft has been quietly flagging in its own advisories all year.
The two organisations had the same starting posture. They did not have the same ending posture.
The tradecraft was identical. The SOC tuning, the escalation authority, and the Conditional Access policy for workload identities were not.
Why Organisation A detected nothing
Organisation A had the alerts that a default SIEM deployment ships with. They had the Microsoft Sentinel default analytics rules, or the Splunk content pack, or the Elastic detection rules that come out of the box. The problem with the default content pack is that it is calibrated for the noisy middle of the threat landscape, not for the tradecraft that any competent red team will actually run.
The default rules fired on the phishing payload because the phish was a credential harvester with a known indicator. They fired on the ADCS enrollment because there is a Sentinel rule for suspicious certificate enrollment. They fired on the MAQ abuse because there is a rule for that too. But none of those alerts were tuned. They were routed to the same generic queue as the spam clicks and the failed logins from old service accounts. The SOC analyst who picked them up closed them as "benign positive" within the same shift, because that is what the queue has trained them to do.
CISA describes this failure mode as "alert fatigue producing detection blind spots," which is the polite way of saying that an alert the SOC closes as benign ten times a day is not an alert anymore. It is noise the SOC has decided to ignore.
The other piece of the puzzle was escalation authority. Organisation A's SOC had a runbook. The runbook said "escalate suspected ADCS abuse to the identity team." The identity team was on a different shift. The escalation went into a ticket queue. By the time the identity team picked up the ticket, the red team had moved two stages further along the chain. The escalation authority was, in practical terms, an email to a queue that nobody was watching.
Why Organisation B caught it in hours
Organisation B had, by CISA's account, three things Organisation A did not. The first was tuned detections. They had taken the default rules and rebuilt them around the tradecraft they actually expected to see in their environment, with thresholds and exclusions written by people who had seen ADCS abuse in their own network and knew what the false-positive rate looked like in their own environment. The default rule for suspicious certificate enrollment was still firing, but in Organisation B it was tuned to fire only on certificate templates that did not have an approved enrollment list, and the analyst who owned that rule had a named escalation contact on the identity team.
The second was Conditional Access for workload identities. This is the one that matters most for the Entra ID era. Organisation B had built Conditional Access policies that applied to service principals and managed identities, not just to human users. When the red team's OAuth scope abuse tried to call a high-privilege Graph API from a workload identity that had never called it before, the policy blocked the call and the SOC got an alert. Organisation A had Conditional Access policies that applied to humans only. The same call from the same workload identity sailed through.
The third was a rehearsed PRT revocation procedure. When the red team's chain pivoted through Entra ID and stole a Primary Refresh Token, Organisation B's SOC knew exactly which three runbooks to pull, which two admin accounts to rotate, and which session revocation endpoint to hit. The procedure was muscle memory because they had rehearsed it in a tabletop exercise the previous quarter. The whole revocation took them 22 minutes. Organisation A had never tested the procedure, and on the day they needed it, they could not find the runbook.
The three lessons, written down
CISA published AA26-237A with three concrete lessons. None of them are about buying a new tool. All of them are about doing the job you already own more carefully.
Lesson 1 - Detection engineering is a program, not a one-time setup. The default SIEM content pack is a starting point. It is not the destination. Every default rule needs an owner, a tuned threshold, and a documented escalation contact. The owner is the person who answers the page when the rule fires at 2am. The tuned threshold is calibrated to the tradecraft your environment actually sees. The escalation contact is a named human, not a ticket queue. If you cannot name all three for each of your top twenty detection rules, you have a coverage gap that does not show up in any vendor dashboard.
Lesson 2 - Conditional Access has to extend to workload identities. This is the lesson that catches most ANZ Entra ID tenants. Conditional Access was designed for humans, and most orgs deployed it for humans. Workload identities (service principals, managed identities, app registrations) now outnumber human identities in the average Entra ID tenant by a factor of five or more, and they have the same OAuth scope abuse surface. The CISA advisory is explicit: any Conditional Access policy that does not have a parallel workload-identity equivalent is incomplete. The work to close that gap is mostly policy authoring and a tenant-wide audit of every app registration's consented permissions. It is not glamorous, but it is the difference between the two organisations in this story.
Lesson 3 - Rehearse the PRT revocation procedure. Primary Refresh Tokens are the long-lived cloud session tokens that Entra ID issues after a successful sign-in. If an attacker steals one, they have persistent access until the token expires or is revoked. The revocation procedure is well-documented by Microsoft, but it is also multi-step, and it touches Conditional Access, sign-in frequency, and the Global Administrator role in ways that are easy to get wrong under pressure. Rehearse it. Tabletops count. Purple-team exercises count. The point is that the person running the revocation has done it before at non-emergency pace, so that when the emergency comes the procedure is muscle memory, not a Google search.
The ADCS piece nobody is talking about
The single most actionable item in the advisory is buried on page 11. ADCS ESC1 misconfiguration is the foothold that the red team used in both assessments. ESC1 means a certificate template that allows low-privileged users to enroll, that defines an enrollee-supplied subject alternative name, and that grants enrollee-supplied SANs the right to authenticate as any other principal. It is a configuration bug that has been in the top tier of "things to fix in your ADCS deployment" since SpecterOps published the Certified Pre-Owned research in 2021, and it is still common because ADCS template configuration is one of those things nobody touches after the initial deploy.
The audit is mechanical. For every certificate template in your CA, check three things. First, does the template allow low-privileged users to enroll? If yes, you have a candidate. Second, does the template define an enrollee-supplied subject alternative name in the SAN field? If yes, the candidate is exploitable. Third, does the certificate, once issued, grant authentication rights for any other principal (Domain Admins, Enterprise Admins, the DC computer account itself)? If yes, you have ESC1 and the red team can use it to escalate from a low-privileged user to domain equivalence.
The fix is template redesign, not patching. There is no vendor patch for ESC1. There is only a configuration change to the certificate template, a re-enrollment of any certs already issued under the vulnerable template, and a documented audit trail showing the templates were reviewed and either fixed or formally accepted as risk.
What this looks like for a small ANZ SOC team
If you are a two- or three-person SOC team running EDR plus a SIEM for a single mid-size ANZ organisation, the AA26-237A lessons scale down. You do not have the budget for a full detection engineering program. You do have the time to do three things this quarter.
First, pick your top ten detection rules by alert volume, and for each one identify the named human owner, the tuned threshold, and the escalation contact. If you cannot, those ten rules are your first-quarter project.
Second, audit your Entra ID tenant for workload identities with high-privilege Graph API permissions. The query is in the Microsoft Entra audit logs under "app role assignment activities." Any workload identity with Directory.ReadWrite.All, RoleManagement.ReadWrite.Directory, or Application.ReadWrite.All should be reviewed this month. If you cannot justify the permission, remove it.
Third, run the PRT revocation procedure against a test tenant. Microsoft has a runbook in the Entra ID documentation. Walk through it once with a colleague watching, time the procedure, write down the steps in your own runbook. The next time you rehearse it will be in anger, and you want that to be the second time, not the first.
The CISA advisory is not telling you to buy anything new. It is telling you the three things you already own are the three things that separated the org that caught the attack from the org that did not. The work is unglamorous. The work is the work.
Frequently Asked Questions
Q: We do not run ADCS in our environment. Are we safe from the AA26-237A tradecraft?
A: You are safe from the ADCS pivot, but you are not safe from the workload-identity pivot. The tradecraft in the advisory is staged. ADCS was the on-prem foothold. If your environment is cloud-first, the red team will start at stage four (the Application-permission pivot) instead of stage two. Conditional Access for workload identities matters for you regardless of whether you have ADCS.
Q: How do I audit ADCS ESC1 without breaking certificate enrollment for users who legitimately need it?
A: Use the PSPKIAudit toolkit from SpecterOps, run it in report-only mode, and review the output with the team that owns the CA. PSPKIAudit does not make any changes; it just enumerates the vulnerable templates and the certificates already issued under them. The remediation is template redesign, then a phased re-enrollment, then a hardening of the CA itself to block the vulnerable templates from issuing new certs.
Q: We are a Microsoft shop but we run a SIEM that is not Sentinel. Does the AA26-237A advice still apply?
A: Yes. The tradecraft is the same regardless of SIEM. The detection engineering work is portable. The Conditional Access advice is Entra ID native. The PRT revocation procedure is Entra ID native. The SIEM only matters insofar as you can write and tune the detections that fire on the tradecraft stages.
Q: How often should we rehearse the PRT revocation procedure?
A: Once per quarter for a small SOC team. The procedure has enough moving parts (Conditional Access policy edit, sign-in frequency reset, admin role rotation, session revocation) that a six-month rehearsal cadence starts to lose the muscle memory. Quarterly is the cadence Microsoft recommends in its own Entra ID operational guide.
Further Reading
- CISA AA26-237A: A Tale of Two SOCs, Insights From Two Red Team Assessments - the 25 August 2026 advisory this post is built around
- CISA News: Advisory Highlights Red Team Findings - the CISA news page summary of the advisory
- SpecterOps: Certified Pre-Owned research - the foundational 2021 research on ADCS ESC1 abuse
- Microsoft: Workload identities overview (Entra ID) - the vendor guidance on Conditional Access for workload identities
- Microsoft: Revoke Primary Refresh Tokens (the runbook) - the procedure for revoking PRTs in an emergency
- August Patch Tuesday: ANZ SMB priorities - the broader August patch cadence context for ANZ IT-pro teams
- Metabase zero-day week two: SMBs got hit first - a parallel post on detection engineering for an SMB IT team
- CISA Known Exploited Vulnerabilities catalog - the federal feed worth tracking weekly
The two organisations in AA26-237A were not that different on paper. They were very different in execution. The work that separated them was unglamorous and already in scope. Detection engineering. Conditional Access for workload identities. A rehearsed PRT revocation runbook. None of that needs a new tool, and all of it lives inside what an ANZ IT-pro team can realistically deliver this quarter. Forward this to whoever owns your Entra ID tenant and your SIEM, and start with the audit.
Mathew Clark Founder, SecureInSeconds Currently: rewriting our own Conditional Access policies to extend to service principals, one app registration at a time.
