Notifications
Clear all
Topic starter
27/08/2026 2:11 pm
TL;DR: CISA’s AA26-237A shows that two critical infrastructure organisations can face the same red-team tradecraft and yet diverge sharply on detection, with default Machine Account Quota and ESC1 ADCS templates turning ordinary domain users into certificate-based domain impersonators, according to SafeBreach. The lesson for identity teams is that cloud and on-prem controls fail together when privilege, visibility, and certificate issuance are governed as separate problems.
NHIMG editorial — based on content published by SafeBreach: A Tale of Two SOCs: SafeBreach Coverage for CISA Alert AA26-237A Summary
By the numbers:
- SafeBreach maps 24 behavioral simulations and 2 phishing-delivery simulations to the techniques used in the advisory.
Questions worth separating out
Q: What breaks when Machine Account Quota and ADCS templates are left loose?
A: A low-privilege domain user can create trusted machine identities and use weak certificate templates to impersonate higher-value accounts.
Q: Why do certificate templates and machine accounts matter so much in domain compromise?
A: Because they convert a small initial foothold into an identity that the rest of the domain is willing to trust.
Q: How do cloud permissions change the impact of an on-prem identity compromise?
A: They extend it. Refresh tokens, application permissions, and service-account trust let an attacker move from local compromise into mailboxes, APIs, and tenant-wide data access. If cloud ownership and token revocation are not tied to the same response process, containment stops at the wrong boundary.
Practitioner guidance
- Zero out machine-account creation by default Set Machine Account Quota to zero unless a specific operational case exists, then restrict exceptions to the smallest possible administrative group and review them regularly.
- Audit ADCS for impersonation-capable templates Review certificate templates for ESC1 conditions, enrollee-supplied subject data, and weak enrollment restrictions that allow low-privilege impersonation.
- Unify cloud and on-prem identity incident response Treat refresh tokens, application permissions, mailbox access, and service-account abuse as one containment path so a local compromise cannot continue into the tenant.
What's in the full article
SafeBreach's full post covers the operational detail this post intentionally leaves for the source:
- The exact CISA AA26-237A tradecraft mapping across endpoint, Active Directory, ADCS, and cloud identity stages.
- The specific behavioural simulations SafeBreach says already cover the advisory chain, including the two phishing-delivery paths.
- The validation scenarios that let teams test whether Machine Account Quota, ADCS templates, and cloud token controls fail in the same sequence.
- The detection and tuning details for organisations that want to reproduce the advisory under controlled conditions.
👉 Read SafeBreach’s coverage of CISA advisory AA26-237A and identity control gaps →
CISA AA26-237A: what ADCS templates and Machine Account Quota exposed?
Explore further
27/08/2026 2:12 pm
Default machine-account creation is not a convenience control. It is an identity issuance decision. Machine Account Quota assumes non-admin users should be able to mint new computer identities as part of ordinary domain operations. That assumption breaks when a low-privilege account can create objects that downstream authentication and certificate controls trust. The practical conclusion is that machine-account creation belongs in privileged identity governance, not in baseline convenience settings.
A few things that frame the scale:
- Only 44% of organisations have implemented any policies to manage their AI agents, despite 92% agreeing that governing AI agents is critical to enterprise security, according to The 2026 Infrastructure Identity Survey.
- 69% of security leaders agree identity management must fundamentally shift to address agentic AI systems, according to The 2026 Infrastructure Identity Survey.
A question worth separating out:
Q: Who is accountable when a red team compromise exposes both endpoint and cloud identity gaps?
A: The accountable owners are the teams that govern directory settings, certificate issuance, cloud application permissions, and incident escalation. When those responsibilities sit in separate silos, nobody owns the full attack path. Frameworks such as NIST CSF and NIST SP 800-53 expect those controls to work together, not in isolation.
👉 Read our full editorial: CISA AA26-237A shows how weak ADCS and MQA become domain compromise
