CISA's Tale of Two SOCs: Default Credentials, Cleartext Secrets, Full Domain Compromise

CISA's red team reached full domain compromise, sensitive business systems and cloud resources at two US critical-infrastructure organizations. It used similar tradecraft in both assessments, but the defensive outcomes were sharply different. One organization did not detect or contain the activity. The other detected the initial payloads and isolated affected workstations within minutes.

The advisory is unusually useful because it connects the entire chain: default credentials enabled an internal phishing foothold; misconfigurations enabled privilege escalation; cleartext passwords and long-lived cloud keys opened sensitive systems; and fragmented detection and response processes let the activity continue. This was an authorized assessment, not a criminal intrusion, but the weaknesses and response lessons are directly applicable to real incidents.

What CISA confirmed

CISA assessed one organization in the Government Services and Facilities sector and one in the Water and Wastewater Systems sector. The advisory calls them Organization A and Organization B and does not disclose their names.

At Organization A, the red team found a web application whose built-in accounts still used default credentials. That access allowed it to send phishing messages from an internal address and compromise four workstations. It then combined Active Directory weaknesses to elevate privileges and move laterally without being contained.

CISA says the team accessed three sensitive business systems using credentials found on reachable machines. Those included cleartext service and database credentials, decrypted database configuration files and static AWS access keys configured never to expire. In the cloud, the team also obtained a Primary Refresh Token and abused over-permissioned Entra ID applications to read security-team email and learn whether defenders had noticed.

One SOC saw nothing; the other changed the attack

Organization A generated alerts, but useful signals were buried among thousands of higher-rated false positives. Multiple SOCs and endpoint products lacked shared visibility, analysts had limited authority to act, and a real alert was dismissed after responders could not identify the affected system's owner.

Organization B detected the initial phishing payloads as they ran and isolated the affected workstations in roughly two to 20 minutes. That severed command-and-control access and forced CISA to continue under an assume-breach model using a designated host. CISA still found serious credential exposure—including a cleartext service-account password with a path to domain-controller compromise—but the early containment changed what the original foothold could achieve.

The lesson is not that Organization B had no weaknesses. Both organizations reached a full-domain-compromise result under the assessment rules. The difference was that one response team detected and constrained the first stage before the attacker could use it freely.

A default credential is already a disclosed secret

Default passwords are not private merely because a system is internal. They are shared knowledge across manuals, installers, administrators and adversary playbooks. Every deployed service needs an accountable owner, a changed initial credential and a path for safe rotation. If ownership is unknown, even a correct alert can stall while teams debate who is allowed to disconnect the asset.

The same principle applies after initial setup. A cleartext database password on an administrator workstation and a non-expiring cloud key turn a local compromise into a reusable access package. Secrets should be scoped to the task, short-lived where the platform supports it, and unavailable to systems and people that do not need them.

Keep the recovery channel outside the compromised channel

CISA's red team could read security-team email at Organization A. That creates a dangerous incident-response loop: if responders distribute replacement credentials, investigation notes or recovery links through the same mailbox or chat environment, an intruder can observe the cleanup and capture the new secrets.

Declare a known-clean coordination channel. Do not assume corporate email, chat or the affected identity provider is safe.
Identify owners before the incident. Responders need authority and current contacts for high-impact systems.
Revoke sessions as well as passwords. Refresh tokens and existing cloud sessions can outlive a password change.
Rotate in dependency order. Start with identities that can mint, read or reset other credentials.
Replace standing secrets. Prefer managed identities and short-lived credentials over static keys that never expire.
Verify the recipient separately. A secure transfer protects content, but it does not prove who is on the other end.

Where Secretus fits

Secretus can help an authorized response team transfer a temporary recovery password, replacement API key or break-glass value without placing plaintext in a persistent ticket or chat transcript. One-time links and short expiration reduce the lifetime of the human-facing copy; Team Split can require more than one holder to release a critical recovery secret.

It is not a substitute for identity verification, endpoint trust, credential rotation or SOC process. Do not open a replacement secret on a device under investigation, and do not send the link through a channel the attacker may already control. Establish a known-clean device and verify the recipient before handing off the value.

What remains unknown

CISA intentionally anonymized both organizations and did not publish a complete inventory of affected products or every alert generated during the assessments. The advisory does not establish that either organization suffered a real-world criminal compromise. What it does establish is narrower and more actionable: tools alone did not compensate for unmanaged credentials, unclear ownership and weak response authority.