How Attackers Use AI to Sidestep MFA on Okta and Microsoft 365

Why this report matters for Okta and Microsoft 365

At Infosecurity Europe, the report’s main point should matter to anyone running Microsoft 365 or Okta: AI does not break identity systems by itself, but it makes the attack chain cheaper, faster, and more reliable.

That sounds modest until you look at what attackers actually want. Passwords are usually just the first barrier. The real prize is the session, the mailbox, the OAuth grant, or the device-trust decision that follows MFA. Once an attacker has a valid session or a trusted browser context, a lot of “we have MFA” language stops meaning what teams assume it means.

The report also connected this to a wider pattern: AI-driven cyber threats, MFA bypass, and supply-chain exposure were all part of the same conversation, with Microsoft 365, Google Workspace, and Okta named as high-value identity layers. I am focusing on Microsoft 365 and Okta here because the mechanics are similar, and because both are often treated as the final control when they are really the front door to business access.

The key point from the Infosecurity Europe findings

The useful takeaway is not “AI defeated MFA.” That is too broad, and it misses the real failure mode.

The better reading is this: attackers are using AI to improve every step around MFA. They use it to gather cleaner recon, write more believable lures, vary messages at scale, and react in real time when a target authenticates. That makes the human part of the flow easier to exploit, while the technical part stays just as brittle as before.

For Okta and Microsoft 365, the interesting break is not a missing login screen. It is the moment a user approves a prompt, enters a code into a fake page, or hands over a token-bearing browser session that the attacker can replay somewhere else.

Why AI changes the scale of identity attacks, not the basic physics

AI does not change the underlying constraints:

• the attacker still needs a valid credential path,
• the identity provider still evaluates risk signals,
• the session still has to be created somewhere,
• and the platform still trusts a browser, token, or device state.

What AI changes is throughput and tailoring.

A human operator can write one decent phishing email. An AI-assisted operator can generate dozens of variants that match a target’s role, org chart, recent activity, and business context. A human can manually sort through public signals from LinkedIn, GitHub, corporate blogs, and breach dumps. An AI system can turn that into a pretext in seconds. A human can proxy one victim at a time. Automation lets an operator handle many victims at once, then keep the ones that yield fresh sessions or privileged access.

That is why this is a practical cybersecurity problem, not a sci-fi one. The attack is still built from ordinary identity mistakes.

The attack chain attackers actually use

The chains that work in the field are not novel. They are just packaged better.

Most compromises I have seen or reviewed follow the same shape:

1. gather enough public context to make the lure believable,
2. drive the user to a login flow that the attacker controls,
3. capture credentials and MFA in real time,
4. steal the resulting session or token,
5. pivot into mail, apps, or admin surfaces,
6. use identity tooling to stay in the environment.

Recon and persona building from public data

The first step is not exploitation. It is impersonation.

AI helps attackers build a usable picture of the target faster than a human can. Public job postings, social profiles, conference speaker pages, supplier portals, and even old press releases can tell the attacker enough to answer basic questions:

• what systems the person likely uses,
• who they report to,
• whether they are finance, IT, sales, or procurement,
• what vendors they deal with,
• and what kind of urgent business pressure makes them click.

This matters because identity attacks work better when the lure matches the target’s daily routine. A finance user is more likely to believe a wire transfer or invoice theme. A helpdesk user is more likely to trust a device enrollment or password reset theme. A Microsoft 365 admin is more likely to treat a “security notification” as normal noise unless the timing feels off.

The attacker does not need perfect intelligence. They just need enough detail to avoid looking generic.

AI-assisted lure generation and message variation

Once the persona is built, AI helps with the part that used to make phishing easier to spot: repetition.

A lot of old lures fail because they reuse the same wording, the same spelling mistakes, or the same visual cues. AI removes those tells. It can generate a believable message in a specific tone, adapt it to the target’s region or company vocabulary, and create many variants for the same campaign.

The practical effect is simple: email security teams and users see less uniformity. That makes static detection weaker.

A good defensive model assumes the lure can be written well. The question is no longer “does this email look amateurish?” The question is “does the click lead to an authentication flow that can survive hostile relay, or does the session get handed to whoever controls the page?”

Adversary-in-the-middle phishing and real-time token capture

This is the core of modern MFA bypass.

In an adversary-in-the-middle, or AiTM, flow, the attacker sits between the victim and the real login service. The victim believes they are authenticating to Okta or Microsoft 365. In reality, the attacker’s infrastructure relays requests to the real service and captures what comes back.

The dangerous part is not only the password. The dangerous part is the authenticated browser state that follows a successful MFA challenge.

If the attacker can relay the sign-in in real time, they can capture:

• cookies,
• authorization artifacts,
• refresh tokens in some flows,
• and enough browser state to continue the session from another machine.

That is why OTPs and push approvals are weaker than they look. They prove the user was present at a moment in time. They do not prove the browser or device holding the session afterward is safe.

Session hijacking after MFA succeeds

A lot of defenders stop thinking after the second factor succeeds. That is the mistake.

Once the session exists, the attacker does not always need to keep reauthenticating. They may move to session replay, token abuse, or API access. In practice, that often means:

• opening the mailbox,
• creating inbox rules,
• registering a new OAuth app or granting consent,
• adding a new factor or recovery path,
• and looking for admin surfaces, cloud files, or downstream SaaS access.

If the token stays valid long enough, the attacker can do all of this before the victim notices anything unusual.

Where MFA breaks down

MFA is not one thing. The difference between a hard control and a soft one matters here.

Phishing-resistant MFA versus push approvals and OTPs

Not all second factors are equal.

Phishing-resistant MFA changes the game because the assertion is tied to the legitimate origin and often to hardware-backed keys. That does not make identity attacks impossible, but it raises the cost sharply.

The mistake I see a lot is treating “MFA enabled” as a single yes/no control. In reality, your risk depends on which factor is allowed for which user, and whether the sign-in flow can be proxied at all.

Session cookies, refresh tokens, and why the second factor can disappear

Once the user completes MFA, the platform usually issues a session artifact. That artifact is what the attacker wants.

A password can be rotated. A token can live longer than a password reset. A browser session can remain valid until the issuer or the application notices something is wrong. That means a password change is not enough if the attacker already has a session or a refresh path.

This is why incident response on identity compromise has to look beyond the login event itself. You need to ask:

• Is there an active browser session?
• Are there refresh tokens or app-specific tokens still valid?
• Did the attacker add a new factor?
• Did they create a mailbox rule or OAuth grant?
• Did they log in from an unmanaged browser on a device that still has access?

If the answer to those questions is “maybe,” the compromise is not done.

Device trust and conditional access gaps that attackers exploit

Conditional access is powerful, but only if the inputs are trustworthy.

Attackers look for gaps such as:

• unmanaged devices allowed for some apps,
• legacy auth paths that skip modern controls,
• weak device compliance enforcement,
• relaxed rules for “trusted” networks,
• and policies that focus on sign-in location instead of session behavior.

The issue is not that conditional access is useless. The issue is that many organizations rely on it as if it were a wall. It is really a set of filters. If a filter accepts a hostile browser session, the session still gets through.

A realistic compromise sequence to walk through

I find it useful to model the attack as a sequence, because every stage leaves different evidence.

Step 1: Initial contact and credential capture

The first message usually has one goal: get the user to an authentication page.

The email or chat lure is often business-shaped. It may claim a document was shared, a file is pending review, a security alert needs confirmation, or a vendor action is overdue. AI makes this stage look polished, but the substance is still simple: create urgency, lower suspicion, and move the user into a login flow.

At this point, defenders should care about:

• the sender domain,
• the landing domain,
• whether the page is doing relay instead of real login,
• and whether the user entered credentials into a form that was not the real IdP.

If the user only sees a branded login page, that is not reassuring. AiTM pages are often branded too.

Step 2: Live proxying into Okta or Microsoft 365

Once the user begins signing in, the attacker relays the session to the real service.

That is the moment where the second factor can still be captured in real time. From the victim’s point of view, the login succeeds. From the attacker’s point of view, the session is now theirs to use.

A good security team should assume that any login path that allows real-time relay is not truly MFA-resistant. The authentication succeeded, but the channel was not protected well enough.

Step 3: Establishing persistence with sessions, OAuth grants, or mailbox rules

After the first foothold, the attacker usually tries to make the access survive a password reset.

Common persistence paths include:

• a live session that stays valid,
• a refresh token or app token,
• a new OAuth consent grant,
• a mailbox forwarding rule,
• delegated access to mail or files,
• or a new recovery method or authenticator.

This is where Microsoft 365 and Okta both become especially important. In Microsoft 365, mail and cloud apps can provide endless follow-on access. In Okta, a compromised identity plane can fan out to many downstream SaaS apps through SSO.

Step 4: Privilege discovery and lateral movement through identity tooling

The attacker then looks for what the compromised identity can see.

That may include:

• group membership,
• admin roles,
• app assignments,
• helpdesk reset paths,
• connected enterprise apps,
• directory objects,
• or privileged users with weak secondary controls.

Identity attacks often look lateral before they look vertical. The attacker does not need domain admin on day one. They need a way to impersonate someone who can reach more systems, more approvals, or more trust.

Microsoft 365-specific failure modes to inspect

Microsoft 365 gives you a lot of telemetry, but only if you know how to connect it.

Entra ID sign-in logs and impossible travel patterns

Start with the sign-in logs.

Look for combinations like:

• a successful sign-in from a new ASN or country,
• a user agent that does not match the user’s normal profile,
• a device that appears unmanaged or newly registered,
• and a burst of activity shortly after the first login.

Impossible travel is still useful, but I would not treat it as proof. AiTM sessions can appear to come from a local region or proxy network that looks less suspicious than expected.

What matters more is correlation. A clean sign-in followed by a mailbox rule creation or OAuth consent within minutes is a better signal than geography alone.

OAuth consent abuse, inbox rules, and delegated access

This is one of the most common post-login persistence patterns in Microsoft 365.

Watch for:

• new OAuth consents from unusual apps,
• delegated permissions that were not part of normal business workflows,
• mailbox forwarding rules to external addresses,
• inbox rules that hide security alerts or move messages out of view,
• and changes to delegated access or application credentials.

These actions often happen quickly after compromise because they are cheap for the attacker and hard to notice in the moment.

Session revocation limits and token lifetime assumptions

A lot of teams think a password reset is enough. It is not.

If the attacker already has a valid token or an active session, revoking the password alone may not close the door. You need to know how long different sessions survive, where refresh is allowed, and which clients can silently reauthenticate.

The practical lesson is to test your own tenant assumptions. Do not guess how long access persists. Verify it.

Okta-specific failure modes to inspect

Okta gives you a different shape of evidence, but the compromise patterns rhyme.

Suspicious authenticator enrollment and factor resets

One of the first things I would inspect is whether the attacker tried to change the account’s trust posture.

That includes:

• new authenticator enrollment,
• factor resets,
• recovery method changes,
• and suspicious admin-initiated or helpdesk-assisted account updates.

If a user who rarely changes devices suddenly re-enrolls an authenticator, that is worth a close look. If it happens right after a login from a new browser or IP, it is even more concerning.

New device, new IP, and unusual user-agent combinations

Okta system logs can help identify sessions that do not fit normal behavior.

Pay attention to:

• first-seen browser fingerprints,
• IPs that do not match the user’s usual region,
• user-agents that change mid-session,
• and sign-ins that succeed despite odd device context.

AI-assisted campaigns often generate many attempts, but the successful one still tends to stand out if you compare it to historical behavior. A user who normally uses a managed laptop from one region should not suddenly authenticate through a strange browser chain and then start touching high-value apps.

Admin actions, app assignments, and SSO abuse after login

If an Okta admin or delegated operator is compromised, the blast radius gets much larger.

Review:

• app assignments,
• group membership changes,
• SSO policy updates,
• new API tokens,
• and any admin action performed soon after a suspicious sign-in.

A compromised identity provider is often more dangerous than a single mailbox compromise because it can unlock many downstream systems in one move.

What to hunt for in telemetry

The best detections correlate identity, email, and endpoint signals. Any one of them alone can be misleading.

Identity provider logs, email logs, and endpoint/browser signals

You want to connect the following:

• IdP sign-in logs,
• MFA challenge results,
• mailbox audit events,
• OAuth consent and app registration logs,
• browser and endpoint telemetry,
• and EDR alerts for credential theft or token abuse.

A useful question is: did the login happen in isolation, or did it immediately trigger a chain of control-plane actions?

Indicators that suggest AiTM rather than a normal login

A few patterns deserve extra attention:

• login succeeds after an unusual lure or short-lived link,
• MFA is completed but the device is not one you expect,
• session behavior changes immediately after authentication,
• token or browser activity appears from a different host than the one used for the MFA challenge,
• and the user reports “I signed in, but then things felt off” or sees suspicious prompts.

AiTM often leaves a mismatch between where the authentication started and where the resulting session is used.

Correlating sign-in events with mailbox and OAuth activity

Here is the practical order I would use in an investigation:

1. Find the first successful sign-in that looks odd.
2. Check whether MFA completed normally or was relayed.
3. Look for mailbox rules, OAuth consents, or delegated access within the next few minutes.
4. Check whether the user’s device or browser history shows a fake login page.
5. Review whether the attacker attempted factor enrollment or recovery changes.
6. Determine whether any downstream SaaS app was reached through SSO.

That correlation usually tells you whether you are looking at a one-off phishing event or a broader identity compromise.

Defensive controls that actually reduce risk

This is where most organizations need to be more opinionated.

Move high-risk users to phishing-resistant MFA

If there is one control that consistently pays off, it is phishing-resistant MFA for the users who matter most.

Start with:

• admins,
• finance,
• HR,
• executives,
• helpdesk staff,
• and anyone with access to identity or payment workflows.

WebAuthn and passkeys reduce the chance that an attacker can replay the login through a fake page. That does not eliminate all risk, but it makes AiTM much less effective.

Tighten conditional access and device compliance checks

Conditional access should do more than ask whether the user knows a password.

Enforce:

• managed device requirements for sensitive apps,
• step-up auth for risky actions,
• strict rules for admin consoles,
• and blocks for legacy or weak auth methods.

If a session is coming from an unmanaged browser on a device that never enrolled in your fleet, that should not be treated like a normal workday login.

Reduce session lifetime where it matters most

Shorter sessions can reduce how long an attacker can ride on stolen access.

That is especially useful for:

• admin sessions,
• high-risk SaaS apps,
• and workflows that expose sensitive data or financial actions.

You do not need to shorten everything equally. The goal is to make the highest-value sessions less reusable after compromise.

Lock down OAuth consent and app registration paths

A surprising amount of persistence begins with a user clicking “allow.”

You should review:

• who can consent to apps,
• whether unverified publishers are blocked,
• whether app registrations are restricted,
• and whether high-privilege scopes are heavily controlled.

If users can grant broad access to mail or files without guardrails, a password reset will not save you.

Browser, email, and endpoint hardening

Identity controls are stronger when the browser and endpoint are not easy to misuse.

Link rewriting, isolation, and domain filtering

Email security should reduce the chance that users ever reach the fake login page.

Useful layers include:

• URL rewriting and detonation,
• attachment sandboxing,
• domain reputation filtering,
• lookalike domain controls,
• and browser isolation for risky links.

These are not perfect, but they buy time. In identity attacks, time matters because the attacker wins by getting the user to authenticate before the message is recognized as malicious.

Endpoint detection for suspicious browser behavior and credential theft

Endpoint telemetry should watch for:

• browser processes spawning unusual helper processes,
• token theft patterns,
• unexpected browser profile changes,
• suspicious extensions,
• and memory or cookie access that does not fit normal user behavior.

This is not about scanning every browser action. It is about catching the moment a supposedly normal login is turned into a reusable session on a different machine.

User-facing controls that help without relying on user judgment alone

Users should still be trained, but training cannot be the only line of defense.

Useful user-facing controls include:

• clear MFA approval details,
• visible device and location context,
• alerts for new authenticator enrollment,
• and friction for risky sign-in changes.

The point is to make the unsafe path noisy before it becomes persistent.

How to respond if you suspect MFA bypass already happened

If you think the attacker already got in, move like the session is alive until proven otherwise.

Immediate containment steps for Okta and Microsoft 365

Start with containment:

• revoke active sessions,
• reset the password,
• disable or re-enroll authenticators,
• remove suspicious mailbox rules,
• block suspicious OAuth apps,
• and isolate the endpoint if you suspect token theft or browser compromise.

Do not wait for a perfect root cause before cutting access. A live identity compromise can keep spreading while you investigate.

What to rotate, revoke, and recheck after containment

After the initial lockout, verify:

• recovery methods,
• delegated access,
• app passwords or legacy auth artifacts where they still exist,
• API tokens,
• admin role assignments,
• and connected SSO apps.

A reset that leaves one shadow path behind is not a reset.

Why mailbox and OAuth cleanup matters after the password reset

This is the part teams miss.

An attacker who had mail access may already have set forwarding, hidden alerts, or approved access for another app. If you only rotate the password, the old path may still work through an external inbox rule or an OAuth grant that survives the login change.

That is why cleanup has to include the control plane, not just the credential.

Verification checklist for your own tenant

If you want to know whether your current controls would stop this attack chain, ask these questions.

Questions to ask before you trust MFA as a control

• Are admins and high-risk users on phishing-resistant MFA?
• Can a user complete MFA from a fake page and still yield a valid session?
• Are legacy auth paths fully blocked?
• Can users consent to powerful OAuth apps?
• How long do stolen sessions remain valid after a password reset?
• Do conditional access policies require managed devices for sensitive apps?
• Are mailbox rules and forwarding monitored in near real time?

If you cannot answer those quickly, your MFA story is probably less mature than your dashboard says.

Practical tests you can run in a safe environment

In a controlled tenant or lab, you can test defensive behavior without doing anything offensive:

1. Use a test account with the same MFA class as a real user.
2. Confirm what happens when the account signs in from a new browser and device.
3. Verify that session revocation actually ends access to mail and cloud apps.
4. Check whether a user can grant OAuth consent to a test app.
5. Create a benign inbox rule and confirm your detections fire.
6. Review whether Okta or Entra alerts on authenticator enrollment, device changes, or risky sign-ins.
7. Measure how quickly your team can correlate sign-in, mail, and app activity.

The goal is not to simulate abuse in detail. It is to prove whether your logging, policy, and response path are fast enough to matter.

Closing perspective

The real lesson from AI-assisted identity attacks

The report’s real value is that it shifts the conversation away from “AI is scary” and toward the controls that fail in practice.

AI makes phishing more convincing and more scalable, but the compromise still depends on old weaknesses: non-phishing-resistant MFA, weak session hygiene, lax OAuth governance, and overconfident trust in a successful login.

If you run Okta or Microsoft 365, the right question is not whether MFA exists. The right question is whether your identity stack can survive a user authenticating through a hostile relay and then handing the attacker a session that still works ten minutes later.

That is the test that matters now.