Bluekit PhaaS Uses Browser-in-the-Middle Attacks to Steal Microsoft Logins

A sophisticated Phishing-as-a-Service (PhaaS) platform dubbed Bluekit has moved from theoretical development into active deployment, with researchers at Netcraft identifying approximately 70 live hostnames in the past week alone.

First documented by Varonis Threat Labs, which noted that the platform still appeared to be under development, Bluekit is now confirmed as fully operational, targeting Microsoft credentials through a novel Browser-in-the-Middle (BitM) technique that fundamentally reimagines how adversary-in-the-middle (AitM) phishing works.

Unlike traditional AitM tools such as Evilginx, which intercept proxied traffic between the victim and the legitimate site, Bluekit takes a more invasive approach.

Bluekit PhaaS Uses Browser-in-the-Middle Attacks

The platform loads the real Microsoft login page inside an attacker-controlled browser and streams what the victim sees and interacts with in real time.

Victims believe they’re logging in to Microsoft on their own machines. In reality, they’re authenticating directly into a session running inside the attacker’s infrastructure.

The mechanism behind this is rrweb, an open-source JavaScript library originally designed for session replay.

Browser-in-the-Middle Attack (Source: Netcraft)
Browser-in-the-Middle Attack (Source: Netcraft)

Bluekit repurposes it as a covert delivery channel: the attacker’s browser serializes the live DOM of the legitimate login page and streams it to the victim over a WebSocket connection.

The victim’s browser renders it natively not as a screenshot or video, making it visually indistinguishable from the real page.

Keystrokes, mouse movements, and form submissions are captured and relayed back to the attacker’s browser, which executes them on the legitimate site.

Bluekit operates in two distinct phases:

  • Phase 1 – Victim Qualification: Before any phishing content appears, every visitor undergoes a multi-layered bot-detection sweep. This includes CSS filter manipulation to defeat screenshot hash detection, a heavily obfuscated 1MB+ JavaScript file that rotates periodically, a custom CAPTCHA that impersonates target brands or services like Cloudflare, hardware fingerprinting, and WebRTC-based IP mismatch detection, which exploits a documented browser behavior to expose analysts and scanners routing traffic through a proxy.
  • Phase 2 – BitM Delivery: Visitors who pass all checks receive a live-streamed DOM from the attacker’s browser. Page assets not included in the stream are fetched via a proxy API endpoint on Bluekit’s infrastructure, ensuring no direct network requests flow from the victim’s machine to Microsoft’s servers.

Bluekit’s architecture offers a notable advantage that defenders should understand: session consistency.

With reverse-proxy tools like Evilginx, a stolen session is later loaded into a different browser environment, creating a fingerprint mismatch that detection systems can flag.

With Bluekit, the attacker’s browser both creates and uses the session from the start, eliminating that signal entirely.

Technologies like Device Bound Session Credentials (DBSC) offer no protection against BitM, unlike the partial protection they provide against traditional AitM.

The trade-off is resource cost. Bluekit requires a full or headless browser on the attacker’s infrastructure and exposure to the target site’s own bot-detection mechanisms, since the attacker’s browser must interact directly with Microsoft’s login environment.

Netcraft stated that Bluekit’s administration panel gives operators a real-time view of victim sessions, powered by the same RRWeb infrastructure used for delivery.

Demonstrations circulating on Telegram show live monitoring of victims as they navigate the phishing page and complete the login flow, enabling operators to intervene or extract credentials on demand.

Security teams should note that the BitM architecture introduces a subtle but measurable indicator: additional round-trip latency not typically present on legitimate login pages. Victims may notice marginally slower keyboard and mouse response.

Automated phishing analysis environments should also be hardened to prevent WebRTC from leaking analyst IP addresses during kit evaluation.

Organizations relying on Microsoft 365 environments should treat MFA bypass as a baseline assumption for modern PhaaS platforms, such as Bluekit and Evilginx, which bypass MFA entirely, and prioritize phishing-resistant authentication methods.

Observable SignalStageNotes
WebSocket connection sending encrypted/binary data on login pageBitM DeliveryCore rrweb DOM stream in transit to victim browser
rrweb library present outside known product analytics contextBitM DeliveryPrimary delivery mechanism; high-confidence indicator when found on login-themed pages
Proxy API endpoint handling image/font/CSS asset fetchingBitM DeliveryAssets not loaded directly from legitimate target site — abnormal asset origin
WebRTC IP mismatch detection on landing pageAnalyst DetectionAttempts to expose real visitor IP; flag any landing page invoking STUN server calls
Custom CAPTCHA not sourced from Google or CloudflareVictim QualificationMay spoof target brand styling; inconsistent CAPTCHA HTML on each load is a strong signal

Note: IP addresses and domains are intentionally defanged (e.g., [.]) to prevent accidental resolution or hyperlinking. Re-fang only within controlled threat intelligence platforms such as MISP, VirusTotal, or your SIEM.

Follow us on Google News , LinkedIn and X to Get More Instant UpdatesSet Cyberpress as a Preferred Source in Google.

Tamilselvan
Tamilselvanhttps://cyberpress.org/
Tamilselvan is an Investigative cybersecurity journalist dedicated to breaking stories on ransomware cartels, data breaches, and state-sponsored espionage.

Trending News

Related Stories