Bluekit is not a new name. Varonis Threat Labs first documented the phishing-as-a-service kit in April 2026, cataloguing an AI assistant built on jailbroken language models, more than 40 templates spoofing brands from Apple ID and Gmail to GitHub and Ledger, automated domain registration, and voice cloning add-ons sold as a package. What is new is how it steals a login. Netcraft’s latest analysis, published this month, found that Bluekit has added a Browser-in-the-Middle technique, and identified roughly 70 active phishing sites running it in a single week. That is not a proof-of-concept circulating in a forum post. That is a commodity kit already deployed at scale.
From Reverse Proxy to Live Browser Stream
Older adversary-in-the-middle kits like Evilginx work by proxying traffic. The victim’s browser talks to the phishing server, the phishing server relays requests to the real site, and the kit captures whatever passes through in both directions, including the session cookie that survives after MFA is satisfied. That architecture leaves fingerprints defenders have learned to look for: mismatched TLS certificates, proxy-specific headers, unusual routing.
Bluekit’s Browser-in-the-Middle approach skips the proxy entirely. Using rrweb, an open-source library built for recording and replaying DOM interactions, the kit loads the real login page inside a browser the attacker controls and streams what that browser renders to the victim in real time, then relays the victim’s clicks and keystrokes back into it. The victim is not looking at a copy of the login page. They are remotely operating the actual page, running on the attacker’s machine. There is no proxy traffic to fingerprint because there is no proxy in the traditional sense at all.
Why This Beats the MFA You Are Counting On
Because the session lives on the attacker’s browser from the start, any MFA challenge the victim completes, including a one-time code or a push approval, authenticates that browser directly. The attacker does not need to intercept and replay a session token after the fact. They already have the authenticated session, live, the moment the victim finishes logging in. Reporting on the kit ties this specifically to Microsoft account theft, and the evasion layered on top makes it harder to catch before that point: dynamic JavaScript obfuscation, a custom CAPTCHA that impersonates the target brand or a legitimate anti-bot vendor, WebRTC checks that flag mismatched IP addresses, headless-browser fingerprinting, and HTML that is randomized on every page load. The one weakness Netcraft’s researchers point to is subtle: streaming a live DOM over rrweb adds latency that a real login page does not have, so the page can feel marginally slower to type into or click through. That is a detection signal for a security team. It is not something a rushed employee is likely to notice.
Why DMARC Never Gets a Vote
DMARC authenticates a domain’s outbound mail. It does not authenticate a session, a browser, or a page a victim reaches by clicking a link, and Bluekit’s entire value proposition lives entirely after that click. The message that delivers the link can come from a freshly registered lookalike domain the attacker owns and authenticates cleanly, from a compromised account on a domain with a perfect DMARC record, or from a channel DMARC never touches at all, like SMS or a chat app. However that link arrives, DMARC’s job is finished the moment the mail lands. Bluekit’s Browser-in-the-Middle technique operates entirely in the layer beneath it, at the session, and MFA, the control most organizations lean on as their backstop once a message gets through, is exactly what it is built to defeat.
What Security Teams Should Do Now
Move toward phishing-resistant MFA wherever the platform supports it. FIDO2 security keys and passkeys bind the authentication ceremony to the legitimate site’s origin, which a streamed or proxied fake page cannot satisfy no matter how convincing it looks.
Monitor for anomalous session behavior, not just failed logins. A session token used from an unexpected device or location immediately after a clean authentication is a stronger signal than a login failure, and it is the exact pattern a Browser-in-the-Middle attack leaves behind.
Keep DMARC at p=reject on every domain you own, including the ones that never send bulk mail. It will not stop Bluekit, but it closes off the cheaper, more common attacks that still ride on your own domain’s reputation, freeing your team to focus on the harder session-layer threats.
Train users to notice friction, not just spelling errors. A login page that feels slightly slower or less responsive than usual is a more useful warning sign against this specific technique than any logo or grammar mistake would be.
The Takeaway
Bluekit’s Browser-in-the-Middle upgrade is a reminder that phishing defenses built around what a message looks like, or even around classic session-token replay, are chasing a target that keeps moving one layer deeper. DMARC still matters. It just was never positioned to answer the question Bluekit is now asking.
Excello Mail keeps the domains you own fully authenticated and enforced, closing off the cheapest phishing paths so your security team’s attention goes where it is actually needed, on session-layer threats like Bluekit that no authentication record can touch. Sign up for free to Excello Mail to see your domain’s real authentication posture today.