Browser-in-the-middle phishing turns login trust against defenders

At a glance

What this is: NHI Mgmt Group's analysis, drawing on Netcraft's blog post: Bluekit takes phishing-as-a-service beyond reverse proxy theft by streaming a legitimate login page inside an attacker-controlled browser and evading analysis with layered anti-detection.

Why it matters: This matters because identity teams cannot rely on browser fingerprint mismatch or proxy interception alone once authentication happens inside the attacker’s runtime, not the victim’s.

By the numbers:

• Netcraft detected approximately 70 hostnames in the last week tied to Bluekit deployments.

Context

Browser-in-the-middle phishing moves the trust boundary from the network path into the browser runtime. Instead of stealing a session after the fact, the attacker makes the victim authenticate inside infrastructure the attacker controls, which breaks assumptions built into many anti-phishing and session-theft detections.

That shift matters for identity, IAM and fraud teams because the usual signals, such as proxy use, token replay, and post-login fingerprint mismatch, become weaker when the login session starts life on attacker-owned infrastructure. The pattern is more aggressive than legacy reverse-proxy phishing and more operationally mature than a one-off kit test.

Key questions

Q: What are the signs that a phishing campaign is using an attacker-in-the-middle kit to steal session access?

A: Common signs include a convincing but unofficial login page, domain variations that mimic a real service, and behavior designed to keep security tools from analyzing the page, such as requiring a specific referral path. If the page works only through an ad click or redirects oddly when opened directly, that is a strong indicator the site is built to evade inspection.

Q: Why does browser ownership matter in phishing attacks?

A: Browser ownership matters because phishing can rely on the victim’s trusted browser session, stored credentials, cookies, and local autofill rather than only a fake page. Attackers use browser-in-the-middle or session hijack tactics to capture tokens or bypass MFA. Defences include phishing-resistant MFA, session binding, and transport-layer checks for unusual certificate or proxy behaviour.

Q: What is the difference between reverse web proxy phishing and Browser-in-the-Middle attacks?

A: Reverse web proxy phishing sits between the victim and the real login page, forwarding traffic while stealing the session and related credentials. Browser-in-the-Middle goes further by tricking the victim into remotely controlling the attacker’s browser, which can expose additional secrets and tokens. The first is easier to scale, while the second is harder for the site to detect.

Q: What signs indicate a phishing kit is using DOM streaming?

A: A phishing kit using DOM streaming often shows page content being assembled live in the browser, with scripts that update the document without full reloads. Common signs include frequent asynchronous fetches, hidden form fields, obfuscated JavaScript, and WebSocket connections used to relay typed data or page fragments to the attacker in real time.

Technical breakdown

How browser-in-the-middle phishing changes the trust model

Browser-in-the-middle phishing does not merely relay credentials. It places the legitimate login page inside an attacker-controlled browser and streams the rendered DOM to the victim, so the user interacts with a real page layout while authenticating into the attacker’s session. That distinction matters because the browser, not just the network path, becomes the point of compromise. Defenders looking only for traffic interception miss the fact that the attacker now owns the execution context that completes authentication.

Practical implication: Treat browser runtime trust as part of your login assurance model, not just the transport layer.

Why DOM streaming is harder to spot than remote desktop fraud

DOM streaming sends page structure and interaction events instead of pixels. That makes the attack more efficient and visually convincing than remote desktop style relay, while also avoiding many artefacts that analysts use to detect synthetic browser delivery. Because the page renders natively in the victim’s browser, there is no obvious screenshot or video feed to flag. The remaining detection surface shifts toward latency, unusual WebSocket behaviour, and inconsistent asset-loading patterns.

Practical implication: Hunt for browser sessions that stream page state rather than load content normally.

What layered anti-analysis adds to phishing-as-a-service

Bluekit combines obfuscation, custom CAPTCHA, WebRTC IP mismatch checks, browser fingerprinting, and randomized HTML to separate real victims from scanners. The point is not one evasive trick but a sequence of gates that makes automated analysis expensive and noisy. This is a familiar pattern in mature phishing operations: add enough friction that defenders cannot safely observe the kit without exposing their analysis environment. It also means a single control failure is rarely enough to expose the whole campaign. See the Phishing Guide.

Practical implication: Assume phishing kits will test your analysis environment before they reveal their delivery logic.

Threat narrative

Attacker objective: The attacker aims to obtain a live authenticated session that can be used without needing to replay stolen credentials through a separate browser environment.

1. Entry occurs when a victim reaches a Bluekit-hosted landing page that first runs anti-analysis checks rather than showing phishing content.
2. Credential access happens when the victim logs into the legitimate service inside the attacker-controlled browser, so credentials and session state are created in the attacker’s runtime.
3. Impact follows when the attacker retains the authenticated session from the start, reducing the fingerprint mismatch signals that often expose reverse-proxy theft.

Breaches seen in the wild

• CoPhish OAuth phishing via Copilot Studio: Datadog showed Copilot Studio agents on a Microsoft domain can front OAuth consent phishing and forward stolen tokens; no victims reported.
• EmeraldWhale Git config credential theft: Tokens in exposed .git/config files let EMERALDWHALE clone private repositories and steal more than 15,000 cloud credentials.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Browser ownership is now the decisive trust variable in phishing. Bluekit shows that session theft is no longer only a matter of intercepting traffic; it can also be a matter of relocating the login event into attacker infrastructure. That shifts the control problem from network inspection to runtime trust, browser integrity, and stronger session binding. Practitioners should treat the browser as part of the identity perimeter, not a passive endpoint.

Anti-analysis has become a first-class capability in phishing-as-a-service. The mix of obfuscation, fingerprinting, custom CAPTCHA and WebRTC checks shows that modern phishing kits are built to resist both automated scanning and human review. That raises the cost of timely detection and means investigators need safer sandboxes, diversified telemetry, and more careful isolation of analyst environments. The practical conclusion is that detection engineering must account for the kit’s own analyst-detection logic.

Device binding helps, but it is not a complete answer to BitM. Bluekit highlights the limits of controls that assume the victim’s browser remains the execution point throughout authentication. Device-bound session mechanisms can reduce replay abuse, yet they do not stop an attacker who owns the browser where the login occurs. The governance lesson is to separate anti-replay from anti-relay and not treat them as the same control problem.

Phishing kits are converging with software delivery techniques. Reusing rrweb for malicious DOM streaming illustrates a broader trend: threat actors increasingly borrow legitimate developer tooling to gain scale and blend in. That creates a provenance problem as much as a phishing problem, because defenders cannot treat a familiar open-source component as suspicious in isolation. The right response is contextual detection around how the component behaves, not just whether it is present.

Login assurance now depends on observable trust transitions, not just MFA success. A successful second factor no longer proves that the user authenticated in a trustworthy environment. The control gap is the assumption that completed authentication equals reliable session ownership, when BitM can invalidate that assumption entirely. Practitioners should move policy and monitoring toward the moment of session creation, where the real trust decision occurs.

From our research library:

• The IBM/Ponemon 2025 Cost of a Data Breach Report found that phishing-initiated breaches cost an average of $4.8M each.

What this signals

Session ownership is becoming a runtime problem. Identity programmes need to assume that successful authentication no longer proves the user controlled the browser that executed it. Monitoring should therefore shift toward browser behaviour, session creation context, and anomalous delivery patterns rather than relying on proxy interception alone.

Browser-in-the-middle phishing widens the gap between credential theft and detection. The more the kit can mimic a normal interactive login, the less useful simple replay logic becomes for defenders. That pushes practitioners toward layered runtime controls, stronger device trust signals, and detection that starts before the credential exchange completes.

For practitioners

• Instrument browser-side session telemetry Capture WebSocket activity, DOM streaming behaviour, and asset-loading patterns around login pages so unusual browser-mediated delivery stands out from normal authentication flows.
• Harden analysis environments against IP leakage Separate analyst browsers, proxies, and VPN paths so WebRTC and fingerprint checks do not reveal a real investigation source during kit evaluation.
• Prioritise session-binding controls over replay-only defences Evaluate whether your identity stack can distinguish a login that occurs in the user’s browser from one created inside an attacker-controlled browser with the same credentials.
• Add phishing detections for browser runtime anomalies Alert on custom CAPTCHA flows, randomized HTML, and DOM streaming on pages that should behave like standard identity provider sessions.
• Review authentication assumptions for device-bound sessions Use the login flow to test where the trust decision is actually made and whether attacker-owned browser environments can still complete the session without triggering a strong challenge.

Key takeaways

• Bluekit shows that phishing can move the point of compromise from the network path into the browser runtime, which weakens detection methods built around traffic interception alone.
• The campaign’s anti-analysis layers make automated inspection harder, so defenders need runtime visibility into login sessions, not just post-login token misuse.
• Practitioners should test whether their authentication controls can distinguish a trustworthy browser session from one created and owned by an attacker.

Related NHI Mgmt Group resources: Phishing Guide · Top 10 Phishing Techniques · Social Engineering Guide · Phishing-as-a-Service Platforms Guide

Key terms

• Phishing-as-a-service: A criminal service model that packages phishing infrastructure, templates, delivery tools, and sometimes evasion features for reuse by multiple attackers. It lowers the skill threshold for advanced campaigns and makes targeted identity abuse more repeatable across victims and sectors.
• DOM Streaming: DOM streaming is a web technique where page content is delivered and updated incrementally through the browser DOM. It uses client-side scripting and asynchronous network calls, sometimes including WebSocket connections, so content can change without a full page reload. Attackers can use it to stream phishing pages, form fields, or stolen input in real time.
• Adversary-in-the-Middle (AiTM): An attack pattern where the adversary sits between the user and the service to capture or replay authentication data and session state. The victim may still log in successfully, which is why the compromise often appears legitimate until privileged actions begin. AiTM is especially dangerous for admin workflows that trust issued sessions too much.
• WebSockets: WebSockets are a persistent communication channel that supports real-time, two-way data exchange between a client and a server. They are commonly used when systems need immediate update delivery instead of periodic checking. That makes them useful for synchronization scenarios where freshness matters.

Deepen your knowledge

NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course. Explore the course if your programme needs a stronger model for how identity trust breaks down at runtime.