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

At a glance

What this is: This analysis shows how Sneaky2FA’s Browser-in-the-Browser phishing adds another layer of disguise to phishing-as-a-service operations while still stealing Microsoft credentials and active sessions.

Why it matters: It matters because IAM and security teams cannot rely on email gateways, web filters, or signature-based detection alone when phishing kits are engineered to mimic legitimate browser login flows.

By the numbers:

• The latest Sneaky2FA phish used a 150-character path on a benign-looking domain.

👉 Read Push Security’s analysis of Sneaky2FA browser-in-the-browser phishing

Context

Browser-in-the-Browser, or BITB, is a phishing technique that makes a fake login prompt look like a normal in-browser authentication pop-up. In this case, Sneaky2FA used the pattern to hide a Microsoft credential-harvest flow inside a visually convincing window, which is a direct challenge to identity assurance in web sign-in journeys.

The broader governance problem is that modern phishing kits are no longer simple static pages. They now combine bot protection, conditional loading, obfuscation, and URL masking to stay alive long enough to steal credentials and sessions, which means identity teams need to think beyond mailbox controls and into browser-visible trust signals. For background on breach patterns tied to identity exposure, see the 52 NHI Breaches Analysis.

Key questions

Q: How should security teams defend against browser-in-the-browser phishing?

A: Focus on the full login journey, not just the URL. Detect iframe-based prompts, unusual browser chrome, conditional loading, and session theft patterns. Combine phishing-resistant authentication, browser telemetry, and rapid session revocation so that even a convincing fake sign-in surface cannot easily produce a reusable authenticated session.

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 do security teams get wrong about modern phishing detection?

A: They often over-rely on static indicators such as reputation, known malicious domains, or page signatures. Modern kits use obfuscation, short-lived infrastructure, bot checks, and conditional loading to change fast enough that static controls lag behind. Detection needs to account for behaviour, not just indicators.

Q: How can organisations reduce account takeover from browser-based phishing?

A: Limit the value of any captured session by enforcing short-lived, policy-bound access, step-up checks for sensitive actions, and rapid invalidation of suspicious tokens. That way, even if a user is phished, the attacker gains less durable access and has fewer paths to privilege escalation.

Technical breakdown

How Browser-in-the-Browser hides a fake Microsoft login

BITB creates a browser window inside the page that imitates a legitimate authentication pop-up. The attacker controls the embedded frame, but the user sees a familiar browser chrome, a plausible URL display, and a brand-aligned sign-in screen. That visual layer is the core trick: it reduces suspicion without needing to defeat the user’s password directly. In this campaign, the pop-up was styled to look like Microsoft sign-in and linked to a document-viewing lure. The result is a credential capture workflow that rides on normal user expectations rather than malware delivery.

Practical implication: treat browser-rendered login appearance as a trust signal that needs validation, not proof of legitimacy.

Why bot protection and conditional loading extend phish lifetime

Sneaky2FA used Turnstile checks, selective redirects, and environment checks to block crawlers, security vendors, and unwanted visitors. Conditional loading means the phishing page only reveals itself when the attacker wants it to, which breaks reputation-based discovery and slows takedown workflows. Obfuscation then makes the HTML and JavaScript harder to fingerprint by hiding text, encoding interface elements as images, and splitting content into fragments. Together, these controls do not make the phish safer for the attacker, but they make it harder for defenders to analyse quickly.

Practical implication: inspect live browser content and environment-triggered behaviour, not just static URLs and page source.

Why reverse-proxy phishing still beats many MFA assumptions

Reverse-proxy phishing captures credentials and session artefacts in real time by standing between the user and the real identity provider. That matters because many organisations still assume MFA ends the risk once a code or approval is entered. In reality, attackers want the active session, not just the password, because that bypasses subsequent prompts and can enable account takeover. BITB adds a disguise layer on top of that existing AITM pattern, making the handoff look cleaner and more legitimate to the victim while preserving the attacker’s session theft objective.

Practical implication: pair phishing-resistant authentication with session-aware detection and conditional access that can respond to token theft.

Threat narrative

Attacker objective: The attacker wants Microsoft account takeover by stealing both the user’s credentials and the active authenticated session.

1. Entry occurs when the victim is lured to a benign-looking domain and forced through a bot check before the phishing page is revealed.
2. Escalation occurs when the fake Microsoft login collects credentials and active session material through a reverse-proxy form hidden in a browser-in-the-browser pop-up.
3. Impact occurs when the attacker uses the stolen session to take over the account and bypass normal MFA expectations.

Breaches seen in the wild

• MongoBleed breach — MongoBleed exposed secrets across 87K MongoDB servers.
• IOS app secrets leakage report — iOS apps leaking hardcoded secrets and credentials endangering user privacy.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

BITB is not a new phishing category, but a visual upgrade to session theft. Sneaky2FA is still operating inside the same identity abuse model: deceive the user, capture credentials, and hijack the authenticated session. The difference is that the browser-in-the-browser layer makes the lure feel more native to the user’s workflow, which raises the bar for visual inspection and automated detonation alike. Practitioners should treat this as a refinement of account takeover tradecraft, not as a separate problem.

Identity-based attacks now succeed by controlling the last mile of trust, not by breaking authentication outright. The controls being bypassed here are email filtering, web reputation, static page scanning, and simple MFA expectations. That matters because the phishing kit is engineering around the point where users decide whether a login surface is real. Security teams need to recognise that the trust decision is now happening inside the browser, not at the gateway.

Browser-visible authenticity has become a governance problem for IAM teams. If users cannot reliably distinguish a legitimate session prompt from a fake embedded prompt, then the organisation has a human-verification gap at the point of authentication. That gap is wider in Microsoft-centric environments where the attacker can mirror familiar sign-in flows and document-sharing lures. The practical conclusion is that authentication assurance must now include session binding, browser telemetry, and policy responses for suspicious login surfaces.

PhaaS professionalisation is compressing the time between innovation and mass abuse. Push notes that kits like Tycoon, NakedPages, Flowerstorm, and Salty2FA already dominate the phishing landscape, which means one kit’s technique quickly becomes another’s baseline. The market signal is clear: defences built on stale signatures or domain lists will continue to lag attacker iteration. Practitioners should assume that today’s edge-case phish becomes tomorrow’s commodity kit feature.

From our research:

• Lack of credential rotation is cited as the top cause of NHI-related attacks by 45% of organisations, followed by inadequate monitoring and logging (37%) and over-privileged accounts (37%), according to The State of Non-Human Identity Security.
• 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, with 38% reporting no or low visibility and 47% reporting only partial visibility.
• For a broader breach pattern view, read 52 NHI Breaches Analysis for recurring identity abuse patterns and control failures.

What this signals

Browser-in-the-browser phishing shows that identity assurance now depends on what the user sees after the browser renders, not just what the gateway inspects before delivery. That shifts defensive priority toward session-level controls, browser telemetry, and prompt validation across Microsoft and other federated sign-in flows. The signal for practitioners is to treat the browser as an authentication control surface, not a neutral container.

With 85% of organisations lacking full visibility into third-party vendors connected via OAuth apps, per The State of Non-Human Identity Security, the same visibility deficit is now showing up in user-facing trust decisions. Attackers exploit gaps where identity, browser, and access policy do not converge cleanly. Teams that cannot see the full delegated-access picture will struggle to spot when a stolen session becomes a durable foothold.

PhaaS is turning phishing innovation into an operational supply chain, and that has direct implications for IAM resilience. The more attackers package bot checks, obfuscation, and reverse-proxy logic as reusable features, the less value static controls deliver over time. Identity programmes need continuous validation of sign-in surfaces and strong session cancellation paths.

For practitioners

• Harden phishing-resistant sign-in paths Move high-risk users and privileged workflows toward phishing-resistant methods that reduce reliance on browser-embedded login prompts and session replay opportunities.
• Add browser-layer inspection to detection pipelines Look for iframe-based login prompts, mismatched window chrome, and authentication surfaces that render inside embedded browser windows.
• Monitor for conditional-loading and bot-check behaviour Flag phishing pages that require CAPTCHA-style checks, selective redirects, or environment-specific rendering before showing the full lure.
• Treat session theft as a first-class IAM risk Review controls that can invalidate suspicious active sessions quickly, especially where attackers may capture tokens after successful password entry.

Key takeaways

• Browser-in-the-browser phishing makes session theft look like normal authentication, which weakens user judgement at the exact point IAM depends on it.
• Push’s observation of PhaaS dominance and fast-moving evasions shows that phishing kits are industrialising account takeover, not just improving lures.
• Teams should prioritise browser-level detection, phishing-resistant authentication, and rapid session invalidation because those controls change the attacker’s payoff, not just the alert volume.

Key terms

• Browser-in-the-Browser: A phishing technique that renders a fake authentication window inside a webpage so it looks like a normal browser pop-up. The goal is to trick users into entering credentials or completing sign-in in a context that appears trustworthy while the attacker controls the underlying content.
• PhaaS: Phishing-as-a-service is a criminal operating model in which phishing infrastructure, templates, and evasion features are rented or licensed to attackers. It lowers the skill barrier for account takeover campaigns and accelerates the spread of techniques such as reverse-proxy phishing and browser deception.
• Session theft: Session theft is the capture of an authenticated session token or cookie that lets an attacker act as the user without repeating the full login process. In identity security, this is often more dangerous than password theft because it bypasses the user-facing parts of MFA.
• 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.

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.

This post draws on content published by Push Security: Sneaky2FA adds Browser-in-the-Browser phishing functionality. Read the original.