How an autonomous red team went from an ADCS relay to full on-prem compromise — and was stopped at the cloud.
Published 2026-09-11 · Updated 2026-09-13
An autonomous red-team run drove an 11-phase chain — ESC8 NTLM relay → DCSync → rogue cloud device → attempted tenant takeover. It was stopped at one wall: a phishing-resistant MFA policy. Here is every step, and every place a SOC could have caught it.
In one line. An unmanaged cloud administrator without phishing-resistant MFA let R0 turn a single relayed certificate into full control of the on-prem domain in about 25 minutes, entirely autonomously. The push into the cloud tenant ran a further ~35 minutes and was stopped by one control: phishing-resistant MFA enforced through Conditional Access. The same run hands your SOC a detection checkpoint for every step.
All names, domains, hostnames, IP addresses, tenant IDs and accounts below are fictional placeholders (corp.example). Real R0 output from a lab run, with every identifier replaced by a fictional corp.example placeholder.
Eleven phases, one continuous run.
The full chain, grouped by stage of the chain. Successful, partial and blocked steps are all shown — a red team is as useful for what it can’t do as for what it can.
On boundaries. R0 is non-destructive by default. Higher-impact actions — credential changes, device enrolment — run only under the explicit rules of engagement for a run, after an operator approval gate, and every one is reversible from the ledger. Nothing here touched data or availability.
On-prem in 25 minutes. Cloud attempt in the next 35.
Phase by phase, with evidence.
Selected phases with redacted evidence as R0 captured them to the audit ledger on a lab run. Secrets, hashes and passwords are removed.
ESC8 — ADCS enrolment relay
Both issuing CAs exposed HTTP web-enrolment without Extended Protection for Authentication (EPA). R0 coerced NTLM auth from a domain machine, relayed it to the CA’s /certsrv endpoint, obtained a machine-account certificate, and used PKINIT to mint a TGT — escalating to Domain Admin in prod.corp.example.
Certificate enrolment from a non-standard source IP; NTLM-relay signatures in CA/IIS logs; events 4886/4887 for machine-account enrolment; sudden PKINIT/TGT requests for DC machine accounts.
DCSync — full domain compromise
With DA privileges, R0 performed a DRSUAPI replication (DCSync) against the child DC and extracted the full credential set — including the krbtgt key and the cloud-sync service accounts that make the on-prem → cloud pivot possible.
Event 4662: replication access on the domain object from a non-DC; DsGetNCChanges originating from a workstation IP rather than a domain controller.
Rogue cloud device enrolment
Targeting an unprotected Global Admin (admin_ga01, no MFA methods), R0 forged a Kerberos ticket with the seamless-SSO computer-account hash, obtained a cloud-join token, and joined a rogue device — receiving a Primary Refresh Token and device certificate.
Cloud audit: new device registration by a GA from an unusual source; SSO sign-in with a forged Kerberos ticket (SID mismatch); device name outside the naming convention; PRT for a brand-new non-compliant device.
Privileged account password reset
Holding the account’s hash, R0 reset the Global Admin’s password over LDAPS via pass-the-hash, satisfied the fine-grained password policy on the third try, and confirmed the change synced to the cloud within seconds — enabling ROPC token flows.
Event 4724: password reset for a GA by a DA; event 4723: failed complexity attempts; NTLM auth from a Linux/WSL IP to a DC; directory-sync of a privileged password change.
FOCI token swapping
R0 tried to swap the limited first-party refresh token for clients with broader scopes. FOCI-family clients accepted the token but triggered an MFA challenge; non-FOCI clients were refused outright. With zero MFA methods enrolled, the challenge could never be satisfied.
Multiple token requests for different resources in a short window from one session; repeated AADSTS MFA-required failures for an account with no registered methods.
WHfB key registration — the wall
A signed-PRT exchange produced a device-registration token proving possession (amr: pwd,rsa), but key registration was rejected: the service demands an MFA claim (amr: mfa/ngcmfa). A device signature proves possession, not identity assurance — and with no MFA method, that claim can never be minted.
DRS key-registration failures for a new device; ForceNGCMFA errors; PRT-signed requests lacking an MFA claim — a strong signal of exactly this attack being attempted.
The MFA chicken-and-egg problem.
Every remaining path to the tenant depended on the one after it. The Conditional-Access policy requiring phishing-resistant MFA is what ultimately closed the loop.
Every step maps to a detection.
The same run that proves the attack path hands the SOC a checklist: what should have fired, and where. R0 pairs each action with the telemetry that catches it.
NTLM-relay enrolment in CA/IIS logs; events 4886/4887; enrolment from a non-standard IP.
Event 4662 replication from a non-DC; DsGetNCChanges from a workstation IP.
Events 4724/4723; PtH from a Linux IP; directory-sync of a privileged password change.
New device by a GA from an unusual source; PRT for a non-compliant device; off-convention name.
KDC TGT-revoked / PAC-validation events; SID-history mismatches on inbound tickets.
Repeated AADSTS MFA-required failures for a no-MFA account; rapid multi-resource token requests.
Autonomous end-to-end — and it respected the one real control.
One run crossed external, on-prem AD and hybrid-identity boundaries without a human driving, chained eleven techniques, and produced CVSS-scored, replayable evidence for each. It also proved a defensive truth worth paying for: phishing-resistant MFA, enforced everywhere, stops the takeover cold.
Run this chain
against your estate.
See R0 attempt the same path in your environment — and show you exactly where it stops.