Detailing a phishing attack: Nyasher, a Google account-takeover kit - David E. WeeklySkip to main contentAn 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.

For security researchers only. Every domain and URL below is, or recently was, live hostile infrastructure. They are written "defanged" ([.] in place of dots) so nothing here is clickable by accident. Do not reassemble or visit any of them unless you are a security researcher working in an isolated analysis environment. Re-fanging one of these links and opening it in a normal browser can hand your live Google session to the attacker.

“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:

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.

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.

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.

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 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,...