The SOC That Caught Everything Still Lost KRBTGT

On 25 August, CISA published advisory AA26-237A, “A Tale of Two SOCs.” It compares two red team assessments run against two critical infrastructure organizations with similar tradecraft and opposite detection outcomes. The industry read it, correctly, as a story about detection maturity. Organization A caught nothing; thousands of false positives from siloed SOCs that never shared visibility buried the signal. Organization B caught the phishing payload and isolated it in two to twenty minutes.

Everyone is holding up Organization B as the good outcome. It is the good outcome. And I want to talk about it anyway, because Organization B is the one that should scare you more.

Here is what happened at the org that did detection right. The SOC saw the initial phishing, severed command and control before it spread, and did exactly what a mature SOC is supposed to do. So CISA, running an assume-breach model, dropped a payload on a designated non-privileged host to continue the assessment. And from there, the red team found cleartext credentials for a domain service account sitting in a System Center Configuration Manager config file. That account had rights over a domain controller. They ran a DCSync and pulled the krbtgt secret.

The krbtgt account anchors Kerberos in an Active Directory domain. Its hash lets an attacker forge tickets for any user or service, indefinitely. That is game over for the domain. And the organization that CISA is holding up as the detection success story handed it over through a service-account password left in plaintext in a config file.

Detection maturity bounded the damage. It did not touch the thing that caused it.

Two Orgs, One Identical Disease

Read the advisory as an identity practitioner and the “tale of two SOCs” framing starts to feel like it is describing the symptom while the diagnosis sits underneath, the same in both patients.

Walk Organization A’s chain. Initial access through a web application running default credentials on a built-in account. Privilege escalation through a Machine Account Quota left at its default, letting any domain user add machine accounts, combined with misconfigured AD CS certificate templates, the ESC1 pattern, letting them request a certificate as any user. Lateral movement using cleartext credentials found on reachable systems, including a decrypted database config and static AWS access keys that CISA notes “were set never to expire.” Cloud compromise by stealing a Primary Refresh Token and abusing over-permissioned Entra ID applications to read the security team’s own email.

Now Organization B. Different SOC, different outcome, identical underlying exposure: cleartext service-account credentials in an SCCM config, rights over a domain controller, DCSync, krbtgt.

There is no malware story in either chain. No zero-day, no custom implant, nothing an attacker would bother writing up. From initial access to domain dominance to cloud, every single pivot rode a non-human identity that was misconfigured or left lying around in cleartext. Default credentials. A service account with domain-controller rights. Static keys set never to expire. Over-scoped OAuth applications. That is the entire attack surface CISA documented, in both organizations, and it is a credential surface from top to bottom.

The two SOCs differed. The identity debt was the same. And the identity debt is what actually lost the domain.

Why "Our SOC Is Good" Is the Dangerous Conclusion

The comfortable reading of AA26-237A is: be Organization B. Fix your alert fatigue, unify your SOCs, and you will be the success story. That reading will get organizations breached, because it treats detection as the finish line when detection is the backstop.

Detection is what happens after an identity has already been abused. Organization B’s SOC was excellent, and by the time it could have mattered for the krbtgt compromise, the red team was already authenticating with a service account that should never have had domain-controller rights and should never have stored its password in cleartext. No alert un-forges a golden ticket. The best detection in the advisory bought containment of the initial foothold and nothing at all for the identity exposure sitting one config file away.

This only matters more as the attacker tempo changes, and it is changing fast. CISA’s red team is human, and human red teams operate on human timelines. So ask what this same chain looks like once the operator is an agent instead of a person.

We have already watched what that looks like. Last November, Anthropic documented GTG-1002, a Chinese state operation that used Claude Code to run a standard APT kill chain, reconnaissance, credential harvesting, lateral movement, exfiltration, at 80 to 90% autonomy and, in their words, “physically impossible request rates.” This month, researchers documented near-autonomous agents attacking Taiwan’s nuclear safety agency, running up to eight sub-agents across twelve attack waves over four days, cracking 85 accounts by spraying employee-ID patterns. That is the operator profile these identity misconfigurations now face.

Organization B’s two-to-twenty-minute detection is genuinely good against a human. Against an agent that harvests a cleartext service-account credential, DCSyncs, and forges tickets in the time it takes an analyst to open the ticket, “we caught the phishing fast” is the floor you start from, the minimum viable outcome. The window between initial access and domain compromise is being compressed to machine speed, and the only defense that operates faster than that window is the credential being worthless to exploit in the first place.

What to Do This Week

Read AA26-237A. Fix your alert fatigue and unify your SOCs, because Organization A’s failures are real and CISA is right about them. But do not stop at the detection lesson, because the detection lesson did not save krbtgt. Go after the identity debt that was identical in both organizations.

• Hunt cleartext credentials in config files, and start where CISA found them. SCCM configs, database configs, deployment scripts, .env files. A service-account password in plaintext is a domain compromise waiting for a foothold nearby, and detection will not be fast enough to matter.
• Find every service account with rights it should not have, especially rights over a domain controller. The account that lost Organization B’s domain should never have been able to. Scope down or eliminate anything that can DCSync.
• Kill static keys set never to expire. CISA called out AWS access keys with no expiry and no revocation path. Every one of those is how Organization A lost its cloud. Move to short-lived, workload-bound credentials.
• Audit AD CS templates for ESC1 and reset Machine Account Quota. The two misconfigurations that gave Organization A its domain are both defaults. Both are one-time fixes. Do them.
• Inventory over-permissioned Entra ID and OAuth applications. An app that can read every user’s mail is how the attacker watched Organization A’s security team react. Enumerate what your applications can reach and cut it to what they use.

CISA framed this as a story about detection, and detection is a real part of it. But the advisory’s own best-defended organization still lost the keys to its domain, and it lost them to a service-account password in a config file, with its SOC working exactly as designed. Detection tells you the house is on fire. It does not make the house out of something that will not burn.

Be Organization B on detection. Do not be either organization on identity.