When a browser window asks you to approve a login and it looks exactly like the real thing, how do you know you are not approving your own theft? That is the dilemma now stalking defenders: phishing kits that pretend to be a browser are being sold to criminals who do not need coding skill to break into accounts protected by two‑factor authentication.
Security researchers at Push Security have observed that a Phishing‑as‑a‑Service (PhaaS) kit known as Sneaky 2FA has adopted Browser‑in‑the‑Browser (BitB) functionality — a deception that renders familiar push prompts and pop‑up confirmations indistinguishable from legitimate browser dialogs. The Hacker News reported Push Security’s findings, highlighting how BitB makes it far easier for low‑skill attackers to carry out large numbers of real‑time relay attacks against 2FA-protected accounts.
BitB works by embedding a fake browser chrome inside a page so that a malicious site can show a pop‑up that looks like a native browser authentication dialog or a service’s push notification. Victims see what appears to be an authentic approval prompt and, thinking the action is expected, click to approve. Behind the scenes the attacker relays that approval to the real service, completing account takeover in real time.
The rise of Sneaky 2FA and related kits is not an isolated trend. Comparable offerings — given names such as Salty2FA and Whisper 2FA in industry reporting — have demonstrated the same pattern: attackers commoditize sophisticated relay and session‑hijack techniques and rent them on PhaaS marketplaces, dramatically lowering the bar for large‑scale abuse .
To understand the threat, consider the attack chain in simple steps:
- An attacker lures a user to a convincingly faked login page.
- The victim enters credentials and receives a push notification or a 2FA prompt.
- The fake BitB dialog on the malicious page prompts the user to “approve” or enter a code — the user complies.
- The attacker relays that approval or code to the real site and gains access, often within seconds.
Why this matters: organizations and users have long relied on two‑factor authentication to raise the cost of account compromise. But these kits attack the human link in synchronous 2FA flows and exploit the trust users place in familiar browser chrome. Where session handling and authentication are not cryptographically bound to a specific device or attested origin, a proxied or relayed approval looks legitimate to the service.
From a technologist’s perspective, the takeaway is familiar but urgent: move beyond shared secrets and human‑mediated approvals when possible. Phishing‑resistant methods such as FIDO2/WebAuthn, hardware tokens, and cryptographic attestation bind authentication to a device and include origin checks that simple relays and BitB pop‑ups cannot mimic. Additional mitigations include:
- Strengthening session and device binding so a successful second factor must also match a device fingerprint or cryptographic attestation;
- Detecting and blocking suspicious real‑time proxy behavior and abnormal token submission patterns;
- Requiring step‑up authentication on high‑risk actions rather than reusing a single synchronous approval;
- Improving user interface signals and user education so that approval prompts that arrive unexpectedly are treated with suspicion.
Policymakers and regulators, meanwhile, face a layered problem. Mandates that require multifactor authentication are valuable, but if they do not distinguish between easily spoofed second factors and phishing‑resistant authentication, they may create a false sense of security. Guidance and procurement standards that favor cryptographic MFA, encourage secure default session policies, and require stronger attestation for high‑assurance access would reduce the attack surface that PhaaS operators exploit.
For everyday users, the practical rules are the same ones security practitioners have long recommended, but with greater emphasis: do not approve unexpected push requests; if you receive a confirmation you did not initiate, treat it as a possible compromise and change passwords and revoke active sessions. Organizations should make it easier for users to report unexpected prompts and should automate account recovery controls that assume an approval could have been relayed.
Adversaries have clear incentives: PhaaS converts sophisticated exploitation into a recurring revenue stream, while BitB increases conversion rates by reducing the cognitive friction that would otherwise tip off victims. The result is scalable and efficient harm — more attacks, by more actors, against a broader set of targets.
There are tradeoffs. Deploying FIDO2 or hardware tokens at scale can be expensive and affect usability; behavioral and device‑fingerprinting solutions raise privacy and inclusivity questions. But the alternative is to accept that the second factor is merely another checkbox that attackers will learn to mimic. The balance of cost, usability, and security must shift toward methods that cannot be trivially proxied.
Ultimately, this is a story about the industrialization of deception. As push notifications and browser dialogs become weapons in an adversary’s toolkit, organizations must treat authentication as an architecture, not a single control. Will defenders respond by hardening the entire flow — cryptographically binding proofs to devices and origins — or will we allow convenience to keep us bound to fragile approvals that look too much like the real thing?
Source: https://thehackernews.com/2025/11/sneaky-2fa-phishing-kit-adds-bitb-pop.html
