CISA Red Teamed Two Critical Infrastructure Orgs at Once

CISA published advisory AA26-237A on August 25, 2026, under the title "A Tale of Two SOCs." It documents two red team assessments run at the same time, against two critical infrastructure organizations, using similar tradecraft. Both organizations were compromised at the domain level. In both, the red team reached sensitive business systems and cloud resources. The difference between them was not the attack. It was whether anyone noticed, and whether the people who noticed were allowed to act.

That framing matters because the reflex after a report like this is to buy another tool. Organization A had more tools than Organization B. It had multiple SOCs and multiple EDR products. It saw nothing. What follows is the attack path in each organization as CISA reported it, what separated the two responses, the mitigations CISA lists, and how RedEye reads it.

Organization A: the SOC that saw nothing

Initial access through a web app nobody hardened

The red team found an internal web application still carrying default credentials for several built-in accounts. One of those accounts could send email from an internal address, so the phishing campaign that followed came from inside the organization's own domain. Four workstations were compromised.

From there the team ran a modified BloodHound collector, altered to slip past the static EDR signatures, and scraped the whole of Active Directory: users, computers, groups, ACLs, organizational units and group policy. Two findings did the damage. One workstation sat in a domain with the default Machine Account Quota of 10, so any unprivileged user could add computer accounts. And the certificate services carried multiple templates with the ESC1 misconfiguration, which lets any user request a certificate on behalf of any other user or computer. The team created a machine account, requested a certificate for it, and from that point could mint certificates for any account in the domain. Domain compromise, with no exploit and no malware, from two settings that ship that way by default.

Three sensitive business systems, three credential finds

With the domain in hand the team went after the systems that actually matter. Their route was the same each time: use the AD data to find the users and groups tied to a target system, query SCCM to map users to their workstations, move laterally to those workstations through the SCCM server, and pick up credentials there.

• System 1, a database: cleartext credentials sitting on an administrator's workstation.
• System 2, another database: a SQL developer tool's connections.json and product-preferences.xml, decrypted to a cleartext password.
• System 3, an automated processing system: long-lived AWS IAM user keys saved in configuration files in users' home directories. Nobody had configured expiration or rotation, so the keys never expired.

Two of the targets lived behind virtual desktops, which should have limited the team to whatever session a user had open. The virtual desktops synced to a root drive on the distributed file system. The team compromised that root drive and could search the local files of thousands of users' desktops at once, whether or not anyone was logged in. Administrative access to all three systems followed, proxied through compromised workstations, with no defensive intervention.

Into the cloud, and into the SOC's own inbox

The cloud path did not need a password. The team enumerated the Entra ID tenant with AzureHound and ROADrecon and looked for applications holding Application permissions to the Microsoft Graph API: Mail.ReadWrite, Chat.Read.All, Files.Read.All, Application.ReadWrite.All. Those permissions belong to the application, not to a user, so they sit outside every Conditional Access policy written for people. They found an application with Mail.ReadWrite, found its owner, moved to the owner's machine, took the primary refresh token, used it to get an access token as the owner, added a client secret to the application, and from then on read email as the application. CISA notes it has never seen an organization use Conditional Access for workload identities, which would have stopped this.

The first thing the team read was the SOC's email, to see if anyone knew they were there. Nobody did. The team then moved onto SOC workstations, took screenshots, ran keyloggers and pulled Teams messages. They watched the defenders from inside the defenders' own tools.

Why the alerts died

The EDR did fire. The red team's activity produced medium and low severity alerts. They were buried under thousands of false positives generated by normal business operations, many of them rated higher. The organization ran multiple SOCs and multiple EDR platforms; the staff of one SOC did not talk to the others and could not see their tools, and SOC staff did not talk to system owners. The team watched a chat thread in which defenders tried to work out who owned an SCCM server, what it did and how it was normally used. They could not find out. They marked the alert a false positive. CISA's conclusion: no standard operating procedure for escalation, and defenders with little authority, so the default became wait and see.

Organization B: 10 minutes, 2 minutes, 20 minutes

The phish that got caught

The red team harvested addresses from public websites and sent a spearphishing campaign. Three users clicked. Each payload produced one medium severity alert, "An executable file loaded an unexpected DLL file." The SOC triaged all three and manually isolated the workstations in 10, 2 and 20 minutes. Command and control was dead. Before the last isolation the team managed to pull the AD structure over LDAP, but the foothold was gone.

Because the defenders won that round, the assessment switched to an assume breach model: the organization's trusted agents ran a red team payload on a designated host under a standard user account, giving the team the access they would have had if nobody had noticed. Everything after this point is what a real intruder who evaded the first alert would have done.

From one service account to the whole domain

The Machine Account Quota here was 1,000 for every domain user. The team created a machine account named to look like a real host and used it to run tools from their own Linux box, proxied through the assume breach host and around the EDR. AD itself showed no escalation path. SCCM did: an XML file on a distribution point held cleartext credentials for a domain service account with control over almost a thousand accounts and AllExtendedRights over a domain controller. That permission allowed a resource-based constrained delegation attack, which gave the team DCSync, which gave them every credential in the domain, starting with krbtgt.

One of two named sensitive business systems fell next, through a user with access to its web server and Kerberos authentication: DCSync the user's hash, request a ticket-granting ticket, request a service ticket, import it into a VM and tunnel in over a SOCKS proxy through a compromised host.

The OT jump host, and the egress rule that held

The team found an IT workstation holding RDP files, one of them named ics-[redacted]-org. That workstation had remote access to a bastion host in the OT DMZ. FTP credentials worked for SSH, and the team had visibility of the OT network. They dropped several payloads on the host and ran them. None called home: the host blocked outbound internet connections. The execution triggered an alert, and the SOC quarantined the bastion. A blocked egress rule and a defender allowed to act ended the OT excursion.

The cloud, again

Organization B ran a hybrid identity with on-premises AD synced to Entra ID. The team used ADConnectDump to obtain cleartext credentials for the on-prem MSOL account and the cloud sync account, and logged into the Azure portal with a service account that had no MFA and was never meant for interactive use. Microsoft's own alert fired, the SOC blocked the account, and the team lost that path too.

What worked was Seamless SSO. The team took a target user's encrypted credentials by DCSync, requested service tickets with Rubeus, and browsed to the Azure portal with legitimate Kerberos tickets from a trusted IP address. That gets a first factor as any synced user, which means it works for exactly the accounts that have no second factor: service accounts. They found an application with permission to read, write and send email for every user in the tenant, owned by a synced account that was disabled in AD. They re-enabled the account from a compromised host, DCSynced its hash, authenticated to Entra ID, added a client secret to the application, and could read every mailbox in the organization from the public internet.

Organization B's SOC still had custom detections that caught pieces of this: Risky User alerts for "Unfamiliar sign-in properties," and "Suspicious API traffic" rules keyed on the AzureHound user agent and on accounts exceeding request thresholds to the Graph API. CISA's table of the engagement is short and worth reading as a list: three phished workstations, three quarantines and reimages; one OT bastion payload, one quarantine; one suspicious portal login, one blocked account. Every alert that fired was actioned. The red team got in anyway, through the gaps no alert covered.

What separated them

CISA's three lessons are plain, and the first two have nothing to do with tooling.

• Untuned detection tools lead to missed threats. The same activity that triggered alerts and action in Organization B produced no response in Organization A, because Organization A had no baseline and no alert filtering, so routine business activity and false positives outnumbered the real signal. Organization B had a baseline and a tuned alert set, so anomalies stood out.
• Silos and bureaucratic hurdles prevent response. Multiple SOCs that did not share visibility, SOC staff who could not find system owners, unclear authority across network segments, and no escalation procedure. Organization B's defenders triaged, investigated root causes, found the misconfigurations and coordinated remediation with engineering, because they were allowed to.
• Both underestimated the cloud. Long-lived IAM keys set to never expire. No Conditional Access for workload identities, so every application with broad permissions was a door. No process for revoking access and refresh tokens after a compromise, which means an intruder evicted from the network can walk back in through the cloud.

The shared gaps are as telling as the differences. Both organizations had a permissive Machine Account Quota. Both had cleartext credentials where the red team could reach them. Both had service accounts and applications with permissions nobody had reviewed. Both had SCCM reachable as an ordinary server rather than guarded as the Tier 0 asset it is. Organization B was better, not clean. Its SOC bought it the time and the visibility to find out.

CISA's mitigations, in the order that matters

• Establish a baseline and cut the noise. Maintain a baseline of installed software, account behavior and network traffic, and tune monitoring until it separates typical administration from threat behavior. CISA points to its joint guidance on living off the land techniques for the method.
• Break the silos and empower defenders. Shared tools and cross-functional teams across IT, security and business units. Detection wired into response workflows. Written policy on when a defender may act alone and when to escalate. Explicit authority to isolate systems and block traffic without a chain of approvals, and exercises that rehearse it.
• Cloud controls. A documented, tested procedure for detecting, remediating and revoking access and refresh tokens. Conditional Access for workload identities, with monitoring of sign-in logs and policy evaluation for applications. Regular review and removal of unnecessary application permissions, including Mail.Read and Files.Read.All. Phishing-resistant MFA on every account, service accounts included. Just-in-time privileged access. In AWS, no long-lived IAM user keys: temporary credentials through SSO, and audits to prove none remain. CISA's SCuBA baselines and the no-cost ScubaGear tool cover the Microsoft 365 side.
• Active Directory and credentials. Disable the ENROLLEE_SUPPLIES_SUBJECT flag on certificate templates and restrict who can enroll. Set the Machine Account Quota to zero unless there is a documented need. Scan shares and workstations for plaintext credentials and remove them. Least privilege, separate admin accounts on separate admin workstations, PAM with logging and alerting, time-bound elevation.
• Endpoint configuration managers are high value assets. SCCM, Jamf, BigFix and their peers can reach thousands of hosts. Guard and monitor them as Tier 0.
• Segment OT. Strict rules between IT and OT, jump servers limited and behind MFA, OT traffic monitored for lateral movement, change management on OT components. Organization B's egress rule on the bastion is the model.
• Validate. Take the ATT&CK techniques in the advisory, align your controls against each one, and test them. Find out which SOC you are before a red team or an adversary does.

RedEye's read: a working SOC, not a bigger one

Organization A is the more common shape. Several SOCs, several EDRs, thousands of alerts a day, and no shared picture of what normal looks like. When the alert that mattered arrived it was medium severity, sitting under higher-rated noise, about a server nobody in the room could identify. The defenders did not lack a tool. They lacked the context to answer "is this normal?" in the time it takes to decide, and the authority to act on the answer.

Tuning is not a setting. A baseline is telemetry: endpoint, identity, cloud sign-ins, Active Directory, SCCM, the OT jump host, all of it kept long enough and searchable fast enough that an analyst can pull six months of behavior for one server while the alert is still open. Most organizations cannot afford to keep all of that in the platform they pay per-gigabyte for, so they drop sources, shorten retention, and then discover in an engagement like this one that the missing source was the one that explained the alert. Organization A's SCCM question was answerable. The answer was in logs nobody had in front of them.

Every step in this advisory is detectable, and most of it is detectable from logs that already exist: a machine account created by a standard user, a certificate requested for a different principal, DCSync from a non-DC, a disabled account re-enabled and used within the hour, a sync account signing in interactively, a client secret added to an application with mail permissions, a Graph API client identifying itself as AzureHound, an RDP file named after an ICS network being opened, a DMZ host trying to reach the internet. Organization B caught the ones it had written detections for and had the authority to act on. That is the whole difference.

How RedEye is positioned for this

Keep everything, so tuning is possible. Caver is built so that the cost of storage stops being the reason a source gets dropped. Endpoint, identity, cloud, AD, SCCM, OT bastion logs and network telemetry go into one place, on storage you already own, at a measured fraction of what the same window costs in a per-gigabyte platform, and they stay there for as long as the baseline needs. A SOC that keeps its identity and cloud logs next to its EDR alerts can answer the "what is this server" question with a query instead of a Teams thread.

Query in the time an alert is open. Months of telemetry return in seconds, in the query language your analysts already know, with Sigma content for the techniques in this advisory and a grounded assistant that turns a question into a real, bounded query your team can keep. Severity is not priority. Context is, and context is a fast query away or it is nothing.

Detections for this tradecraft, shipped continuously. RedEye's live detection feed carries rules for the ATT&CK techniques CISA mapped here: T1136.002 machine account creation, T1649 certificate abuse, T1003.006 DCSync, T1550.001 application token use, T1114 email collection, T1021.004 SSH to a bastion, and the cloud reconnaissance user agents. They run in Caver and they ship to the platform you have today if you are not ready to move.

People with authority. Organization B's outcome came from defenders who isolated a host within minutes without asking permission. RedEye's MDR is contracted that way: written authority to isolate, block and revoke, exercised on a schedule, with the escalation path agreed before the first alert rather than during it.

The OT half. The bastion host in the OT DMZ is the moment this report stops being about email. RedEye's ICS practice assesses exactly that path, the RDP file on an IT workstation that leads to a jump host that leads to the plant, and Caver's network sensor watches the segment so a payload that cannot call home is still a payload that got seen.

Two organizations, one adversary, one script. One saw it in two minutes and one found out from CISA. Which one you are is a decision about baseline, authority and retention, and it can be made before anyone tests it for you.