Bluekit shows why phishing-resistant identity assurance matters

At a glance

What this is: Bluekit is a Browser-in-the-Middle phishing platform that hijacks Microsoft authentication by moving the login ceremony into attacker-controlled infrastructure.

Why it matters: It matters because IAM teams have to harden not just login, but recovery, fallback, and privileged workflows across human and machine identities.

By the numbers:

• Netcraft reported roughly 70 Bluekit hostnames in one week.
• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes.
• Only 5.7% of organisations have full visibility into their service accounts.
• 91.6% of secrets remain valid five days after the targeted organisation is notified.

👉 Read HYPR’s analysis of Bluekit Browser-in-the-Middle phishing on Microsoft authentication

Context

Bluekit is a Browser-in-the-Middle phishing-as-a-service platform that changes the problem from fake login pages to controlled authentication environments. The primary issue is not whether a user can spot a suspicious page, but whether the identity system still depends on human interpretation to establish trust.

That distinction matters for IAM, because enterprise assurance now spans Microsoft login flows, recovery steps, privileged workflows, and the growing number of AI-driven actors that will initiate access at machine speed. When trust is inferred by people instead of verified by protocol, phishing-resistant authentication is only partially effective.

Key questions

Q: What fails when phishing-resistant authentication is undermined by fallback workflows?

A: The main failure is not the primary factor but the alternate path. If recovery, help desk verification, or legacy exceptions can be completed with weaker assurance, attackers will target those routes instead. Strong authentication only reduces risk when every path that establishes or restores identity uses comparable controls.

Q: Why do Browser-in-the-Middle attacks still succeed against modern IAM programmes?

A: They succeed because many programmes still rely on people to judge whether a login ceremony is legitimate. When the attacker streams the real service through hostile infrastructure, the user sees an authentic experience while the session itself is controlled elsewhere. The programme is weak wherever trust is inferred rather than verified.

Q: What do security teams get wrong about passkeys and FIDO2?

A: They sometimes treat passkeys as a narrow login upgrade instead of an assurance model. Passkeys reduce phishing risk substantially, but only if the surrounding lifecycle, recovery, and privileged workflows do not recreate weaker forms of trust. The control is strongest when it is consistent across the full identity journey.

Q: Who is accountable when phishing-resistant login still leads to account compromise?

A: Accountability usually sits with the identity programme owner, not the authentication method alone. If fallback routes, support processes, or exception handling reintroduce weaker proof, the control design is incomplete. Frameworks such as NIST SP 800-63 and Zero Trust expect assurance to be consistent across the full access journey.

Technical breakdown

Browser-in-the-Middle phishing against Microsoft authentication

Bluekit uses a Browser-in-the-Middle model, which means the victim is not typing into a fake static page but interacting with a live Microsoft login session streamed from attacker-controlled infrastructure. The attacker runs the actual browser session, proxies the assets, and relays user input back into that session. That design makes the experience look legitimate while keeping the session ownership on the attacker side.

Practical implication: treat the browser session origin as part of the trust boundary, not just the login screen.

Why session replay and MFA do not solve the underlying problem

Traditional adversary-in-the-middle kits often steal a session cookie and reuse it elsewhere, which can trigger device or fingerprint mismatches. Bluekit avoids that by creating the session inside the attacker’s browser from the start. MFA may still be completed, but it is completed in the wrong environment, so the factor authenticates the user to the attacker’s session rather than protecting the enterprise session itself.

Practical implication: reduce reliance on replayable or recoverable authentication paths that can be completed outside the legitimate relying party.

Why passkeys and origin binding change the control model

FIDO2 passkeys and other phishing-resistant methods shift verification from user judgment to cryptographic origin binding. The authenticator checks the relying party before releasing a credential, which removes the attacker’s ability to transplant the ceremony into a controlled browser. That is a materially different control model from passwords, push approvals, or one-time codes, all of which can be abused in a streamed session.

Practical implication: prioritise phishing-resistant authentication for high-risk users and workflows, then test fallback paths with the same scrutiny.

Threat narrative

Attacker objective: The attacker wants an authenticated Microsoft session that can be used for account takeover without needing to defeat the MFA factor directly.

1. Entry occurs through phishing-as-a-service infrastructure that first filters victims with anti-analysis checks and then presents a streamed Microsoft login session.
2. Credential capture and MFA completion happen inside the attacker-controlled browser, so the authenticated session is born in the wrong environment instead of being stolen later.
3. Impact is unauthorised access to Microsoft-backed enterprise identity workflows, with the attacker able to operate as the user inside downstream systems.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• ASP.NET machine keys RCE attack — 3,000+ exposed ASP.NET machine keys enabled remote code execution.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Subjective trust is now a broken identity control. Bluekit shows that training users to spot suspicious pages is no longer a reliable primary defence when attackers can stream a legitimate login experience from their own browser. The real failure is not a weak password alone, but an identity model that still expects people to decide whether the ceremony is legitimate. Practitioners should treat human interpretation as a secondary signal, not a trust anchor.

Phishing-resistant authentication is necessary, but it is not the whole assurance model. Microsoft Entra ID, FIDO2, and passkeys reduce the effectiveness of streamed phishing, yet the enterprise still has recovery, fallback, help desk, and exception paths that can reintroduce lower assurance. Bluekit is a reminder that identity assurance is only as strong as the weakest alternate path. Teams need to evaluate the full workflow, not just the primary login method.

Browser-in-the-Middle attacks expose an identity assurance gap, not merely a phishing gap. The named concept here is trust relocation: the attacker moves the authentication ceremony into infrastructure they control while preserving the user’s perception of legitimacy. That matters because many governance models still assume trust is established at the relying party, when in practice the attacker can relocate the event before the system sees it. Practitioners should redesign around verifiable context, not assumed user recognition.

AI agents make the same architectural flaw harder to ignore. As machine actors begin requesting access, invoking tools, and initiating privileged actions, the industry cannot keep depending on subjective legitimacy checks in the identity layer. The pattern Bluekit exploits in humans becomes more brittle when the actor is non-human and the decision loop is faster than manual review. Teams should align identity design with cryptographic proof and policy, not perception.

Recovery and exception handling remain the hidden attack surface. Bluekit succeeds because enterprises still need alternate routes when primary authentication fails, and those routes often rely on weaker verification. That creates a governance asymmetry: the strongest login method can be undermined by the weakest fallback. Practitioners should measure assurance across the entire lifecycle, from enrolment to recovery to privileged action.

From our research:

• 91.6% of secrets remain valid five days after the targeted organisation is notified, according to Ultimate Guide to NHIs.
• From our research: 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, according to Ultimate Guide to NHIs.
• As identity assurance becomes more automated, teams should use 52 NHI Breaches Analysis to map where credential exposure and lifecycle failures turn into account compromise.

What this signals

Trust relocation: Bluekit is a reminder that the control problem is moving from authentication strength to ceremony integrity. If the identity event can be relocated into hostile infrastructure, then policy, device trust, and origin validation have to do more work than user awareness ever could.

For programme owners, the next audit question is whether recovery, help desk, and legacy access paths are held to the same assurance standard as the primary login. A single weaker fallback can erase the value of a strong first factor, especially when attackers are optimising for the alternate path.

With only 5.7% of organisations having full visibility into their service accounts, per the Ultimate Guide to NHIs, the broader lesson is clear: identity programmes that cannot see every credential path will not be able to defend every trust path either.

For practitioners

• Harden the recovery path Review help desk, account reset, and identity proofing workflows for any step that can be completed without the same phishing-resistant controls used at primary login.
• Remove subjective trust checks from high-risk access Replace user-judgment-based verification with device binding, origin validation, and policy decisions that do not depend on recognising a page or conversation as legitimate.
• Prioritise phishing-resistant methods for privileged users Deploy passkeys or other phishing-resistant authenticators first for administrators, finance, support, and anyone with access to sensitive recovery or approval workflows.
• Test fallback access as an attacker would Walk every exception path, including legacy apps and contractor access, to confirm that a lower-assurance route cannot be used to bypass stronger authentication controls.

Key takeaways

• Bluekit demonstrates that attackers can preserve a legitimate login experience while relocating the authentication ceremony into infrastructure they control.
• The scale of the problem is not limited to phishing pages, because weak recovery and fallback paths can nullify strong primary authentication.
• The practical response is to remove subjective trust checks, strengthen fallback workflows, and extend phishing-resistant assurance across the entire identity lifecycle.

Key terms

• Browser-in-the-Middle: A Browser-in-the-Middle attack places the attacker between the user and the legitimate service while preserving the look and feel of the real login flow. The victim interacts with a live session that is controlled or mediated by the attacker, which makes the attack more convincing than a simple fake page.
• Phishing-resistant authentication: Phishing-resistant authentication uses cryptographic verification, usually tied to the legitimate origin or device, so the user cannot easily reuse or relay the factor in a fake context. It reduces the value of password capture, push fatigue, and proxy-based phishing by making the authenticator validate the relying party.
• Identity assurance: Identity assurance is the confidence an organisation has that an account, session, or request is genuinely tied to the right subject. It includes proofing, authentication, recovery, and exception handling, so assurance is only as strong as the weakest step in the full identity journey.
• Recovery workflow: A recovery workflow is the set of processes used when a user loses access and needs their identity restored. These paths often become a softer target than primary authentication because they rely on support staff, alternate channels, or temporary credentials that attackers can exploit if the controls are weaker than the login flow.

What's in the full article

HYPR's full blog post covers the operational detail this post intentionally leaves for the source:

• Walkthrough of the Browser-in-the-Middle attack flow, including anti-analysis checks and session relay mechanics.
• Explanation of why Device Bound Session Credentials do not address a session created inside attacker-controlled infrastructure.
• Direct comparison of passwords, push MFA, and FIDO2 passkeys against streamed phishing techniques.
• Discussion of Microsoft identity workflows, recovery paths, and the broader identity assurance model.

👉 HYPR’s full post covers the attack mechanics, session handling, and why FIDO2 changes the trust model.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.