2 min read

Sneaky2FA PhaaS kit adds Browser-in-the-Browser technique to steal Microsoft credentials

Sneaky2FA PhaaS kit adds Browser-in-the-Browser technique to steal Microsoft credentials

A recent analysis shows that Sneaky2FA now includes Browser-in-the-Browser functionality, expanding its ability to phish Microsoft 365 users.

 

What happened

According to BleepingComputer, Sneaky2FA, a phishing-as-a-service kit known for attacker-in-the-middle methods, has incorporated a Browser-in-the-Browser (BitB) pop-up designed to mimic legitimate Microsoft login windows. The new feature enables attackers to steal both credentials and active session tokens, even when victims have two-factor authentication enabled.

 

Going deeper

Sneaky2FA is one of several PhaaS platforms that target Microsoft 365 accounts, alongside Tycoon2FA and Mamba2FA. Its previous capabilities relied on SVG-based phishing pages and reverse-proxy authentication flows, forwarding real session tokens to attackers in real time.

The new BitB component displays a pop-up tailored to the victim’s operating system and browser. Because the interface imitates the look and behaviour of a legitimate OAuth window, victims are more likely to trust it. The template functions as an iframe designed to resemble an independent browser instance, complete with a fake URL bar showing an authentic Microsoft domain.

During recent attacks, victims were directed to a phishing link on previewdoc[.]com, passed through a Cloudflare Turnstile challenge and then prompted to “Sign in with Microsoft.” When clicked, the BitB window appeared and loaded Sneaky2FA’s reverse-proxy Microsoft login page inside it. Conditional loading further hid malicious behaviour from bots and security researchers.

Push Security also found that Sneaky2FA pages are heavily obfuscated, using encoded images instead of text, invisible tags within UI elements, and other techniques directed at avoiding static detection.

 

What was said

Researchers at Push Security described the BitB integration as a cosmetic layer that enhances existing attacker-in-the-middle workflows, increasing the realism of the phishing chain without altering its underlying mechanics. They noted that the kit’s obfuscation choices make it difficult for email security systems and scanning tools to reliably detect the phishing pages.

Experts advised users to test suspicious pop-up windows by attempting to drag them outside the browser frame or by checking whether the pop-up appears in the taskbar, two indicators that can distinguish genuine browser windows from iframe-based BitB fakes.

 

The big picture

Browser-in-the-Browser techniques continue to appear across phishing-as-a-service ecosystems. Academic analyses in the Journal of Engineering Research and Sciences show that the method exploits users’ trust in familiar sign-in windows by mimicking the visual and interactive behaviour of legitimate OAuth or SSO prompts. Recent research from the same study reports that attackers are now pairing BitB interfaces with reverse-proxy tooling capable of harvesting both credentials and active session tokens. Such combinations enable adversaries to circumvent multi-factor authentication and maintain ongoing access without requiring repeated logins.

 

FAQs

What makes Browser-in-the-Browser attacks convincing?

They recreate the look and behaviour of real OAuth pop-ups, including a fake URL bar, correct dimensions, and familiar branding, which can make the window appear legitimate even to experienced users.

 

Why do PhaaS platforms add BitB capabilities?

BitB techniques increase the success rate of phishing campaigns by masking reverse-proxy flows behind a trusted interface, which helps attackers steal authentication tokens with less user suspicion.

 

How can users check whether a login pop-up is real?

A genuine pop-up can be dragged outside the main browser window and appears as a separate instance in the taskbar. BitB pop-ups, which are iframes, cannot be moved independently.

 

Why are session tokens valuable to attackers?

Session tokens allow an attacker to access an account without needing the password again, and they often bypass multi-factor authentication checks because the session is already validated.

 

How can organizations defend against these phishing methods?

They can deploy token-binding protections, monitor for unusual authentication patterns, use phishing-resistant authentication where possible, and train staff to recognise deceptive pop-ups that mimic single sign-on workflows.