Introduction

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:

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
  • Clipboard manipulating JavaScript referencing .onion mirrors

Phishing Risk and Gateway Trust Considerations

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.