CISA’s Red Team Wake-Up Call: Two Critical Infrastructure Organizations Lost Their Domains, But Only One Saw the Attack Coming + Video

Listen to this Post

Featured ImageIntroduction: The Attack Was Not the Biggest Problem

A recent advisory from the Cybersecurity and Infrastructure Security Agency (CISA) delivers a particularly uncomfortable lesson for critical infrastructure defenders: an organization can have security products everywhere and still be effectively blind.

In advisory AA26-237A, CISA describes two simultaneous red team assessments against organizations operating in critical infrastructure sectors. The attackers used broadly comparable techniques against both environments. In both cases, the red team eventually achieved full domain compromise and reached sensitive business systems and cloud resources.

Yet the outcomes were dramatically different.

One organization barely recognized what was happening. Its security operations center was flooded with false positives, teams operated in isolation, escalation procedures were unclear, and analysts repeatedly dismissed suspicious activity as normal noise. The attackers eventually gained enough visibility into the SOC itself to confirm that nobody was responding.

The second organization also suffered serious security weaknesses. It lost control of privileged credentials, exposed pathways toward operational technology, and ultimately had its cloud environment compromised. But its defenders reacted quickly enough to isolate systems, investigate suspicious behavior, and force the attackers into an “assume breach” situation.

That contrast is the real story.

This was not a demonstration that one organization had hackers who were smarter than the other. It was a demonstration that detection, coordination, visibility, and response can determine whether a compromise becomes a catastrophe or a contained incident.

CISA’s Experiment: Same Attack Philosophy, Different Results

CISA intentionally conducted the assessments simultaneously to observe how organizations with different defensive capabilities would respond to comparable intrusion techniques.

Organization A belonged to the Government Services and Facilities Sector, while Organization B operated within the Water and Wastewater Systems Sector.

Both environments contained exploitable weaknesses.

Both experienced domain compromise.

Both had cloud security gaps.

Both contained paths that could potentially lead toward highly privileged systems.

But their defensive maturity was very different.

The experiment therefore provides something more valuable than another list of vulnerabilities. It demonstrates what happens when an organization is attacked in the real world and its security team must make decisions under pressure.

Organization A: A Compromise Hidden in Plain Sight

The first organization suffered from a problem that sounds simple but can become devastating: a web application was still using default credentials.

The red team exploited those credentials and used the trusted application to send phishing messages from an internal address.

That detail mattered enormously.

A phishing email originating from a legitimate internal account can look far more trustworthy than a message coming from an unfamiliar external domain. Once employees interacted with the campaign, the red team gained access to four workstations.

The attackers now had their foothold.

But that was only the beginning.

The Active Directory Certificate Services Weakness

From the compromised workstations, the red team discovered a misconfigured Active Directory Certificate Services environment containing an ESC1-style certificate template weakness.

AD CS can be extremely powerful because certificates can be used for authentication.

When templates are improperly configured, a low-privileged user may be able to request a certificate that represents another identity, potentially including a privileged administrator.

The red team exploited this pathway to elevate privileges.

The important lesson is not simply “patch AD CS.”

The deeper lesson is that identity infrastructure can become an attacker’s privilege-escalation engine when administrators treat certificate services as ordinary infrastructure rather than a high-value security boundary.

Full Domain Compromise Without the SOC Reacting

Once privileged access was obtained, the attackers moved through the environment and reached targeted sensitive business systems.

And remarkably, defenders did not stop them.

The red team eventually moved into the

The purpose was simple.

They wanted to know whether anyone had discovered the intrusion.

They had not.

The attackers were effectively checking the

The Real Enemy: Alert Fatigue

CISA’s assessment exposes one of the most dangerous problems in modern security operations: too many alerts can become almost as dangerous as too few.

Organization

Some of those alerts were categorized as more serious than alerts generated by the actual red team intrusion.

This created an environment in which defenders had to constantly distinguish meaningless noise from potentially catastrophic activity.

Eventually, analysts encountered SCCM-related alerts associated with the red team’s activity.

Instead of escalating the events, they could not determine the affected system’s owner or function and ultimately classified the activity as a false positive.

That single decision illustrates a much larger organizational problem.

When analysts lack context, unclear events are often treated as harmless.

When Security Teams Become Too Busy to See the Attack

The red team did not stop there.

After gaining access to SOC workstations, the attackers deployed keylogging and screenshot capabilities to determine whether defenders were investigating them.

The answer was effectively no.

The organization had multiple SOC teams using different endpoint detection and response platforms. Those teams lacked sufficient cross-team visibility and coordination.

One security team might see something suspicious, but there was no reliable mechanism to ensure that another team could act on the information.

Security had become fragmented.

The organization had tools.

It had analysts.

It had alerts.

What it lacked was a unified defensive system.

Technology Cannot Compensate for Broken Processes

CISA makes a crucial point in the advisory: security tools are only as effective as the people and processes surrounding them.

An EDR platform cannot decide what an unfamiliar machine means to the business.

A SIEM cannot automatically understand every

An alert cannot contain an attacker if nobody has the authority or procedure to act on it.

At Organization A, analysts were sometimes responsible for systems they did not fully understand.

There were also no clearly documented escalation procedures.

When something looked suspicious but ambiguous, waiting became the default response.

For an attacker, hesitation is opportunity.

Organization B: Compromised, But Fighting Back

Organization B was not secure.

That distinction is important.

The red team still discovered serious weaknesses and ultimately achieved domain compromise.

The difference was that defenders recognized suspicious activity much earlier and responded decisively.

They investigated.

They coordinated with engineering teams.

They isolated systems.

They reimaged compromised machines.

They did not simply close alerts and move on.

That response forced the red team to operate under an assume-breach model.

The attackers still found paths forward, but defenders were actively disrupting them.

The SCCM Credential Exposure

One of Organization

The red team discovered a password stored in plaintext inside an XML file.

Plaintext credentials are dangerous anywhere, but they become particularly serious when they belong to service accounts with elevated privileges.

The attackers used the exposed service account to gain powerful access involving a domain controller.

From there, they performed a DCSync attack and obtained the krbtgt hash.

That changed the threat level dramatically.

Golden Tickets: When Domain Trust Is Broken

The krbtgt account plays a fundamental role in Microsoft’s Kerberos authentication system.

Once an attacker obtains the necessary credentials, they can potentially forge Kerberos Golden Tickets.

These forged tickets can allow attackers to impersonate users and maintain powerful access across an Active Directory environment.

This is one reason why domain controllers and associated identity infrastructure must be treated as crown jewels.

If an attacker controls the mechanisms that establish trust inside a Windows domain, ordinary password resets may not be enough to restore confidence.

The organization may need a much deeper identity recovery process.

The Hidden Road Toward Operational Technology

The red team also discovered a pathway toward the OT environment.

RDP files referenced a bastion host that could potentially bridge otherwise separated infrastructure.

The attackers discovered FTP credentials on a jump server and used them to connect to the bastion through SSH.

Fortunately, the bastion did not have outbound internet connectivity.

That prevented the

The SOC then quarantined the host.

This was a defensive success, but it also exposed a dangerous architectural weakness.

The path existed.

Segmentation Is Not Just About Firewalls

Network segmentation is frequently discussed as a technical configuration.

CISA’s exercise demonstrates why segmentation must be viewed as an entire security architecture.

A system may be technically isolated from the internet yet still be reachable from compromised enterprise infrastructure.

A jump server may be legitimate but become dangerous when credentials are exposed.

An RDP file may look harmless but reveal a route toward a sensitive environment.

Security boundaries must therefore be evaluated from the perspective of an attacker.

The question should not simply be, “Is this network segmented?”

The better question is, “If an attacker owns an ordinary workstation, what can they eventually reach?”

The Cloud Problem Both Organizations Shared

Perhaps one of the most important discoveries was that both organizations had the same cloud security weakness.

Neither had enabled Conditional Access protections for workload identities.

Conditional Access is often associated with human users, but modern cloud environments also depend heavily on applications, service accounts, and machine identities.

These identities can possess extremely broad permissions.

If they are not appropriately protected, an attacker who compromises an application credential may bypass security controls designed primarily around human authentication.

This creates a dangerous gap between identity security and application security.

Microsoft Graph Beccomes an Attack Surface

The red team exploited cloud permissions to access organizational email.

This demonstrates why Microsoft Graph permissions deserve the same scrutiny as traditional administrator privileges.

An application that can read, write, or send email across an entire tenant is effectively holding an enormous organizational capability.

If attackers obtain control over that

One application identity can become the master key.

Organization A Had Another Cloud Problem

Organization A also stored AWS IAM credentials inside users’ home directories.

The credentials did not have expiration dates.

That creates a persistent risk.

Long-lived credentials can survive for months or years if nobody rotates or revokes them.

A stolen credential can therefore remain useful long after the original compromise has been forgotten.

The principle is straightforward:

Credentials should have the smallest practical permissions, the shortest practical lifetime, and a clear ownership model.

Organization B’s Azure Identity Chain

The cloud compromise at Organization B was even more sophisticated.

After obtaining Kerberos material through DCSync, the red team abused Seamless SSO to authenticate to Azure without requiring a user’s cleartext password.

They then discovered a disabled Active Directory-synchronized account associated with an application that possessed extensive permissions over employee email.

The attackers re-enabled the account, obtained its credentials, and added a client secret to the application.

The result was devastating.

The application could access mailboxes across the tenant from the public internet.

A single identity and application permission chain had effectively transformed an obscure disabled account into a cloud-wide access mechanism.

The Defenders Eventually Detected the Cloud Attack

Organization B did demonstrate meaningful defensive capability.

Its monitoring systems detected tools such as AzureHound based on user-agent information.

The organization also identified unusual Microsoft Graph API request volumes.

But there was an important caveat.

Those detections occurred after the attackers had already established initial cloud access.

That distinction matters.

Detection after compromise is still valuable, but early detection can dramatically reduce the attacker’s ability to establish persistence and escalate privileges.

The goal is not merely to detect attackers eventually.

The goal is to detect them before they become deeply embedded.

Deep Analysis

Finding One: Default Credentials Remain Dangerous

A sophisticated attack can begin with something embarrassingly simple.

Default credentials are among the easiest weaknesses to eliminate, which makes their continued presence especially concerning.

Organizations should maintain continuous inventories of applications and explicitly prohibit vendor-default authentication in production.

Finding Two: AD CS Deserves Tier-0 Treatment

Active Directory Certificate Services should be considered part of the identity security boundary.

Misconfigured templates can provide privilege escalation paths that are difficult to notice using conventional endpoint monitoring.

Security teams should audit certificate templates, enrollment permissions, authentication settings, and risky subject-name configurations.

Finding Three: Search for ESC1 Conditions

Defenders can begin auditing certificate templates using tools designed for AD CS security assessment.

For example, administrators and authorized security teams can inspect certificate templates with:

certutil -template

For deeper auditing, organizations can use Microsoft-supported administrative tooling and dedicated AD CS assessment utilities in controlled environments.

The objective is to identify templates where low-privileged users can influence certificate identities or request certificates capable of privileged authentication.

Finding Four: Monitor Suspicious Certificate Enrollment

Certificate enrollment should generate meaningful security telemetry.

Look for unusual certificate requests, unexpected enrollment by ordinary users, authentication certificates associated with privileged identities, and certificate activity originating from unusual endpoints.

A certificate request should never be treated as inherently trustworthy simply because it uses Microsoft’s native infrastructure.

Finding Five: SCCM Is More Powerful Than It Looks

Configuration Manager infrastructure can become an enormous attack surface.

SCCM servers and distribution points can contain credentials, software deployment capabilities, administrative permissions, and access to thousands of endpoints.

For that reason,

If an attacker controls your software deployment platform, they may effectively control your endpoints.

Finding Six: Search for Cleartext Credentials

Organizations should regularly search managed endpoints and network shares for exposed credentials.

A basic PowerShell investigation can begin with controlled searches such as:

Get-ChildItem -Path C:\Users -Recurse -File -ErrorAction SilentlyContinue |
Select-String -Pattern "password|passwd|secret|apikey" -SimpleMatch

This is only a starting point.

Real enterprise credential discovery should use dedicated secrets-scanning systems, endpoint telemetry, and controlled security assessments rather than relying on one command.

Finding Seven: DCSync Requires Immediate Attention

Defenders should monitor for suspicious directory replication activity.

A DCSync attack abuses replication permissions to request password-related information from Active Directory as though the attacker were another domain controller.

Unexpected replication requests from ordinary workstations or accounts deserve immediate investigation.

Finding Eight: Protect the krbtgt Account

The krbtgt account is central to Kerberos trust.

If its hash is compromised, defenders must assume that attackers may be able to forge Golden Tickets.

Recovery planning should therefore include procedures for rotating the krbtgt password appropriately and investigating persistence mechanisms before declaring the domain clean.

Finding Nine: Golden Tickets Change Incident Response

A conventional password reset may not eliminate a Golden Ticket.

Forged Kerberos tickets can have lifetimes independent of the user’s ordinary password.

Incident responders should investigate Kerberos abuse, privileged account compromise, domain-controller integrity, and persistence mechanisms whenever evidence suggests krbtgt exposure.

Finding Ten: Conditional Access Must Include Workloads

Human identities are not the only identities that require protection.

Organizations using Microsoft cloud services should evaluate Conditional Access policies for workload identities and applications where supported.

Machine identities deserve authentication restrictions, monitoring, lifecycle management, and least-privilege permissions just as human accounts do.

Finding Eleven: Microsoft Graph Permissions Need Governance

Applications with broad Graph permissions should be treated as privileged assets.

Security teams should regularly inventory:

Get-MgServicePrincipal

and investigate applications with unusually broad permissions.

The precise commands available will depend on the Microsoft Graph PowerShell modules and organizational permissions, but the security objective remains the same: identify applications capable of reading or manipulating sensitive tenant data.

Finding Twelve: Disabled Accounts Should Not Become Forgotten Accounts

A disabled account can still have dangerous relationships with applications, service principals, synchronization systems, or privileged resources.

Security teams should periodically review disabled identities and remove unnecessary ownership relationships.

An account that no longer serves a business function should not remain connected to a highly privileged application.

Finding Thirteen: Rotate Secrets Automatically

Cloud application secrets should have defined expiration periods.

Long-lived client secrets create unnecessary persistence opportunities.

Where possible, organizations should prefer stronger identity mechanisms and automated credential rotation rather than manually managed permanent secrets.

Finding Fourteen: AWS IAM Credentials Need Lifecycle Controls

The AWS example demonstrates why credential inventory matters.

Security teams should identify access keys without rotation or expiration controls and replace long-lived credentials with short-lived mechanisms wherever practical.

Useful AWS CLI checks include:

aws iam list-users
aws iam list-access-keys --user-name USERNAME

These commands should only be used against environments you are authorized to administer.

Finding Fifteen: Alert Quantity Is Not Security Quality

A SOC receiving thousands of alerts is not necessarily a strong SOC.

If analysts cannot distinguish routine activity from meaningful anomalies, the organization may actually be increasing its exposure.

Security operations should prioritize signal quality, asset context, behavioral baselines, and correlation.

Finding Sixteen: False Positives Have a Security Cost

Every false positive consumes analyst attention.

If false positives consistently receive higher severity than real malicious activity, defenders can develop dangerous expectations about what a “critical” alert looks like.

Organizations should continuously tune detections based on real incident and red-team data.

Finding Seventeen: Every Alert Needs Context

An alert about “SCCM activity” is not enough.

Analysts should be able to answer:

What system generated it?

Who owns the system?

What does the system do?

Is the activity expected?

What changed?

What other systems communicated with it?

Is the behavior consistent with the baseline?

Without context, detection becomes guesswork.

Finding Eighteen: SOC Teams Cannot Operate in Silos

Multiple SOCs using different security platforms can create blind spots.

Centralized visibility does not necessarily require one product.

It requires coordinated processes.

Critical incidents should have clear cross-team escalation paths, shared case management, common severity definitions, and authority to isolate systems.

Finding Nineteen: Escalation Procedures Should Be Written Before the Attack

During an incident is the worst possible time to debate who has permission to shut down a compromised server.

Organizations should define:

Who can isolate endpoints.

Who can disable accounts.

Who can revoke tokens.

Who can quarantine cloud applications.

Who contacts engineering.

Who communicates with executives.

Who makes recovery decisions.

Ambiguity benefits attackers.

Finding Twenty: Assume-Breach Exercises Matter

Organization B demonstrates the value of operating under an assume-breach mentality.

Instead of asking whether compromise is possible, defenders ask what happens after compromise.

That changes the defensive architecture.

Endpoints become monitored more aggressively.

Privileged identities receive stronger controls.

Network segmentation becomes more meaningful.

Cloud activity becomes part of the

Finding Twenty-One: OT Security Begins Before OT

The attempted movement toward the OT network is especially important for critical infrastructure.

An OT environment does not need to be directly exposed to the internet to become vulnerable.

Enterprise credentials, jump servers, RDP files, administrative workstations, and bastion hosts can create indirect pathways.

Defenders should map those pathways regularly.

Finding Twenty-Two: Bastion Hosts Need Strict Controls

A bastion host should not simply be considered a secure bridge because it has a special purpose.

It should have tightly restricted authentication, limited network routes, strong logging, hardened software, and carefully controlled administrative access.

Its connectivity should be explicitly justified.

Finding Twenty-Three: Outbound Restrictions Can Save an Environment

Organization B benefited from the

That prevented the

This is an important reminder that egress filtering remains valuable.

Even after an attacker gains access, restricting outbound communication can limit command-and-control, payload retrieval, data exfiltration, and malware execution chains.

Finding Twenty-Four: Identity Is Now the Primary Battlefield

The assessment repeatedly returns to identity.

Default credentials.

AD CS.

Service accounts.

DCSync.

krbtgt.

Kerberos.

Workload identities.

Application permissions.

IAM credentials.

Client secrets.

The modern attacker increasingly does not need to “hack the computer” in the traditional sense.

They need to obtain an identity that already has the authority to do what they want.

Finding Twenty-Five: Cloud and On-Premises Identity Are Connected

Organization B demonstrates why treating Active Directory and cloud identity as separate security problems is dangerous.

Credentials and tickets originating in on-premises infrastructure can influence cloud access.

Synchronization mechanisms can create unexpected relationships.

Security teams need an identity map that crosses traditional infrastructure boundaries.

Finding Twenty-Six: Detection Should Follow the Attack Chain

Individual alerts are less useful than correlated attack stories.

A suspicious certificate request followed by unusual privileged authentication is more meaningful than either event alone.

Likewise, DCSync activity followed by abnormal cloud authentication should immediately increase the priority of an investigation.

Detection engineering should therefore mirror attacker behavior.

Finding Twenty-Seven: Security Teams Need Authority

CISA’s findings expose an organizational problem that technology cannot solve.

If analysts discover suspicious activity but cannot isolate systems without navigating multiple layers of approval, attackers gain time.

Incident responders need clearly defined emergency authority.

That authority should be tested during exercises.

Finding Twenty-Eight: Recovery Must Be Tested

Organizations often test whether backups exist.

They should also test whether they can recover from domain compromise.

Can administrators rebuild trusted identity infrastructure?

Can privileged credentials be rotated?

Can cloud tokens be revoked?

Can malicious application secrets be removed?

Can compromised endpoints be reimaged quickly?

These questions should have documented answers.

Finding Twenty-Nine: Tier-0 Thinking Should Expand

Traditional Tier-0 discussions focus heavily on domain controllers.

CISA’s findings suggest a broader definition.

Certificate services, identity synchronization infrastructure, endpoint management platforms, privileged cloud applications, and authentication systems can all become foundational control points.

If compromising a system allows an attacker to control many others, that system deserves Tier-0-level protection.

Finding Thirty: Security Maturity Is Measured During Failure

Organization A had many security controls.

Organization B also had significant weaknesses.

Neither environment was perfect.

The difference was how each organization behaved when something went wrong.

That may be the most valuable conclusion in the entire assessment.

Security is not measured by how impressive the architecture looks on paper.

It is measured by what happens when an attacker starts breaking the assumptions behind it.

What Undercode Say:

The Biggest Vulnerability May Be the SOC Itself

The most disturbing part of this assessment is not the AD CS vulnerability or the exposed credentials.

It is that attackers eventually discovered that the defenders were not responding.

Once an attacker knows the SOC is blind, the psychological balance changes.

They can become more aggressive.

They can move laterally.

They can experiment.

They can establish persistence.

They can take their time.

That is an extremely dangerous position for a defender.

More Security Products Do Not Automatically Mean More Security

Organizations frequently respond to incidents by purchasing another security platform.

But Organization A already had multiple EDR environments and multiple SOCs.

The problem was not simply a lack of technology.

The problem was the lack of integration, context, authority, and decision-making.

Adding another dashboard to an already overloaded SOC could make the situation worse.

Alert Fatigue Is an Attack Surface

Attackers do not have to disable your detection system.

Sometimes they only need to generate enough noise that defenders stop trusting it.

This makes alert quality a security control.

A detection that fires constantly without useful context can become functionally invisible.

Security engineering should therefore optimize for meaningful detection rather than impressive alert counts.

The Human Response Was the Deciding Factor

Organization B still suffered a domain compromise.

Yet its defenders repeatedly interrupted the attack.

They isolated systems.

They investigated.

They coordinated.

They reimaged endpoints.

They responded to suspicious behavior.

That is what mature defense looks like.

Perfect prevention is unrealistic.

Fast containment is achievable.

AD CS Should Be on Every Defender’s Radar

The assessment also reinforces a lesson that security teams sometimes overlook: identity infrastructure can contain extremely powerful privilege escalation paths.

AD CS weaknesses can turn relatively modest access into administrative authentication.

Organizations using AD CS should perform dedicated assessments instead of assuming that standard Active Directory monitoring provides sufficient protection.

SCCM Is a Sleeping Giant

Endpoint management platforms often receive less security attention than domain controllers.

That is a mistake.

If SCCM can deploy software across an enterprise, control thousands of machines, or access privileged credentials, it should be treated as a strategic security asset.

An attacker controlling it could potentially transform one compromised system into an enterprise-wide deployment mechanism.

Cloud Permissions Can Quietly Become Enterprise Keys

The application with broad mailbox permissions at Organization B is another major warning.

A service principal does not look like a human administrator.

It does not sit at a keyboard.

It may not even have a traditional interactive login.

Yet its permissions can be more powerful than those of most employees.

That means cloud application governance must become a central part of identity security.

Disabled Does Not Mean Harmless

A disabled account that owns or controls an application should never be forgotten.

Organizations need continuous identity-to-application mapping.

Security teams should know which accounts own applications, which applications have privileged permissions, and what happens when those identities are disabled or removed.

The Most Dangerous Attack Paths Cross Boundaries

The assessment moves across endpoints, Active Directory, certificate services, SCCM, cloud identity, email, and OT.

That is precisely how real enterprise attacks work.

Attackers do not respect organizational boundaries.

A defender who monitors only endpoints may miss cloud abuse.

A cloud team may miss AD compromise.

An OT team may not know that an enterprise credential has become compromised.

Security needs to connect the entire chain.

Critical Infrastructure Cannot Rely on Prevention Alone

Government and water infrastructure have consequences that extend far beyond the compromised workstation.

If attackers reach operational systems, disruption can become a public safety concern.

That makes resilience essential.

The goal should not simply be to prevent every intrusion.

The goal should be to make intrusion difficult to escalate, easy to detect, and fast to contain.

Red Teams Are Valuable Because They Expose Reality

A compliance report may say that security controls exist.

A red team can demonstrate whether those controls actually work.

CISA’s assessment effectively asked two organizations:

What happens if someone gets inside?

The answer was revealing.

One organization struggled to recognize the intrusion.

The other fought it.

That difference is far more meaningful than a checklist.

The Best Security Program Is One That Can Fail Safely

This is perhaps the most important lesson.

Organizations cannot guarantee that attackers will never obtain credentials.

They cannot guarantee that every application will remain perfectly configured.

They cannot guarantee that every endpoint will stay clean.

But they can design environments where one mistake does not automatically become domain-wide control.

That means segmentation, least privilege, short-lived credentials, strong identity protections, monitoring, and rehearsed response.

CISA’s Advisory Should Be Treated as a Blueprint

The assessment is more than a postmortem.

It provides defenders with a practical blueprint for evaluating their own environments.

Organizations should ask whether they could detect the same techniques.

Then they should ask the harder question:

Would we actually respond?

If the answer is uncertain, the security program still has work to do.

✅ Two Organizations Experienced Full Domain Compromise

CISA’s advisory documents that the red team ultimately achieved full domain compromise in both environments and accessed sensitive systems and cloud resources. The difference was primarily how effectively each organization detected and responded to the intrusion.

✅ Organization A Failed to Detect the Intrusion

The assessment found that Organization

✅ Organization B Detected and Contained Important Attack Activity

Organization B also had major security weaknesses, but its defenders identified suspicious activity, isolated systems, coordinated investigations, and reimaged affected machines. Its response forced the attackers to operate under an assume-breach model.

✅ Both Organizations Had Cloud Identity Weaknesses

CISA identified missing Conditional Access protections for workload identities in both environments. This created opportunities for applications and service identities with broad permissions to become powerful attack paths.

✅ Organization B Had a Serious AD and Cloud Attack Chain

The red team obtained credentials, performed DCSync, obtained the krbtgt hash, abused Kerberos authentication, and ultimately leveraged a highly privileged cloud application. The chain demonstrates how on-premises identity compromise can lead into cloud resources.

Prediction

(+1) More Organizations Will Begin Treating SCCM and Identity Infrastructure as Tier-0 Assets

The combination of credential exposure, endpoint management privileges, AD CS abuse, and DCSync makes it increasingly difficult to justify treating these systems as ordinary infrastructure. Security teams are likely to expand Tier-0 protections beyond traditional domain controllers.

(+1) Workload Identity Security Will Become a Larger Cloud Priority

As organizations deploy more applications and automated services, attackers will increasingly target machine identities rather than individual employees. Conditional Access, short-lived credentials, workload monitoring, and application permission governance should become more prominent parts of enterprise security programs.

(+1) Red-Team Testing Will Focus More Heavily on Detection and Response

Future assessments are likely to measure not only whether attackers can obtain privileged access, but how quickly defenders recognize and contain each stage of the attack chain.

(+1) Security Operations Will Shift From Alert Volume to Alert Quality

The lesson from Organization A is difficult to ignore. Thousands of alerts mean very little if critical events disappear inside the noise. Mature SOCs will increasingly prioritize contextual, correlated, behavior-based detections.

(-1) Long-Lived Credentials Will Continue to Create Persistent Enterprise Risk

Organizations that leave AWS keys, client secrets, service-account passwords, or other credentials active indefinitely will remain vulnerable to attacks that persist long after the original compromise.

(-1) Fragmented SOC Operations Will Continue Producing Blind Spots

Organizations that operate multiple security teams without shared visibility, common escalation procedures, and coordinated authority will remain vulnerable to attackers moving between environments faster than defenders can communicate.

(+1) Assume-Breach Will Become a Normal Security Philosophy

The biggest strategic lesson from CISA’s exercise is simple: the question is no longer whether an attacker can get inside, but what happens when they do.

The organizations that answer that question honestly, test their assumptions, and give defenders the authority to act will be far more difficult to destroy.

▶️ Related Video (70% Match):

🕵️‍📝Let’s dive deep and fact‑check.

🎓 Live Courses & Certifications:

Join Undercode Academy for Verified Certifications

🚀 Request a Custom Project:

Secure, high-velocity infrastructure and disruptive technological engineering. Contact our engineering team for high-tier development and proprietary systems:
[email protected]
💎 Smart Architecture | 🛡️ Secure by Design | ⭐ Trusted by Thousands

References:

Reported By: securityaffairs.com
Extra Source Hub (Possible Sources for article):
https://www.stackexchange.com
Wikipedia
OpenAi & Undercode AI

Image Source:

Unsplash
Undercode AI DI v2

🔐JOIN OUR CYBER WORLD [ CVE News • HackMonitor • UndercodeNews ]

💬 Whatsapp | 💬 Telegram

📢 Follow UndercodeNews & Stay Tuned:

𝕏 formerly Twitter 🐦 | @ Threads | 🔗 Linkedin | 🦋BlueSky | 🐘Mastodon | 📺Youtube