Detailing a phishing attack: Nyasher, a Google account-takeover kit

An email showed up this morning on a mailing list I’m on. Subject line: “Bid Proposal Invitation.” A PDF attachment, a polite note, a button to view the document. It came from a real person’s Gmail account, someone I recognized, and Google had already scanned the attachment and marked it safe.

It was not safe. The account was hijacked, the PDF was a lure, and behind the “view document” button was one of the more sophisticated phishing kits I’ve taken apart: a live Browser-in-the-Middle system that steals your Google session in real time and walks straight through two-factor authentication. I spent the day pulling it apart. The good news is that other researchers have been tracking this exact framework for months, so I wasn’t starting from zero. This post is what I found, and where it confirms and extends what they’ve published.

“Google scanned it and it’s safe” means almost nothing here

The first thing worth internalizing: the PDF really was clean. No malware, no macro, no exploit. I extracted every object in it. The only weapon it carried was a hyperlink.

That’s the whole trick. Attachment scanners look for malicious bytes, and there weren’t any. The document was generated by a Python HTML-to-PDF library, personalized with the sender’s name in the title, and its “View Proposal” button (and a QR code, for the mobile-first victims) pointed at a web page. Everything dangerous happens after you click, on infrastructure the scanner never visits. “Google deemed this attachment safe” is technically true and practically meaningless. It means “this file contains no malware,” not “this is not a phishing lure.”

The layers, peeled back

The link didn’t go straight to anything obviously bad. It went through a chain, and each hop was a legitimate service being abused so that no single link looked like the attack:

1. The PDF linked to a page hosted on Framer (view-proposal-document-djd7[.]framer[.]website), a real, reputable site builder. This page did nothing but display a “View Proposal” button that forwarded you onward.
2. That button led to a Cloudflare Workers page (invitation-to-bid-proposal-ch8y[.]w-r1v6ya[.]workers[.]dev) showing a fake “press and hold to prove you’re human” check, followed by a fake Cloudflare challenge screen.
3. The fake challenge is not decoration. It’s an anti-analysis gate. The real payload only loads after a real human press-and-hold gesture, which means automated URL scanners, the ones that power the red warning in your browser, see nothing but a CAPTCHA and move on.
4. Once you pass, the page encrypts some data about you, sends it to one of six backend “relay” Workers, gets an encrypted response back, decrypts it in your browser, and renders it as an in-memory blob URL (blob:https://…). The credential page never exists at a real, crawlable address. It’s assembled in your tab and thrown away.

The page is also armored against inspection: it disables right-click and the developer-tools shortcuts, nukes the console, runs an anti-debugger loop, and wipes itself if it detects DevTools open. This is not someone’s weekend project.

To see what the blob actually contained, I replicated the kit’s own encryption (it derives an AES key from a hardcoded seed, a detail I’ll come back to) and asked the relay for the payload directly, from a throwaway server so I wasn’t poking at attacker infrastructure from my home address. What came back was 227 KB of HTML, and a configuration field that said mode_url: https://accounts.google.com.

It’s a Google credential phishing page. Which closes a nasty little loop: this is how accounts like the sender’s get taken over, and hijacked accounts are exactly what’s used to mail the lure to the next batch of victims. The thing is self-propagating.

It’s not a fake form. It’s a remote-controlled browser.

Here’s the part that moves this from “annoying” to “actually dangerous.” I expected a static clone of Google’s login: type your password, it gets emailed to some inbox in a <form> somewhere. That’s the usual shape.

This had no form at all. Instead it opens an encrypted WebSocket back to the attacker’s server and streams a real browser session. The victim is looking at, and typing into, an actual Google login page that’s running inside a browser on the attacker’s machine. Keystrokes, clipboard, mouse. Copy and paste are literally forwarded to the remote browser. The page even contains a hidden operator console: tabs, a “pause/activate” control, a “connection status” indicator, an admin metadata panel.

This class of attack is called Browser-in-the-Middle (BitM), and the reason it matters is two-factor authentication. A stolen password is useless against an account with 2FA, because the attacker still can’t complete the login. But if the victim completes the login, including the 2FA prompt, inside a browser the attacker controls, then the attacker walks away with the authenticated session cookie. The session is already past 2FA. Your second factor protected the login; it did nothing for the session that login produced. That is how a well-defended, 2FA-protected Google account gets taken over by clicking a link.

Finding the real server

The relay Workers and the Framer page are disposable: throwaway accounts, easily rotated. The interesting infrastructure is the server running those remote browsers, and its address wasn’t sitting in plain sight. It was passed to the page as an encrypted parameter.

The kit obfuscates it with an XOR cipher whose key is hardcoded right there in the JavaScript: _SuperBigNyasher47_. Decrypting the parameter offline gave up the command-and-control server: gold[.]sommiedo[.]site, with a WebSocket endpoint at wss://gold[.]sommiedo[.]site/ws, plus a campaign reference number and the target provider. Unlike the throwaway Workers, this is a registered domain: Namecheap, created five weeks before the attack, sitting behind Cloudflare so its true origin stays hidden.

Standing on other researchers’ shoulders

At this point I searched for that distinctive key, and found I was walking a trail others had already blazed.

ZeroBEC published a detailed writeup on June 29, 2026, nine days before my email, covering this exact framework. They named it “Nyasher,” after the same rare _SuperBigNyasher47_ key I’d just pulled out of my sample, which they’d found appearing across multiple samples going back months. Their analysis is excellent and I’d recommend it; it independently documents the WebSocket control traffic, the hidden admin telemetry, the blob-hosted Google page, and the same C2 domains. They credit an even earlier analysis by the researcher DarkMarc, whose February 6, 2026 writeup first documented the framework hitting video-production agencies. That campaign, it turns out, used the same Framer landing-page template I’d just walked through. Malwarebytes covered the same broad “fake Google check becomes a browser RAT” technique class around the same time, here.

So the framework isn’t new, and I’m not the one who discovered it. What I can add is a fresh, independent data point that shows how the operation has evolved and how wide it runs. Here’s specifically where my observations build on the prior work:

• The same Framer template, five months on. DarkMarc’s February sample used a Framer page at view-proposal-document-vjmsq[.]framer[.]website. Mine was view-proposal-document-djd7[.]framer[.]website: the same naming template, still in service in July, even though ZeroBEC’s June case had moved to Webflow. The operator swaps hosts, but this particular Framer proposal-document template has persisted for at least five months, which makes the template itself a durable thing to hunt for.
• A broader delivery vector. The documented cases spread through targeted or person-to-person email (a spear-phished CEO in DarkMarc’s write-up, a forward in ZeroBEC’s). Mine was a blind-copied blast to an entire mailing list from the hijacked account, which trades precision for reach.
• An indicator nobody had published. My sample hardcodes a live ipinfo.io API token (2991c478cc5e5c), which the kit uses to geolocate victims. I verified it’s active. It doesn’t appear in the earlier reports, and because it’s tied to whatever account registered it, it’s a durable fingerprint that ties this operator’s campaigns together. I’ve reported it to ipinfo.
• Confirmation the same C2 serves everyone. This is the part that made me sit up. I cross-checked my decoded server against two other independent public detonations of different campaigns: a Joe Sandbox analysis and a urlquery report. Four separate campaigns, with different lures (bid proposals, payment remittances), different hosting, and different throwaway accounts, all funnel to the same gold[.]sommiedo[.]site server. One of the relay accounts even recurs across ZeroBEC’s case and the sandbox run. This isn’t a scattered set of copycats; it’s one operation with a shared backend and a rotating front end.

One more data point is worth separating out, because it cuts the other way. A Joe Sandbox run of a different sample shows the same technique (a workers[.]dev front end feeding a blob-hosted page that opens a WebSocket back to a Cloudflare-fronted relay), but a Microsoft login target and a different C2 (ghrenity[.]xyz), and Joe Sandbox fingerprints it as a separate kit (“Crown Phishing Kit”). So the workers.dev-plus-blob-plus-WebSocket BitM pattern isn’t unique to this one operator or to Google. The four rows above are one operation sharing a backend; this Microsoft-targeted sibling is the same playbook in someone else’s hands. Worth knowing if you’re writing detections: hunt the pattern, not just the sommiedo domain.

What I can’t tell you

I can describe the operator’s habits. They’re organized: a farm of throwaway Cloudflare accounts, freshly-registered domains rotated behind Cloudflare for the real servers, and a Mac to work on (a screenshot filename left in the Framer project gives that away, dated two weeks before the send). But I can’t tell you who they are or where they are, and I’m not going to pretend otherwise. Every command-and-control domain hides behind Cloudflare, so the true origin IP never shows, not even under full sandbox detonation. And the email headers, which prove the sending account was genuinely compromised rather than spoofed (the Google DKIM signature is valid), expose no client IP, because Google strips it for mail sent through the web interface. ZeroBEC, who have far more samples than I do, also decline to name an actor. That’s the honest ceiling on the evidence.

What to actually do

A few takeaways that outlast this particular campaign:

“The attachment is safe” is not “the email is safe.” A link-only lure carries no malicious bytes and sails through attachment scanning by design. Judge the message, not the file.

Two-factor is necessary but it is not a force field. Browser-in-the-Middle steals the session after you complete 2FA. The defenses that actually stop it are phishing-resistant ones: passkeys and hardware security keys, which are bound to the real site’s origin and simply won’t produce a valid response for a lookalike page. If you’re protecting anything that matters, move to passkeys.

If an account is ever compromised, resetting the password is not enough. This is the step people skip. A password reset doesn’t revoke existing sessions, OAuth app grants, or app-specific passwords, so a session cookie or a planted “sign in with this app” grant survives the reset. When I walked the affected sender through remediation, the important part wasn’t the new password; it was revoking third-party app access and checking for attacker-created mail-forwarding rules.

When something like this lands, report it, because the chain has many weak points. I reported the pieces to Cloudflare, Framer, the mailing-list operators, Google Safe Browsing, the domain registrars behind the C2, and ipinfo. No single report kills it, but the backend server is shared across every campaign, so getting that domain taken down does real damage to the whole operation, not just my copy of it.

I’ll update this if any of the takedowns land or the infrastructure moves. My thanks to the ZeroBEC and DarkMarc teams, whose prior work turned a day of blind reverse-engineering into something I could corroborate and build on.

Indicators (defanged)

For anyone hunting the same framework. Domains are defanged; treat all as hostile.

• C2: gold[.]sommiedo[.]site, wss://gold[.]sommiedo[.]site/ws, sage[.]bucking[.]top
• My campaign’s front end: view-proposal-document-djd7[.]framer[.]website, invitation-to-bid-proposal-ch8y[.]w-r1v6ya[.]workers[.]dev
• ipinfo token: 2991c478cc5e5c
• Framework code markers: _SuperBigNyasher47_ (XOR key), zrawHazh, ADMIN METADATA LOG, no-email-mode@email.com
• Relay crypto seed (this sample): X7kP9mQ2vR4nL8jF3wE6yT1hG5bN0cZ9
• Related (different kit/target): ghrenity[.]xyz (Microsoft-targeted BitM, Joe Sandbox 1920454)
• Full IOC list and the four-campaign correlation are in ZeroBEC’s writeup plus my notes above.

Artifacts for researchers

I kept the full set: the original lure PDF, my complete campaign-intelligence notes (kill chain, decoded C2, the four-campaign correlation), and archived copies of the corroborating ZeroBEC and Joe Sandbox reports. If you’re a security researcher and want them for your own analysis or hunting, email me at david@weekly.org and I’ll send them over. I’m not posting them publicly, because the lure is live and I’d rather it not get re-weaponized by someone clicking around.

This article was co-authored with Claude Fable 5 and reviewed by me before publication. The reverse-engineering, the decoded indicators, and the conclusions are my own.