Threat Research
Nyasher: A Live Google Account Takeover Framework Using Webflow, Cloudflare Workers, and Hidden Admin Telemetry
ZeroBEC intercepted a live bid/proposal campaign in a customer environment. The investigation exposed Nyasher, a Google account takeover framework with stable code markers, evolving frame transport, WebSocket telemetry, and hidden admin instrumentation.
By ZeroBEC Team · June 29, 2026 · 12 min read
ZeroBEC intercepted a live bid/proposal campaign in a customer environment. The investigation exposed Nyasher, a Google account takeover framework with stable code markers, evolving frame transport, WebSocket telemetry, and hidden admin instrumentation.
Executive summary
ZeroBEC investigated a live Google account takeover campaign targeting a U.S. property business through a bid/proposal workflow. The campaign is notable because the first victim did not only receive the lure. After failing to access the promised document, that victim forwarded the email to another business contact and asked for help. This created an unintentional second verification layer that made the next click more likely.
We track this framework as Nyasher because multiple JavaScript samples contain the rare hardcoded key _SuperBigNyasher47_. The word "Nyasher" also appears as West African Pidgin slang for the backside, but we do not make any linguistic, geographic, or actor-attribution claim from that meaning.
The same key appears in a December 2025 sample, a February 27, 2026 sample, and the current June 2026 property-business case. Across that timeline, the framework shows clear evolution: the December 2025 and February 2026 samples used AVIF-based frame handling, matching the behavior documented by DarkMarc in February 2026, while the current June 2026 deployment moved to WebP frame handling, embedded campaign configuration, and runtime C2 selection.
The current campaign uses multiple trust and evasion layers: an authenticated Gmail forward, a Webflow-hosted bid-project page, Cloudflare Workers verification gates, a blob-hosted Google sign-in interface, WebSocket-based control traffic, and a post-authentication Google Drive handoff. Runtime admin metadata exposed by the page confirms campaign routing, target provider, C2 selection, victim fingerprinting, and the Google Drive landing page.
This campaign extends prior public reporting in four ways: it shows the framework was present as early as December 2025, it demonstrates visible evolution in the framework's rendering and configuration model, it documents targeting against a U.S. property business rather than video production agencies, and it shows how a legitimate first victim can become an unintentional trust amplifier for a second victim.
The victim becomes the verifier
The most important behavioral element is not the fake Google page. It is the human relay in the middle of the attack. The outer message was a real Gmail forward that asked the property-business recipient to help open a document. The inner message was a polished bid/proposal workflow with a deadline and a dashboard button.
This changes the recipient decision model. Instead of deciding whether to trust a cold external proposal, the recipient is asked to help someone who appears to have already interacted with the document. The first victim accidentally performs social proof for the attacker.
This is especially effective in property management, real estate, construction, vendor management, and facility operations. Bid packages, RFPs, subcontractor scopes, project attachments, and last-minute deadlines are normal business patterns in those environments.
Figure 1: Forwarded bid/proposal lure. Personal identifiers are blurred in the source image.
Observed social chain:
- Real Gmail user → forwards failed document → property-business recipient
- Inner lure → "Executive Review Requested" → bid/proposal dashboard → Webflow link
- Behavioral effect → the first victim unintentionally validates the lure for the second target
Email and gateway view
The message traversed Gmail, Mimecast, and Microsoft 365. The forwarded email was submitted through Gmail from an Apple/iPad mail client, which supports the assessment that the outer sender was a real Gmail account rather than a simple display-name spoof.
At Mimecast, Gmail authentication passed. After Mimecast relayed the message to Microsoft, Microsoft reported SPF softfail, DKIM fail, and DMARC fail at the final hop, yet the message still received low-risk treatment with SCL 1 and category NONE. That is the core control gap: the high-risk relationship pattern was not represented by the final spam score and the email landed in the Inbox.
Redirect and runtime chain
The observed click path moved through the following stages. URLs are defanged in this document.
hxxps://url[.]us[.]m[.]mimecastprotect[.]com/s/...domain=proposals-ultra-awesome-site-secure-vie[.]webflow[.]io
hxxps://proposals-ultra-awesome-site-secure-vie[.]webflow[.]io/
hxxps://invitation-for-proposal-submission-m4wg[.]w-hne4jz[.]workers[.]dev/
hxxps://super-dash-787[.]martin1jones890[.]workers[.]dev/eal
hxxps://zen-grid-6142[.]marcoodom41[.]workers[.]dev/eal
hxxps://zen-grid-6142[.]marcoodom41[.]workers[.]dev/create
blob:hxxps://invitation-for-proposal-submission-m4wg[.]w-hne4jz[.]workers[.]dev/<uuid>Webflow first stage
After the recipient clicked the View Dashboard button in the email, the first browser-visible stage loaded from a Webflow subdomain: hxxps://proposals-ultra-awesome-site-secure-vie[.]webflow[.]io/.
This was not only a page that looked like Webflow. The URL itself was under webflow[.]io, the page displayed the visible Webflow badge, and the browser loaded standard Webflow assets from Webflow and website-files infrastructure. This confirms Webflow was used as the first-stage hosting layer.
The Webflow page was intentionally simple. It displayed an invitation to a bid project, told the victim that two PDF documents were ready for review, and presented an Access Secure Project button. Its purpose was not to collect credentials directly. Its role was to add a trusted SaaS-hosted transition point between the email and the attacker-controlled Workers stage.
When the victim clicked "Access Secure Project", the flow left Webflow and moved into the Cloudflare Workers infrastructure that handled the fake verification gates and the later Google sign-in experience.
Figure 2: First-stage Webflow page after cropping the browser address bar.
Cloudflare Workers verification gates
Clicking the Webflow Access Secure Project button moved the victim to Cloudflare Workers infrastructure, visible through the workers[.]dev hostnames. workers[.]dev is Cloudflare's default deployment domain for Workers, which makes it attractive for disposable, serverless phishing stages.
The campaign then presented a custom press-and-hold verification page followed by a Cloudflare-themed verification page. This sequence accomplishes two things: it normalizes friction before the Google login page, and it filters automated scanners that do not execute the full browser flow.
The verification pages are part of the conversion funnel. They make the eventual Google sign-in page feel like the result of a security check rather than a suspicious redirect.
Figure 3a: Custom press-and-hold verification check served from the Workers stage.
Figure 3b: Cloudflare-styled verification page completing the two-layer gate.
Current campaign: blob-hosted Google sign-in page
In the current June 2026 deployment, after verification, the browser navigated to a blob URL whose creator origin was the Workers domain. The final page displayed a Google sign-in interface but was not reachable as a normal hosted HTML document. It existed as a browser-created object URL.
This blob-hosted sign-in behavior should be treated as a feature of the latest observed deployment. The stable framework markers are the rare key, rawHash/zrawHazh lineage, admin telemetry, WebSocket control, and browser-mediated frame transport. In this campaign, the final credential collection stage is separated from conventional URL inspection.
blob:hxxps://invitation-for-proposal-submission-m4wg[.]w-hne4jz[.]workers[.]dev/<uuid>- Target provider in decoded configuration:
hxxps://accounts[.]google[.]com - Post-auth landing page:
hxxps://drive[.]google[.]com/file/d/10w3vSkoxSbwPcGRuJcTe5_JBpPZ-n4d-/view?usp=sharing
Figure 4: Final Google sign-in view, delivered through a blob URL. Browser address bar cropped.
Decoded campaign configuration
The current JavaScript contained embedded cached configuration values. The _cachedU value decrypted to a server URL, provider list, and campaign reference. The _cachedH value decoded into the target provider, lure title, Google Drive handoff, and persistence flag.
The exported admin metadata later confirmed these decoded values at runtime. This is stronger than a static-only decode because the live page reported which server and WebSocket endpoint it was using.
Decoded _cachedU:
|10|hxxps://sage[.]bucking[.]top|["_known_providers_and_all_links", "dg, Messi", "constricted", "hxxps://accounts[.]google[.]com", "Tags: nations"]|7649679112Decoded _cachedH / rawHash:
ref_id: 7649679112
mode_url: hxxps://accounts[.]google[.]com
domain_: Invitation for Proposal Submission
landingPage_: hxxps://drive[.]google[.]com/file/d/10w3vSkoxSbwPcGRuJcTe5_JBpPZ-n4d-/view?usp=sharing
use_persistent: trueHidden admin metadata log and C2 routing
A secret key combination exposed an ADMIN METADATA LOG inside the same blob-delivered page that displayed the Google sign-in form. The victim-facing page contains hidden operator/debug instrumentation that records campaign state, decrypted configuration, C2 routing, WebSocket endpoint selection, and victim environment metadata.
Two runtime captures show that the server URL can vary by session or configuration. One exported metadata file reported hxxps://sage[.]bucking[.]top and wss://sage[.]bucking[.]top/ws. The later admin-panel capture showed hxxps://gold[.]sommiedo[.]site and wss://gold[.]sommiedo[.]site/ws. Both captures included shadow_url_used: true, which suggests the framework supports shadow routing, C2 indirection, or per-session endpoint selection.
The metadata fields include platform, GPU, Windows version, user agent, color scheme, locale, timezone, IP-derived geography, accessed_inbox, use_persistent, and pchromium. The field accessed_inbox is especially interesting because it suggests the framework tracks whether the session reached mailbox content or a mail-related state.
Figure 5: Hidden admin metadata panel inside the blob-hosted Google sign-in page. Personal IP/location fields are redacted.
Runtime-confirmed metadata fields:
ref_id: 7649679112
mode: 3
mode_url: hxxps://accounts[.]google[.]com
email: [email protected]
accessed_inbox: false
server_url: hxxps://sage[.]bucking[.]top or hxxps://gold[.]sommiedo[.]site
websocket_url: wss://sage[.]bucking[.]top/ws or wss://gold[.]sommiedo[.]site/ws
shadow_url_used: true
landingPage_: hxxps://drive[.]google[.]com/file/d/10w3vSkoxSbwPcGRuJcTe5_JBpPZ-n4d-/view?usp=sharingStatic code artifacts and AI-like development style
The JavaScript lineage contains consistent internal naming and unusual developer-facing artifacts. The key _SuperBigNyasher47_ appears across all three samples. The same code family also carries zrawHazh, dimensions_admin, dimensions_admin_client, keyInputChange, EnterBTN, first_frame_received, [email protected], and ADMIN METADATA LOG.
The files also contain emoji-labeled debug statements and very explanatory comments, including strings such as Decrypted Email, Is Admin, Server URL, Allowed Links, Admin Password, Devtools size detection, and Debugger trap. This does not prove the framework was generated by AI, but the style is consistent with AI-assisted development or rapid prototyping. More importantly, these strings are stable code-lineage markers that persist across the December 2025, February 2026, and current samples.
Figure 6a: Commented-out console.log lines with distinct emoji icons per field. A stylistic fingerprint consistent across the framework's lineage.
Figure 6b: Current script showing the hardcoded Nyasher key and embedded cached configuration values.
Connection to prior public reporting
DarkMarc published a February 7, 2026 technical analysis of a similar Google-focused phishing operation targeting video production agencies. There is a strong technical correlation because it documents the same rare key and several of the same runtime concepts.
DarkMarc documented a video-production-agency lure with Framer and PDF delivery. The current campaign uses a Webflow-hosted bid/proposal lure against a U.S. property-business target. It also shows a later implementation change from image/avif frame handling to image/webp, plus the unintentional second-verification pattern created by a real Gmail victim forwarding the lure after failing to access the document.
Nyasher framework evolution: AVIF to WebP
Figure 7: Nyasher evolution. The rare key persists while the frame transport changes from AVIF in the older samples to WebP in the current deployment.
| Evidence date | Sample SHA256 | Configuration model | Frame transport | Notable evolution |
|---|---|---|---|---|
| Dec 3, 2025 | 36931f545f5d9dae91eaa8b3c1ed2c8260324b25a24ab800a73d8526923a52cc | Default shell: `\ | 00\ | \ |
| Feb 27, 2026 | b2fbcaaa9d0cf6a1c36b802c6c95fa510a43b45a9e3c625ae040fdb7d2d66d77 | u/h parameters from URL | AVIF | Adds detectGPU, pmanager, ipinfo lookup, window.__origHref handling, and explanatory anti-debug comments. C2 likely lived in original URL parameters. |
| Jun 2026 | 6338a3f599bc830a0454430f419d6ab977de9d1a0088acad785f4d2157e9e1a7 | Embedded cached U/H | WebP | Property-business lure, Webflow first stage, Workers verification chain, embedded C2/config, AES-GCM WebSocket encryption, blob-hosted Google sign-in in this deployment, and visible admin metadata log. |
IOC table
The table separates where each indicator came from. Personal Gmail addresses, recipient identifiers, and customer-specific details are intentionally redacted for publication.
| Indicator | Type | Source / significance |
|---|---|---|
proposals-ultra-awesome-site-secure-vie[.]webflow[.]io | Domain | Initial Webflow landing page from email CTA and browser trace |
url[.]us[.]m[.]mimecastprotect[.]com | Domain | URL wrapping layer seen in the delivered email |
invitation-for-proposal-submission-m4wg[.]w-hne4jz[.]workers[.]dev | Domain | Primary Cloudflare Workers stage and blob page origin |
super-dash-787[.]martin1jones890[.]workers[.]dev | Domain/path | Workers stage observed after clicking Access Secure Project, path /eal |
zen-grid-6142[.]marcoodom41[.]workers[.]dev | Domain/path | Workers stage observed during verification and payload creation, paths /eal and /create |
sage[.]bucking[.]top | C2 domain | Decoded from current script and confirmed in one runtime admin metadata export |
wss://sage[.]bucking[.]top/ws | WebSocket C2 | Runtime-confirmed WebSocket endpoint in metadata export |
gold[.]sommiedo[.]site | C2 domain | Observed in network traffic and later admin-panel runtime capture |
wss://gold[.]sommiedo[.]site/ws | WebSocket C2 | Observed WebSocket endpoint and later admin-panel capture |
drive[.]google[.]com/file/d/10w3vSkoxSbwPcGRuJcTe5_JBpPZ-n4d- | Post-auth handoff | Decoded from rawHash/cachedH as the landing page after authentication |
_SuperBigNyasher47_ | Code string | Rare hardcoded XOR key used to name the framework |
zrawHazh | Code string | Tracking value sent in admin/dimensions messages |
ADMIN METADATA LOG | Code/UI string | Hidden runtime metadata panel inside victim page |
no-email-mode@email[.]com | Code/default value | Fallback email mode when no victim email is supplied |
36931f545f5d9dae91eaa8b3c1ed2c8260324b25a24ab800a73d8526923a52cc | SHA256 | Dec 3, 2025 VT sample containing Nyasher key and admin framework |
b2fbcaaa9d0cf6a1c36b802c6c95fa510a43b45a9e3c625ae040fdb7d2d66d77 | SHA256 | Feb 27, 2026 VT sample with parameter-driven configuration |
6338a3f599bc830a0454430f419d6ab977de9d1a0088acad785f4d2157e9e1a7 | SHA256 | Current campaign JavaScript saved from Chrome DevTools |
Why ZeroBEC helps
This campaign illustrates why link reputation, authentication results, and static gateway scoring are not enough. The final message did not look like a classic bulk phish. It was a real forward from a real account, wrapped around a business process that made sense for the target vertical.
ZeroBEC detected the risk because the message carried relationship and intent anomalies: a non-established Gmail sender, a minimal help-request forward, an inner bid/proposal lure, undisclosed recipients, a SaaS-hosted link unrelated to the sender or recipient, a call-to-action button, and a mismatch between the business context and the link infrastructure.
The malicious chain was also staged so that no single first-hop URL fully represented the attack. The Webflow page was only the entry point. The Google credential collection page appeared later as a blob object created in the browser. The C2 selection and WebSocket routing were only visible after runtime execution. A control that evaluates only the visible URL or only email authentication misses the actual risk.
Conclusion
Nyasher is best understood as a live, browser-mediated Google account takeover framework rather than a static credential page. Its stable code markers, hidden admin panel, WebSocket routing, victim fingerprinting, frame-based interaction model, and Google Drive handoff point to an actively maintained framework that has been present in public repositories since at least December 2025. The current deployment adds a blob-hosted Google sign-in view and WebP frame handling, while earlier samples used AVIF.
The current case shows the framework moving into a property-business bid/proposal workflow. That vertical fit matters. Property and vendor-heavy businesses regularly exchange external documents, project bids, scopes, and deadlines. When a first victim forwards the lure after failing to open the document, the attacker gains something more valuable than a polished template: human validation.
The technical lesson is that the phishing page is no longer the whole story. The social chain, runtime execution, and hidden operator telemetry are part of the attack surface. Stopping this class of campaign requires context-aware detection that can connect sender history, conversation flow, link mismatch, cloud-hosted staging, and business-process abuse before the victim is pushed into the live credential workflow.