In recent weeks, a highly organized phishing campaign has surfaced, characterized by its use of legitimate Google infrastructure to bypass standard security filters. I have identified more than 25 distinct phishing emails targeting a single account, all of which ultimately direct users to a specific URL:
The URL in question is hosted on Google Cloud Storage (GCS). To the average user or basic email security gateway, the domain googleapis.com appears trustworthy because it is a legitimate Google-owned domain used for hosting cloud assets.
In this specific exploit:
The Bucket: whilewait is a unique storage container created by the attacker within a Google Cloud project.
The Payload: comessuccess.html is a script-heavy file designed to act as a “gatekeeper” or “redirector“.
By hosting the initial link on Google’s servers, the attackers ensure the email passes authentication checks like SPF and DKIM. Once a user clicks, the HTML file on Google’s server silently redirects the browser to a third-party malicious site, often used for credit card harvesting or malware distribution.
Diversity of Social Engineering Tactics
More than 25 emails captured in this study demonstrate an exhaustive range of “hooks” designed to appeal to different psychological triggers. While the underlying technical path is identical, the presentation varies wildly:
Security Fears: Alerts regarding a “Critical Threat Detected” or “Antivirus Protection Expired“.
Retail Incentives: Reward offers from brands such as Lowe’s, T-Mobile, and State Farm.
Lifestyle & Health: Promotions for “Homemade Recipes“, “Harry & David Gift Baskets“, “Blood Sugar Watch” or “Neuropathy Pain” solutions.
Despite these different themes, the goal remains consistent, drive traffic to the whilewait storage bucket to initiate a fraudulent transaction or steal sensitive information.
The Final Objective: Credit Card Harvesting
Following the redirect from the Google Cloud link, users are typically presented with a “shipping fee” or “service charge” for their reward or security update. This is the Credit Card (CC) Harvesting phase. Any payment information entered on these secondary sites is captured by the attackers, leading to immediate financial fraud. This specific lure mirrors the tactics identified in recent threat research (link given below), where scareware emails are increasingly used to push users toward these fraudulent “subscription” or “service” portals.
To defend against this specific style of “Trusted-Platform Phishing“, the following steps are recommended:
Inspect the Redirect Path: Be aware that a link starting with storage.googleapis.com is not an official communication from Google, it is a file hosted by a third party using Google’s tools.
Verify Sender Metadata: Even if the link looks legitimate, the “From” address in these 25 plus samples often consists of unrelated, randomized alphanumeric strings.
Submit Infrastructure Abuse Reports: These campaigns rely on the longevity of the storage bucket. Reporting the whilewaitbucket to the Google Cloud Abuse Team is the most effective way to dismantle the entire 25 plus email network at once.
I recently came across a phishing campaign impersonating the Yoroi Desktop Wallet, targeting cryptocurrency users with what looked like a legitimate upgrade.
The email itself was clean and well-written. It talked about improved security, hardware wallet support, and even AI-based scam detection. Nothing immediately stood out as suspicious. The landing page looked polished too, with proper branding and a familiar layout.
The Setup
The phishing email redirects users to a domain:
hxxps://download[.]v1desktop-yoroiwallet[.]com/
the domain was recently registered (Feb 2026), yet it was already indexed on Google, meaning users could also land on it via search results, not just email.
The Download That Isn’t a Wallet
The site promotes a “Yoroi Desktop” download, but instead of hosting anything legitimate, it redirects to a file-sharing service and delivers an MSI file:
Once executed, the system is quietly enrolled into a remote access setup. There’s no obvious warning, no suspicious pop-ups, just a legitimate tool being used in the wrong way.
Looking at the configuration reveals what’s happening behind the scenes:
This isn’t random. It shows the machine is being registered into a pre-configured remote access fleet, controlled by whoever owns that GoTo Resolve tenant.
At this point, the attacker doesn’t need to trick the user anymore. They already have what they need, persistent access to the device.
One thing that stands out across both campaigns is how the payload is delivered.
In all cases, the final MSI files are not hosted directly on the phishing domains. Instead, the sites redirect users to gofile[.]io, a legitimate file-sharing service, to download the installer.
This adds another layer of evasion. Hosting the MSI on a legitimate service like gofile makes it harder to block and also reduces suspicion from users, since the download doesn’t come directly from the phishing domain.
While digging further into this, I also noticed that the MSI files are hosted across multiple gofile storage endpoints such as:
store-na-phx-[1/4/5].gofile.io/download/direct/
Changing the server index (for example, 1, 4, or 5) reveals similar download paths hosting MSI files that follow the same theme, crypto wallet installers that actually deploy RMM tools.
Combined with the use of legitimate tools like GoTo Resolve (LogMeIn) and delivery through trusted file-sharing services, the overall chain appears clean on the surface but ultimately leads to full remote access.
I recently came across a message containing the following link:
hxxps://yandex[.]com/poll/PdZ7vgekGrNakuXZcpiB6b
At first, it didn’t look suspicious. It opened as a simple survey/poll page. But as I continued, the flow quickly shifted into a crypto reward scenario, claiming that I was eligible to receive a Bitcoin compensation payment.
And as expected with these kinds of lures, there’s a catch.
Before you can withdraw the funds, you’re asked to pay a small “commission” fee.
Full Scam Walkthrough (Video)
This gives a better idea of how smoothly the entire flow is designed to push the victim toward payment.
Infection / Lure flow
1.Initial Entry (Survey / Poll Page)
The flow starts with a Yandex poll link, which works as a kind of entry point.
This step likely serves multiple purposes. It helps make the interaction feel legitimate since it’s hosted on a known platform. It may also act as a basic filter to distinguish real users from automated systems. More importantly, it sets up the next stage of redirection.
2.Fake Bitcoin Compensation Page
After interacting with the poll, I was redirected to a page that looks like it belongs to a Bitcoin related service.
The page presents a sense of urgency by claiming that a new transaction of 0.943 BTC has been created and already marked as approved. It then introduces pressure by warning the user to withdraw the funds within 24 hours, a tactic commonly used to rush victims into taking immediate action without verifying the legitimacy of the claim.
This is where the emotional hook kicks in. Seeing a large amount like 0.943 BTC immediately grabs attention.
3. Social Engineering via Chat Assistant
Then a chat window appears, introducing a support agent.
The message explains that to complete the payment process, you need to register your profile in a compensation system. It sounds procedural and official, which is exactly the intention.
Shortly after, the real objective becomes clear.
You are asked to:
Pay $67 for legal profile registration services
4.Payment Gateway
Clicking the payment link takes you to a dedicated payment page.
Here, everything is carefully designed to appear legitimate and trustworthy. The page shows a specific payment amount of $67, provides a Bitcoin payment option via a QR code, and displays a wallet address to reinforce authenticity. On top of that, a countdown timer indicating invoice expiry adds urgency, subtly pressuring the user to complete the transaction quickly without questioning its validity.
The design mimics real crypto payment processors, which helps reduce suspicion.
The flow is quite structured and intentional.
It starts by engaging the user through a trusted platform, which lowers initial suspicion. Then it introduces a high-value crypto reward, creating excitement. A chat assistant adds a layer of interaction, making the process feel guided and legitimate.
Finally, the user is asked to pay a relatively small fee to unlock a much larger reward.
This is essentially an advance fee scam, adapted to fit into a crypto themed narrative.
Additional Variant Observed (Octa-Themed Flow)
While analyzing further, I encountered another link that follows the same backend scam logic, but with a different initial presentation.
The flow eventually leads to the same outcome, pay a commission to withdraw BTC.
Variant Walkthrough (Video)
1. Fake Account / Transfer Notification
This version starts with a fake dashboard impersonating Octa.
The page further attempts to lure users by displaying a message stating “You have a new money transfer”, along with a balance of 1.824 BTC. This presentation is crafted to create excitement and curiosity, making it seem like the user has unexpectedly received funds, while subtly encouraging them to engage with the page and follow the next steps without questioning its authenticity.
2. Fake Login & Temporary Password Flow
The user is asked to log in using a temporary password.
This step closely mimics real authentication flows to build trust and credibility. It displays a temporary password, includes an OTP style input field, and reinforces legitimacy with messaging like “Do not share this password!”. These familiar elements are designed to make the process feel secure and authentic, lowering suspicion while guiding the user further into the flow.
3. Transaction Dashboard
After logging in, the user is presented with a dashboard that appears highly convincing, displaying details such as the sender labeled as Octa, a balance of 1.824 BTC, and a status marked as paid. The layout, wording, and transaction details are all carefully crafted to create a sense of authenticity, making the entire interface look legitimate and encouraging the user to trust the process without suspicion.
4. Commission Justification
Before allowing any withdrawal, the platform introduces an additional requirement in the form of a commission fee of around $69, accompanied by an explanation about wallet limits and transfer rules. This step is designed to appear reasonable and procedural, giving the impression that the fee is a standard part of the process while subtly nudging the user to make a payment in order to access the supposed funds.
5. Payment Page
Just like the initial flow, the process ultimately leads to a familiar payment stage, presenting a Bitcoin payment request along with a QR code and a wallet address for convenience. An expiry timer is also displayed to create urgency, pressuring the user to act quickly and complete the payment without taking the time to question the legitimacy of the request.
What stands out is how the attackers reuse the same core scam but change the entry point.
I also looked into related activity on URLScan and found similar lures being actively scanned in the last couple of days, which indicates that this is not a one off campaign but something currently active and evolving.
Indicators of Compromise (IOCs)
URLs
Along with the observed infrastructure, I checked domain registration timelines, which further indicate that this campaign is relatively recent and actively being used.
Recent threat intelligence analysis uncovered a login surface associated with the Kraken darknet ecosystem that is simultaneously exposed through traditional clearnet domains and Tor onion services.
The CAPTCHA workflow, authentication layout, and visual structure appear nearly identical across both environments, indicating a shared deployment rather than independent mirrors.
Closer inspection of client side behavior, background network requests, embedded routing logic, and indexed clearnet infrastructure reveals that the public web instance behaves not as a standalone marketplace, but as a gateway layer positioned in front of onion hosted backend services.
Clearnet Authentication Flow and Backend Coordination
Credential submission from the clearnet interface occurs through a local POST endpoint (entry/login), meaning authentication data is first delivered to the clearnet server rather than directly to an onion server.
At the same time, the page issues a background request to an internal routing component (modules/onion_servers/take_server.php). This behavior indicates that session binding or mirror selection takes place before authentication completes, a pattern consistent with broker like access layers used to shield hidden backend infrastructure.
Client side scripting implements hashing and cookie persistence mechanisms that coordinate session state and routing identifiers across requests, further reinforcing the interpretation that the clearnet layer performs pre-authentication orchestration rather than simple credential validation.
Session Routing and Onion Backend Telemetry via Cookies
Captured HTTP cookies from the clearnet authentication workflow expose additional internal routing and infrastructure metadata that is not visible in the user interface.
Observed cookie values include:
Technical Interpretation
The structure and naming of these cookie parameters reveal multiple layers of backend coordination:
Tor aware routing indicators: Fields such as tor_scheme_id, tor_port, and onion_server_id strongly suggest that the clearnet gateway is dynamically binding user sessions to specific hidden service endpoints.
Session orchestration across proxy layers: Identifiers like proxy_cf_session_id, remote_route, and remote_server_id indicate traversal through intermediary infrastructure, likely used for load distribution, resilience, or service isolation.
Referral and discovery tracking: The presence of a clearnet referrer (kraken106[.]com) demonstrates linkage between publicly reachable discovery domains and backend onion infrastructure.
Taken together, these cookie artifacts offer clear, practical evidence of how the underlying flow operates. They suggest that authentication is first handled through clearnet session brokers, that individual user sessions are then tied to specific onion based backends, and that routing decisions happen even before credential validation is fully completed.
Embedded Onion Infrastructure and Clipboard Manipulation
Inspection of the clearnet HTML reveals embedded onion addresses referenced directly inside client side logic.
JavaScript within the page intercepts clipboard copy events and transparently replaces known onion domains with alternate mirrors. This behavior is consistent with operational techniques used to maintain mirror redundancy, traffic steering, and controlled user routing inside darknet service ecosystems.
The script attaches a copy event listener to the document and inspects any selected text before it reaches the system clipboard.
If the copied content contains a known onion hostname, the script replaces it with a different hidden service address mapped inside an internal dictionary before writing the modified value to the clipboard.
Public Indexing of Gateway Domains
Multiple clearnet domains serving the CAPTCHA gateway are indexed by public search engines, making the entry surface discoverable outside Tor.
Search results indicate that these domains primarily act as entry points within a broader ecosystem. They serve as accessibility bridges that help new users reach otherwise hidden services, function as discovery surfaces that introduce users to marketplace environments, and operate as routing frontends that ultimately direct traffic toward underlying onion based infrastructure.
Public indexing fundamentally alters the traditional hidden service threat model by exposing the initial access layer to open web reconnaissance and defensive monitoring.
Discovery of Distributed CAPTCHA Gateway Infrastructure
URLScan telemetry reveals a broad cluster of clearnet domains hosting identical CAPTCHA gated login interfaces tied to the same backend ecosystem.
Observed infrastructure includes:
Domain
Registered On
captcha[.]krad2[.]cc
2025-11-05
captcha[.]kraba5[.]cc
2025-12-15
captcha[.]kraba5[.]at
NA
captcha[.]kra52[.]at
NA
captcha[.]kra51[.]cc
2025-09-26
captcha[.]krafb5[.]at
NA
captcha[.]krafb5[.]cc
2025-12-31
captcha[.]krabi5[.]at
NA
captcha[.]krabi5[.]cc
2025-12-23
captcha[.]krabi4[.]at
NA
captcha[.]krabi4[.]cc
2025-12-23
captcha[.]krabi3[.]at
NA
captcha[.]krabi3[.]cc
2025-12-23
captcha[.]krafb2[.]cc
2025-12-31
captcha[.]krad2[.]at
NA
captcha[.]krabi2[.]cc
2025-12-23
captcha[.]krabi2[.]at
NA
kra46l[.]cc
2025-10-27
kra46l[.]at
NA
krak45[.]cc
2024-12-21
krak45[.]at
NA
kra45l[.]cc
2025-10-27
kra45l[.]at
NA
kra44l[.]cc
2025-10-27
kra44l[.]at
NA
kcra43[.]cc
2025-07-04
kcra43[.]at
NA
kraken106[.]com
Structural Observations
The domain cluster demonstrates
systematic naming variation
numeric rotation patterns
mirrored TLD deployment across .cc and .at
consistent captcha. subdomain segmentation
These characteristics indicate intentional large scale provisioning designed for redundancy and survivability rather than opportunistic reuse.
Architectural Interpretation
Correlation of routing behavior, session-binding logic, clipboard manipulation, public indexing, and distributed domain infrastructure produces a coherent architectural model.
The service appears to follow a layered access model in which users first interact with a clearnet gateway that assigns routing paths and session identifiers. From there, the core authentication processes and marketplace logic are handled behind onion-based services, while a network of mirrors helps maintain availability, redundancy, and overall resilience.
Relation to Kraken Marketplace Evolution
Open source reporting describes Kraken as a major successor within the Russian language darknet ecosystem, rapidly expanding after prior market disruptions and adopting infrastructure focused on resilience and accessibility.
Rather than relying solely on hidden services, the platform appears to deploy clearnet discovery and routing layers that ultimately funnel traffic toward onion based backend systems.
This hybrid exposure model represents a notable shift in darknet operational design, blending anonymity with controlled public reach.
Detection Status Across Security Telemetry
At the time of analysis, several of the identified clearnet gateway domains remained unflagged by VirusTotal, while a subset had already begun receiving malicious or phishing classifications from individual security vendors.
Indicators of Compromise (IOC)
Clearnet CAPTCHA Gateway Domains listed above. Here is URLScan.io results for searched domains.
Network Endpoints
Authentication Submission
POST /entry/login
Purpose: Credential submission from clearnet login interface prior to backend routing.
Onion Routing Coordination
GET /modules/onion_servers/take_server.php
Purpose: Background request used for mirror selection, session binding, and backend routing orchestration.
Detection Considerations
Repeated access to CAPTCHA-prefixed rotating domains
HTTP requests to:
/entry/login
/modules/onion_servers/take_server.php
Presence of Tor-routing cookie parameters in web telemetry
The clearnet CAPTCHA protected login page that sits in front of the onion backend naturally raises questions about how much it can be trusted with user credentials. The visual similarity between the clearnet and onion interfaces, along with the session binding and routing behavior observed in the background, could indicate a shared and intentionally designed gateway rather than a simple phishing copy. At the same time, this clearnet layer acts as a single interception point where credentials are submitted before any interaction with hidden services occurs, which makes it an ideal location for logging, redirection, or credential collection. The use of rotating gateway domains, mixed security vendor detections, and client side traffic steering logic adds further uncertainty and makes it difficult to determine intent from surface analysis alone. Because of this, the clearnet entry point should be treated as inherently high risk from a defensive perspective, regardless of whether it ultimately connects to genuine onion infrastructure.
I identified a long-running redirect infrastructure abusing Cloudflare Pages (pages.dev) to host benign-looking SEO articles (for example, celebrity “net worth” blogs or gaming help content) that display a forced “Continue reading / Continue Read” pop-up shortly after page load.
Once the user clicks the button, the browser is redirected into downstream infrastructure that may lead to:
More than 250 URLs were observed using the same visual template and behavior, and historical evidence from URLScan shows activity persisting for 5 months, suggesting deliberate reputation building and SEO indexing.
Initial Infection Vector: Benign SEO Content on Cloudflare Pages
The landing pages appear as normal blog articles but automatically display a modal message:
“Continue reading by clicking the button below.”
This design ensures the redirect is user-initiated, helping bypass automated scanners and reputation systems.
Common characteristics
Hosted on: *.pages.dev
SEO-style article content
Modal overlay appears a few seconds after page load
Redirect only occurs after button click
Scale, Persistence, and Search Engine Exposure
Across the analyzed samples, more than 250 distinct URLs were identified showing identical UI and UX behavior, indicating the use of the same phishing template or kit deployed across different article topics. The activity has remained visible for approximately five months based on URLScan observations, suggesting persistence rather than short-lived campaigns. Additionally, some of these pages have been indexed in Google search results, significantly increasing the likelihood of exposure to real users and amplifying the overall risk posed by the operation.
Redirect Logic (Click-Gated Pre-Lander Behavior)
The redirect mechanism is implemented using delayed modal display and a click-triggered JavaScript redirect.
Key Observation
Across many different pages, most samples use the same redirect destination inside window.open()
This is important because it shows that the pages.dev sites are probably not standalone phishing pages created one by one. Instead, they appear to work more like traffic pre-landers that quietly direct visitors to a shared backend system. The key= parameter in the URL also looks intentional rather than random, and it is likely being used for tracking or routing within the campaign, possibly as a campaign ID, an affiliate tracking token, or even a value used to classify or group potential victims.
In short:
Multiple benign-looking SEO pages are acting as entry points into a centralized redirect infrastructure.
likely serves as a Traffic Distribution System (TDS) decision node, responsible for:
Geo/IP filtering
Proxy/VPN detection
User-agent validation
Campaign routing
Conditional payload delivery
Simplified Kill Chain
Anti-Analysis Behavior: Proxy / VPN Detection
During testing, downstream pages performed VPN/Proxy checks.
If anonymity was detected, the page displayed:
“Anonymous Proxy detected.”
and stopped further redirection.
Security Impact
From a security perspective, this behavior is particularly concerning because it makes deeper analysis much harder. By blocking or redirecting automated environments, it can prevent sandboxes and researchers from ever reaching the real payload, which in turn leads to very low antivirus detection rates. As a result, automated scans may incorrectly appear clean, creating a false sense of safety even though malicious activity may still be present behind the scenes.
Observed Downstream Outcomes
1) Fake File Download Funnel – S3 ZIP Payload
One redirect path showed a “Your File Download Is Ready” page, leading to:
Final payload stored on Amazon S3 (SetupFile-xxxx.zip)
2) Fake Browser Diagnostics – Opera Download Lure
Another branch displayed a fake compatibility/diagnostics score (e.g., 40/100) urging users to:
“Download Opera Browser”
This pattern feels very similar to the affiliate-driven browser installation funnels often seen in malvertising campaigns, where traffic is quietly redirected through multiple steps before reaching the final payload or monetization stage.
3) QR Code / Fake CAPTCHA Social Engineering
Some redirects presented:
“Prove you are not a robot”
QR code requiring mobile scan
Flows like this are commonly designed to move victims step by step toward the attacker’s real objective. In many cases, the final destination can be a phishing page that steals credentials, a subscription fraud scheme that silently charges the user, or even the delivery of mobile malware disguised as a legitimate download.
Payload Example and Low Detection Context
One observed executable sample (adware/PUP classification):
What makes this particularly notable is that the overall setup closely matches how modern malvertising Traffic Distribution Systems (TDS) typically operate. The infrastructure shows several familiar patterns, such as abusing a trusted hosting platform like Cloudflare Pages, allowing pages to be indexed by search engines to attract organic traffic, and using click-gated redirects to evade automated analysis. Behind the scenes, everything appears to funnel through a centralized redirect endpoint where the final payload can be delivered conditionally, depending on the visitor. This kind of design also supports multiple monetization paths rather than a single outcome. Taken together, it suggests we are not looking at just one phishing kit, but a broader shared redirect ecosystem designed to distribute traffic at scale.
This campaign highlights how attackers carefully blend several techniques to stay under the radar and keep their operation running for long periods. By abusing legitimate hosting services, leveraging SEO poisoning to attract real users, using click-triggered redirects to avoid automated detection, and routing visitors through a centralized traffic system, they create a stealthy and resilient infrastructure capable of quietly delivering malware or other malicious outcomes over time
