CISA AA26-237A shows how weak ADCS and MQA become domain compromise

At a glance

What this is: CISA’s AA26-237A shows that default Machine Account Quota and weak ADCS templates can combine into full domain compromise, with detection maturity determining whether the attack is stopped or missed.

Why it matters: IAM, PAM, and NHI teams should treat certificate issuance, machine account creation, and cloud token governance as one attack surface, not separate admin domains.

By the numbers:

• SafeBreach maps 24 behavioral simulations and 2 phishing-delivery simulations to the techniques used in the advisory.

👉 Read SafeBreach’s coverage of CISA advisory AA26-237A and identity control gaps

Context

CISA advisory AA26-237A is a control-effectiveness test, not a threat-actor report. It shows how ordinary identity misconfigurations, especially in Active Directory Certificate Services and machine-account governance, can be chained into domain compromise when detection and escalation paths are weak.

The advisory matters to identity teams because the failure was not limited to endpoint security or cloud identity in isolation. Machine account creation, certificate templates, delegated permissions, and token hygiene all sat on the same attack path, which is typical of environments where identity domains are managed separately instead of as one control plane.

Key questions

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. That turns ordinary directory settings into an escalation path. The failure is structural because the environment allows identity material to be minted without the level of accountability applied to other privileged actions.

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. Once a user can request or shape a certificate, authentication can bypass the original account boundary. That is why certificate governance belongs inside identity and privilege controls, not in isolated infrastructure administration.

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.

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.

Technical breakdown

How default Machine Account Quota enables unprivileged domain expansion

Machine Account Quota is the Windows setting that allows non-administrative users to create computer accounts in Active Directory. When left at the default value, it gives any domain user a foothold for abusing machine trust, including paths that support certificate requests, Kerberos abuse, and delegated access. The key issue is not the number itself, but the fact that a low-privilege user can create identity material that downstream controls treat as more trusted than the original account. In a mature environment, machine-account creation is treated as privileged identity issuance, not background configuration.

Practical implication: set Machine Account Quota to zero unless there is a documented operational need and tightly restrict any exception.

Why ESC1 ADCS templates turn certificates into identity impersonation

An ESC1 misconfigured certificate template allows enrollee-supplied subject data and weak enrollment restrictions, which means the requester can influence who the issued certificate represents. In practice, that lets a low-privilege user request a certificate for another identity and then authenticate as that identity if the certificate maps to domain trust. This is not a theoretical certificate hygiene issue. It is a direct identity substitution path in environments where certificate issuance, template permissions, and enrollment scope are not governed together.

Practical implication: review ADCS templates for ESC1 conditions and remove low-privilege enrollment paths that can mint impersonation-capable certificates.

How cloud token and application permissions extend an on-prem foothold

The advisory shows a common pattern in modern compromises: once attackers reach a trusted identity, they pivot into cloud applications, refresh tokens, and application permissions. A primary refresh token can provide persistent single sign-on capabilities, while application permissions such as Mail.ReadWrite can expose mailbox content without user interaction. That makes cloud identity a continuation of the same compromise, not a separate incident. Endpoint alerts may fire, but if token revocation, application ownership, and service-account monitoring are weak, the attacker keeps moving after the initial foothold is contained.

Practical implication: tie cloud application permissions, refresh-token monitoring, and service-account controls into the same incident response workflow as on-prem identity events.

Threat narrative

Attacker objective: The objective was to prove that ordinary identity misconfigurations can deliver full domain and cloud compromise without malware or a custom exploit.

1. Entry began with a default Machine Account Quota and an ESC1 ADCS template that let an unprivileged domain user create machine accounts and request impersonation-capable certificates.
2. Escalation followed when the red team used those certificates, service-account abuse, and cloud application permissions to move from low privilege into domain and tenant-wide trust.
3. Impact was full domain compromise, mailbox access, and cloud identity exposure, with one organisation failing to detect the sequence at all while the other contained only the earliest stage.

Breaches seen in the wild

• Sisense breach — unauthorized GitLab access led to exfiltration of access tokens, API keys and certificates.
• MITRE ATT&CK Enterprise Matrix — MITRE ATT&CK Enterprise — adversary tactics and techniques, threat detection, attack chain mapping, credential access, lateral movement, privilege escalation.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

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.

ESC1 certificate templates create an identity substitution path, not just a misconfiguration. The issue is not simply that the template is loose. It is that the certificate can become a portable claim of identity that bypasses the normal user-to-service accountability chain. In NIST CSF terms, access control and identification controls are being asked to compensate for a trust decision that already failed upstream.

Cloud identity gaps and on-prem gaps now behave as a single compromise surface. The advisory shows the same actor moving from local credential exposure into refresh tokens, application permissions, and mailbox access. That means PAM, IGA, and NHI governance can no longer stop at the directory boundary. Practitioners need to treat token hygiene, app ownership, and conditional access as part of the same identity lifecycle.

Detection maturity, not tool possession, separates survivable compromise from silent compromise. One SOC saw the activity, one did not, even though both organisations carried the same misconfigurations. That gap exposes a governance failure in alert triage, authority to escalate, and shared visibility across teams. The field lesson is that identity compromise becomes systemic when detection is fragmented across silos.

Identity blast radius is now defined by how many trust primitives are left ungoverned. In this advisory, machine accounts, certificate templates, service accounts, refresh tokens, and application permissions all contributed to the same outcome. That is the operating reality for modern identity security. Practitioners should judge control maturity by how much trust can be chained, not by how many tools are deployed.

From our research:

• 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.
• For a broader lens on machine identity compromise, see The 52 NHI breaches Report, which tracks recurring breach patterns across identity material and trust abuse.

What this signals

A programme that treats machine accounts, certificates, refresh tokens, and service principals as separate workstreams will miss the compound risk this advisory highlights. The next step is to map where identity trust can be chained across on-prem and cloud boundaries, then validate those paths under controlled conditions using CISA cyber threat advisories as the test harness.

Identity blast radius: when a single trust primitive can be chained into domain compromise, the question is no longer whether a control exists, but how far the resulting trust extends. That is the metric practitioners should be reporting upward.

The practical signal is that alert quality and escalation authority matter as much as detection coverage. If the team cannot act on low-severity identity anomalies before the attack reaches cloud tokens or mailbox permissions, the organisation is already behind the compromise curve.

For practitioners

• 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.
• Reduce alert noise before the next validation test Measure false-positive volume, define who can escalate, and make sure red-team-style identity activity is visible to the same team that can contain it.
• Inventory privileged identity objects across trust layers Map machine accounts, certificate templates, service principals, and delegated permissions together so the full escalation path is visible before an incident does it for you.

Key takeaways

• AA26-237A shows that default machine-account settings and weak ADCS templates can turn ordinary users into domain impersonators.
• The scale of the problem is operational, not hypothetical: one SOC missed the compromise entirely while another stopped the same tradecraft in minutes.
• The limiting control is identity governance across directory, certificate, and cloud token layers, because that is where the attack chain was made possible.

Key terms

• Machine Account Quota: The Active Directory setting that limits how many computer objects a non-admin user can create. In managed directories, the quota may remain in place even when customers cannot fully administer the domain, which makes the surrounding join workflow and group membership just as important as the setting itself.
• ESC1 Certificate Template: An ADCS template configuration that allows the requester to influence the subject of the issued certificate and weakens enrollment restrictions. In practice, it can let a low-privilege user mint a certificate that authenticates as a different identity.
• Primary Refresh Token: A Primary Refresh Token is a session credential that allows a user to keep authenticating without repeating full interactive sign-in. In practice, it becomes a high-value identity artefact because whoever holds it can continue access as the original user until the session expires or is revoked.
• Identity Blast Radius: The amount of damage a compromised identity can cause across systems, data, and infrastructure. In NHI environments, it is shaped by permissions, network reach, and administrative capability rather than by the credential alone. Reducing blast radius is a containment strategy that limits lateral movement and data exposure.

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.

👉 The full SafeBreach post shows the attack chain, simulation coverage, and validation steps in more detail.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or lifecycle governance, it is worth exploring.