The contrast is the point of CISA’s A Tale of Two SOCs report. Organization A, in the Government Services and Facilities sector, received endpoint alerts but failed to act as the red team moved from phishing to full Active Directory compromise, sensitive databases, AWS credentials, and Microsoft 365 email. Organization B, a Water and Wastewater Systems organization, contained the opening phishing activity quickly enough that CISA had to continue under an assume breach model using an approved internal foothold.
That makes this more useful than a conventional “phishing succeeded” warning. CISA shows two different failures: one operational, where alert volume and unclear authority caused a SOC to miss an intrusion it was being shown; the other architectural, where decisive response contained individual hosts but could not compensate for privileged service accounts, plaintext credentials, and hybrid-identity paths that enabled deeper access.
Organization A missed an intrusion its tools had already flagged
CISA says the red team found a web application using default credentials for built-in accounts, then used an internal email address to send phishing messages and compromise four workstations. From there, it customized a BloodHound collector to avoid static endpoint detection and response signatures, mapped Active Directory, and found the domain’s Machine Account Quota still set to the Windows default of 10.
That quota allowed an unprivileged user to create machine accounts. Combined with an Active Directory Certificate Services template vulnerable to the ESC1 misconfiguration, it gave the team a route to request certificates for arbitrary users and computer accounts. In practical terms, a configuration that is often treated as legacy directory plumbing became a lateral-movement mechanism.
The team then used SCCM to identify user-to-device relationships, moved through user workstations, and recovered credentials from the places organizations routinely forget to treat as credential stores: database connection files, SQL developer configuration files, and cloud configuration files. CISA reported that it found AWS IAM credentials configured never to expire in users’ home directories.
The more serious operational failure came afterward. Organization A’s SOC did receive medium- and low-severity EDR alerts related to the activity, according to CISA. But thousands of higher-severity false positives and routine alerts buried them. Separate SOC teams used separate EDR products without shared visibility, and staff could not identify an SCCM system’s owner or normal function before dismissing an alert as a false positive.
CISA’s account does not establish that alert overload alone caused the compromise. It does establish something more actionable: the organization’s defenders had telemetry, but lacked a usable baseline, shared context, documented escalation procedures, and authority to act. Adding another detection product to that structure would likely have increased the noise rather than improved containment.
Organization B proved containment works — then exposed the limits of endpoint response
Organization B’s SOC behaved very differently during the phishing phase. Three users clicked malicious links, producing the same medium-severity endpoint alert for an executable loading an unexpected DLL. Analysts manually isolated the three workstations in 10, 2, and 20 minutes, respectively, cutting off the red team’s command-and-control sessions.
Those response times are the strongest practical finding in CISA’s comparison. The same class of initial access that went unanswered in Organization A was quickly triaged, quarantined, analyzed, and reimaged at Organization B. When the red team later attempted to establish command and control on a bastion host in the operational technology DMZ, outbound controls blocked the callback and the SOC quarantined the host.
But containment of the original endpoint is not eradication of the underlying identity risk. Once CISA moved to its assumed internal foothold, it found that Organization B allowed users to create machine accounts, and then located cleartext domain service-account credentials in an SCCM distribution-point XML file. The service account had AllExtendedRights over a domain controller, enabling a resource-based constrained delegation attack and DCSync access.
DCSync is the pivot that changes an intrusion from a compromised machine into a domain-wide identity incident. CISA used it to obtain account credentials, including the krbtgt account hash. A real attacker with that material could create forged Kerberos Golden Tickets and impersonate domain users, subject to the practical limits of the domain’s controls and detection.
Organization B also had plaintext credentials for OT systems on jump servers, according to CISA. Its network segmentation and egress restrictions stopped the team’s payload from reaching external infrastructure, but an FTP credential still let the team authenticate to the bastion host over SSH. The lesson is not that segmentation failed. It did what it was configured to do. The lesson is that jump hosts, SCCM infrastructure, service accounts, and directory replication privileges must be treated as high-value identity assets rather than ordinary servers.
The Entra ID finding is about application ownership, not simply MFA
Both organizations ultimately exposed a Microsoft Entra ID path. At Organization A, CISA targeted applications holding broad Microsoft Graph application permissions such as Mail.ReadWrite, Files.Read.All, and permissions capable of assigning additional application roles. The team compromised the owner of a high-privilege application, obtained that user’s primary refresh token, added a client secret to the application, and accessed emails through Microsoft Graph.
CISA says that access included SOC staff email, Teams messages, screenshots, and keystrokes from SOC workstations. That creates a particularly damaging feedback loop: an attacker with access to security personnel communications can learn what defenders have noticed, which hosts they are investigating, and how containment is being organized.
Organization B took a different route. CISA recovered credentials for the on-premises account used by Entra ID Connect synchronization, then triggered a Microsoft automated alert by using the account interactively in the Azure portal. Its SOC blocked that suspicious activity. CISA subsequently abused the organization’s Seamless SSO configuration and an AD-synced account that owned an application with tenant-wide email permissions. By re-enabling that account on premises, using Kerberos material to authenticate, and adding an application client secret, the team gained the ability to retrieve every user’s email from the public internet.
The important distinction is that MFA protected some user sign-ins in Organization B; it did not remove the danger of a highly privileged application owned by a synchronized identity. Service accounts, disabled accounts, synchronization accounts, application owners, and enterprise applications need the same lifecycle discipline as named administrators. Disabling a user in Active Directory is insufficient if its cloud ownership, standing permissions, secrets, or synchronized identity state still create a recovery path.
Conditional Access for workload identities has real limits
CISA recommends Conditional Access for workload identities, and that is sound advice for eligible Microsoft Entra service principals. Microsoft’s documentation confirms that these policies can restrict service-principal token requests based on named network locations or Microsoft Entra ID Protection risk, and that administrators should monitor service-principal sign-in logs.
However, the advisory’s practical takeaway should not be reduced to “turn on a policy and fix app permissions.” Microsoft documents several limits that matter during remediation:
- Conditional Access policies for workload identities must be assigned directly to individual service principals; putting service principals in a group and applying policy to the group does not enforce the policy on those principals.
- The policies apply to single-tenant service principals registered in the customer tenant. Microsoft, third-party SaaS, multitenant applications, and managed identities are outside that policy scope.
- The available controls are centered on blocking access based on location or risk, rather than applying the full menu of user-focused Conditional Access grants.
- Continuous Access Evaluation for workload identities requires application support and currently applies to Microsoft Graph. A workload must explicitly declare support for claims challenges before it receives CAE tokens.
Those limits do not weaken CISA’s core recommendation. They define the audit work administrators need to do first: identify which applications are service principals versus managed identities or multitenant apps, determine who owns each application, inventory Graph application permissions, and verify that policy assignments actually apply to the intended object.
Microsoft’s Entra documentation also describes primary refresh tokens as device-bound authentication artifacts that, on supported Windows configurations, use TPM-protected keys. That protection is valuable, but CISA’s assessment is a reminder that attackers operating from a compromised endpoint or using stolen session material do not need to defeat the TPM in the abstract to turn a user or application ownership relationship into cloud access. Endpoint isolation, token investigation, session revocation, and application-secret review must be coordinated.
Start with the paths CISA used
For Windows domain and Microsoft 365 administrators, the most urgent response is a focused validation exercise rather than a broad product purchase. Reproduce the defensive questions raised by the assessment against the environment you operate:
- Set Active Directory Machine Account Quota to zero unless a documented business process requires otherwise, then grant the minimum exception needed rather than leaving domain-wide creation rights available.
- Audit ADCS templates for ESC1 conditions, especially templates allowing enrollee-supplied subjects or unnecessary enrollment and write permissions.
- Search SCCM servers, distribution points, user profiles, virtual desktop file stores, jump servers, configuration repositories, and developer-tool folders for plaintext passwords, connection strings, API keys, AWS keys, and Entra application secrets.
- Review every service account’s effective rights, prioritizing any account with replication rights,
AllExtendedRightsover a domain controller, broad delegation rights, or membership that can influence privileged accounts. - Inventory Entra enterprise applications with Microsoft Graph application permissions, identify their owners, remove abandoned owners and disabled accounts, and review every recently created client secret or certificate.
- Confirm that the SOC can isolate a host or block an account without waiting for an ownership dispute, then test that authority through a tabletop exercise and a controlled technical drill.
CISA’s advisory does not describe an active campaign or assign the behavior to a named threat actor. It is a government red-team report, and the organizations are deliberately anonymous. Its value lies in the evidence that attacker progress was determined less by a novel exploit than by mundane conditions: default credentials, excessive permissions, unrotated secrets, insecure files, unreviewed certificate templates, noisy alerts, and teams unable to act together.
Organization B’s initial response shows that rapid isolation is worth having. Its later compromise shows why a SOC’s success cannot be measured only by whether it catches the first phishing alert. In a hybrid Windows and Entra environment, the operational standard has to be harsher: contain the device, then assume the attacker is already testing the identities, applications, tokens, and management systems that can outlive it.
