Bluekit shows why phishing-resistant identity assurance matters

At a glance

What this is: This is HYPR’s analysis of Bluekit, a browser-in-the-middle phishing platform that preserves a legitimate Microsoft login experience while shifting authentication into attacker-controlled infrastructure.

Why it matters: It matters because IAM and identity assurance programmes can no longer treat user recognition, help desk judgment, or fallback workflows as sufficient controls when phishing-resistant verification is available.

By the numbers:

• Netcraft reported roughly 70 Bluekit hostnames in one week.

Context

Bluekit is a browser-in-the-middle phishing-as-a-service platform that turns the login ceremony itself into the attacker’s control point. The relevant identity problem is not whether users can spot a fake page, but whether the organisation still depends on human interpretation to establish trust in the first place.

HYPR frames the issue as an identity assurance gap across the full lifecycle, not just a login problem. Recovery paths, help desk validation, legacy password flows, and alternative access routes all become part of the attack surface when the authentication experience can be streamed from attacker infrastructure.

That makes this article useful beyond a single phishing kit. It shows how a modern identity programme fails when it assumes users, support teams, or even AI agents can reliably judge legitimacy at runtime.

Key questions

Q: What breaks when browser-in-the-middle phishing is used against Microsoft sign-in flows?

A: The failure is not simply credential capture. Browser-in-the-middle attacks preserve a legitimate login experience while moving the authentication ceremony into attacker-controlled infrastructure, which means the session is created in the wrong place from the start. That breaks the assumption that visual legitimacy and successful MFA together prove trustworthy access.

Q: Why do adversary-in-the-middle attacks still work when MFA is enabled?

A: Because the attacker does not need to defeat MFA directly. They relay the real login flow in real time, capture the valid session cookie after authentication succeeds, and reuse that cookie elsewhere. The control failure is at the session layer, where a trusted token outlives the original browser context.

Q: How should organisations reduce dependence on help desk identity verification?

A: Treat help desk identity checks as a supporting control, not the main trust decision. Recovery, reset, and re-verification workflows should be limited, strongly logged, and aligned to phishing-resistant methods so that attackers cannot move the weakest part of the process into support channels.

Q: How do passkeys change the risk model compared with passwords and one-time codes?

A: Passkeys shift trust from the user’s judgment to the cryptographic origin check performed by the authenticator. That reduces the value of deceptive login pages because the authentication step fails when the relying party is not the legitimate one, instead of relying on a person to spot the deception.

Technical breakdown

How browser-in-the-middle phishing preserves a real login session

Browser-in-the-middle attacks do not simply clone a page. They proxy or stream a genuine authentication flow through attacker-controlled infrastructure, so the victim interacts with a real service while the attacker owns the browser context. In Bluekit’s case, rrweb serialises the live DOM and streams it through a WebSocket, while inputs are relayed back to the attacker’s browser. That means the login ceremony is authentic at the service layer but compromised at the execution layer. The user is not asked to enter a fake site, which is why visual inspection and awareness training lose value quickly.

Practical implication: Treat the browser context itself as part of the trust boundary, not just the credential prompt.

Why Device Bound Session Credentials do not solve session creation inside attacker infrastructure

Device Bound Session Credentials are designed to reduce reuse of stolen sessions by binding a session to a device. Bluekit sidesteps that model by creating the session inside the attacker’s browser from the outset, then using the victim only to complete the authentication ceremony. The core technical distinction is that the attacker is not replaying a captured cookie later. Instead, the attacker originates the authenticated session and keeps it within their own controlled environment. That is why anti-replay controls are necessary but not sufficient against browser-in-the-middle abuse.

Practical implication: Evaluate whether your controls stop stolen-session reuse or also stop attacker-originated session creation.

Why FIDO2 and passkeys change the authentication model

FIDO2 passkeys use public key cryptography and origin binding, so the authenticator verifies the relying party before releasing a credential. That shifts trust from the user’s judgment to the protocol itself. If the origin is wrong, the authentication step fails rather than relying on the user to notice a suspicious page. This is a different control model from passwords, one-time codes, or push approvals, all of which can still be satisfied inside a deceptive session. Bluekit is effective because it exploits the gap between convincing presentation and weak context validation.

Practical implication: Prioritise phishing-resistant authentication where the protocol, not the user, validates the origin.

Threat narrative

Attacker objective: The attacker’s objective is to obtain a usable authenticated Microsoft session without relying on reusable stolen cookies or obvious fake-login indicators.

1. Entry begins when Bluekit qualifies visitors with anti-analysis checks such as CAPTCHA, fingerprinting, browser checks, and environment inspection so that real victims proceed while scanners are screened out.
2. Credential access occurs when the victim completes Microsoft authentication, including MFA, inside the streamed browser session that is already running in attacker-controlled infrastructure.
3. Impact follows because the authenticated session belongs to the attacker’s browser context, allowing access without the stolen-cookie handoff pattern used by older adversary-in-the-middle tooling.

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.
• Mailchimp breach 2022: Attackers socially engineered Mailchimp staff, used a support tool to export 102 customer lists and exposed customer API keys for phishing.

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-in-the-middle attacks expose an identity assurance gap, not just a phishing problem. The security failure is the continued assumption that users can tell when a login experience is trustworthy. That assumption breaks when the page is genuine, the session is attacker-owned, and the human is only providing inputs to an already hostile browser. The practitioner conclusion is that trust has to move out of user judgment and into protocol-level verification.

Phishing-resistant authentication and phishing-resistant identity assurance are not the same control. FIDO2 and passkeys strengthen the login event, but many enterprises still surround that event with password recovery, help desk verification, fallback methods, and legacy exceptions. Bluekit shows that the weaker surrounding workflows can erase the value of a strong primary factor. The implication is that assurance must be governed across the whole lifecycle, not only at sign-in.

Human interpretation is becoming an unreliable control surface for both employees and AI agents. The article is explicit that future enterprises will include machine actors making privileged requests at scale, which makes subjective trust even harder to sustain. Identity architecture that depends on someone deciding whether an interaction looks legitimate will not scale cleanly across human, NHI, and autonomous behaviours. The conclusion is that cryptographic and policy-based assurance becomes the common control language across actor types.

Subjective trust is now an identity debt that accumulates across recovery, support, and exception handling. Help desk vishing, account recovery fraud, and browser-in-the-middle phishing are all variations of the same governance weakness: trust decisions are still spread across people and workflows that were never designed to resist deception at machine speed. That debt will grow as enterprises add more delegated and automated access paths. Practitioners should treat subjective verification as a structural liability, not a training problem.

Identity programmes need a named concept for the real issue: assurance drift. Assurance drift is the gap between deploying a strong authentication factor and maintaining that level of trust across the entire set of workflows that establish, recover, and prove identity. Bluekit is a clean example because the login itself may be strong, yet surrounding workflows reintroduce ambiguity. The practical conclusion is to measure assurance at the workflow level, not just the factor level.

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

Assurance drift: enterprises often deploy stronger login factors while leaving recovery and support workflows exposed. That gap is where browser-in-the-middle phishing keeps its value, because the attacker does not need to beat the strongest factor if the surrounding trust model still permits weaker entry points.

As organisations add AI agents and more delegated access paths, subjective identity checks become harder to sustain at scale. The architectural direction is clear: trust decisions need to move from human interpretation to cryptographic verification and policy enforcement across the full identity lifecycle.

For practitioners

• Strengthen phishing-resistant authentication coverage Expand FIDO2 and passkey adoption to the highest-risk Microsoft authentication paths, especially privileged users and high-value workflows where browser-in-the-middle attacks are most likely to succeed.
• Remove human judgment from trust decisions Reduce dependence on users, help desks, and support staff as the primary trust gate for authentication, recovery, and account re-verification workflows.
• Constrain recovery and fallback paths Review password reset, account recovery, and temporary credential processes so they do not become weaker alternate routes around phishing-resistant sign-in.
• Test browser-in-the-middle resistance Validate whether your current controls detect sessions that are created inside attacker-controlled browsers rather than merely detecting later cookie replay.
• Prepare identity governance for machine actors Map which workflows still rely on subjective legitimacy checks, then redesign them for environments where employees and AI agents both initiate privileged actions at scale.

Key takeaways

• Bluekit is a good example of why login security and identity assurance are not identical problems. A strong factor at sign-in does not eliminate weak recovery, support, and exception workflows.
• The article shows that browser-in-the-middle attacks can preserve a legitimate Microsoft experience while moving the session into attacker-controlled infrastructure. That changes the defensive problem from detecting fake pages to validating the trust context itself.
• Organisations should prioritise phishing-resistant methods and reduce dependence on human judgment in trust decisions. The control gap is not just at authentication, but across the full lifecycle where identity is established and recovered.

Key terms

• Browser-in-the-middle attack: A browser-in-the-middle attack places an attacker-controlled browser or proxy between the user and the legitimate service while preserving the appearance of a normal session. The victim interacts with a real login flow, but the authentication context and resulting session are controlled by the attacker.
• Phishing-Resistant Identity Verification: Phishing-resistant identity verification is a method that does not rely on shared secrets, one-time passcodes, or knowledge questions that attackers can easily intercept or guess. It uses stronger evidence, often including device-bound or biometric checks, to confirm the person requesting help is the legitimate user. This reduces social engineering risk.
• Assurance Drift: Assurance drift is the gap that forms when governance evidence stops matching actual system behaviour. In AI environments, it appears after model updates, new data flows, or integration changes that are not reflected in reviews or documentation. The result is a false sense of control maturity.
• Identity lifecycle automation: The orchestration of joiner, mover, and leaver events so access is granted, adjusted, and removed without manual gaps. For mixed identity estates, it matters because revocation and review must keep pace with identities that do not follow human employment timelines.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an identity programme, it is worth exploring.