Security teams check the boxes and sleep well. MFA enabled. ITDR deployed. SIEM ingesting logs. EDR everywhere. Everything is safe, right?
Wrong.
A competent attacker can use a successful adversary-in-the-middle (AiTM) hack to walk through all of it, without tripping a single alert.
We know. We tested this in our lab and ran the complete scenario. Here's what we learned: surviving such an attack isn't about better detection, it's about having a rebuild architecture that allows you to save your business before attackers take it offline.
The Phish That MFA Can't Stop
Forget fake login pages. Modern AiTM frameworks like Evilginx don't fake anything. They sit between the user and the real Microsoft login page, proxying everything in real time.
The user sees the actual Microsoft sign-in, types their password, gets the multi-factor authentication (MFA) prompt with number matching, and authenticates with their fingerprint. After they authenticate, they land on Microsoft 365 like normal. Everything looks right because, from the user’s perspective, there’s no indication that anything went wrong.
But the proxy sitting in the middle captured two things: the user's plaintext credentials and a valid session token.
AiTM may be sneaky, but it isn't perfectly silent. The proxy server, the user's real location, and the attacker's eventual session all generate activity from different places. That's three geographic zones touching the same identity in a short window. A well-tuned environment might flag impossible travel or anomalous token activity.
Might.
In practice, plenty of orgs don't have those detections tuned. Or they're drowning in false positives from a sales team that logs in from a different airport every week. And the attacker has options—route through a residential proxy near the target and the geography problem mostly goes away.
The point isn't that AiTM is undetectable in theory. It's that it regularly succeeds in practice, across every spider group and half the e-crime ecosystem.
Two Things Worth Stealing
Here's what matters about the AiTM capture: the attacker walked away with two different keys to two different doors.
The session token gives them cloud access. They can replay it and operate inside Entra ID, M365, whatever the user had access to. No MFA challenge.
The plaintext credentials give them something else entirely. In a hybrid environment—which is most enterprises—those same credentials authenticate to the on-prem Active Directory with a different authentication plan and different protocols. On-prem AD authentication is traditional network security: username, password, Kerberos tickets. Nobody's getting an MFA push to log into a domain-joined workstation.
The attacker picks the door. In our scenario, they go on-prem because Active Directory is where privilege lives.
Kerberoasting: Active Directory Hands Over the Keys
The attacker authenticates to the domain with the stolen credentials. They're regular users now—no exceptional privileges, nothing special. But any authenticated domain user can request a service ticket for any account with a Service Principal Name and each ticket is encrypted with that account's password hash.
They request tickets for every SPN-associated account, dump them to a file, and take them offline.
The identity threat detection and response (IDTR) system fires a "suspicious protocol implementation" alert, flagging the compromised user. The SOC gets notified. The runbook says disable the account, quarantine the device.
But it doesn't matter. The attacker already has the tickets. Disabling the account doesn't un-crack a hash.
So they run hashcat. Within minutes, the service account password falls. This particular account has unconstrained delegation and Enterprise Admin membership.
No alert fires for the offline cracking. No alert can fire. It's happening on the attacker's hardware, completely outside your telemetry.
The Fork
This is where the attacker decides whether you ever find out what happened.
The Quiet Path - Golden Ticket: In the first scenario, the attacker now has Enterprise Admin credentials. They don't need to do anything fancy. They access a domain controller, pull the KRBTGT hash, and forge a golden ticket.
A golden ticket lets the attacker impersonate any user in the domain. It's not a session that expires. It's Kerberos TGT that every domain controller trusts because the trust is cryptographic and the attacker has the key.
Meaningful alert count for the entire chain: zero.
The AiTM phish either slipped past detection or got lost in a queue of false positives. The Kerberoasting alert led nowhere. The offline cracking was unobservable. The golden ticket is indistinguishable from a real TGT.
This leads to full compromise. Persistent, unrestricted access. But the SOC's dashboards are still green.
The Loud Path - Logging Into the Domain Controller (DC): In the second scenario, the attacker uses the cracked service account to interactively log into the DC. This is where detection actually works, but only because the attacker made an unnecessary choice.
The ITDR flags or blocks the interactive login. Service accounts don't interactively log into domain controllers. The alert fires and the security team can see what happened: attribute changes, persistence mechanisms, backdoors. They roll back the changes and clean up.
The system worked. But only because the attacker chose the loud option. DCSync would have been silent.
What Do You Do About a Successful AiTM Attack?
You found the attacker. Maybe the ITDR caught an interactive login to a domain controller. Maybe your IR team found the golden ticket, the skeleton key, the DCShadow registration, the backdoor accounts baked into AdminSDHolder. You know they're in there.
Now you're in a race.
The attacker still has valid credentials, forged tickets, and persistence mechanisms spread across your identity infrastructure. Every minute they keep access is a minute they could decide to detonate a wiper and take everything down. You've seen the playbook — Handala, Scattered Spider, ALPHV, the crews that hit MGM and Caesars. They don't always encrypt. Sometimes they just destroy. And when Active Directory is the target, "destroy" means every system that depends on AD for authentication will stop working.
You need to kick them out and rebuild the identity plane before they make that call. And this is where most organizations discover they don't have a plan.
Manual AD forest rebuild is a 150+ page process per domain. It requires specialized IR firms. It takes weeks. You don't have weeks. You might not have hours. And the whole time you're rebuilding, the attacker still has their golden ticket, their skeleton key, their backdoor accounts. You can't revoke what you can't rebuild.
Say you get through it. Say you rebuilt from a clean copy that's 30 to 180 days old (that duration is drawn from real world CISO examples). You've lost everything in between: new hires, permission changes, service accounts, GPO updates. All gone. Your AD is "clean" but it's also a N-Days behind reality.
Then the sync catastrophe hits. Okta reconnects to the recovered AD and triggers a full import. Every user created after your rebuild point gets deactivated. Group memberships revert. Attributes roll back. Entra ID loses its security groups, Conditional access fails silently, MFA enforcement breaks. You survived the attack and created a second outage yourself.
This is the problem Rubrik solves. Immutable, air-gapped copies of your identity provider that the attacker can't touch, even with domain admin. Real-time change tracking so you can threat-hunt for the last clean rebuild point without guessing. Orchestrated rebuild that takes hours instead of weeks, so you can actually outrun the attacker's decision to go destructive.
On top of that, you have a silver bullet: roll forward (in Research Preview). You can restore to the clean point, then bring every sanctioned change forward from the attack window while stripping out the attacker's persistence. New hires stay active. Legitimate group memberships stay intact. Service accounts keep working. Golden tickets, skeleton keys, backdoor accounts, privilege escalation chains—gone. Zero data loss. The attacker's artifacts are removed and everything legitimate carries over.
The difference between 28 days of downtime and a couple hours isn't better detection. It's having the rebuild architecture already in place so that when you find the attacker, you can actually do something about it before they burn the house down.
To learn more about Rubrik Identity Resilience, head here.