Bluekit PhaaS Uses Browser-in-the-Middle to Bypass MFA

The Bluekit phishing-as-a-service platform has integrated browser-in-the-middle capabilities that render traditional multi-factor authentication useless, with nearly 70 new hostnames identified in the past week alone. Netcraft researchers documented the evolution, warning that the platform's combination of AI-assisted phishing generation and real-time session hijacking represents a significant escalation in credential theft operations.

TL;DR

• What happened: Bluekit PhaaS added browser-in-the-middle attack capabilities
• Who's affected: Microsoft 365, Gmail, GitHub, and 40+ other service users
• MFA status: SMS codes, authenticator apps, and push approvals provide no protection
• Action required: Deploy hardware security keys; implement conditional access policies

How Browser-in-the-Middle Works

Unlike traditional phishing that captures credentials and replays them later, browser-in-the-middle attacks operate in real time. Bluekit uses the open-source JavaScript library rrweb to serialize the legitimate login page's DOM and stream it over a WebSocket connection to the victim. The victim sees an authentic Microsoft (or other target) login page because it is the real page—just rendered through the attacker's infrastructure.

When victims enter credentials and complete MFA challenges, authentication completes in the attacker's browser. The attacker receives a valid session token with unlimited access to the victim's account. From the target service's perspective, this looks like a legitimate login.

Traditional MFA—SMS codes, authenticator apps, push approvals—provides zero protection against this architecture. The victim completes the MFA challenge themselves, directly authenticating the attacker's session.

AI-Powered Phishing Generation

First documented by Varonis in April, Bluekit distinguishes itself with an integrated AI assistant supporting Llama, GPT-4.1, Claude, Gemini, and DeepSeek for generating phishing emails. The platform provides over 40 templates targeting Microsoft Outlook, Gmail, GitHub, Ledger hardware wallets, and other services.

Operators access a real-time monitoring system with 5-second update intervals, allowing them to track victims during login sessions and observe post-compromise activity as it happens.

Sophisticated Evasion Architecture

Bluekit's detection evasion goes well beyond typical phishing kits:

• Randomized CSS filters defeat screenshot-based detection systems
• Obfuscated JavaScript bundles exceeding 1MB rotate frequently
• Custom CAPTCHAs impersonate Cloudflare or target brands
• Browser fingerprinting checks RAM, CPU cores, screen resolution, and headless browser indicators
• WebRTC IP detection identifies users connecting through VPNs or proxies

The platform randomizes HTML on every page load, making signature-based detection ineffective. Security tools analyzing the phishing page see different content than victims do.

Targeting Microsoft at Scale

The 70 new hostnames identified over the past week primarily target Microsoft 365 credentials. This focus makes sense—compromised Microsoft accounts provide access to email, documents, Teams conversations, and often single sign-on to other enterprise applications.

Organizations that have invested in phishing-resistant MFA like hardware security keys remain protected because the authentication occurs on the victim's device rather than passing through attacker infrastructure. FIDO2 keys validate the origin of authentication requests, detecting the mismatch between the legitimate Microsoft domain and the phishing infrastructure.

This attack pattern mirrors what we've seen with callback phishing campaigns that abuse trust in legitimate communication channels—attackers increasingly focus on session hijacking because credential-only theft faces effective countermeasures.

Detection and Defense

Organizations should implement several layers of defense against browser-in-the-middle attacks:

1. Deploy FIDO2 security keys - Hardware keys with origin binding defeat session hijacking by validating the authentication request comes from the legitimate service
2. Enable conditional access - Require authentication from managed devices, trusted locations, or both
3. Monitor session anomalies - Alert on logins where the session token originates from a different IP or geography than the authentication attempt
4. Implement impossible travel detection - Flag accounts authenticating from geographically distant locations in short timeframes
5. Disable legacy authentication - Block protocols that don't support modern MFA

For users unfamiliar with advanced phishing techniques, our guide on phishing email examples covers common patterns to recognize, though browser-in-the-middle attacks can defeat even cautious users since the login page is genuine.

Why This Matters

Phishing-as-a-service platforms democratize sophisticated attack capabilities. Operators don't need to understand browser exploitation, DOM manipulation, or evasion techniques—they pay for access and receive a turnkey solution. The AI integration further lowers barriers by generating convincing lure content without requiring social engineering expertise.

The browser-in-the-middle approach specifically targets the assumption that MFA provides strong protection. Organizations that deployed authenticator apps or SMS verification believing they had addressed credential theft now face a technique that treats those controls as obstacles to route around rather than barriers to break.

Microsoft and other identity providers are working on solutions like token binding and continuous access evaluation that could detect session hijacking. Until those protections deploy universally, hardware security keys remain the only reliable defense against real-time credential theft operations like Bluekit.