文章总结： 文档分析了俄语暗网市场克拉肯采用混合访问模型，利用明网网关将流量导向Tor后端。明网登录页在验证前即处理会话路由，通过Cookie遥测和剪贴板操控协调流量，并部署大规模分布式域名。该架构打破了传统暗网威胁模型，将初始访问层暴露于公开监控。文章提供了IOC指标，建议将明网入口视为高风险目标。 综合评分： 86 文章分类： 威胁情报,网络安全,安全运营

克拉肯暗网通过明网网关提供访问

夯磅棱

2026年2月21日 09:32 北京

威胁调查发现，著名的俄语暗网市场克拉肯（Kraken）在其基础设施中采用了一套混合访问模型。其登陆页面不仅通过Tor洋葱服务隐藏，同时也部署在普通的网站上。这些明网页面实际上充当了网关角色，在用户验证前就分配好路由和会话，最终将流量导向隐藏的后端服务。这种做法打破了传统暗网威胁模型，将初始访问层暴露在了公开网络监控之下。

发现明网登录入口

最近的分析发现，与克拉肯暗网生态相关的一个登录页面，同时可以通过传统的明网域名和Tor洋葱服务访问。

两边的验证码流程、认证布局和视觉结构几乎一模一样，这说明它们是同一套部署，而不是独立的镜像网站。

进一步检查客户端行为、后台网络请求和嵌入式路由逻辑会发现，公开的网页实例不是独立的市场，而是放在洋葱服务后端前面的一个网关层。

明网认证流程与后端协调

用户在明网界面提交的凭证，会发往一个本地 POST 接口（/entry/login）。这意味着认证数据是先发送给明网服务器，而不是直接给洋葱服务器。

同时，页面还会在后台向一个内部路由组件发起请求（/modules/onion_servers/take_server.php）。这种行为表明，在认证完成之前，会话绑定或镜像服务器选择就已经发生了。这很像那些用来隐藏后端基础设施的代理或接入层的工作模式。

客户端的脚本实现了哈希和Cookie持久化机制，用来协调跨请求的会话状态和路由标识，这进一步证实了明网层做的是认证前的协调工作，而不只是简单的凭证验证。

会话路由与洋葱后端遥测

从明网认证流程中捕获的HTTP Cookies暴露了更多内部路由和基础设施的元数据，这些东西在用户界面是看不到的。

观察到的Cookie值包括：

• session_id
• tor_scheme_id
• tor_port
• proxy_cf_session_id
• onion_server_id
• remote_route
• remote_server_id
• clear_net_ref: kraken106[.]com

技术解读

这些Cookie参数的结构和命名透露出多层的后端协调机制。

• Tor感知的路由指示器

  ：像tor_scheme_id、tor_port和onion_server_id这样的字段，强烈暗示明网网关正在动态地将用户会话绑定到特定的隐藏服务端点。

• 跨代理层的会话编排

  ：像proxy_cf_session_id、remote_route和remote_server_id这样的标识符，表明流量穿过了中间基础设施，可能是用于负载均衡、弹性或服务隔离。

• 引荐和发现跟踪

  ：明网引荐源（kraken106[.]com）的存在，证明了公开可访问的发现域名与后端洋葱基础设施之间存在关联。

总的来说，这些Cookie痕迹清晰地展示了底层流程是如何运作的。它们说明认证首先通过明网会话代理处理，然后单个用户会话被绑定到特定的基于洋葱的后端，而且路由决策甚至在凭证验证完全完成之前就发生了。

嵌入式洋葱基础设施与剪贴板操控

检查明网HTML代码会发现，洋葱地址直接嵌在客户端逻辑里。

页面中的JavaScript会拦截剪贴板复制事件，并悄悄地把已知的洋葱域名替换成备用的镜像地址。这种行为符合暗网服务生态中用来维持镜像冗余、流量引导和受控用户路由的操作技巧。

脚本给文档附加了一个复制事件监听器，在选中的文本进入系统剪贴板之前检查它。

如果复制的内容包含一个已知的洋葱主机名，脚本会用一个内部字典里映射的不同隐藏服务地址替换它，然后再把修改后的值写入剪贴板。

网关域名的公开索引

提供验证码网关的多个明网域名已经被公开搜索引擎收录，这使得访问入口可以在Tor之外被发现。

搜索结果表明，这些域名主要充当更广泛生态系统中的入口点。它们作为可访问性的桥梁，帮助新用户接触到原本隐藏的服务；作为发现界面，向用户介绍市场环境；并作为路由前端，最终将流量导向底层的洋葱基础设施。

公开索引从根本上改变了传统的隐藏服务威胁模型，它将初始访问层暴露在了开放的网页侦察和防御监控之下。

发现分布式验证码网关基础设施

URLScan（https://urlscan.io/search/#hash%3A9fa0fd5b129cc1062500cf31c6be66f6617d829c3e4ccf0dc7cdba46f992632e）的遥测数据揭示了一大批明网域名，它们都承载着相同的、验证码保护的登录界面，并且连接到同一个后端生态系统。

观察到的基础设施包括：

| 域名 | 注册日期 | | — | — | | captcha[.]krad2[.]cc | 2025-11-05 | | captcha[.]kraba5[.]cc | 2025-12-15 | | captcha[.]kraba5[.]at | 未提供 | | captcha[.]kra52[.]at | 未提供 | | captcha[.]kra51[.]cc | 2025-09-26 | | captcha[.]krafb5[.]at | 未提供 | | captcha[.]krafb5[.]cc | 2025-12-31 | | captcha[.]krabi5[.]at | 未提供 | | captcha[.]krabi5[.]cc | 2025-12-23 | | captcha[.]krabi4[.]at | 未提供 | | captcha[.]krabi4[.]cc | 2025-12-23 | | captcha[.]krabi3[.]at | 未提供 | | captcha[.]krabi3[.]cc | 2025-12-23 | | captcha[.]krafb2[.]cc | 2025-12-31 | | captcha[.]krad2[.]at | 未提供 | | captcha[.]krabi2[.]cc | 2025-12-23 | | captcha[.]krabi2[.]at | 未提供 | | kra46l[.]cc | 2025-10-27 | | kra46l[.]at | 未提供 | | krak45[.]cc | 2024-12-21 | | krak45[.]at | 未提供 | | kra45l[.]cc | 2025-10-27 | | kra45l[.]at | 未提供 | | kra44l[.]cc | 2025-10-27 | | kra44l[.]at | 未提供 | | kcra43[.]cc | 2025-07-04 | | kcra43[.]at | 未提供 | | kraken106[.]com | 未提供 |

结构观察

这个域名集群显示出几个特点：

• 系统化的命名变化
• 数字轮换模式
• 在 .cc 和 .at 顶级域名上的镜像部署
• 一致的 captcha. 子域名细分

这些特征表明这是为了冗余和生存性而有意进行的大规模配置，而不是机会性的重复利用。

架构解读

将路由行为、会话绑定逻辑、剪贴板操纵、公开索引和分布式域名基础设施关联起来，可以得到一个连贯的架构模型。

这项服务似乎遵循一个分层访问模型：用户先与一个明网网关交互，该网关分配路由路径和会话标识符。之后，核心的身份验证流程和市场逻辑由洋葱服务在后台处理，而一个镜像网络则帮助维持可用性、冗余性和整体弹性。

与克拉肯市场演变的关联

一些公开报告（https://onionpages.com/market/kraken-russian-darknet-market-review/2025-09-21）将克拉肯描述为俄语暗网生态中的一个主要后继者，在先前市场动荡后迅速扩张，并采用了注重弹性和可访问性的基础设施。

该平台似乎并不是仅仅依赖隐藏服务，而是部署了明网发现和路由层，最终将流量引入基于洋葱的后端系统。

这种混合暴露模型代表了暗网运营设计上的一个明显转变，将匿名性与受控的公开可达性结合了起来。

安全遥测中的检测状态

在分析时，已识别的几个明网网关域名在VirusTotal上仍然没有标记，而其中一部分已经开始收到个别安全厂商的恶意或钓鱼分类。

入侵指标（IOC）

明网验证码网关域名

上述列出的域名。这里是URLScan.io（https://urlscan.io/search/#hash%3A9fa0fd5b129cc1062500cf31c6be66f6617d829c3e4ccf0dc7cdba46f992632e）对搜索域名的结果。

网络端点

认证提交

• POST /entry/login 用途：在路由到后端前，从明网登录界面提交凭证。

洋葱路由协调

• GET /modules/onion_servers/take_server.php 用途：用于镜像选择、会话绑定和后端路由编排的后台请求。

检测考量

• 重复访问以 CAPTCHA 为前缀的轮换域名

• HTTP 请求至：

• /entry/login

• /modules/onion_servers/take_server.php

• 网络遥测中出现 Tor 路由相关的 Cookie 参数

• 引用 .onion 镜像的剪贴板操控 JavaScript

钓鱼风险与网关信任问题

摆在洋葱后端前面的这个明网验证码登录页面，自然让人怀疑它能在多大程度上被信任来处理用户凭证。明网和洋葱界面视觉上的相似性，加上后台观察到的会话绑定和路由行为，可能指向一个共享的、故意设计的网关，而不是一个简单的钓鱼副本。

不过话又说回来，这个明网层是一个单一拦截点，在与任何隐藏服务交互之前，凭证就在这里提交了。这使它成为记录日志、重定向或收集凭证的理想位置。轮换网关域名的使用、混合的安全厂商检测结果以及客户端流量引导逻辑，都增加了不确定性，让人很难仅从表面分析就断定其意图。

因此，从防御角度看，无论这个明网入口点最终是否连接到真正的洋葱基础设施，都应该被视为具有固有的高风险。

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：夯磅棱 《克拉肯暗网通过明网网关提供访问》