暗网监控的幻象：为什么“免费又可靠”的泄露数据并不存在

摘要

我们最初要回答的是一个看似简单的产品问题:我们是否应该在内部安全平台中加入暗网与泄露凭证监控?最便宜且可靠的数据源又是什么?

我们投入了大量精力去梳理这个市场——头部厂商、声誉良好的参考级服务、一长串免费与付费的泄露数据 API、灰色市场的凭证查询引擎,以及自建那些在网上流传的海量泄露凭证语料库这一选项。

结果证明,工程实现是最简单的部分。把一个泄露查询 API 接入到发现(findings)流水线里,不过是几百行成熟的代码。真正让我们止步的,是代码之外的一切:持有被盗凭证的法律风险、一旦你开始处理他人个人数据便随之而来的数据保护义务、构建在与攻击者所用工具别无二致的服务之上的声誉风险,以及一个令人不安的发现——一旦你真正去读那些条款、去实测那些接口,"免费又可靠"这个组合基本上只是一个幻象。

本文是我们研究成果的完整记录,并刻意保持厂商中立。它面向任何正在权衡同样的"自建 vs. 采购 vs. 放弃"决策的安全或平台团队。一句话总结:把"免费"当作威胁情报里最昂贵的词,永远不要持有并非由你自己生成的明文凭证,并且在导入任何一条记录之前,先让法务对合法性依据签字确认。如果你无法跨过这些门槛,那么负责任的做法——也是我们所选择的——就是不去构建它。

第一部分:"暗网监控"到底承诺了什么

在评估供应商之前,先准确界定这个品类是什么会很有帮助,因为其营销话术是刻意宽泛的。

商业形态下的"暗网监控",通常被归入一个统称:数字攻击面分析(Digital Attack Surface Analysis,DASA)或"数字风险保护"。各厂商的说辞高度一致:你把在意的东西交给服务——你的邮箱域名、特定员工的邮箱地址、用户名、IP 段、电话号码——服务便持续地将这些"元素"与一个庞大的泄露数据库进行比对,同时爬取隐藏论坛、市场、粘贴站(paste sites)和聊天频道。一旦有你的东西出现,你就会收到告警。

这个品类中一个有代表性的产品,通常会宣传如下能力的某种组合:

• 暗网/深网监控,覆盖黑市站点、点对点网络、隐藏聊天室、僵尸网络、IRC 和私密论坛。
• 泄露凭证检测,针对受监控的域名、邮箱、用户名、IP 和电话号码,并附带泄露元数据(日期、严重程度、类别)。
• 实时告警——元素被持续重新扫描,一旦出现新的泄露即刻通知。
• 仿冒域名(typosquatting)/品牌冒充检测——标记用于钓鱼的近似域名。
• 邮件安全态势检查——评估域名的 SPF/DMARC 记录以及其邮件服务器上的 STARTTLS 支持情况。
• 可作为证据的报告——包含截图和描述的泄露报告。
• 威胁情报可视化——将你的资产与威胁关联起来的图形化视图。
• API 与白标选项——让托管服务提供商(MSP)可以转售该能力,或将其接入 SIEM/XDR。

这类产品背后的数据库,通常宣称在"180 亿到 230 亿条记录"这个量级——这个数字因来源和时间不同而差异巨大,值得抱以怀疑(为什么,见第二部分)。

纸面上看,这是一个颇具吸引力、往往低成本、可自助使用的产品。但对任何把监控产品当作数据供应商而非仪表盘来考虑的人来说,有一个反复出现的细节值得注意:许多这类厂商高调宣传"API 访问",却不提供任何公开的、第一方的 API 参考文档——没有端点列表、没有鉴权方案、没有响应结构、没有速率限制——直到你进入销售洽谈为止。营销能力与文档化契约之间的这道鸿沟,贯穿整个品类。

本节的目的不是针对任何厂商,而是确立这个承诺的形态。这个领域里的每个产品,卖的都是同一个核心闭环:你的标识符 → 与泄露数据比对 → 告警 + 报告。所有有意思的东西,都藏在"泄露数据"这几个字里:它从哪里来,有多新,以及——关键所在——持有并处理它在法律上意味着什么。

第二部分:泄露数据究竟从何而来

要评估供应商,你必须理解其原材料,因为原材料同时决定了在其之上构建的一切的价值(新鲜度与准确度)和风险(合法性与敏感度)。

泄露凭证数据大体来自三类来源,按新鲜度与危险性递增排列:

1. 聚合型泄露合集。这些就是巨型"组合列表(combolist)"——由数百上千次历史泄露拼凑而成的 邮箱:密码 对文件。多年来已有若干巨型合集公开流传,其中一个据报含有约 27 亿行、数亿个唯一地址;后来又有一个更大的聚合被报道含有数百亿条记录、分布在数千个文件夹中。

关于这些合集,最关键的事实是:它们是回收的,而非新鲜的。针对每一次的报道都一致指出,其中大部分数据早已从更早的泄露中公开。它们高度重复、格式混乱,充满解析残渣。作为监控服务的原料——监控本应告诉你新的暴露——它们几乎毫无用处。它们告诉你某个用户在多年前被泄露过,而这一点用户几乎肯定早已知道。这也是"数十亿条记录"这类营销数字值得怀疑的原因:庞大的原始记录数,几乎说明不了任何关于新鲜度、去重或准确度的信息。

2. 组合列表与信息窃取木马的"窃取日志(stealer logs)"。这是新鲜而危险的一端。信息窃取木马会在感染的那一刻抓取受害者浏览器中保存的一切:用户名、明文密码、自动填充数据,以及——最危险的——可以完全绕过多因素认证的活跃会话 Cookie。与陈旧的泄露转储不同,窃取日志是在感染当下捕获凭证的,并且这些日志会在被窃取后一两天内就在犯罪渠道上出售。

这是唯一真正新鲜、也真正对监控有用的数据。但根据定义,它直接来自活跃的犯罪供应链,并且捆绑着明文密码和会话令牌——是你数据库里可能存放的最有毒的载荷。

3. 直接来源的泄露转储。单次泄露事件,有时由研究人员在保密协议下获得,有时在论坛上买卖。声誉良好的服务会对其进行策展和验证;不负责任的服务则只是转手托管它们能拿到的任何东西。

因此,新鲜度谱系从"陈旧但相对安全"(旧合集)一直延伸到"新鲜但极其危险"(窃取日志)。而定义整个品类的陷阱正在于此:价值与危险是正相关的。对监控产品真正有用的数据,恰恰是获取、持有和再分发起来在法律和道德上最棘手的数据。

第三部分:"免费又可靠"的张力

最初的任务是找一个免费又可靠的数据源。在梳理了整个领域之后,诚实的结论是:这两个词彼此矛盾,而理解为什么需要一个框架,而不是一份供应商清单。

三个敏感度层级

每一个泄露数据源,都可以根据一次查询所返回的内容,归入三个层级之一。这个单一的区分,是整个领域中最重要的设计决策:

• A. 这个密码是否已泄露? — 它回答的问题: "这个密码是否出现在任何泄露中?"——不附带任何标识符; 敏感度: 最低——匿名、安全; 典型获取方式: 免费,无需密钥(k-匿名)
• B. 这个账户是否在某次泄露中? — 它回答的问题: "这个邮箱/域名是否出现在泄露 X 中?"——输入标识符,输出泄露名称,不含密码; 敏感度: 中等——你查询的是真实标识符; 典型获取方式: 付费 API 密钥,最好带 k-匿名
• C. 明文密码是什么? — 它回答的问题: "给我这个账户的明文凭证"; 敏感度: 最高/极度危险; 典型获取方式: 免费到付费的灰色市场;你现在持有了被盗凭证

A 层是安全的,因为它与身份解耦——你问的是一个抽象的密码,而非某个人。B 层是合法监控的核心——"你的账户出现在某次泄露中,请更换密码"——而负责任的版本从不返回实际密码。C 层是责任所在:那些为任意第三方交出 邮箱:明文密码 对的服务。

可靠性与免费之间的张力,几乎完美地对应到这些层级上。免费 + 可靠只存在于 A 层。做得正规的 B 层是要花钱的。C 层是"免费"再次出现的地方——而它之所以再次出现,恰恰是因为这些服务运作在一个正规厂商避之不及的法律与道德灰色地带。

A 层:真正免费、真正安全的那一层

"免费又可靠"确凿成立的唯一场景,是匿名密码检查,它建立在一种名为 k-匿名的技术之上。客户端在本地对密码进行哈希,只把哈希值的前几个字符发送给 API,再接收回共享该前缀的一组哈希后缀,并在本地完成比对。密码——甚至完整的哈希——从不离开本机。这一模式最知名的实现是免费、无限量、无需 API 密钥提供的,而使用它的正规服务刻意做到从不将明文密码与邮箱地址存放在一起,因为这么做"风险太大"。

这就是值得效仿的模式:它让你能以零隐私暴露、零数据持有责任的方式,回答一个真正有用的问题("这个密码是否已知被泄露?")。而且值得注意的是,它也是唯一免费又安全的层级。

B 层:可靠的标识符查询——正规但付费

检查某个特定账户或域名是否出现在泄露中,是合法监控的核心,而"免费"也正是在这里开始耗尽。这一层中正规、文档完善的服务对 API 访问收费——小规模使用通常从每月个位数美元起步,并随查询吞吐量而上升。其中最好的那些只返回某个标识符出现在哪些泄露中,从不返回密码本身,有些还提供邮箱搜索的 k-匿名模式,使得完整地址无需被传输。

对组织而言,这一层里的明星能力是域名验证搜索:你证明自己掌控某个域名(通过 DNS 记录、邮件或文件),服务便返回它已知的、该域名下每一个被泄露的 用户@你的域名 地址。这是保护隐私的模式——你不是把员工名单上传给第三方,而是询问对方针对一个你所掌控的域名已经暴露了什么。有些服务在每个域名被泄露地址数低于某个小阈值时免费提供该能力(实际中这覆盖了相当大比例的域名),超过则适度收费,并提供面向 MSP 场景的批量域名验证 API。

这一层里也有可信的免费或免费增值选项——包括一些开源项目和公共 API,它们返回泄露名称和暴露的字段类型,但不返回明文。对于按需的、单个的查询,它们确实有用。但它们往往有两个共同的局限,使其无法胜任批量引擎:一是每日/每小时的硬性速率上限——适合交互式使用,却远不足以支撑对众多域名的每夜监控;二是其语料库是从公开流传的转储中自行收集的,而非独立策展的。有些还带有单一维护者的可持续性风险。凡是提供付费层以解除上限的,其定价便与更成熟的付费服务趋同——到那个点上,声誉和文档质量就成了决定性因素。

最后,关于面向消费者的服务提一句:一些知名的浏览器和身份厂商向终端用户提供泄露通知仪表盘,但这些是消费级产品,没有开发者 API,而且这个领域里至少有一个知名的付费产品已在 2025 年底停止运营。如果你想要这类仪表盘背后的数据,你会直接去找其底层的泄露通知服务。

C 层:灰色市场——"免费"变得危险的地方

接下来是那一簇会为任意邮箱地址交出 C 层明文密码的服务,有时甚至便宜或免费。如果你不小心,"免费又可靠"的搜索最终就会通向这里——而这恰恰是你绝不该去的地方。

与其点名并评判个别服务——那既不公平也不明智——更有用的是描述这个品类及其一致的特征:

• 它们返回明文。其定义性特征就是"未经审查的结果"——真实密码紧挨着真实标识符,常常横跨邮箱、用户名、IP、电话和地址。
• 它们经常暴露面向攻击的功能,比如批量 邮箱:密码 的"组合"查询,其主要用途是撞库验证。
• 它们通常不做买家审查——没有 KYC,没有将访问限制在防御或执法用途的限制。任何人都能购买。
• 它们的"条款"往往是免除对滥用的一切责任,而非加以约束;即便它们确实限制未经同意再分发个人数据,那条限制也可能直接禁止你想要在其之上构建的那个产品。
• 它们的可靠性与数据来源不透明。有些建立在陈旧的静态合集之上;有些转手托管并非自己收集的数据;有些则干脆已经衰败或被弃置,其仿冒域名会把访问者重定向到别处。

整个灰色市场的模式一目了然:这些正是与账户接管和撞库攻击者所用的同一类明文凭证搜索引擎。在这样的供应链之上构建防御性产品,意味着全盘继承它的法律与声誉风险画像——这对任何以信任为价值主张的产品来说都是一个自相矛盾。

自建的诱惑

最后一个"免费"的想法,是最让工程师心动、在实践中却最危险的:完全绕过 API,下载那些大型合集,自己建立索引,自己跑查询。没有单次查询成本,没有速率限制,完全掌控。

它在每一个维度上都站不住脚:

• 数据是陈旧的。如前所述,这些大型合集是回收的历史转储。你会把一个"监控"产品建立在多年前就已不再新鲜的数据之上。
• 存储与运维成本是实打实的。这些合集动辄以 TB 计;近期暴露的凭证集群更是达到多个 TB。把这样的体量索引进搜索集群,每月要花上数千美元,而这还不算把格式混乱、连专业研究者都难以完全去重的转储规范化所需的大量工程投入。
• 而且它把你自己变成了目标。这里有一个黑色幽默般的讽刺:近年来最大的几起泄露头条,恰恰是关于某人配置错误、自建、无鉴权、塞满明文凭证的数据库泄露了数十亿条记录。构建一个明文凭证库,不仅承担下文所述的风险——它简直是把你自己变成下一个泄露头条。

这就把我们带到了我们真正止步的原因。

第四部分:合规与责任的清算

正是这一部分,把一次技术评估变成了"不做"。上文的每一个问题——陈旧、速率限制、来源不透明——都是要小心的理由。而合规与责任问题,是在你无法跨越某些高昂门槛的情况下根本不去构建它的理由。

(以下是对风险图景的一般性概述,并非法律建议。具体情形因司法辖区和事实而异,请咨询合格的法律顾问。)

持有本身就可能有问题

最反直觉、也最重要的发现是:下载并持有来源不正当的泄露数据,即使你从不再分发、你的意图纯粹是防御性的,也可能带来法律风险。

针对"我们自己搭一个泄露查询"这一恰好对应的问题,法律评论在这一点上是一致的:持有以非法手段获得的个人数据——无论你是否分发——都可能触犯计算机滥用法规(例如美国的《计算机欺诈与滥用法》CFAA)以及各类州级隐私法律。通过匿名网络获取,或在非法市场上购买这些数据,还可能带来进一步的风险,包括围绕贩运被盗信息的责任。安全从业者长期以来一直行走在一条被某业界评论称为"细微且并不十分明确的法律红线"上。关键原则是:防御性目的并不能洗白非法的获取或持有。

数据保护法:没有合法性依据 = 非法处理

如果被暴露的个人中有任何人受综合性数据保护法规的保护——而在任何泄露语料库中,许多人都会是——那么一旦你导入并存储这些数据,你就成了以控制者(controller)身份处理个人数据。诸如欧盟/英国 GDPR 之类的法规要求该处理具备一项合法性依据(同意、合同、法律义务、重大利益、公共任务或正当利益)。持有一堆第三方被盗凭证,你通常一项都不具备。在缺乏合法性依据的情况下,法律要求你删除这些数据——而在某些司法辖区,非法获取或处理个人数据属于刑事犯罪,而不仅仅是行政违规。

其他法规(例如美国各州的隐私法,如 CCPA)也制造出类似的问题:同样是"你没有正当依据来持有这些数据"的问题反复出现。具体界限因司法辖区而异,值得法务审阅——但方向是一致的。

再分发让问题成倍放大

如果你的产品向客户展示这些泄露数据——而这正是监控产品的全部意义——你就从持有走向了再分发。即便是灰色市场供应商自己的服务条款,有时也会禁止未经受影响个人同意就再分发个人或敏感信息——这一条款如果照字面理解,恰恰禁止了你试图在其之上构建的那个产品。而向你的客户再分发泄露 PII 的数据保护义务,落在你身上,而非你的供应商身上。

持有明文的安全责任

存储明文凭证会让你成为高价值目标和潜在的二次泄露源。这并非假设——它正是一些最大规模凭证暴露头条背后反复出现的失败模式。这正是为什么市场中正规的一端,在架构上做到从不将密码与邮箱存放在一起、只提供匿名化的 k-匿名哈希。这种设计不是锦上添花——它是让整个事业得以站得住脚的承重风险控制。任何要求你持有明文第三方密码的架构,都已经抛弃了唯一能让这个品类得以存续的那个控制措施。

声誉与供应商风险

最后是较软性但真实存在的顾虑:那些愿意给你丰富数据的免费或廉价供应商,往往身处"与黑客为邻的 OSINT"空间——没有买家审查、带有面向攻击的双用途功能、面向任何肯付钱的人做营销、来源不透明。在这样的供应链之上构建一个安全产品——一个其全部价值主张就是可信度的产品——是一个自相矛盾。如果客户、审计师或监管者问一句"你们的泄露数据从哪里来?",答案不能是"一个条款里写着对滥用概不负责的匿名查询站"。

合规小结

综合来看,合规与责任的全貌是一叠彼此独立的障碍,其中任何一个都足够严重:

1. 持有来源不正当的泄露数据本身就可能带来法律风险——意图不是抗辩理由。
2. 在没有合法性依据的情况下处理它,可能违反数据保护法,在某些司法辖区还构成刑事犯罪。
3. 向客户再分发它,会叠加数据保护风险,并可能违反供应商自己的条款。
4. 持有明文会让你成为下一个泄露头条。
5. 廉价的供应商在声誉上与一个以信任为核心的产品格格不入。

工程实现是一周的工作量。而上面这份清单,是一项我们判断与其价值并不相称的法律与组织承诺。

第五部分:向内看的工作 vs. 向外看的工作

把这个决策放到一个像我们这样的平台确实能够安心开展的那类安全工作旁边对照一下,是有价值的,因为这种对比澄清了为什么外部泄露监控值得调研,以及为什么它终究是一个不同的、更高风险的品类。

我们大部分的安全工具本质上是向内看的。它审计并修复那些已经在清晰服务关系下被管理的资产的安全态势:终端资产盘点与漏洞态势、终端防护健康度、身份与租户卫生(MFA 缺口、风险登录、特权角色审查)、设备关联、修复工作流等等。

那里的一切都共享一个定义性特征:被审计的东西是你拥有或管理的。数据是你的或你客户的;合法性依据是清晰的(你是在为客户自己的系统提供合同约定的安全服务);你从不触碰任何他人的被盗数据。

暗网/泄露监控在类别上截然不同。它向外看,看的是源自他人泄露的数据、关于从未同意被你处理的个人的数据、来自犯罪供应链的数据。从产品意义上,两者是互补的——知道一个被管理的账户同时出现在某次泄露中,确实有用——但它们分处一条明亮合规红线的两侧。向内看的工作让你稳稳待在这条红线可辩护的一侧。向外看的工作则会跨在线上。

这种对比,最终让决策变得清晰。并不是泄露监控没有价值——而是价值真实却有限,而增量的合规与责任负担庞大,且会永久地留在你这一侧的账本上。

第六部分:如果你非做不可——唯一可辩护的模式

假设对你的组织而言,价值论据足够充分,以至于放弃并非选项。那么确实存在一种可辩护的做法。它很狭窄,并且主要由你拒绝去做的事情来定义:

1. 永远不持有原始数据。接入一个经过审查的、有授权的 API,其提供者的整个业务就是合法处理泄露数据。不要下载语料库,不要自建转储,不要从不负责任的查询站购买。让提供者去承担持有责任。
2. 待在 A 层和 B 层;绝不进入 C 层。用 k-匿名密码检查(免费、匿名、安全)来做密码卫生信号,用一个正规的"输入标识符 / 输出泄露名称"的 API 来做账户暴露检查。绝不导入或展示明文密码。如果你的设计要求明文第三方凭证,那设计就是错的。
3. 按已验证的域名查询,而非上传人员。保护隐私的模式是:证明你拥有某个域名,然后询问对方针对它已经暴露了什么——而不是把员工名单发给第三方。带批量验证的域名验证搜索,正是为此而生,并且意味着你所呈现的,永远只是一个你所掌控域名上业已公开的数据。
4. 优先选择围绕风险最小化而设计的提供者。参考姿态是:不存储明文、k-匿名、明确的可接受使用条款、以及合法的数据来源协议。这种姿态本身就是产品。
5. 在导入任何一条记录之前,先让法务对你的合法性依据签字确认。这不是可选项,也不是走过场。数据保护与计算机滥用的分析,需要一个针对你的司法辖区、你的客户群体和你的数据流的真实答案。
6. 最小化数据并保持透明。只存储最低限度的信息(哪次泄露、哪个日期、你的哪个标识符),而不是凭证本身。告诉用户你检查什么、以及为什么。

请注意,这个可辩护的模式也是最省钱的:匿名密码检查是免费的,域名验证搜索在多数域名所处的规模上是免费或廉价的,而你避开了每一个灰色市场供应商和每一笔自建成本。负责任的路径与可负担的路径殊途同归——因为让灰色市场路径"便宜"的那个东西,恰恰是你在合法性与安全上偷工减料的结果,而那本就是你承担不起的。

第七部分:经验教训

为任何将要走进同样评估的人,提炼如下:

• "免费又可靠"的泄露数据是一个 A 层现象。你可以免费且安全地检查一个密码是否已泄露。而要可靠、且成规模地检查一个人的账户是否被暴露,是要花钱的——这是市场诚实的现状,而不是你没有货比三家。
• 在这个领域,价值与危险是相关的。新鲜、有用的数据在法律上最棘手。安全、廉价的数据对监控而言陈旧无用。不存在一个同时新鲜、免费又安全的象限。
• 陷阱在于持有,而不只是分发。直觉是"我们只是看看,不会分享它"。法律可能并不在乎——持有来源不正当的个人数据,本身就可能是那个问题。
• 不负责任的供应商是一种声誉溶剂。它们难以与攻击者工具区分,运作时不做买家审查,其条款免除责任。信任型产品无法建立在那样的地基上。
• 自建泄露转储会把你变成下一个泄露事件。新闻里那些巨型泄露的一个主要成因,正是某人自建的明文凭证库。别去建它。
• 最好的架构由拒绝来定义。永不持有原始数据,永不存储明文,永不通过上传人员来查询,永不跳过法务。正规服务不做的那些事,才是让它们安全的原因。
• 有时,正确的工程决策是不去做工程。代码是微不足道的。正确的决定仍然是"不做"。识别出障碍在于合规而非能力,本身就是一项资深的技能。

结论

我们最初是在寻找一种便宜、可靠的方式,把暗网监控加进一个安全平台,而我们带回来的结论是决定不去构建它——不是因为我们做不到,而是因为要把它做好,意味着要么付钱给一个正规提供者去承担我们不愿持有的责任,要么踏入一个灰色市场——其数据是被盗的,其供应商是不受问责的,其法律风险在数据落入你数据库的那一刻就附着到你身上。

暗网监控这个品类并非骗局——存在正规、运营良好的厂商,而知道自己的凭证何时泄露也确实有真实的防御价值。但"随手抓一个免费泄露 API 接上去"的那个版本,是一个幻象。剥开营销话术,你会发现免费选项要么安全但受限(A 层密码检查),要么正规但付费(域名验证账户搜索),要么免费但极其危险(灰色市场)。那条既可辩护又可负担的路径很狭窄,并且由一套拒绝来定义:不碰原始数据,不碰明文,不用不负责任的供应商,不在没有法务背书合法性依据的情况下导入数据。

对我们而言,在权衡有限的增量价值与永久性的合规和责任负担之后,答案就是继续做那些向内看的安全工作——在那里,我们的合法性依据是清晰的,我们的手是干净的——并把外部泄露监控留给那些把整个业务、以及整套风险架构,都围绕着合法处理这些数据而构建起来的专业厂商。

威胁情报里最昂贵的词,真的是"免费"。第二昂贵的,是"我们就先留着它吧"。