Notifications
Clear all
Topic starter
04/07/2026 10:01 pm
TL;DR: Bluekit’s Browser-in-the-Middle phishing model shows how attackers can preserve a legitimate Microsoft login experience while controlling the session from their own browser, according to HYPR and Netcraft. The deeper issue is that identity programmes still depend on human judgment in places where cryptographic assurance should be doing the work.
NHIMG editorial — based on content published by HYPR: Thwarting Bluekit Phishing-as-a-Service Attacks on Microsoft Authentication
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.
Questions worth separating out
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.
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.
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.
Practitioner guidance
- 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.
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.
👉 Read HYPR’s analysis of Bluekit Browser-in-the-Middle phishing on Microsoft authentication →
Bluekit browser-in-the-middle attacks: is your identity model ready?
Explore further
04/07/2026 10:08 pm
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.
A few things that frame the scale:
- 91.6% of secrets remain valid five days after the targeted organisation is notified, according to Ultimate Guide to NHIs.
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Bluekit shows why phishing-resistant identity assurance matters
