Analyzing the latest Sneaky2FA Browser-in-the-Browser phishing page

PhaaS kits make up the vast majority of phishing sites intercepted by Push and dominate the phishing landscape, with kits like Tycoon, NakedPages, Flowerstorm, Salty2FA, and various Evilginx variations proving very popular among attackers targeting Push customers.

PhaaS kits are incredibly important to cybercrime because they make sophisticated and continuously evolving capabilities available to the criminal marketplace, lowering the barrier to entry for criminals running advanced phishing campaigns. This is not unique to phishing: Ransomware-as-a-Service, Credential Stuffing-as-a-Service, and many more for-hire tools and services exist for criminals to use for a fee. 

This competitive environment has fuelled attacker innovation, resulting in an environment in which MFA-bypass is table stakes, phishing-resistant authentication is being circumvented through downgrade attacks, and detection evasion techniques are being used to circumvent security tools — from email scanners, to web-crawling security tools, to web proxies analyzing network traffic.

Recently, we’ve noticed an increase in detections relating to Sneaky2FA, which operates through a fully-featured bot on Telegram. Customers reportedly receive access to a licensed, obfuscated version of the source code and deploy it independently.

This makes Sneaky2FA something that can be reliably profiled and tracked due to these codebase similarities — which is what we’re actively doing at Push. 

Why is this relevant? Well, the latest Sneaky2FA phish we identified was pretty interesting. 

Sneaky2FA adds BITB to its phishing toolkit

We recently detected a Sneaky2FA server that is a bit different from the typical reverse-proxy Attacker-in-the-Middle site, featuring an embedded browser window that contained the actual phishing page. 

You can see how the page loaded below in the video below.

When the URL previewdoc[.]us is first accessed, a Cloudflare Turnstile check must be completed before the page loads. 

The page then redirects to a subdomain of previewdoc[.]us, which prompts the user to “Sign in with Microsoft” in order to view a document, styled to look like Adobe Acrobat Reader. 

Upon clicking ‘Sign in with Microsoft” a reverse-proxy phishing page resembling a Microsoft login form is loaded in an embedded browser, with a custom background image designed to resemble a document library. 

Interestingly, the pop-up window adjusts to the visitor’s OS and browser — you can see some different examples below.

Completing authentication will result in the user’s Microsoft credentials and active session being stolen by the attacker, facilitating account takeover. 

You can see the sequence of pages loaded and Push detection events in the timeline below.

Why Browser-in-the-Browser?

BITB was first coined as a technique in 2022 by mr.d0x, but standard AITM phishing pages are far more frequently encountered in the wild, particularly when it comes to enterprise business targets.

BITB is principally designed to mask suspicious phishing URLs by simulating a pretty normal function of in-browser authentication — a pop-up login form. BITB phishing pages replicate the design of a pop-up window with an iframe pointing to a malicious server. 

The pop-up browser window shows a legitimate Microsoft login URL — this is in fact a fake URL that is designed to fool the user. 

This BITB example shares many of the advantages of typical reverse-proxy based phishing pages, as well as the detection evasion techniques that are commonly used by attackers (and baked into PhaaS kits off-the-shelf). This includes:

Bot protection to defeat web scraping tools

Attackers are using common bot protection technologies like CAPTCHA and Cloudflare Turnstile to prevent security bots from accessing their web pages to be able to analyse them (and therefore block pages from being automatically flagged). This requires anyone visiting the page to pass a bot check/challenge before the page can be loaded, meaning the full page cannot be analysed by automated tools. 

Stop unwanted visitors with conditional loading

Conditional loading techniques are used to prevent unwanted visitors from accessing the phishing page — reducing the chance that it is detected and flagged and extending the longevity of the phish. This often includes known security vendor IPs, VPN/proxy services, but is often used to target specific organizations (or even specific users within an organization). 

In this case, where the correct parameters are not supplied or the phishing site detects an unwanted variable, it will redirect to a benign wikibooks page. 

Sneaky2FA has also been commonly observed using anti-analysis techniques to detect or disable browser developer tools to block attempts to analyse the page for malicious content. 

Page and code obfuscation

The HTML and JavaScript of Sneaky2FA pages are heavily obfuscated to evade static detection and pattern-matching, such as breaking up UI text with invisible tags, embedding background and interface elements as encoded images instead of text, and other changes that are invisible to the user, but make it hard for scanning tools to fingerprint the page. 

Domain rotation and URL masking

In addition to masking the phishing site URL presented to the user via the BITB window, Sneaky2FA has been seen using stealthy hosting and domain tactics. Each campaign uses a fresh, long, randomized URL (typically a 150-character path) on a benign-looking domain (often an old or compromised site). These domains are usually short-lived: many are taken down after just a few days or weeks. Analysts have observed that Sneaky2FA domains often lie dormant or serve harmless content until right before an attack, then quickly vanish after use. This “burn-and-replace” approach makes traditional defenses (which rely on domain reputation or pattern-matching) much weaker.

Are attackers moving to BITB? 

There is evidence that Sneaky2FAs shift to BITB might not be an isolated change. Raccoon0365 is another PhaaS service that has been seen utilizing BITB functionality after announcing a “BITB mini-panel” would be added as part of a service revamp. 

Conclusion

Attackers are continuously innovating their phishing techniques, particularly in the context of an increasingly professionalized PhaaS ecosystem. With identity-based attacks continuing to be the leading cause of breaches, attackers are incentivized to refine and enhance their phishing infrastructure. 

The addition of BITB, with the frequent iteration and improvement of detection evasion techniques, means that traditional security controls such as email gateways, web filters, and signature-based defenses will continue to be reliably bypassed. 

How Push can help

Push researchers are continuously analysing and developing new detections based on the latest phishing kits and TTPs which enables us to stay two steps ahead of attackers.

Despite the various detection evasion techniques, and the use of BITB methods, Push still detected this toolkit running on the page, enabling any attack to be detected and blocked before the user could be phished. Because we can inspect the live page, we detect malicious content loaded in the browser in real time. 

To learn more about Push, check out our latest product overview or book some time with one of our team for a live demo.