A popular phishing-as-a-service kit known as Sneaky2FA has added support for browser-in-the-browser (BitB) attacks, dramatically improving its ability to hijack corporate accounts. By convincingly imitating single sign-on (SSO) login windows, the service can steal not only usernames and passwords, but also live session tokens, effectively bypassing two‑factor authentication (2FA) and multi‑factor authentication (MFA).
Sneaky2FA is primarily used against Microsoft 365 tenants, where access to corporate email, SharePoint, OneDrive and Teams often provides a direct path to sensitive business data. The addition of BitB makes these attacks harder for users to spot and more difficult for automated security tools to detect.
What Is Sneaky2FA Phishing-as-a-Service?
Sneaky2FA belongs to the growing ecosystem of phishing‑as‑a‑service (PhaaS) platforms. These are subscription‑based toolkits that provide turnkey phishing pages, hosting, management consoles and support, allowing even low‑skill attackers to run large‑scale phishing campaigns. Similar PhaaS offerings have been repeatedly highlighted in industry reports as one of the reasons phishing remains a top initial access vector in breaches.
In the case of Sneaky2FA, the service offers ready‑made templates tailored to common corporate services such as Microsoft 365. Customers of the platform can quickly configure campaigns, track victims in real time and export stolen credentials and tokens for resale or direct account takeover.
How the Attacker-in-the-Middle Scheme Steals Session Tokens
The core of Sneaky2FA is an attacker‑in‑the‑middle (AitM) architecture. When a victim clicks a phishing link, they land on a site that transparently proxies their traffic to the legitimate service (for example, portal.office.com or login.microsoftonline.com). To the user, the page looks and behaves like the real login site.
As the victim enters their username, password and one‑time 2FA code, the AitM proxy forwards this data to Microsoft in real time. Microsoft then issues a valid session token (essentially a cryptographic “ticket” proving the user is authenticated). Sneaky2FA captures this token and can reuse it to access the account without ever needing to re-enter the password or 2FA code. This means that even correctly configured MFA does not prevent account takeover if the session itself is hijacked.
Browser-in-the-Browser (BitB) Attacks: From Concept to Weaponization
The browser‑in‑the‑browser concept was publicly detailed in 2022 by a researcher using the handle mr.d0x. The idea is to use HTML, CSS and JavaScript to render a completely fake browser window inside a web page that visually mimics native SSO pop‑ups from providers such as Google, Microsoft, Apple, Facebook or Steam.
Users are accustomed to clicking “Sign in with Microsoft” or “Continue with Google” and seeing a compact pop‑up window with a familiar login form and a trusted URL. In a BitB attack, this “window” is just part of the page. Attackers not only replicate the SSO layout but also draw a fake address bar, padlock icon and browser controls, giving the illusion that the user is interacting with a secure domain like login.microsoftonline.com.
Why BitB Support Makes Sneaky2FA Especially Dangerous
By integrating BitB, Sneaky2FA now combines a realistic fake SSO pop‑up with its AitM proxy. The phishing kit dynamically adapts the fake window to the victim’s operating system and browser, imitating, for example, Edge on Windows or Safari on macOS, including fonts, window chrome and alignment.
An attack typically unfolds as follows: the victim receives a phishing email, instant message or link from a compromised website, leading to what appears to be a Microsoft 365 portal. When they click “Sign in with Microsoft”, a BitB‑generated window appears. Everything entered into this window is immediately relayed via the Sneaky2FA infrastructure to the real Microsoft login page, where the attacker harvests valid credentials and fresh session tokens.
Obfuscation, Traffic Filtering and Evasion Techniques
Researchers note that Sneaky2FA uses heavy HTML and JavaScript obfuscation to evade analysis. Text on the phishing pages is interleaved with invisible tags, and many interface components are rendered as encoded images rather than plain HTML elements. This design is intended to frustrate static analysis engines and anti‑phishing scanners that rely on pattern matching or DOM inspection.
The kit also implements traffic splitting and cloaking. Requests that appear to originate from crawlers, security scanners or analysis sandboxes are redirected to benign content instead of the live phishing page. This makes it harder for security vendors to automatically discover and classify the malicious infrastructure, and complicates incident response when analysts do not initially see the same content as real victims.
Defending Against BitB Phishing and Phishing-as-a-Service
Technical controls: phishing-resistant authentication
Organizations relying on Microsoft 365 and other SaaS platforms should treat phishing‑resistant authentication as a priority. Hardware security keys and modern standards such as FIDO2 / WebAuthn bind authentication to the specific website origin and device, making stolen passwords and one‑time codes far less valuable to AitM kits like Sneaky2FA.
Additional protection can be achieved with Conditional Access policies: restricting logins by geography and device type, requiring step‑up authentication for risky sessions, and blocking legacy protocols that bypass modern controls. Security teams should continuously monitor for anomalous sign‑ins, impossible travel, unusual OAuth application consents and long‑lived session tokens, and be prepared to revoke sessions at scale during an incident.
User awareness and security operations
Because BitB windows are visually convincing, user awareness becomes a critical layer of defense. Regular phishing simulations, targeted training and post‑incident reviews help employees recognize red flags such as unexpected SSO prompts, mismatched business context (for example, a sudden need to re‑authenticate), or login requests following unusual email content.
From an operational standpoint, organizations should enforce least‑privilege access, maintain clear processes for rapidly disabling compromised accounts, and tightly control which third‑party OAuth applications can be granted access to Microsoft 365 data. Security monitoring should include dedicated detection rules for AitM behavior, such as multiple user sessions originating from unfamiliar infrastructure shortly after a phishing campaign.
The evolution of platforms like Sneaky2FA—now combining phishing‑as‑a‑service, attacker‑in‑the‑middle proxies and browser‑in‑the‑browser deception—illustrates how quickly adversaries are innovating to bypass traditional 2FA. To stay ahead, organizations need more than basic MFA: they must adopt phishing‑resistant authentication, invest in continuous monitoring and incident response, and systematically train employees to challenge unexpected login prompts. Strengthening these layers now significantly reduces the likelihood that the next wave of BitB‑enabled phishing campaigns will lead to successful compromise of corporate accounts.
