Tycoon 2FA against Entra ID and Google Workspace: MFA bypass and authentication assumptions under fire

Tycoon 2FA attacks against Entra ID and Google Workspace show a sharper version of an old authentication failure: MFA can succeed and the attacker can still obtain the session. The weakness is not that a one-time code, push approval or second factor has no value. The weakness is that many organisations still treat MFA completion as the end of the authentication story, while modern attack-in-the-middle phishing treats it as one event to be proxied, captured and converted into session access.

Elastic Security Labs' 26 May 2026 research on detecting Tycoon 2FA AiTM attacks across Entra ID and Google Workspace is useful because it does not frame MFA bypass as a weird edge case in one identity stack. The research describes telemetry fingerprints across both platforms and detection rules for each, which is the more important point. The attack method targets the shape of cloud identity itself: browser-mediated login, federated applications, reusable sessions, conditional access decisions and users trained to complete whatever authentication ceremony appears after entering a password.

That makes MFA bypass a misleading phrase. It sounds as if attackers have stepped around a control. In many AiTM cases they have stepped through it, with the victim doing the work.

MFA did not fail in the way people expect

When defenders hear MFA bypass, the mental model often goes to factor weakness. SMS can be intercepted. Push prompts can be fatigued. One-time passwords can be phished. Help desks can be socially engineered. Those are real problems, but AiTM phishing changes the centre of gravity. The attacker is not always trying to learn a static password and then solve MFA later. The attacker is placing infrastructure between the user and the legitimate identity provider so the whole authentication exchange can be relayed.

The user sees a convincing login page. The identity provider sees a login attempt that may look familiar enough to process. The MFA challenge is completed. The attacker receives the resulting session material or equivalent access opportunity, depending on the exact implementation and flow. From the user's perspective, the login may even appear to work. From the application's perspective, an authenticated session now exists. From the defender's perspective, the neat boundary between failed phishing and successful account takeover has disappeared.

This is why old MFA deployment metrics are becoming less useful. A dashboard that says 98 percent of users have MFA enabled may be comforting, but it does not answer whether those users are protected from session theft. A policy requiring MFA for cloud applications may be necessary, but it does not answer whether a proxied authentication flow can produce a usable session from an adversary-controlled path. An audit finding that MFA is enforced may be true and still incomplete.

MFA is an input into assurance. It is not assurance by itself.

Authentication has become a session security problem

Legacy authentication models were built around a discrete event. A user proved identity at login, then the system issued a session and moved on. That model worked tolerably when applications were fewer, networks were more bounded and attackers had to reuse stolen credentials in obvious places. Cloud identity broke that simplicity. The session is now the asset.

A modern employee may authenticate to an identity provider once and reach mail, storage, chat, developer tools, CRM, finance systems and administration consoles through federated access. The browser becomes the front door to the organisation. Tokens, cookies, refresh flows and application sessions carry authority across services. If an attacker can obtain the right session state, they may not need to know the password in any durable sense. They need the organisation to accept the artefact that says authentication already happened.

That is authentication control degradation. The formal control remains present. MFA is enabled. Conditional access exists. The identity provider logs activity. The application trusts the identity provider. Yet the security value of the control degrades because the attacker has moved to the point where the control's output is consumed.

This pattern is familiar in application security. A route guard checks access, then a backend operation trusts that the caller must be authorised. A UI hides a button, then the API accepts the direct request. In cloud identity, the login ceremony can become the route guard. Once it has produced a session, too many systems assume the hard part is over.

AiTM attacks exploit that assumption. They do not need to disprove MFA. They need to make MFA produce something portable enough to abuse.

The old assumptions are now liabilities

Four legacy assumptions fail particularly badly against modern MFA bypass techniques.

The first is that user interaction proves user intent. A user typing a password and approving an MFA prompt proves that a human interacted with a flow. It does not prove the human understood the origin of the flow, the relying party behind it or the session destination. Attackers exploit this by making the fraudulent path look close enough to the legitimate one. The victim's successful completion of the control becomes part of the compromise.

The second is that MFA completion upgrades the session for long enough to be trusted broadly. That assumption is risky when the session can be captured at the point of issuance or replayed through attacker infrastructure. The more authority attached to a newly authenticated browser session, the greater the value of relaying that login. Administrative portals, mailboxes, file stores and application consent flows become downstream prizes.

The third is that cloud identity telemetry can be reviewed later. AiTM attacks compress the useful response window. Elastic's research emphasised telemetry fingerprints and automated response workflows, including the ability to contain incidents involving these attacks in under 10 seconds. That number matters less as a vendor claim than as a design signal. Manual review after a suspicious sign-in alert is not an adequate control when a stolen session can be used immediately.

The fourth is that platform consistency means control consistency. Entra ID and Google Workspace differ in implementation, policy language and telemetry. Tycoon 2FA's relevance across both shows that the attack is not a quirk of one interface. It abuses common cloud identity properties: web login, session issuance, factor completion and user trust in familiar authentication screens.

A control that depends on users reliably distinguishing legitimate and malicious authentication paths is a brittle control. It may work often. It will not work enough.

Detection has to move closer to the session

Elastic Security Labs' focus on telemetry fingerprints is the right level of analysis because the security question has shifted from whether MFA occurred to whether the resulting session makes sense. Detection must look at the behaviour around authentication, not merely the fact of authentication.

Useful signals include mismatches between the user's historical login patterns and the new session path, suspicious proxy infrastructure, abnormal user agents, impossible travel, changes in device trust, unusual token usage, rapid access to high-value applications and immediate post-login actions that do not resemble the user's normal workflow. None of these signals is perfect. Together they describe whether the session is behaving like an extension of the user or like a freshly stolen capability.

The difficult part is that organisations have spent years tuning identity alerts to reduce noise. That pressure is understandable. Nobody wants a security operations team drowning in routine travel, VPN use, browser updates and mobile network changes. But AiTM pushes defenders towards faster decisions with less certainty. Waiting for perfect confidence can mean waiting until the attacker has read mail, created persistence, registered an OAuth application or changed recovery paths.

The right response is not to alert on everything. It is to predefine which session anomalies trigger containment, step-up authentication, token revocation or application access restriction. The threshold for interrupting a session that has just completed a suspicious login should be lower than the threshold for accusing a user of malicious behaviour. Containment is not attribution. It is a way to prevent a questionable session from becoming a breach.

This is where identity security often lags endpoint security. Endpoint teams are used to isolating a host when behaviour crosses a line. Identity teams are often more cautious because disabling a session can disrupt business. AiTM attacks make that caution expensive. A cloud session is a workstation without a chassis.

Phishing-resistant MFA is not a slogan

The usual recommendation after AiTM research is to adopt phishing-resistant MFA. That phrase is overused, but the concept is precise. A phishing-resistant factor binds the authentication to the legitimate origin in a way a proxy phishing site cannot simply relay. Hardware-backed passkeys and FIDO2/WebAuthn-style authentication are designed for this property because the authenticator verifies the relying party origin before completing the operation.

This changes the attack economics. A user can still be tricked into visiting a fake page. They can still be socially engineered. They can still be targeted with malware. But a basic AiTM proxy cannot harvest a reusable code or transparently complete the same ceremony if the authenticator refuses to authenticate to the wrong origin. That is a material improvement over push approvals and one-time codes that can be relayed.

The objection is deployment friction. Hardware keys, platform passkeys, recovery processes, shared workstations, mobile enrolment, contractor access and legacy application compatibility all complicate rollout. Those complications are real. They are also often used as a reason to keep weaker MFA in place for the exact users attackers target first: executives, administrators, finance staff, help desk personnel and developers.

A phased model is defensible. Start with privileged roles and high-value applications. Require phishing-resistant factors for administrative actions, application consent, security settings, mailbox delegation, financial workflows and source code access. Treat weaker MFA as a transitional control rather than an equivalent option. The problem is not that every organisation has failed if it still uses push MFA somewhere. The problem is pretending push MFA and origin-bound authentication carry the same assurance.

They do not.

Conditional access needs adversarial context

Conditional access policies often encode reasonable business assumptions. Users can sign in from managed devices. Administrators require stronger factors. Risky countries are blocked. Legacy protocols are disabled. Session lifetime is limited. These policies are valuable, but AiTM attacks expose how static some of them can be.

A condition is only as strong as the context it measures. If the policy trusts a device state that is not bound tightly to the session, the attacker may still benefit from a proxied login. If location rules are broad enough to accommodate remote work, they may not distinguish an employee from a relay node. If step-up authentication uses a phishable factor, the step-up can become another relayed event. If session lifetime is generous, a short successful compromise can create a long window.

Conditional access should be treated as runtime risk management, not a compliance checklist. Policies need to account for authentication method strength, token binding where available, device compliance, session age, application sensitivity and post-login behaviour. A low-risk session reading a public internal page should not be governed like a session granting mailbox export, admin consent or identity policy changes.

This matters because attackers chain identity actions. A successful session is rarely the final objective. It is used to search mail, identify payment processes, request password resets, register persistence, enumerate groups, create forwarding rules, access cloud storage or pivot into developer systems. The authentication decision has to follow the risk of those actions. Otherwise the session created by a phished login carries too much ambient authority.

The attacker moves faster than the control review cycle

The Hacker News summary of the Europol-led Tycoon 2FA takedown captures a broader operational reality: the kit relied on short-lived infrastructure, CAPTCHA checks, dynamic decoy pages and account-takeover chaining rather than one static trick. That observation is not a substitute for primary telemetry, but it matches what identity defenders see in practice. The attack chain evolves faster than policy review boards, quarterly audits and annual MFA projects.

This speed mismatch is where legacy assumptions become most dangerous. Many organisations still change authentication controls as if they are infrastructure projects: design, approve, pilot, document, roll out, review. Attackers change phishing kits as if they are software products. They test lures, adjust domains, rotate infrastructure and borrow whatever worked last week. A vulnerability closed yesterday can become a template for tomorrow's intrusion path. A control deployed last year can become a harvesting workflow this year.

The answer is not permanent panic. It is shorter feedback loops. Identity telemetry should feed policy changes. Incident response should revoke tokens and adjust conditional access quickly. High-value groups should have different authentication requirements from the general population. Detection rules should be treated as living code, not static content loaded into a SIEM and forgotten. Authentication controls need the same engineering discipline organisations already apply to endpoint detections and cloud posture.

If a new AiTM pattern appears across Entra ID and Google Workspace, the relevant question is not only whether a detection exists. It is how long the organisation takes to move from detection to containment to policy hardening.

MFA is a floor, not a boundary

None of this means MFA is obsolete. Removing MFA would make attackers' work easier. Password-only authentication remains indefensible for important systems. MFA still blocks credential stuffing, reduces the value of password reuse and forces attackers into more expensive paths. The mistake is treating MFA as a boundary rather than a floor.

A boundary stops the attacker from crossing. A floor raises the minimum cost of the attempt. AiTM phishing shows that MFA often performs the second role. That is still valuable, but it requires additional controls above it: phishing-resistant factors, origin binding, token protection, session anomaly detection, conditional access tuned to action risk, rapid revocation and user flows that make suspicious authentication harder to mistake for routine work.

The language matters because it shapes investment. If MFA is described as the control that prevents account takeover, every bypass looks like an exception. If MFA is described as one component in session assurance, AiTM attacks look like a predictable pressure test. The second framing is less comforting and more accurate.

Authentication has always been a claim about continuity: the subject at the keyboard is the same subject the system believes it is authorising. Modern cloud identity stretches that claim across browsers, tokens, devices, proxies, applications and time. Attackers do not need to break every piece. They only need one place where the system keeps trusting the ceremony after the ceremony has stopped proving enough.

The organisations that adapt will not be the ones with the longest MFA deployment slide. They will be the ones that can answer a harder question for every sensitive session: why should this action still be trusted now.