Nyasher: The Evasive Phishing Kit That Live-Streams the Real Google Login

Every phishing detection product on the market is built on the same assumption: somewhere in the attack there is a fake page. A cloned DOM, a stolen logo, a lookalike domain, a form that posts to the wrong host. Find the fake, block the page.

The kit we pulled apart this month has no fake page. The victim is watching a live video feed of the real accounts.google.com, rendered in a browser the attacker controls somewhere else, streamed frame by frame into their tab, with a real input box positioned on top of the pixels where Google's email field appears. Type a character and it is relayed into the attacker's browser and typed into Google for real, and the next frame comes back showing it. Every brand signal is authentic because it came from Google. Every byte of HTML in the victim's tab belongs to the attacker's streaming client, and none of it looks like a login form.

This is a Browser-in-the-Middle (BitM) attack, and the sample we caught is a mature, productized version of it. ZeroBEC tracks this kit family as Nyasher, and DarkMarc documented a closely related campaign using the same Cloudflare Workers plus blob URL delivery against video production agencies. Our sample used a procurement lure. Same bones.

The chain, one hop at a time

It starts somewhere very boring: a Confluence page.

That is a real Atlassian tenant on a real atlassian.net domain, published externally. There is no attachment, no macro, no lookalike domain, and nothing for a secure email gateway to detonate. The link is one click and the reputation is borrowed. Following it leads through a compromised Romanian site (greenimpact.ro/rfp/rfp-portal-access, recovered from the kit's own routing token) and on to a Cloudflare Worker.

Cloudflare's free developer domains are now standard phishing infrastructure. Fortra measured a 104% year-over-year surge in phishing on Workers, and BleepingComputer covered the same trend across pages.dev and workers.dev. They are free, instantly provisioned, TLS-valid, and they rotate faster than any blocklist.

Then comes the gate.

Press and hold. Behind it in the same bundle sit a fake Cloudflare Turnstile card (complete with a hardcoded Ray ID and a "Performance and Security by Cloudflare" footer that never talks to Cloudflare), a canvas-rendered math captcha, a fake reCAPTCHA image grid built from picsum.photos tiles, and a browser-version gate that rejects anything older than Chrome 120. There is also a 30 minute inactivity timer that quietly redirects to google.com, so a sandbox that parks on the page reports a clean result.

None of this stops bots from a bot's perspective. It stops analysts. By the time anything reaches the credential stage, the visitor has been filtered down to a live human on a modern browser, which is precisely the population that automated defenses are not.

The landing page is a video feed

Clear the gate and the tab navigates to a blob: URL.

We have written before about why blob: documents are a structural blindspot for browser extensions: the HTML never crosses the network, and a blob: document reports an empty location.hostname, which zeroes out host, TLD, and subdomain heuristics. That post covered kits that smuggle a cloned page into a blob. This kit does something further.

Open DevTools and the illusion falls apart immediately.

The entire Google sign-in screen is a single 30 kB image, and it is one frame of a running stream. There is no <form>, no #identifierId, no Google CSS, no Google JavaScript. There are two <img class="strmv"> elements, image-buffer-a and image-buffer-b, holding successive frames of the remote browser and swapped by opacity so the picture updates without tearing, which is the same double-buffering trick a video player uses. On top of them sits an <canvas id="overlayCanvas"> drawing the remote cursor, wrapped in a tabindex="0" container that captures the victim's keyboard. A WebSocket relays keystrokes and clicks back to the attacker's browser, which is the thing actually logged into Google.

The credential capture is an absolutely positioned real <input> at z-index:999, styled opaque to match the streamed dark-mode field, carrying data-input-id="#identifierId" so the kit knows which field on the remote page to mirror the typing into.

The same JavaScript bundle ships the operator console: a tabbed dashboard where each tab is a live victim session, a take_control button so the operator can seize the session mid-login, and audible alerts from actions.google.com/sounds/ when a new victim connects.

Why every conventional signal misses

BitM is not new as a concept. Tommasi, Catalano and Taurino described it academically in 2021, mr.d0x demonstrated it with noVNC in 2022, and Mandiant published BitM Up! Session Stealing in Seconds in March 2025 along with their internal Delusion tooling. What is new is that it has been packaged into a turnkey kit with an operator dashboard and a full evasion stack in front of it.

Walk down the standard detection list and every entry fails for a different reason:

This is not a kit that slips past one control. It is a kit engineered so that the category of signal each control depends on is absent from the page.

The two halves cover for each other

Blob delivery and BitM are both a few years old, and neither one on its own is remarkable anymore. What makes this kit effective is that they cancel out opposite halves of the detection stack, and the gap left over is close to the whole stack.

Blob delivery defeats everything that inspects the attack in transit. The phishing document never exists as an HTTP response. It is assembled inside the renderer and loaded by a top-level navigation, so there is no body for a gateway to hash, no artifact for a feed to republish, and no URL for a reputation service to score. Push a blob: URL into any tool that expects a fetchable address and you get nothing back.

BitM defeats everything that inspects the attack at rest, in the page. A blob-delivered clone, like the ones we wrote about in May, still contains a fake login form in the DOM. Anything that can read the document can find it. Here there is no form, no brand asset, no cloned markup, nothing but two images and a canvas. Getting into the document buys you almost nothing, because the phishing page is not in it.

Layer by layer, that combination looks like this:

• Secure email gateway. Sees a link to a real, externally published Confluence page on atlassian.net. No attachment, no payload, no lookalike domain.
• URL detonation and sandboxes. Follow the link and hit the press-and-hold gate, the fake Turnstile, the canvas math captcha, and the browser-version check. Most report the last state they reached, which is a benign interstitial. The 30 minute inactivity redirect to google.com cleans up anything that lingers.
• Secure web gateway and TLS inspection. See a TLS-valid workers.dev connection and a WebSocket. The credential never crosses the wire as a form post, because it is delivered as keystrokes into someone else's browser session.
• Threat intel feeds. Re-fetch the parent URL, not the blob, so the actual phishing content never enters the public corpus and never gets a name until someone captures it by hand.
• Browser extensions and endpoint agents. Get a document with no login form to protect and, in the default case, an empty hostname to reason about.
• Identity provider and MFA. See a completely normal, successful, MFA-satisfied sign-in, because that is exactly what it is. The only anomaly is where it came from.

Each of those is a reasonable control. Each one is looking for something this kit genuinely does not have. That is the design.

Where it gets caught

Every control in that table sits somewhere the attack has already been designed around: upstream of the browser, or downstream at the identity provider. The one place the attack cannot hide is the tab it is running in. The stream, the overlay, the keystrokes, and the origin serving all of it are only ever assembled in one place, and that is the rendered page in front of the user.

Surface Vision runs there and blocked this sample on the live page, before the first character reached the attacker's browser. We are not going to detail the reasoning behind the verdict here, for the obvious reason that the operators read these writeups too. This kit is proof of that: it shipped with a hardcoded attempt to suppress a specific browser extension's credential monitoring, which is not something you build without studying the defense first.

What is worth saying publicly is the shape of the problem. A verdict that depends on recognizing a fake page has nothing to work with when the page is a screenshot of the real one. A verdict that depends on the URL has nothing to work with when the document reports no hostname. Anything that still works against this kit has to reason about what the page is doing rather than what it looks like or where it came from.

Defensive guidance

The durable control here is origin-bound authentication. A FIDO2 key or passkey registered to accounts.google.com will not sign for the attacker's origin, which breaks the relay no matter how perfect the pixels are. Everything else in this chain, the trusted Atlassian host, the valid TLS, the genuine Google branding, is engineered to be indistinguishable from legitimate, because most of it is.

Two more worth acting on:

• Treat a BitM hit as a session compromise, not a password compromise. Revoke active sessions and refresh tokens and force re-auth. A password reset leaves the attacker signed in.
• Watch outbound traffic to free developer hosting. *.workers.dev and *.pages.dev have very little legitimate business use inside most enterprises, and blocking or alerting on them costs almost nothing.

Indicators of compromise

From this sample, July 2026. These rotate quickly, so treat them as leads rather than lasting signatures.

If you want to see how Surface handles live BitM samples in your own browsers, or test your current stack against one, get in touch.