Identity Is the New Perimeter

Your firewall and your MFA app can be bypassed if an attacker walks in with a valid login and a stolen session token. That's the pattern Microsoft and incident responders keep documenting, and it's the reason identity, not the network edge, is where the fight is now.

Start with the scale, though, because it changes what you should do first. Microsoft's Digital Defense Report puts identity attacks against its customers at roughly 600 million a day, and more than 99% of them are password attacks: spray, credential stuffing, brute force. Token theft and the other MFA-bypass techniques are the fast-growing sliver, not the bulk. So the unglamorous work still carries most of the load. MFA on every account, legacy authentication turned off, no reused passwords. This post is about the sliver, because that's what gets past a business that already did the unglamorous work.

One Stolen Identity, One Full Takeover

The pattern looks like this: a stolen employee identity leads to a broad cloud takeover. No malware. No exploit. No clever piece of code that your antivirus should have caught. The attacker just logs in.

Sometimes a compromised password is all it takes. Where MFA is in the way, a common move is to get a new authentication method registered under the attacker's control: social-engineering your help desk into resetting or re-enrolling the account, or exploiting loose self-service registration so a second factor the attacker owns gets added quietly. It's worth correcting a misconception here, because it circulates widely. Attackers do not use self-service password reset "to satisfy MFA." Entra ID's self-service password reset requires authentication methods to complete a reset in the first place. The weak point is how methods get registered and re-registered, not the reset itself.

That's the shift owners need to internalize. We spent a decade building walls (firewalls, endpoint protection, patch cycles) and attackers stopped trying to climb them. They walk through the front door with a valid credential instead.

How the Token-Theft Attack Actually Works

Here's the chain, step by step:

1. Phish IT and execs. These are the accounts with the most access, so they're the target.
2. A reverse proxy sits between the victim and the real Microsoft sign-in page. This is adversary-in-the-middle (AiTM) phishing, run with kits like Evilginx, EvilProxy, and Tycoon. The proxy relays your password and your MFA response to the genuine site, and captures the session token that comes back.
3. Replay the token. With the session token, the attacker is signed in as the user. MFA is already satisfied, because you satisfied it.
4. Persistence via OAuth consent and role escalation. They plant a foothold that survives a password reset.
5. Exfiltrate Microsoft 365, then pivot to Azure.

Two things get mashed together in most write-ups, and the distinction matters. Browser-in-the-browser kits render a convincing fake sign-in window inside a real browser tab, so the address bar you'd normally check is itself part of the drawing. That's user-interface spoofing, and on its own it harvests credentials. It does not hand anyone a session token. Capturing the token requires an actual AiTM reverse proxy relaying the real login behind the page. The two are often combined, which is what makes a modern phishing page so hard to spot, but they are different mechanisms doing different jobs.

Why a Stolen Session Beats Strong Passwords

When an attacker proxies your real login page and steals the live session token, they inherit an already-authenticated session. Your password and your one-time code did their job; the attacker simply replays what comes after. The problem isn't that passwords or MFA are worthless. It's that a stolen token walks past controls that were never designed to resist phishing: passwords alone, SMS codes, or simple push prompts.

There are real defenses. A practical checklist:

• Phishing-resistant MFA (passkeys or hardware security keys). These are bound to the legitimate site's origin, so a proxy page can't relay them the way it can an SMS code or a push approval. Be precise about the limits, though. Attackers respond by downgrading, steering the user toward a weaker method that's still registered on the account, and infostealer malware can lift session cookies off a device after a perfectly legitimate sign-in. Phishing-resistant MFA raises the cost substantially; it is not a force field. Remove the weak methods too, or you've only added a door next to the one that's still open.
• Conditional access, which decides who gets a token in the first place: require a compliant or managed device, block legacy authentication, and restrict where privileged roles can sign in from. Set expectations correctly here. Conditional access is evaluated at token issuance, so on its own it does not stop a token that has already been stolen from being replayed. And in an AiTM attack the traffic arrives from the attacker's proxy, so location-based conditions frequently never fire. One licensing note, since this trips people up: conditional access comes with Entra ID P1, which is included in Microsoft 365 Business Premium. The risk-based policies people often assume are in the box require Entra ID Protection, which is P2.
• Token protection and Continuous Access Evaluation, which are the controls that actually speak to replay. Token protection binds a token to the device it was issued to, so it's far less useful once lifted elsewhere. Continuous Access Evaluation lets Microsoft 365 services react to revocation and risk events during a live session instead of waiting for the token to expire on its own.
• OAuth app governance: require admin approval for third-party apps so an attacker can't quietly plant consent-based persistence.
• Privileged access controls that limit and separate admin rights, so one compromised account can't escalate to everything.
• Session and identity monitoring to catch replayed sessions, impossible-travel sign-ins, and suspicious OAuth grants.
• An incident response plan written before the incident, including how to revoke sessions and rotate credentials fast. Against a stolen token, fast revocation is the response.

How Comserv Helps

If your security strategy stops at "strong passwords plus MFA," you're guarding the speed bump while the attacker drives around it. Identity-first defense is a different discipline, and it's the one that matters now.

At Comserv Connect, our cybersecurity services cover the parts of this that live in our stack: 24/7 threat monitoring and response with live analysts, zero-trust endpoint control, email security for Microsoft 365 mail flow that stops a lot of this before the phishing page is ever opened, and security awareness training with simulated phishing so your team recognizes a fake sign-in page instead of typing into it. Where the remaining work sits inside your Microsoft tenant, we'll tell you what we see and what we'd change, and we'll be straight about what falls outside what we run.

Want a read on whether your logins would hold up against an AiTM attack? Book a free strategy call and we'll walk through your setup with you.