Browser-in-the-browser phishing is making MFA bypass easier

At a glance

What this is: This is a threat-analysis post on Sneaky2FA's use of browser-in-the-browser phishing, showing how the kit layers bot checks, conditional loading, obfuscation and domain rotation to steal Microsoft credentials and sessions.

Why it matters: It matters because identity teams cannot treat MFA as a sufficient control when phishing kits can mimic login surfaces, evade automated scanning, and capture live sessions before users recognise the fraud.

Context

Browser-in-the-browser phishing is a phishing technique that makes a malicious login prompt look like a normal browser pop-up, even when it is hosting a fake Microsoft sign-in flow. In this case, Push Security says Sneaky2FA added BITB to an already mature Phishing-as-a-Service kit, which changes the defence problem from blocking a page to recognising a forged authentication experience.

The governance gap is bigger than email filtering. Once attackers can combine reverse-proxy phishing, bot checks, conditional loading, obfuscation and domain rotation, the control set must account for the live browser session, the authenticity of the login journey, and the likelihood that the user will be handed a believable but fraudulent identity prompt.

For identity teams, this is a phishing and session-theft issue, not just a URL-blocking issue. The starting position is unfortunately typical for modern enterprise phishing: attackers are iterating faster than controls that still depend on static indicators and pre-rendered content.

Key questions

Q: What breaks when phishing kits proxy the real login page instead of cloning it?

A: Static page checks stop being reliable because the target sees genuine content from the real site, not a brittle HTML copy. The failure is not just visual deception. It is that detection logic built around templates, fingerprints, and reputation can miss a live relayed session that behaves like a normal login.

Q: Why do phishing kits with reverse-proxy flows still bypass MFA?

A: Because the attacker is not trying to defeat MFA in theory. They are trying to steal the authenticated session after the user completes a legitimate-looking sign-in. When the session token is captured, MFA has already been satisfied, so the attacker can continue as the user unless session controls intervene.

Q: What signals indicate a phishing page is designed to evade analysis?

A: Signals include long redirect chains, trusted-host relays, human verification gates such as CAPTCHA or Turnstile, and page elements that change at runtime. When a phishing page only reveals itself after a user passes a challenge, automated scanners are less likely to capture the true malicious content.

Q: Should security teams prioritise browser-side phishing controls over email gateways?

A: They should treat them as complementary, but browser-side controls become critical when phishing kits load after bot checks or masquerade as in-browser authentication. Email gateways remain useful for blocking delivery, yet they cannot see every live-rendered or conditionally loaded phishing page once the user reaches it.

Technical breakdown

How browser-in-the-browser phishing hides the real origin

Browser-in-the-browser, or BITB, uses an embedded browser window that looks like a legitimate pop-up login form while actually rendering malicious content from a different origin. The visual cue that should help users judge trust, the browser chrome and URL bar, is simulated inside the page itself. In Sneaky2FA's case, the fake Microsoft sign-in is wrapped in a document-viewer lure, which lowers suspicion and keeps the user inside the phishing flow long enough for credential capture and session theft.

Practical implication: treat browser-rendered login prompts as a phishing surface and verify whether the authentication flow is externally hosted or only visually embedded.

Why bot checks and conditional loading defeat analysis

Bot protection, conditional loading, and anti-analysis logic change who can inspect the phish. The page first gates access with a challenge such as Cloudflare Turnstile, then checks for unwanted visitors, security vendor infrastructure, or analysis conditions before serving the real payload. That means automated scanners may see only a benign page, a redirect to harmless content, or a partial page state, while the victim sees the full phishing experience. This is why static reputation and basic scraping-based analysis fail against mature Phishing-as-a-Service kits.

Practical implication: validate phishing content in an instrumented live browser, not only through URL reputation, headless crawling, or email gateway inspection.

How reverse-proxy phishing turns credentials into active session theft

Reverse-proxy phishing does more than steal passwords. It relays the victim's authentication to the real identity provider, captures the resulting session artifact, and then lets the attacker reuse that authenticated state. In practical terms, the attacker does not need to win a password-only race if the session token or cookie can be harvested after a successful sign-in. That is why MFA can be bypassed in these campaigns: the attacker rides the legitimate authentication transaction rather than replacing it with a crude credential prompt.

Practical implication: add session theft resistance and token-bound controls to MFA strategy, because password verification alone does not stop a live relay attack.

Threat narrative

Attacker objective: The attacker wants Microsoft account takeover through stolen credentials and reusable session access that survives the initial login.

1. Entry begins with a lure on a benign-looking domain that forces a bot check before revealing the phishing page and embedded login form.
2. Credential theft occurs when the victim enters Microsoft credentials into the fake browser pop-up and the reverse proxy relays authentication to the real service.
3. Escalation happens when the attacker captures the active session and can reuse the authenticated state without needing the victim to sign in again.
4. Impact is account takeover, with the attacker gaining access through stolen credentials and live session artefacts while traditional web and email defences miss the deception.

Breaches seen in the wild

• CoPhish OAuth phishing via Copilot Studio: Datadog showed Copilot Studio agents on a Microsoft domain can front OAuth consent phishing and forward stolen tokens; no victims reported.
• Solana web3.js npm compromise 2024: A phished maintainer's npm access let attackers publish two @solana/web3.js versions that stole private keys from bots and apps.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Browser-in-the-browser phishing is a trust-presentation attack, not just a delivery problem: The user is not persuaded by a malicious link alone, but by a forged authentication context that looks local to the browser. That changes the governance question from blocking destinations to validating whether the login experience itself is authentic. For identity programmes, the point of failure is the trust decision made inside the session.

Phishing-as-a-Service has compressed the control gap between attacker innovation and defender adaptation: The article shows a kit economy where bot checks, conditional loading, obfuscation and domain rotation are now packaged together. That means defenders are no longer dealing with isolated tactics but with a repeatable operational model. The practical conclusion is that control design has to assume continuous attacker iteration, not static phish characteristics.

MFA bypass is now often a session problem, not a password problem: When attackers relay a legitimate sign-in and steal the resulting session, the control that fails is not the login prompt alone but the assumption that successful authentication proves the user is safe. Identity governance has to move beyond the first factor and inspect how sessions are minted, reused and protected in the browser.

Identity-based attack paths are outpacing perimeter-centric detection: Email gateways, web filters and signature-based tooling can all be blinded by conditional loading and browser-side rendering. Identity journey integrity: the assurance that the visible login path, origin and session creation are all genuine, is becoming a distinct control concern. Teams should treat that integrity as a control objective in its own right.

Browser-mediated authentication is now part of the attack surface: Once a phishing kit can mimic the browser's own pop-up and URL presentation, the interface between user, browser and identity provider becomes the place where trust is manipulated. That has implications for human identity programmes, NHI session reuse, and future agentic login workflows alike. Practitioners need to govern the authentication journey, not only the credential.

From our research library:

• The IBM/Ponemon 2025 Cost of a Data Breach Report found that phishing-initiated breaches cost an average of $4.8M each.

What this signals

Identity journey integrity: the browser, the visible login surface, and the issuing identity provider now need to be treated as one control plane. When an attacker can forge the browser context, the trust decision moves from the mailbox to the session itself.

Push-style detection needs live-page inspection because conditional loading and obfuscation are explicitly designed to hide malicious behaviour from crawlers and reputation systems. That shifts the defensive question from whether a URL is known bad to whether the rendered authentication journey is genuine.

For practitioners

• Harden phishing detection beyond URL reputation Inspect rendered login flows in a real browser so bot checks, conditional loading, and embedded pop-ups are visible before users hit them. Email and web filtering alone will miss pages that change state based on visitor type.
• Treat session theft as a first-class risk Assume a successful MFA challenge can still end in account takeover if the attacker can relay authentication and steal the active session. Review where your controls depend on password or second-factor success rather than session binding.
• Test browser-side deception paths Simulate phishing pages that load inside an embedded browser window and compare what users see with what automated scanners see. The goal is to find gaps where the visual login surface is trusted but the origin is not.
• Reduce dependence on static indicators Prioritise detections that use page behaviour, live rendering, and authentication transaction context instead of domain reputation or page fingerprints alone. Short-lived domains and obfuscated code make static signatures fragile.

Key takeaways

• Browser-in-the-browser phishing is effective because it attacks the trust users place in the login experience, not only the destination URL.
• The article shows a layered phishing kit that combines bot checks, conditional loading, obfuscation and domain rotation to reduce detection.
• Defending this pattern requires browser-side inspection, session-aware controls and less reliance on static reputation signals.

Key terms

• Browser-based phishing: Browser-based phishing is phishing that executes through the web browser rather than the inbox, often using redirects, malicious sites, consent prompts, or extensions. It matters because the browser is where identity, application access, and session state intersect.
• Phishing-as-a-service: A criminal service model that packages phishing infrastructure, templates, delivery tools, and sometimes evasion features for reuse by multiple attackers. It lowers the skill threshold for advanced campaigns and makes targeted identity abuse more repeatable across victims and sectors.
• Conditional loading: Conditional loading is a phishing evasion method where a page only reveals malicious content after checking the visitor’s environment, location, or other attributes. It helps attackers hide from crawlers, security tools, and analysts, extending the life of the campaign.
• Session Theft: Session theft is the reuse of an already authenticated access context, usually through stolen cookies, tokens, or browser artifacts. It is dangerous because the attacker may not need to know the password at all. For IAM and NHI governance, it means authentication success cannot be treated as proof of legitimate intent.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.