Thwarting Bluekit Phishing-as-a-Service Attacks on Microsoft Authentication

Bluekit, the latest Browser-in-the-Middle (BitM) phishing-as-a-service platform targeting Microsoft credentials, exposes a much older assumption that still underpins many enterprise identity strategies: if something looks suspicious, trained users will recognize it.

That assumption has always been flawed. Now it’s becoming operationally unsustainable.

Attackers are investing less effort into defeating authentication technologies and more effort into controlling the environments in which authentication takes place. At the same time, organizations are preparing for a future where both employees and AI agents will initiate privileged actions at machine scale. In both cases, identity systems built around subjective decisions become increasingly difficult to operate.

Bluekit is one example of that shift. Help desk vishing campaigns, account recovery fraud, and AI-assisted impersonation point in the same direction. They all succeed by exploiting places where enterprise security still relies on human interpretation to establish trust. That dependency deserves as much scrutiny as the authentication technology itself.

What Is Bluekit and How Does the Browser-in-the-Middle Attack Work?

Bluekit is a phishing-as-a-service platform that has evolved from conventional credential capture into a Browser-in-the-Middle architecture. Netcraft reported roughly 70 Bluekit hostnames in one week and found that the kit now uses rrweb, an open-source session replay library, to stream a legitimate login experience from an attacker-controlled browser to the victim.  

The attack begins before the Microsoft login page appears. Bluekit first qualifies the visitor with anti-analysis checks, including custom CAPTCHA pages, randomized HTML, browser fingerprinting, language settings, screen resolution, CPU and RAM checks, headless browser indicators, and anti-fingerprinting extension detection. These checks help the kit separate real victims from automated scanners and security researchers.  

Once the visitor passes those checks, Bluekit opens the legitimate Microsoft login page inside the attacker’s browser. rrweb serializes the live DOM and streams it to the victim through a WebSocket connection. The victim’s browser renders an interactive page rather than a static screenshot or fake replica. Assets such as images, fonts, and stylesheets are fetched through the attacker’s proxy infrastructure, while the victim’s keystrokes and mouse events are relayed back into the attacker-controlled browser.

From the user’s perspective, the experience looks like Microsoft. From the identity system’s perspective, authentication is occurring in the attacker’s browser.

How Attackers Use Bluekit to Capture Authentication Sessions

Traditional adversary-in-the-middle tooling, such as Evilginx-style reverse proxies, relays traffic between the victim and the legitimate service and then reuses stolen session cookies elsewhere. That reuse can create detection opportunities when the browser or device fingerprint changes.  

Bluekit avoids that handoff. The session is created in the attacker’s browser from the start. The victim supplies credentials and completes MFA through the streamed interface, but the authenticated browser session already belongs to the attacker. Netcraft notes that this model limits the usefulness of Device Bound Session Credentials because DBSC helps protect against stolen session reuse, while Bluekit creates and uses the session in the same attacker-controlled browser.  

That technical distinction is the reason the “MFA bypass” label can be misleading. The attacker has not necessarily defeated the MFA factor. The attacker has relocated the authentication ceremony into infrastructure they control.

Why Microsoft Continues to Be the Primary Target

Bluekit is the latest in a growing list of attacks built around Microsoft authentication. Over the past several years, groups such as Scattered Spider, Storm-1811, and others have consistently targeted Microsoft Entra ID, Microsoft 365, Windows Hello for Business deployments, and the surrounding identity workflows. They aren’t choosing Microsoft because the platform lacks strong security capabilities. They’re choosing Microsoft because it has become a foundation for enterprise tech stacks - and with that, many gaps persist.

Microsoft has made significant investments in phishing-resistant authentication through FIDO2, passkeys, Conditional Access, and Windows Hello for Business. Those capabilities are important, and organizations should continue adopting them. But large enterprises rarely operate in a “Microsoft-only” identity model. Passwords persist for legacy applications. Recovery workflows introduce temporary credentials. Help desks verify identities over the phone. Contractors, shared devices, mergers, acquisitions, and operational exceptions create alternative paths through the identity lifecycle.

Attackers understand that reality.

Bluekit yet again highlights the difference between deploying phishing-resistant authentication and maintaining phishing-resistant identity assurance across every workflow that establishes trust. That distinction is why many organizations continue investing beyond Microsoft E5. Authentication is only one layer of enterprise identity. Recovery, device trust, credential lifecycle management, privileged access, and operational workflows all contribute to whether the organization can consistently enforce FIDO2-level assurance in practice.

Phishing-resistant authentication is most effective when phishing-resistant identity extends beyond the initial login and into every place where users establish, recover, or prove their identity.

How FIDO2 Passkeys Eliminate Browser-in-the-Middle Attacks

Unlike passwords, one-time codes, or push approvals, FIDO2 passkeys don’t create a reusable credential that can be captured and replayed through a phishing workflow. The authenticator cryptographically verifies the origin requesting authentication before a credential is released. If the origin doesn’t match the legitimate relying party, authentication doesn’t complete.

Bluekit succeeds by convincing a user to complete a legitimate authentication ceremony inside infrastructure controlled by the attacker. A properly implemented FIDO2 passkey changes that interaction entirely. The authenticator verifies the legitimate origin before signing the authentication request, preventing credentials from being used in the wrong context. Instead of asking the user to determine whether the login experience is trustworthy, the authentication protocol performs that verification automatically.

This is the difference between authentication that asks users to recognize phishing and authentication that is designed to make phishing materially less effective in the first place.

What Bluekit Means for Enterprise Identity Roadmaps

Bluekit will eventually be replaced by another Browser-in-the-Middle toolkit and the architectural lesson will remain.

For years, organizations have invested in helping employees recognize suspicious emails, identify fraudulent login pages, answer help desk verification questions carefully, and make better security decisions. Those investments remain valuable, but they reflect an operating model where people are expected to compensate for uncertainty throughout the identity lifecycle.

That model is becoming increasingly difficult to sustain.

Attackers are automating deception. Browser-in-the-Middle platforms present legitimate authentication experiences instead of counterfeit ones. Help desk vishing campaigns target recovery processes rather than passwords. AI makes convincing impersonation faster, cheaper, and easier to scale. At the same time, enterprises are preparing for workforces that include AI agents capable of authenticating, requesting access, invoking privileged tools, and executing business processes alongside employees.

Both trends point toward the same conclusion: enterprise identity cannot continue depending on subjective interpretation as a primary security control.

The industry’s adoption of FIDO2 established an important precedent. Rather than asking users to determine whether a login experience was trustworthy, phishing-resistant authentication shifted that responsibility toward cryptographic verification, origin validation, and trusted devices. The next challenge is extending those same principles beyond authentication itself.

That evolution won’t happen because of Bluekit alone.

It will happen because the operating model of the enterprise is changing. Identity systems designed for a workforce composed entirely of people are being asked to support a workforce that increasingly includes autonomous software acting alongside them. Neither environment benefits from asking users—or machines—to infer whether something appears legitimate.

Bluekit is simply another reminder that the future of enterprise identity won’t be defined by adding more authentication prompts. It will be defined by how effectively organizations remove subjectivity from the places where trust is established.

Subscribe to our updates to receive expert insights and learn how HYPR's multi-factor verification and digital identity solutions can protect your business and customers.

Frequently Asked Questions

What is Bluekit?

Bluekit is a phishing-as-a-service platform that uses a Browser-in-the-Middle architecture to proxy legitimate Microsoft authentication sessions through attacker-controlled infrastructure.

Does Bluekit bypass MFA?

Bluekit allows attackers to gain authenticated access despite MFA being enabled, but it does so by manipulating the authentication context rather than defeating the authentication technology itself.

Why is FIDO2 more resistant to Browser-in-the-Middle attacks?

FIDO2 uses public key cryptography and origin binding to verify that authentication is taking place with the legitimate service. That phishing-resistant design significantly reduces the effectiveness of credential phishing compared to traditional MFA approaches.

Why should enterprises care if they already use Microsoft Entra ID?

Bluekit demonstrates that strong identity security depends on the entire identity architecture—not just the authentication platform. Organizations should evaluate recovery workflows, fallback methods, phishing-resistant standards, and identity assurance across the complete identity lifecycle.

What does Bluekit tell us about AI agents?

The same architectural assumptions exposed by Bluekit become even more challenging as organizations introduce AI agents. Identity systems must establish trust through cryptographic assurance and policy, not by relying on humans—or machines—to interpret whether an interaction appears legitimate.