# BlueKit PhaaS: Browser-in-the-Middle via rrweb — When the Login Page You See Runs on the Attacker's Machine

## Executive Summary

**BlueKit** is a Phishing-as-a-Service (PhaaS) platform [first documented by Varonis in April 2026](https://www.bleepingcomputer.com/news/security/new-bluekit-phishing-service-includes-an-ai-assistant-40-templates/), and by late June 2026 [Netcraft confirmed it operating at real-world scale](https://www.netcraft.com/blog/bluekit-phishing-as-a-service-threat), with roughly 70 new hostnames appearing in a single week. What makes BlueKit notable isn't the template count but a technical shift: from reverse-proxy **Adversary-in-the-Middle (AitM)** to **Browser-in-the-Middle (BitM)** built on the legitimate session-replay library **rrweb**.

The core business risk: with BitM, the login page the victim interacts with actually **runs inside a browser the attacker controls**. The victim types their username, password, and even the **MFA code** into a session the attacker already owns — once authentication completes, a valid session token sits on the attacker's machine. The most important takeaway: **Device Bound Session Credentials (DBSC)** — one of the leading hopes for stopping session theft — **does not protect against BitM**, even though it helps against AitM. Priority action: accelerate rollout of **phishing-resistant MFA (FIDO2 / passkeys)**, one of the few defensive layers that still holds against both AitM and BitM.

## What BlueKit is — an all-in-one PhaaS

BlueKit is packaged as a turnkey service, removing almost all technical barriers to standing up a phishing campaign. Per [Varonis' analysis](https://www.bleepingcomputer.com/news/security/new-bluekit-phishing-service-includes-an-ai-assistant-40-templates/), the platform offers:

*   **Over 40 templates** impersonating popular services: Outlook, Hotmail, Gmail, Yahoo, ProtonMail, iCloud, Apple ID, GitHub, Twitter/X, Zoho, Ledger, Zara, and more.
    
*   Integrated **domain purchase and registration** inside the platform, phishing-page setup, and campaign management from a single panel.
    
*   **Exfiltration via Telegram private channels** — harvested credentials and sessions are pushed straight to the operator's private channel.
    
*   **Real-time victim session monitoring** on roughly a **5-second** refresh: cookies, localStorage, live session state, and post-login activity.
    
*   Granular **anti-analysis** filters: blocking VPN/proxy, headless user-agents, and fingerprint-based filtering to weed out analysis environments. The service model means an operator running a BlueKit campaign doesn't need to understand how BitM works — they pick a template, attach a domain, and receive credentials over Telegram.
    

## AI Assistant — cybercrime starts embedding LLMs

A newer component in BlueKit is an **AI Assistant panel** for drafting phishing email content, with a choice of several models: [Llama, GPT-4.1, Claude, Gemini, and DeepSeek](https://www.bleepingcomputer.com/news/security/new-bluekit-phishing-service-includes-an-ai-assistant-40-templates/). It's worth calibrating: Varonis assesses this feature as **early-stage** — output is largely placeholder content and only sketches a campaign skeleton rather than producing a complete, ready-to-run phishing flow.

Rough as it is, its presence reflects a clear trend: LLMs are being wired directly into cybercrime tooling as a bundled feature, no longer something an operator has to arrange externally. For defenders, this signals that the language quality of phishing emails will become more uniform, harder to filter on the "clumsy phrasing" tells of the past.

## The BitM mechanism via rrweb — the core

The real technical differentiator is how BlueKit delivers the login page. Rather than reverse-proxying traffic like Evilginx, BlueKit [runs the genuine login page inside an attacker-controlled browser](https://www.netcraft.com/blog/bluekit-phishing-as-a-service-threat) and replays that interface to the victim using **rrweb** — an open-source session-replay library legitimately used to record and reconstruct user sessions for debugging/analytics.

**rrweb is a legitimate tool** — a page embedding rrweb is not, by itself, evidence of malice. The danger is that the technique has been repurposed to relay a real login session.

The process runs in two phases:

### Phase 1 — Anti-analysis & victim qualification

![]( align="center")

Before delivering the BitM payload, BlueKit runs a screening layer to filter out researcher environments and automated systems:

*   **Randomized CSS filter manipulation** on the page, skewing the pixel-hash to evade phishing-page image-matching systems.
    
*   **Large obfuscated JavaScript (>1MB), continuously rotated** to defeat static analysis and signatures.
    
*   **Custom CAPTCHA** impersonating the spoofed brand or Cloudflare, with HTML randomized on each load to resist structural fingerprinting.
    

![](https://cdn.hashnode.com/uploads/covers/676511773cdd3c06f7b226ee/e286d520-d677-4aab-8a46-8292b8394402.png align="center")

*   **Browser/device fingerprinting**: RAM, CPU core count, language, resolution, headless detection, and anti-fingerprinting extensions.
    
*   **WebRTC IP mismatch detection** — comparing the public IP against the WebRTC-leaked IP to catch analysts hiding behind a proxy/VPN. Only "qualified" visits (resembling a real victim) are advanced to phase two.
    

![](https://cdn.hashnode.com/uploads/covers/676511773cdd3c06f7b226ee/ef862ec7-c1df-4281-93ad-1a2c6107708c.png align="center")

### Phase 2 — BitM delivery

*   Attacker infrastructure opens the **legitimate login page** in a browser it controls.
    
*   **rrweb serializes the entire DOM** of that page and streams it over a **WebSocket** to the victim.
    
*   The victim's browser **renders it natively** (not a screenshot or video) — so the interface looks identical to the real page and interaction is smooth.
    
*   Assets (images, scripts, styles) are fetched through a **proxy API** rather than loaded directly from the genuine provider.
    
*   When the victim enters their details and MFA code, the data is **relayed back** to the attacker's browser; **authentication completes on the attacker's machine**, leaving behind a valid session token.
    
*   The operator watches the whole thing through a real-time admin panel and continues observing post-login activity. Because the real user completes the login flow on the attacker's own infrastructure, the attacker obtains a fully authenticated session — **bypassing MFA** without cracking the second factor.
    

## How BitM differs from Evilginx (reverse-proxy AitM)

| Criterion | AitM / reverse-proxy (Evilginx) | BitM (BlueKit + rrweb) |
| --- | --- | --- |
| Login-page execution context | Runs on the **victim's** machine, traffic through an intermediary proxy | Runs in the **attacker's** browser, interface replayed to the victim |
| How the session is stolen | Captures cookies/tokens as they relay between victim and service | Session completes on the attacker's machine → token already there |
| Service-side fingerprint | Risk of **mismatch** (proxy IP/device differs from victim) → detection signal | More consistent: the real session happens in a single attacker browser |
| DBSC (Device Bound Session Credentials) | **Can** mitigate (binds token to device) | **Provides no protection** — session is minted on the attacker's device |
| Infrastructure cost | Lighter (just proxying traffic) | Heavier (must run a real browser + stream the DOM) |

The key point for defenders: many anti-AitM mechanisms rely on detecting **inconsistency** between the proxy session and the victim. BitM blurs that very signal, because the real login session occurs in a coherent attacker browser — and [DBSC, expected to block session theft, doesn't apply to this model](https://www.netcraft.com/blog/bluekit-phishing-as-a-service-threat).

## Assessment

BlueKit exemplifies two converging trends. First, **PhaaS lowers the technical bar** so far that an attacker who doesn't understand BitM can still deploy the technique at scale — Netcraft's observation of roughly 70 new hostnames in a week points to very rapid infrastructure churn. Second, **BitM neutralizes traditional MFA** (OTP, push, SMS) in a way that even next-generation session-theft protections like DBSC can't cover.

For enterprise environments in Vietnam, the direct consequence is that organizations on Microsoft 365 / Google Workspace can no longer treat "MFA is enabled" as sufficient. The defensive line that genuinely holds against BitM is **phishing-resistant MFA based on FIDO2 / passkeys**, where authentication is cryptographically bound to the real origin — making the attacker's replayed page unable to complete the challenge. Beyond that, high-value domestic brands — banks, e-wallets, e-commerce platforms — can readily be added to a PhaaS template set like BlueKit's, so monitoring for brand-impersonating domain registrations should be a standing process, not a post-incident reaction.

## Observable signals

The three reference sources **do not publish hard hashes/IPs** — by the nature of PhaaS, infrastructure churns constantly. Instead, these are **investigative signals** that help identify a BlueKit-style BitM page, drawn from [Netcraft](https://www.netcraft.com/blog/bluekit-phishing-as-a-service-threat):

```plaintext
- WebSocket carrying binary/encrypted data on a login page (rrweb DOM-stream channel)
- A proxy-API endpoint used to load assets (images/scripts/styles) instead of direct provider loads
- rrweb references appearing outside a legitimate analytics/session-replay context
- Non-native custom CAPTCHA impersonating a brand or Cloudflare, HTML changing on each load
- Randomized CSS filter manipulation (to defeat pixel-hash matching)
- Large obfuscated JavaScript (>1MB), continuously rotated content
- Client-side WebRTC IP mismatch detection running on the landing page
- Abnormal latency during login-page interaction — a red flag for end-users
```

Note: rrweb is a legitimate project; its presence is **not an IOC in itself**. These signals are meaningful in combination, not in isolation.

## Recommendations

*   **Prioritize phishing-resistant MFA (FIDO2 / passkeys)** for privileged accounts and critical apps — one of the few layers that still holds against both AitM and BitM.
    
*   **Don't rely on DBSC to stop BitM**: DBSC mitigates AitM but doesn't apply to a session minted on the attacker's machine.
    
*   **Monitor brand-impersonating domain registrations** (your own and partners') as a standing process; track newly appearing hostnames in bulk.
    
*   **Train users** to recognize abnormal latency and unusual custom CAPTCHAs on login pages — report rather than proceed.
    

* * *

## References

*   Netcraft — [*Bluekit Phishing-as-a-Service: Browser-in-the-Middle (BitM) Analysis*](https://www.netcraft.com/blog/bluekit-phishing-as-a-service-threat)
    
*   BleepingComputer — [*Bluekit phishing kit adopts browser-in-the-middle for login theft*](https://www.bleepingcomputer.com/news/security/bluekit-phishing-kit-adopts-browser-in-the-middle-for-login-theft/)
    
*   BleepingComputer — [*New Bluekit phishing service includes an AI assistant, 40+ templates*](https://www.bleepingcomputer.com/news/security/new-bluekit-phishing-service-includes-an-ai-assistant-40-templates/)