Detailing a phishing attack: Nyasher

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 at minimum a different kit. (I originally wrote that it was the same playbook in someone else’s hands. See the August 2026 update below — I now think the operator question is open.) Worth knowing either way 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.

Update, August 2026: it’s a shop, not a kit

Added 2026-08-30.

I ended this post saying I couldn’t tell you who was behind it. That’s still true. But James Ingram has since taken the operator’s own archive apart, and the picture he came back with is much larger than the one I had. His follow-up, “Nyasher is a shop, not a kit,” is worth your time. He worked from an incident of his own, and from every archived copy of the operation he could pull out of public scan history. (James Ingram on LinkedIn)

The short version: this isn’t one kit. It’s one operator running several. The Browser-in-the-Middle kit I pulled apart above, a separate Microsoft 365 credential kit that cycles through invented brand names, a bank login panel, and the “hold to verify” gate in front of all of them are code-distinct, and they all carry the same two secrets. Different disguises, one backend.

Two of those secrets are in my indicator list below, which is the part I can personally vouch for. The AES seed X7kP9mQ2vR4nL8jF3wE6yT1hG5bN0cZ9 and the JotForm fallback sink I found in this single sample turn up together in about fifty-five independent archived captures spanning a year. Two unrelated strings travelling together that many times is one codebase. I recovered them from one incident in a day; he found them across the whole operation. Nice to have the corroboration run in that direction for once.

A few things I got narrower than reality:

The timeline. I started this story in summer 2026. The first confirmed artifact is August 2025, roughly a year earlier, and the operation ran in three phases: a bare-domain gate era, a move onto Cloudflare Workers in December 2025, then the real-time hijacking wave I walked into. The link between the old stack and the new one isn’t inference. A single disposable Cloudflare account was caught running both.

The targeting. I framed this around video production firms and executives, because that’s what my lure looked like. It isn’t representative. The core business is construction and the trades: bid requests and payment-change notices to builders and suppliers, where one rerouted deposit is the entire payday. Around that, a regional bank, a large IT services firm, a university medical group, and a whole parallel line of consumer webmail phishing wearing Spectrum, Xfinity, EarthLink and Telstra branding.

The scale. I had a handful of domains and Worker accounts. The mapped estate is 119 distinct hosts each carrying two or more of the kit’s private markers.

The disclosures didn’t cost them a day. DarkMarc in February, ZeroBEC in June, this post in July. Each landed mid-wave, and the operator’s answer every time was a fresh domain.

Nobody has named the operator, and Ingram doesn’t either. What changed is where the loose threads run. Six separate ipinfo accounts used to geolocate victims, seven Cloudflare Web Analytics accounts that let the infrastructure be clustered by billing account rather than one domain at a time, two Microsoft OAuth apps and a consumer OneDrive used to stage bait, a habit of buying aged expired domains, and one static IP baked into the source of every build. None of those name a person. All of them name a provider that keeps registration records a subpoena can reach, which is a better place for this to end up than a handle.

One hedge on my own indicator list. I called ghrenity[.]xyz related but distinct. At the kit level I’d still say that, and I’d say it for the same reasons: different C2, different kit fingerprint. But “different kit” and “different operator” are separate questions, and I answered the second one more confidently than my evidence supported. Given how many code-distinct kits this one operator turns out to run, read that entry now as a different kit, possibly the same shop.

Nothing above changes the advice. If anything it sharpens it: an operation this size, running this long, through this many public write-ups, is not going to be inconvenienced by you choosing a better password. Passkeys and hardware keys, out-of-band verification for anything that moves money, and suspicion of any “prove you’re human” step that appears before a login rather than after one.

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, [email protected]
• Relay crypto seed (this sample): X7kP9mQ2vR4nL8jF3wE6yT1hG5bN0cZ9
• Related (different kit; operator unresolved): ghrenity[.]xyz (Microsoft-targeted BitM, Joe Sandbox 1920454). See the August 2026 update above.
• Full IOC list and the four-campaign correlation are in ZeroBEC’s writeup plus my notes above. For the operator-level estate (119 confirmed hosts, the multi-kit linkage, the 2025 origin), see James Ingram’s August 2026 follow-up.

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 [email protected] 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.