Analysis updated September 29, 2026. CISA’s latest red-team comparison is not a story about one organization buying better security software. Both assessed environments were compromised. The difference was that one security operations center found the initial activity, isolated affected systems within minutes, and forced the exercise into an assume-breach phase; the other received relevant alerts but lost them in noise and organizational friction.
Advisory AA26-237A, published August 25, 2026, gives detection engineers a useful case study because it connects technical signals with the human decisions that followed them. It also shows why endpoint visibility alone is not enough when Active Directory, workload identities, cloud tokens, and operational technology sit in the same attack path.
What happened in CISA’s two assessments
CISA ran concurrent red-team assessments against a government services organization and a water and wastewater organization. The teams used comparable tradecraft, beginning with phishing and moving through identity discovery, privilege escalation, lateral movement, cloud access, and sensitive systems. CISA reports that the red team ultimately achieved domain compromise and accessed sensitive business systems and cloud resources in both environments.
The early defensive outcomes were very different. At Organization A, the red team gained access to four workstations and continued its campaign without an effective response. At Organization B, three payload executions produced medium-severity alerts. Analysts isolated the affected workstations in 10, 2, and 20 minutes, terminating command-and-control access. That did not end the assessment—CISA supplied an assume-breach foothold so the exercise could continue—but it demonstrated that the SOC could recognize and contain the initial intrusion.
This distinction matters. A mature SOC cannot promise that every phishing attempt will fail. It can reduce the time between a meaningful signal and containment, preserve evidence, and make each subsequent attacker action more difficult.
Five detection engineering lessons
1. Alert severity is not the same as business priority
Organization A received endpoint alerts related to red-team activity, but thousands of routine and false-positive alerts—some with higher severity—obscured them. Organization B investigated medium-severity DLL-loading alerts and acted quickly. The lesson is not to promote every medium alert to critical. It is to add context that helps analysts recognize unusual behavior on important assets.
A practical queue should consider asset criticality, identity privilege, prevalence, parent process, recent changes, and related events. A medium endpoint event on a Tier 0 management server should not be handled like the same event on an ordinary test workstation. Detection owners should review which rules produce volume without decisions and either improve, suppress, or retire them.
2. Containment authority must be designed before an incident
CISA observed organizational silos at Organization A: separate SOCs lacked shared visibility, system owners were difficult to identify, and analysts did not have clear escalation procedures or authority. An alert involving an SCCM system was eventually treated as a false positive after staff could not establish what the system did or who owned it.
Organization B’s responders could quarantine workstations promptly. That is a process control as much as a technical one. Every high-value detection should name an owner, an escalation path, and the actions an analyst may take without waiting for multiple approvals. For destructive or availability-sensitive actions, define safer intermediate steps such as network isolation, token revocation, session blocking, or temporary egress restrictions.
3. Identity infrastructure is part of the detection surface
The red team examined Active Directory Certificate Services and machine-account settings. At Organization A, CISA identified an ESC1 certificate-template misconfiguration and a default Machine Account Quota that allowed ordinary users to add computer accounts. At Organization B, the quota was even higher, and a service account had excessive rights over a domain controller. Those conditions supported account creation, certificate abuse, DCSync, and broader domain compromise.
Defenders should monitor for computer-account creation by non-administrative identities, changes to certificate templates, certificate enrollment anomalies, directory replication from non-domain controllers, and unusual service-account behavior. CISA recommends setting Machine Account Quota to zero unless a documented business requirement exists and applying least privilege to certificate enrollment and template permissions.
4. Cloud eviction must include tokens and workload identities
Both organizations had cloud weaknesses. CISA found excessive application permissions, long-lived AWS credentials, service accounts that could sign in interactively, and immature procedures for revoking compromised access and refresh tokens. Removing malware from an endpoint does not end an incident if a stolen token or application secret still works from the public internet.
A cloud containment playbook should include user sessions, refresh tokens, application credentials, service principals, federated access, API permissions, and trusted network conditions. Microsoft documents Conditional Access for workload identities, while AWS recommends temporary credentials and IAM roles instead of long-lived access keys. These controls reduce persistence, but they still require logging, review, and tested revocation procedures.
5. Segmentation only works when egress is controlled
At Organization B, the red team reached a bastion host in the operational technology DMZ and attempted to establish command and control. Outbound connectivity was blocked, the activity generated an alert, and the SOC isolated the host. This is a concrete example of layered defense: segmentation limited the path, egress policy prevented the callback, and monitoring drove response.
For bastion hosts and management systems, allow only required destinations and protocols. Alert on denied outbound connections, newly created executables, credential files, and remote administration outside the approved pattern. Treat endpoint managers such as SCCM, Jamf, and BigFix as Tier 0 systems because their administrative reach can turn one compromise into enterprise-wide execution.
Hands-on lab: correlate three safe synthetic signals
The following lab does not exploit a system and does not reproduce CISA’s red-team operations. It uses synthetic JSON events to demonstrate a small correlation rule: a suspicious endpoint alert followed by a newly created machine account and unusual cloud API activity for the same identity. Run it in a disposable directory with Python 3. The exercise is intentionally vendor-neutral so the logic can be translated into your SIEM.
1. Create the sample events
mkdir -p soc-correlation-lab
cd soc-correlation-lab
cat > events.jsonl <<'EOF'
{"ts":"2026-09-29T08:00:00Z","source":"edr","host":"WS-104","user":"alex","event":"unexpected_dll","severity":"medium"}
{"ts":"2026-09-29T08:03:00Z","source":"windows","host":"DC-01","user":"alex","event":"computer_account_created","target":"WS-104-ADM$","event_id":4741}
{"ts":"2026-09-29T08:06:00Z","source":"entra","host":"cloud","user":"alex","event":"graph_api_burst","requests":840}
{"ts":"2026-09-29T08:11:00Z","source":"edr","host":"WS-220","user":"morgan","event":"unexpected_dll","severity":"medium"}
{"ts":"2026-09-29T08:20:00Z","source":"windows","host":"DC-01","user":"svc_join","event":"computer_account_created","target":"KIOSK-77$","event_id":4741}
EOF2. Run a simple correlation script
import json
from collections import defaultdict
from datetime import datetime, timezone
events = []
with open("events.jsonl", encoding="utf-8") as stream:
for line in stream:
event = json.loads(line)
event["time"] = datetime.fromisoformat(
event["ts"].replace("Z", "+00:00")
).astimezone(timezone.utc)
events.append(event)
by_user = defaultdict(list)
for event in sorted(events, key=lambda item: item["time"]):
by_user[event["user"]].append(event)
required = {
"unexpected_dll",
"computer_account_created",
"graph_api_burst",
}
for user, timeline in by_user.items():
observed = {item["event"] for item in timeline}
elapsed = (timeline[-1]["time"] - timeline[0]["time"]).total_seconds()
if required.issubset(observed) and elapsed <= 900:
print(
f"HIGH correlation user={user} "
f"events={len(timeline)} window={int(elapsed)}s"
)python3 correlate.pyExpected output:
HIGH correlation user=alex events=3 window=360sThe individual events are not proof of compromise. A legitimate workstation deployment process may create computer accounts, and an approved automation may generate many Graph requests. The correlation becomes useful because three unusual actions occur for the same identity within a short window. In production, enrich the rule with asset role, approved join accounts, maintenance windows, identity risk, process ancestry, and whether the new machine name follows your naming standard.
3. Translate the logic into operations
Assign the correlated alert to an owner and attach response steps: validate the user’s activity, isolate the endpoint when warranted, disable or contain the suspicious machine account, review directory replication activity, revoke affected cloud sessions and tokens, and search for the same indicators across other identities. Test the rule with authorized purple-team exercises and measure both detection time and analyst decision time.
4. Clean up
cd ..
rm -r soc-correlation-labThe lab uses only local synthetic files. It makes no changes to Active Directory, Entra ID, AWS, endpoints, or network controls.
A 30-day improvement plan
- Week 1: Identify the ten noisiest rules, the ten most critical assets, and every queue where ownership is unclear. Measure alert volume, false-positive rate, and time to disposition.
- Week 2: Add business and identity context to priority detections. Build rules for unusual computer-account creation, risky service-account sign-in, non-DC replication activity, and application-secret changes.
- Week 3: Document who may isolate hosts, block accounts, revoke tokens, or restrict egress. Run a tabletop exercise that crosses endpoint, directory, cloud, and OT teams.
- Week 4: Conduct an authorized detection test, review missed telemetry, and remove rules that create volume without a useful decision. Record the rationale for every suppression.
For implementation ideas, see VigilSecureInfo’s guides to installing Wazuh and writing custom detection rules and advanced SOC threat hunting and SOAR automation.
Conclusion
CISA’s comparison is a reminder that visibility has value only when a team can recognize, investigate, and act on it. Organization B still had serious identity and cloud weaknesses, yet its tuned detections, clear response path, and network controls repeatedly disrupted red-team access. The immediate goal for a SOC is therefore not “more alerts.” It is fewer ambiguous alerts, richer context, tested cloud and identity containment, and authority to act while the evidence is still fresh.
