A September 2026 "Shared Document" lure built a blob: page with a fake verification gate. The page was configured for iCloud Mail. In a test on my own computer, a click made the page display a screen controlled by my test server and send my input back. Code comparison tied the client to the Nyasher phishing kit. The archived browser scan stopped at the gate and recorded no iCloud login.
Phishing uses a deceptive message or page to draw someone into giving away account access. Here, the lure posed as a shared document and borrowed the look of a verification check. The FTC's phishing guide explains the broader pattern.
How a Blob became a phishing page
A Blob is a file-like bundle of data that a web page can create in memory. It can hold text, an image, or HTML. JavaScript can label that data as HTML, then ask the browser for a temporary address that starts with blob:. Opening that address displays the data as a page. MDN explains how Blob URLs work.
Blobs also support ordinary features such as PDF downloads and image previews. This case used one to open a new HTML document after the initial page loaded. The page was built in the visitor's browser, but its code could still communicate with servers. The blob: address points to data held by that browser; the address alone does not contain the page.
What the public scan captured
The public urlscan capture from September 12, 2026, shows the "Shared Document" lure. Its screenshot has an iCloud-style icon and a fake Cloudflare verification box.
Figure 1. The archived lure. The iCloud Mail target came from the recovered configuration, beyond what this screenshot shows.
The saved requests contained an encrypted response from a Cloudflare Worker, a program running on Cloudflare's network. They also contained the Blob document. I decoded the response offline to recover 228,432 bytes of HTML. Its main script matched the script in the saved page byte for byte. The settings named www.icloud.com/mail as the target and sage[.]gerude[.]site as the relay server.
From encrypted response to Blob page
The loader, the script on the first page, probed the Worker's /eal endpoint and sent an encrypted request to /create. The response carried the HTML as encoded text inside an encrypted wrapper. The loader derived a key from a value built into its code, decrypted the response, and built the Blob document. It used SHA-256 for the key and AES-CBC for decryption:
var _bl = new Blob([_hc], {type: _0x[5]});
return URL.createObjectURL(_bl);
// Later, after getting that URL:
window.location.replace(_u);
These lines come from separate parts of the loader. _0x[5] resolves to text/html;charset=utf-8.
A blob: URL shows the site that created it and a browser-generated ID. A scanner outside that browser session cannot retrieve the document from the URL alone. Here the document held code that could show a screen controlled elsewhere and send the visitor's actions back. The public scan captured the Blob document, although its separate Frames view retained the initial HTTPS URL. My replay supplied a separate record of the navigation.
I used an LLM to help untangle parts of the code. I checked its leads against the saved files and the local replay before using them here.
The click that opened the relay
Two verification stages followed. A timed module in the loader invoked the navigation hook. In the Blob page, connect(true) decoded the settings and returned before opening a WebSocket. The September setting was autoClick=false, so the relay waited at the fake checkbox.
The checkbox handler checked for a real user click or the client's internal click token, then called connect(). That function opened a WebSocket, a connection that lets the browser and server exchange messages in both directions:
await connect()
// Inside connect():
socket = new WebSocket(wsUrl);
The public scan reached the verification screen and stopped. It recorded no relay connection. My localhost replay reached the same stage with substitute assets:
Figure 2. The verification stage in my replay. Local substitute assets changed its appearance.
Figure 3. The delivery chain from the saved source and replay. /eal checked availability; /create supplied the encrypted payload.
What the local replay proved
I pointed copies of the files at local test servers on the same machine; the saved originals stayed unchanged. These stand-in servers preserved the encrypted /create exchange, accepted the WebSocket, and supplied a synthetic token and one labelled test screen. I typed only REPLAY_TEST_123.
Chrome and the mocks ran in a separate network namespace with loopback-only firewall rules. Chrome used an unprivileged process and a disposable profile. The packet capture recorded 241 packets, all between 127.0.0.1 addresses. Both firewall ACCEPT counters matched that count, and the capture reported zero drops. No traffic reached the configured attacker relay. Chrome's built-in process sandbox was disabled for this replay; the namespace and firewall supplied the network boundary.
After the click, the page connected to my server and sent a dimensions message with browser-window details. That message used a fixed AES-GCM key and left before my mock returned a session token. The client then derived a session key by hashing the fixed key bytes followed by the token with SHA-256. Messages two through 68 used that key. This order reflects my mock's token timing.
Figure 4. The order observed with my local server's token timing.
My server authenticated and decrypted 68 outbound messages. The text frames carried base64-encoded data: a 12-byte IV, AES-GCM ciphertext, and a 16-byte authentication tag. Each ciphertext matched a captured browser WebSocket frame, and the plaintext matched the browser observations before encryption. The count was one dimensions, one first_frame_received, two mousemove, three mousedown, three mouseup, 15 keyInputChange, and 43 wheel messages. The client displayed my synthetic WebP screen while sending input back.
Figure 5. The paths exercised in the replay. The shortcut and enhanced clipboard paths were inactive in this sample.
Typing worked through the generated input field's input listener. The generic keydown, keyup, and keypress bindings were commented out. My shortcut tests produced no shortcut messages. The enhanced clipboard setup function was defined but never called; the client used a fallback hidden value. I supplied one screen image, so the replay did not test a continuing screen stream.
The synthetic localhost screen after I typed REPLAY_TEST_123 into the input overlay. The decrypted keyInputChange messages confirmed that my test server received it.
The public scan ended at the lure, and my replay used a synthetic screen. Neither showed an iCloud session, a multi-factor authentication step such as a one-time code, or account takeover.
Why I call this client Nyasher
ZeroBEC named the Nyasher kit after an unusual key found in multiple samples. A kit is reusable code that an operator can configure with different lures and account targets. "Nyasher" names that code family. I use "BlobPhish" here for this sample's blob delivery method.
Nyasher acts like a window into a browser controlled elsewhere. The visitor sees images of its screen and sends clicks and typing back to it. Surface Security documented this design with Google sign-in. A successful sign-in on that remote browser gives its operator the authenticated session. My replay confirmed the screen and input relay with a test page; it did not include a real sign-in.
Research by DarkMarc and David E. Weekly helped me identify the family. I compared the September page with public captures from July 16 and August 22. Those configurations targeted Outlook and Google.
Figure 6. The three configurations side by side, with domains defanged.
In each earlier page, 102 of 103 named functions matched the September page byte for byte. Only connect() differed. I normalized four configuration sites: initial autoClick, cached U, cached H, and the IP-information API token. The entire main scripts then matched exactly. The complete HTML files and their hashes differ.
That code match supports a Nyasher family identification. It does not identify the operator. The encryption also appeared in the earlier samples.
How to recognize the same pattern
Look for the sequence: an encrypted response, HTML built in the browser, top-level navigation to that document, a verification prompt, then incoming screen images and outgoing input events. Tie the source and document to the same frame where possible. The recovered HTML, captured DOM, saved requests, and local replay connected those steps in this case. The Blob navigation established execution; the configuration, fake gate, and relay behavior established phishing context. A Blob or WebSocket alone is a weak lead.
The public scan missed the relay because the page waited for a click. The earlier Nyasher configurations enabled automatic activation, so that setting changes what a scan can observe. Source review exposed the gated path; the replay confirmed the screen and input exchange. Check pages built with srcdoc, document.write, or DOM insertion too. Those methods build HTML in the browser without a blob: URL.
Kirk found related infrastructure
My buddy @KirkDerpca, who runs derp.ca, searched for the /eal and /create endpoint pair. He found 434 captures from 2026, mostly from July through September. He inspected 59: 55 yielded Nyasher clients, one tried to misuse a Microsoft device-code sign-in, and three had no saved payload response.
Kirk found two more Workers configured to use the sage[.]gerude[.]site relay from my September sample. The endpoint pair is a hunting lead, though the device-code case shows it also delivered other phishing content. The shared paths and relay establish infrastructure overlap. They do not establish that one operator ran every page.
Indicators from the September sample
These are the addresses and file fingerprint I recovered. The dots in the addresses are replaced with [.] so the domains are not clickable.
| Role | Indicator |
|---|---|
| Loader site | secureshdnskskfk[.]wonnerfitness[.]lat |
| Delivery Worker | shared-document-xvnt-2[.]jferrellsr[.]workers[.]dev |
| Configured relay | sage[.]gerude[.]site (/ws) |
| Recovered HTML SHA-256 | c5bd3fcc8266f414126857580bc2bb8f7ae9b7b64addd327554a707b6d03c871 |
Where the evidence stops
The saved scan shows an encrypted delivery chain, a Blob document, and a verification gate. My contained replay shows that the client displayed a synthetic screen and sent clicks, scrolling, and typed text to a test server. The code match ties this client to Nyasher. None of those observations shows a real iCloud sign-in or identifies the operator.
Kirk's results show that the delivery endpoints appeared in many captures and served more than one kind of phishing content. This bounded search cannot measure how common Blob phishing is relative to ClickFix, which tricks people into running malicious commands on their own devices, or other techniques.