Notifications
Clear all
Topic starter
11/06/2026 11:04 pm
TL;DR: Sneaky2FA has added Browser-in-the-Browser phishing to an already professionalised PhaaS kit, combining reverse-proxy credential theft with bot checks, conditional loading, obfuscation, and domain rotation to evade detection, according to Push Security. The shift shows why identity-based attack paths now defeat many perimeter controls before users ever reach a login form.
NHIMG editorial — based on content published by Push Security: Sneaky2FA adds Browser-in-the-Browser phishing functionality
Questions worth separating out
Q: How should security teams defend against browser-in-the-browser phishing?
A: Focus on the full login journey, not just the URL.
Q: Why do phishing kits with reverse-proxy flows still bypass MFA?
A: Because the attacker is not trying to defeat MFA in theory.
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.
Practitioner guidance
- 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.
What's in the full article
Push Security's full analysis covers the operational detail this post intentionally leaves for the source:
- The exact page flow used by Sneaky2FA, including the Turnstile gate, redirect chain, and embedded Microsoft login sequence.
- The visual indicators Push observed across Windows, Edge, macOS, and Safari that can help analysts recognise BITB variants.
- The obfuscation and conditional-loading methods used to slow down automated analysis and prolong campaign lifetime.
- Push’s detection workflow for live browser inspection and malicious content loaded in real time.
👉 Read Push Security’s analysis of Sneaky2FA browser-in-the-browser phishing →
Browser-in-the-browser phishing: are your controls keeping up?
Explore further
12/06/2026 7:35 am
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Browser-in-the-browser phishing is making MFA bypass easier
