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.
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.
Over the past few weeks, I have been tracking a credential harvesting campaign that repeatedly abuses newly registered *.contractors domains to deliver Gmail and Microsoft 365/Outlook phishing pages.
While the social engineering lures vary including ICANN email verification, document sharing, and account security prompts. The underlying infrastructure, tooling, and execution flow remain consistent
Based on analysis of the phishing HTML, JavaScript, and runtime behavior, this activity can be attributed with high confidence to the Tycoon 2FA phishing kit, based on its distinctive MFA aware execution flow, client side obfuscation, and anti-analysis tradecraft.
This attribution is supported by distinctive Tycoon specific client side tradecraft, including MFA aware flows, advanced anti-analysis logic, and encrypted runtime loaders, as shown below.
Analysis of the extracted HTML and JavaScript reveals multiple Tycoon 2FA specific behaviors that go beyond generic phishing kits.
Anti-Analysis & Sandbox Evasion Logic
The phishing pages actively detect analysis environments and developer tools, immediately terminating execution or redirecting the user if detected:
Additional protections disable common inspection techniques:
This multi-layered anti-analysis logic is a well known characteristic of Tycoon 2FA deployments, commonly observed across multiple campaigns leveraging this phishing-as-a-service (PhaaS) framework.
Runtime Debugger Detection & Forced Redirect
The kit also employs debugger timing detection to identify active inspection and force redirection:
This technique is specifically used by Tycoon based phishing frameworks to evade dynamic analysis and sandbox detonation.
ICANN Email Verification Lure
One of the more recent samples impersonates ICANN (Internet Corporation for Assigned Names and Numbers) and claims that the recipient’s email address must be verified to avoid domain-related disruption.
The email states that:
The recipient’s email is listed as the owner contact for a domain
The address is allegedly unverified or inactive
Failure to verify may result in email suspension
A verification link is provided, styled to appear ICANN-related. However, hovering over the link reveals that it actually points to attacker controlled infrastructure hosted outside of any legitimate ICANN or registrar domain. In this case, the observed link resolved to
The URL embeds the recipient’s email address directly in the path, a common personalization technique used in targeted phishing campaigns to increase credibility and successful credential submission.
Redirection Flow: CAPTCHA as an Anti-Analysis Gate
Clicking the verification link does not immediately present a login page.
Instead, victims are routed through a fake CAPTCHA / “confirm you’re human” page, which serves as a deliberate execution delay.
This delay is important for two reasons:
Automated sandbox services (e.g., URLScan) often complete scanning before the CAPTCHA stage is reached, meaning the actual phishing payload is never rendered during automated analysis.
User interaction is required to proceed, filtering out non-human traffic and reducing detection rates.
Final Payload: Gmail & Microsoft 365 Tycoon 2FA Lures
After CAPTCHA completion, victims are redirected to high-fidelity Gmail or Microsoft 365 / Outlook login pages, depending on the campaign variant.
Observed behaviors include:
Accurate UI and branding replication
Email address prefilled or dynamically referenced
Transition into multi-step authentication flows
MFA approval interception and credential capture
Despite branding differences, both lures share identical loader logic, obfuscation patterns, and runtime behavior, confirming they are part of the same Tycoon 2FA campaign.
Infrastructure Reuse: *.contractors Domains
Across all observed samples, the campaign consistently abuses freshly registered .contractors domains, often using randomized subdomains and long URL paths.
Examples observed include:
Outlook
hxxps://datacenter.lonaihoo.contractors/i!2zDbFPEvdm/
hxxps://pytorch.hithomu.contractors/Hik3GWNtRtmoaf@Ul5FNuB3/$bmVzZS5ndW5lckBlZ29uemVobmRlci5jb20=
hxxps://bigbluebutton.seacrevea.contractors/nGPI9ensbX@Y/
hxxps://redoc.kaidaisoo.contractors/Yi@9yUWrVO/
hxxps://firewall.tiostemio.contractors/nu2ATGWco@GZ/
hxxps://pulumi.kaidaisoo.contractors/QBQG4CC@30W/
Common characteristics observed across these campaigns include domains registered very recently, most notably on 07 January 2026 and 14 January 2026 along with randomized URL paths and identifiers designed to evade detection. Victim email addresses are embedded directly within the URLs to personalize lures and enable tracking.
Observed Evasion via Decoy Landing Pages
When analysis is detected or when execution fails, the infrastructure does not return an error page.
Instead, victims or scanners are redirected to to benign decoy landing page templates, including:
Finquick
Flowguide
Desio Copilot
These templates act as decoy content, helping:
Evade automated detection
Reduce suspicion during manual review
Prolong domain lifespan
This fallback behavior has been repeatedly observed in Tycoon-based phishing campaigns.
Campaign Scope: *.contractors Domains Observed on URLScan
During this investigation, I identified multiple .contractors domains associated with this campaign through URLScan submissions and pivoting.
A consolidated list of all observed .contractors domains, along with scan links and timestamps, will be provided below for reference and detection purposes.
This activity represents a coordinated, MFA aware phishing campaign, not isolated incidents.
While this analysis identifies multiple .contractors domains and consistent infrastructure patterns, it is likely that additional domains and variants are in use beyond those documented here. The findings in this post are based on artifacts and infrastructure observed within the scope of URLScan, and the full extent of the campaign may be broader.
Additional Infrastructure Observed
During continued investigation, I identified additional, distinct domains serving the same Microsoft 365 / Outlook Tycoon 2FA lure, indicating broader infrastructure reuse beyond the initially observed .contractors clusters.
These domains exhibit the same execution flow, CAPTCHA gating, MFA-aware login sequence, and post-authentication behavior, confirming they are part of the same phishing operation, rather than unrelated or opportunistic reuse.
The domains and infrastructure documented above represent only a subset of the total activity observed during this investigation. While many additional domains and variants were identified, listing all of them would significantly expand the scope of this post.
For the purposes of this write-up, I will leave the analysis here, focusing on representative samples that clearly demonstrate the campaign’s tradecraft and attribution.
