← 返回全部文章

拆一条黑灰产链：买号、跑量、接管与洗钱到底怎么落地

上一篇写得太像报告摘要了。黑灰产“产业化、组件化、跨境化”，这种话没有错，但看完还是不知道业务当天报警时该查哪张表。

这次不讲大词，直接拆四个公开案例。每个案例只回答三个问题：

  1. 这条生意实际上怎么转起来；
  2. 平台日志里会留下什么；
  3. 如果我是风控或安全人员，当天能做什么。

本文不会写注册机、群控或洗钱的操作教程，只讨论公开案件已经披露的链路和防守方能落地的检测办法。

案例一：一份通信数据，最后变成一批“正常账号”

最高检 2025 年披露过一起很典型的案件。通信运营商内部人员非法获取用户制卡数据，另一批人将数据写入空白 SIM 卡，再用复制卡批量接收验证码，注册 QQ、京东等平台账号并出售给下游。案件介绍见《斩断收买公民个人信息的利益链条》。

这里值得注意的不是“复制卡”三个字，而是账号资源如何被生产出来：

内部数据泄露
    → 可接收短信的身份资源
        → 批量注册
            → 养号或直接出售
                → 营销、诈骗、薅活动、洗钱

对下游平台来说，这些账号很难用一条规则抓住。手机号是真的，验证码也真的，注册接口没有被攻破。平台看到的甚至是一次“成功的正常注册”。

真正的问题藏在横向关系里。

这伙人是怎么被继续挖出来的

这份公开材料没有交代公安机关最初如何锁定第一批嫌疑人，所以不能编成“某个 IP 暴露了团伙”。但它把案件进入审查起诉后，检察机关如何从已有电子证据里继续挖人写得很清楚。

办案人员先在扣押、提取的数据里发现了两类看起来很像正常业务材料的文件：

  • 用户投诉数据：有人反映自己在不知情的情况下被开通了增值业务；
  • 结算统计报表：运营商与增值业务商之间用于结算、扣减费用的依据。

这两类文件与聊天记录放在一起后，意义变了。涉案人员并不是偶然接触到几份报表，而是在用投诉数据压低风险、核算非法推广收益。检察机关又到省级电信企业补充调查，确认了文件的来源和用途，再把涉案渠道商与运营人员之间的大额资金往来、证人证言对上，补出了原来没有认定完整的诈骗事实。

更关键的一步来自“账对不上”：

供述称：号码、验证码生意获利超过 100 万元
已查明：当时只抓到一个下游，利润约 20 万元
结论：剩下的大量货去了哪里，案件里还有人没出现

办案人员据此回看社交软件和资金流水，找到一个长期购买号码、验证码注册 QQ 的下游，再从他的聊天记录向外筛查，最终监督立案 8 人。另一处矛盾也很明显：只有省级以上运营商才掌握的制卡“五码”，外部团伙为什么能稳定拿到？沿着数据权限和资金关系继续查，才牵出企业内部人员。企业随后处分 7 人、为受影响用户更换 SIM 卡，并升级异常检测。

公开判决结果中，主犯分别被判处十五年、九年六个月；复制卡和下游链条中的多人也被判刑。这起案子真正值得学的侦查思路不是某个神奇工具，而是反复核对三个不一致：

  1. 口供里的利润规模与已抓下游规模不一致；
  2. 所谓“正常业务”与大量投诉、结算扣减不一致；
  3. 外部团伙掌握的数据与正常权限边界不一致。

案子不是在第一次抓人时结束的，而是从这些不一致里继续长出来的。

平台应该查什么

假设业务已经统一采集注册和验证事件，至少要保留下面这些字段：

字段 用途
account_id 账号主键，不能只存脱敏手机号
phone_hash 统计号码关联账号与换绑历史
device_id 观察一台设备注册多少账号
ip、asn、proxy_type 区分家庭网络、机房、代理和异常跳变
otp_request_id 串起请求、下发、验证和账号创建
client_time_zone、locale 检查终端环境是否自洽
event_ts 计算批量操作的节奏
campaign_id、invite_code 判断账号是否集中流入同一活动

有这些数据后，先做最朴素的聚合就能捞出一批样本：

SELECT
  device_id,
  COUNT(DISTINCT account_id) AS accounts,
  COUNT(DISTINCT phone_hash) AS phones,
  MIN(event_ts) AS first_seen,
  MAX(event_ts) AS last_seen
FROM account_events
WHERE event_name = 'register_success'
  AND event_ts >= CURRENT_TIMESTAMP - INTERVAL '24 hours'
GROUP BY device_id
HAVING COUNT(DISTINCT account_id) >= 8;

8 不是通用阈值。一个门店工作机、测试设备或校园公共终端也可能关联多个账号。这个查询只是捞样本，后面还要继续看：

  • 这些账号是否共享邀请人、地址、支付工具或收货人；
  • 注册之后是否按照相同顺序完成资料、领券、下单；
  • 事件间隔是否集中在很窄的区间；
  • 是否在几小时后统一切换到另一批设备或代理；
  • 后续是否向同一个收款方、群聊或外链汇聚。

当天能做的防护

不要一上来封手机号段。号码本身可能属于真实受害者。

更稳的做法是把处置放到“权益”和“高风险动作”上：

  1. 注册可以成功，但批量关联设备上的新账号暂缓领取高价值权益；
  2. 首次支付、发帖、私信、换绑时追加验证；
  3. 同一受益对象的优惠次数按“账号 + 设备 + 支付工具 + 地址”联合限额；
  4. 命中团簇后向外扩一跳，找共享设备、号码、支付工具和邀请关系；
  5. 对确认被冒用的号码提供快速申诉与解绑，不把损失甩给真实用户。

这里的核心不是证明某个手机号“坏”，而是证明一批表面独立的账号其实由同一套基础设施生产。

案例二：1100 元买个外挂，就能做一门抢票生意

2026 年 7 月，上海静安检察机关公开了一起利用外挂批量代抢火车票牟利案。

公开材料给出的链路非常具体：

  • 涉案人员花 1100 元购买非法抢票软件；
  • 通过朋友圈和熟人介绍招揽客户；
  • 提前收集姓名、身份证号和手机号；
  • 批量导入外购的 12306 账号；
  • 使用多线程持续提交购票请求；
  • 抢到后把支付二维码返回给客户；
  • 每单收取 50 至 150 元手续费。

这个案例很有意思，因为它不需要找一个传统意义上的高危漏洞。软件只是在滥用正常业务接口和资源分配规则，用机器速度挤压普通用户。

从异常流量到当天抓人

这起案子的发现入口很朴素。2025 年 2 月下旬，上海静安警方在日常工作中发现，有人对 12306 发起高频、大规模的抢票请求。警方沿着异常请求调查，当天就抓获了郑某。

但“请求很多”只能说明异常，不能单独证明郑某利用程序非法获取数据并靠它赚钱。检察机关提前介入后，要求把几条证据同时固定下来：

  • 对涉案抢票软件做电子数据检查和功能鉴定；
  • 保全电脑、手机中的聊天记录、客户信息和接单记录；
  • 调取转账流水，核对每一笔手续费；
  • 将软件运行能力、具体票单和实际获利逐一对应。

案件还有一个容易争议的点：这款软件没有破解 12306 的底层系统，而是自动、批量调用正常购票流程。鉴定意见确认，它可以在未经授权的情况下批量发起请求，获取系统正在处理、传输的数据。至此，软件鉴定证明“工具能做什么”，聊天记录证明“为谁接了单”，订单台账证明“抢了哪些票”，支付流水证明“赚了多少钱”，四层证据才闭合。

最后查实的不是一个抽象的“外挂用户”，而是 200 余张具体车票、2 万余元具体获利。郑某退缴违法所得并认罪认罚，被判处有期徒刑一年六个月、缓刑一年六个月，并处罚金 5000 元。

这解释了为什么平台侧一定要保存请求 ID、账号、乘车人、设备和订单的关联。只有流量峰值，能报警；能把异常请求还原成一张张票和一笔笔收费，才能成为案件证据。

只按 IP 限速为什么不够

如果攻击者有代理池，单 IP 请求量可以很低；如果每个账号只请求几次，单账号规则也可能不触发。真正稳定的信号通常在“受益对象”和“行为模板”上：

  • 多个账号为同一乘车人、同一行程或同一支付人抢票；
  • 账号登录后不浏览，直接进入查询—提交—支付链路；
  • 大量账号使用近似的请求间隔和失败重试模式；
  • 账号、设备和 IP 看似分散，却共用乘车人、联系人或支付关系；
  • 请求长期低频潜伏，只在放票窗口同时抬升。

对抢购、预约、领券和限量活动来说，限额对象不能只选账号。应该先问清楚稀缺资源最终归谁。

如果权益落到实名乘车人，就按乘车人和行程限；如果是优惠券，就看支付工具、地址和订单受益人；如果是内容曝光，就看最终落地页、广告主和结算账户。

一个更实用的规则

下面这种规则比“同 IP 超过 100 次就封”更接近业务：

在 10 分钟窗口内：

同一受益人关联账号数 >= 4
AND 请求覆盖设备数 >= 3
AND 账号历史有效订单数很低
AND 请求集中在稀缺资源释放窗口

动作：
不直接封号；
合并排队优先级 + 限制并发 + 对受益人追加验证。

它仍然可能误伤家庭代购、企业差旅或正规代理，所以处置动作要可逆。降速、排队和二次确认通常比永久封禁更适合第一阶段。

案例三：37 万个账户，48 天跑出 31.9 亿元

最高检、国家外汇局公开的一起非法支付结算典型案例里，“天天向上”跑分平台以兼职佣金为诱饵，纠集 10 万余名“跑分客”，使用 37 万余个微信、支付宝和银行卡账户提供收款转账服务。

公开数据称，仅 2020 年 4 月 1 日至 5 月 18 日，非法支付结算金额就达到 31.9 亿余元。

“跑分”这个词容易让人误以为只是几个人代收款。这个规模已经接近一套影子支付网络：

上游订单生成
    → 平台分配收款账户
        → 大量个人账户接收小额资金
            → 快速转出或换币
                → 少数节点归集

单笔交易往往不大，收款账户也完成过实名。只看一笔转账，可能就是普通消费；把 10 分钟、1 小时和 24 小时的资金网络拼起来，形状才会暴露。

他们否认知情，办案人员怎么证明

“天天向上”案的公开材料没有披露最初的报警线索，只说明公安机关于 2020 年 9 月 30 日将非法支付结算案移送审查起诉。真正棘手的是，多名被告人辩称自己只是做技术、兑换或转账，不知道资金与犯罪有关。

办案人员恢复、提取手机数据后，在聊天记录里发现了 309 笔使用 USDT 进行非法换汇的记录，里面写着国内收款银行卡、时间、金额和汇率。接下来没有只凭聊天截图定案，而是做了多层交叉验证：

  1. 从 309 笔里抽取 15 笔，调取对应银行明细；
  2. 核对聊天中的时间、金额是否与银行流水一致；
  3. 找到收付款人，以证言确认交易背景；
  4. 对扣押的手机、电脑做电子数据鉴定，提取受控虚拟币钱包地址；
  5. 把链上转账、银行流水和聊天记录按时间排序；
  6. 还原出“外币—USDT—人民币”的完整兑换路径。

最后形成的不是一张“可疑资金图”，而是三套身份系统的对齐：

聊天身份：谁下指令、谁报汇率、谁确认到账
银行身份：哪张卡在什么时间收了多少人民币
链上身份：哪个钱包在前后时间转了多少 USDT

当三条时间线反复重合，“不知道资金性质”的辩解就很难成立。主犯肖某、游某均被判处有期徒刑十一年，赵某被判七年，二审维持原判。

另一起案子：从一条群众举报到十多个省同步抓捕

湖南“人人赚”跑分平台案公开了更完整的抓捕过程。2020 年 2 月 19 日，警方接到群众举报，称“人人赚”App 涉嫌为赌博网站提供资金结算。侦查不是只盯举报人看到的那个 App，而是沿着四层结构向上追：

跑分客与收款码
    → “人人赚”“趣收米”招募端
        → “通付”商户管理后台
            → 源码开发、销售、维护人员

2020 年 3 月 15 日，专案组出动 70 名警力，分成 19 个抓捕组，在湖南、辽宁、河南、广西等十多个省份同步行动。首轮抓获 19 人，后续又抓获 31 人，共 50 人；现场扣押手机 300 余部、银行卡 200 余张，捣毁窝点 14 个。

为什么要跨省同时动手？因为这种平台的证据分散在开发者电脑、商户后台、跑分客手机、银行卡和收款码里。只抓最末端，后台可能删库，群主会解散群，其他窝点会换设备。同步扣押才能把：

  • 800 余万条交易记录；
  • 400 余个个人和对公银行账户；
  • 900 余个商户，其中约九成为赌博网站；
  • 2.6 万余个码商账户；
  • 20 余万个收款码和银行卡；

在同一时间截面上固定下来。全案查明流水超过 50 亿元，17 人被判刑，主犯获刑四年六个月；其余 33 人根据作用和证据情况作相对不起诉处理。

这条侦查路径很有代表性：举报只指出一个入口，资金关系找到商户，后台权限找到运营者，源码和维护记录再找到真正控制平台的人。

资金账户常见的可观测特征

  • 多入快出：来自许多陌生人的入账，在很短时间内大比例转走；
  • 金额模板化：金额被拆成若干常用档位，备注和时间分布相似；
  • 账户突然变性：长期用于生活消费的个人账户突然变成高频收款账户；
  • 多层归集：大量叶子账户经过一两层中转后汇向少数节点；
  • 昼夜异常：交易时间与账户历史习惯、职业和地区明显冲突；
  • 设备共用：多个实名账户却由相同设备、网络或操作环境控制。

可以先定义几个容易解释的指标：

in_degree_1h       1 小时内不同付款方数量
out_ratio_15m      入账后 15 分钟内转出的金额比例
counterparty_new   新交易对手占比
device_accounts    当前设备关联的实名账户数
fan_in_fan_out     是否同时呈现多入、多出

一个用于人工审核队列的示例条件可以是：

in_degree_1h >= 12
AND out_ratio_15m >= 0.80
AND counterparty_new >= 0.90
AND account_age_days < 30

这也不是封禁规则。众筹、票务、社区团购和小商户都可能出现多方入账，工资代发、供应链结算也可能快速转出。审核时需要继续看经营主体、商品或服务、历史流水、设备关系和交易对手网络。

真正有用的处置

资金链处置最怕慢。确认风险后优先级通常是：

  1. 暂缓结算或提现，防止资金继续分层；
  2. 保留订单、登录、设备、绑定关系和交易快照；
  3. 对关联的一跳账户提高监测，不要只处理当前账户；
  4. 联系支付和反欺诈协作渠道做止付；
  5. 区分核心组织者、职业账户与被“兼职”诱导的末端账户。

如果等到账户余额清零再封号，拦截率可能很好看，实际损失一点没少。

案例四：几年前偷的密码，几年后还能进生产环境

黑灰产并不只盯着电商和支付。2024 年 Mandiant 披露的 UNC5537 攻击 Snowflake 客户实例很适合说明“凭据商品化”。

调查中，攻击者使用信息窃取恶意软件历史日志里的客户凭据登录 Snowflake，批量导出数据并勒索。Mandiant 与 Snowflake 的分析显示，被利用账号中至少 79.7% 过去出现过凭据泄露；部分凭据最早在 2020 年就被窃取，却仍然有效。

成功原因并不玄学：

  1. 账号没有启用 MFA；
  2. 泄露多年的密码没有失效；
  3. 实例没有限制可信网络来源。

这件事比“用了什么窃密木马”更值得复盘。攻击者买到的是一份旧日志，但组织把旧日志保鲜了几年。

这不是警方先抓到人，而是威胁情报先撞见了数据

Snowflake 事件与前面三起国内刑事案件不同。Mandiant 公开的是一次威胁调查过程，不是完整的警方抓捕笔录。

2024 年 4 月，Mandiant 收到一批从地下渠道流出的数据库记录。调查人员把数据追溯到某个受害组织的 Snowflake 实例并通知受害者，随后在登录记录中确认：攻击者使用信息窃取木马历史日志里的有效凭据，从未启用 MFA 的账号进入实例。5 月 22 日，新的情报显示这不是单一受害者，Mandiant 与 Snowflake 启动联合通知，最终联系了约 165 个可能暴露的组织，并与执法部门协作。

发现路径可以压缩成：

地下渠道出现真实数据
    → 数据内容指向受害者的 Snowflake 实例
        → 登录日志出现泄露凭据和异常网络来源
            → 多个客户出现同类访问手法
                → 扩大为跨组织事件响应

登录成功之后的命令序列也暴露了目的。攻击者常先枚举用户、角色、会话和表，再创建临时 stage，通过 COPY INTO 把数据压缩到暂存区，最后用 GET 拉走。使用的客户端包括 SnowSight、SnowSQL、JDBC 和 Python，来源则常是商业 VPN 或 VPS。

这类行为说明，“密码正确”只回答了认证问题，没有回答访问是否合理。一个平时只跑固定报表的账号，突然从新 ASN 登录、枚举全库、创建临时 stage 并批量导出，本身就是一条很强的检测链。

后来确实有人被起诉，但公开材料没有写完整的身份溯源

美国司法部后来公布了 Connor Riley Moucka 和 John Erin Binns 一案：检方指控二人入侵至少 10 家组织、窃取数十亿条记录并实施勒索或出售数据。起诉书和逮捕令于 2024 年 10 月签发；Moucka 在加拿大同意引渡，2025 年 7 月在美国出庭并作无罪答辩，目前公开页面显示案件仍在审理，Binns 尚未被美国羁押。

这里必须分清两层事实：

  • Mandiant 的 UNC5537 是威胁活动聚类，用来描述相似基础设施和手法；
  • 司法部页面写的是针对具体被告人的刑事指控，指控在定罪前不等于事实认定。

司法部公开页面没有披露执法机关究竟用哪条技术线索确认被告身份，因此不能硬写成“通过某个 IP 抓到”。能确认的是：受害者数据在地下出现触发调查，日志和凭据复盘证明了入侵路径；之后执法程序通过起诉、逮捕令、加拿大羁押和引渡把其中一名被告带到美国法庭。这是“怎么发现事件”和“怎么把被告带到案”两条不同的线。

账号接管不要只盯登录失败

撞库会产生大量失败登录，比较容易看见；使用正确密码的攻击反而安静。Cloudflare 的公开实践会同时观察登录尝试和失败量的异常上升，并结合泄露凭据等信号，而不是只数 401。参见：Account takeover detection heuristics。

实际检测可以把登录前后串起来：

新设备成功登录
  → 60 分钟内注册新的 MFA 设备
  → 修改恢复邮箱或手机号
  → 创建新 API Token / OAuth 授权
  → 大量查询、导出或添加收款人

其中任意一步单独出现都可能正常，但连在一起就非常危险。

Google Cloud 2026 年的加固指南给出过更具体的检测机会，例如：

  • 10 分钟内收到 5 次以上 MFA 推送但没有对应成功登录；
  • 新 IP 或设备登录后 60 分钟内注册新的 MFA 方式；
  • 已成功认证的会话来自与用户历史不一致的 IP 或 ASN；
  • 未知 OAuth 应用突然获得邮件或文件高权限。

来源见 Proactive Preparation and Hardening Against Destructive Attacks。

当天能改什么

  • 先吊销所有活跃会话和刷新令牌，再改密码；
  • 管理员、财务、客服、数据平台强制 FIDO2 / WebAuthn；
  • 新设备登录后的换绑、导出、Token 创建设置冷静期；
  • 对历史泄露凭据做检测，命中后强制轮换；
  • 给 SaaS、数据库和管理后台加网络允许列表；
  • 把外包和个人设备纳入终端检测范围，别只保护正式员工电脑。

“已经开了 MFA”也不是终点。短信、推送确认和一次性验证码仍可能被社工或中间人钓鱼绕过，高价值系统需要抗钓鱼认证和登录后的持续校验。

这些人通常是怎么暴露、怎么被抓的

把几起案件放在一起看，入口并不神秘，主要就是五种：

发现入口 对应案件 第一条线索能证明什么
用户或群众举报 “人人赚”跑分平台 某个 App 或商户涉嫌代收款
日常流量监测 12306 抢票外挂 某批请求明显不是人工操作
已有案件里的数据矛盾 复制卡产业链 利润、权限或下游规模对不上
聊天、银行与链上记录交叉 “天天向上”跑分平台 同一笔换汇在三套系统留下痕迹
地下数据与受害者系统匹配 Snowflake 事件 流出的数据确实来自某个生产实例

第一条线索通常不够抓完整条链。真正能让案件往前走的是把“人、工具、动作、收益”闭合起来：

人：账号是谁控制，设备是谁使用，指令是谁发出
工具：软件、后台、钱包、收款码是否具备涉案能力
动作：哪一次请求、登录、转账对应哪一笔业务
收益：手续费、分成、虚拟币和银行流水流向哪里
主观明知：聊天、分工、规避审查动作能否证明知情

所以很多人不是败在“技术太差”，而是败在规模化经营必然需要协作和结算。协作会留下聊天与权限，结算会留下银行与链上流水，批量操作会留下稳定的时间模式，售后和投诉又会把受害者证言带进来。只要其中两三条线能相互校验，匿名昵称、跑分卡和代理 IP 就很难继续把真实控制关系完全藏住。

反过来看，安全团队提交线索时也不要只交一张封号表。最好同时导出原始请求、服务端时间、账号和设备关联、订单或受益对象、资金结果以及处置记录。平台日志不能代替司法调查，但结构完整的日志能让“这里有异常”更快变成“这批人做了什么、造成了什么结果”。

把这些案例放到一起

这些案例看上去完全不同：复制卡、抢票外挂、跑分平台、云数据库泄露。但它们共享同一个结构：

阶段 地下资源 业务侧能看到的东西
资源准备 手机卡、账号、泄露凭据 设备关联账号数、凭据泄露命中、注册团簇
扩大规模 代理、自动化、外购软件 请求节奏、设备/IP 切换、相同行为模板
获得收益 抢购、账号接管、诈骗 高风险动作发生得过早、受益对象集中
资金转移 跑分账户、支付通道 多入快出、关系图归集、账户用途突变
持续经营 换账号、换代理、换收款人 基础设施复用、团簇迁移、旧节点复活

所以黑灰产检测不应该按部门拆成“登录安全”“活动反刷”“支付风控”三套互不相干的系统。攻击者只是从你的组织架构缝隙里穿过去。

一套最小可用的事件模型

很多风控项目第一步就上模型，最后发现最基础的事件都没串起来。先把数据打通更重要。

我会优先统一下面这些事件：

register_attempt
register_success
login_failure
login_success
otp_requested
otp_verified
password_reset
security_binding_changed
mfa_method_added
beneficiary_added
order_created
payment_received
withdrawal_requested
content_published
message_sent
session_revoked

每条事件至少带：

{
  "event_id": "全局唯一 ID",
  "event_name": "login_success",
  "event_ts": "服务端时间",
  "account_id": "内部账号 ID",
  "session_id": "会话 ID",
  "device_id": "稳定但合规的设备标识",
  "ip": "请求来源",
  "asn": "网络归属",
  "user_agent": "客户端信息",
  "target_id": "订单、收款人或内容对象",
  "result": "success",
  "risk_context": {
    "new_device": true,
    "proxy_type": "hosting",
    "credential_leaked": false
  }
}

注意几个坑：

  • 时间必须以服务端为准，客户端时间只能当特征；
  • 设备 ID 不能每次清 Cookie 就换一个，也不能偷偷拼接过度采集的隐私数据；
  • 风控结果和原始事实分开存，避免后续无法复盘；
  • 同一个 event_id 要能在网关、业务、风控和客服系统里查到；
  • 处置动作也要记日志，否则只知道“被封了”，不知道谁因为什么封的。

没有这些数据，所谓关系图谱和机器学习基本都是 PPT。

四条可以先上线的组合规则

下面阈值只是示例，上线前必须用自身业务基线回放。

R1：批量注册资源

24 小时内同设备注册账号 >= 8
AND 关联手机号 >= 8
AND 注册后行为序列相似度高

动作：限制高价值权益、追加验证、进入团簇分析。

重点排除：门店设备、企业批量开户、测试环境。

R2：账号接管后固化权限

新设备成功登录
AND 60 分钟内发生换绑或新增 MFA
AND 继续发生导出、提现或新增收款人

动作：阻断最后一个高风险动作，吊销当前会话，用旧绑定渠道通知本人。

重点排除：官方换机流程、客服辅助找回。

R3：稀缺权益自动化

同一受益对象关联账号 >= 4
AND 请求来自多个设备或代理
AND 集中在资源释放窗口
AND 账号历史交易很少

动作：合并配额、降低排队优先级、对受益对象核验。

重点排除：家庭代购、企业差旅、合法代理。

R4：疑似跑分账户

1 小时陌生付款方 >= 12
AND 入账后 15 分钟转出比例 >= 80%
AND 新交易对手占比 >= 90%
AND 账户用途相较历史突然变化

动作：暂缓结算、人工审核、扩展一跳资金关系。

重点排除：小商户、团购、票务、众筹和集中结算。

这四条规则都没有直接“封号”，因为检测和处置是两件事。第一版策略最重要的是把样本捞准、证据留全，并验证攻击是否真的迁移或成本上升。

关系图怎么建才不至于变成大屏

节点不用一开始就很多，先选业务最稳定的五类：

Account ──uses──> Device
Account ──binds─> Phone
Account ──pays──> PaymentInstrument
Account ──benefits──> Target
Account ──connects──> IP / ASN

然后围绕已确认坏账号向外扩一跳：

  1. 找同设备和同支付工具账号；
  2. 找这些账号共同的受益对象；
  3. 检查新节点是否具有相似时间和行为模板；
  4. 只在证据增加时继续扩第二跳。

不要从一个坏 IP 无限扩散。云厂商、校园网、公司 NAT 和移动出口会让图迅速污染。关系的价值也不同：

同支付工具 > 同稳定设备 > 同手机号 > 同地址 > 同 IP

具体权重取决于业务，但“同 IP 就是一伙”通常是最差的起点。

报警之后的 60 分钟

真出事时，不需要先写一份完整报告。

0—5 分钟：止损

  • 暂停提现、导出、群发、换绑等不可逆动作；
  • 吊销高风险会话与 Token；
  • 对涉及资金的事件立即走止付通道；
  • 不要删除账号和日志。

5—20 分钟：画出最小关系图

  • 账号关联了哪些设备、号码、支付工具和收款人；
  • 风险动作前最后一次可信登录是什么；
  • 同设备或支付工具是否还有其他账号；
  • 攻击从哪个时间点开始，是否仍在继续。

20—40 分钟：区分入口与变现

  • 是批量注册、泄露凭据，还是客服找回被绕过；
  • 风险账号最终把权益、数据或资金交给了谁；
  • 封掉当前节点后，攻击是否迁移到相邻节点；
  • 是否涉及外部平台、支付机构或供应商。

40—60 分钟：保全证据并扩大控制

  • 固化原始日志、订单、聊天、登录和操作记录；
  • 记录每个处置动作的时间、人员和理由；
  • 扩大监控，但不要无证据地批量永久封禁；
  • 给客服准备统一解释和受害者恢复流程。

安全团队最常见的失误之一，是忙着封一批号，却没保存攻击发生时的关系快照。两小时后账号换了设备，钱也转走了，只剩一个无法解释的黑名单。

怎么判断策略真的有效

“拦了多少账号”很容易刷高，不适合作为唯一指标。

更值得长期看的是：

指标 它真正回答的问题
每万笔交易欺诈损失 业务最终少损失了吗
高风险动作阻断金额 是否拦在变现前
误报率与申诉恢复时间 正常用户付出了多少代价
账号接管发现时间 从异常登录到报警用了多久
会话吊销完成时间 报警后攻击者还能活跃多久
团簇复发率 封禁后是否换账号继续回来
单次作恶资源消耗 是否迫使对方使用更多账号、设备和资金

一次策略上线后，如果攻击量下降但客服投诉暴涨，可能只是把正常人拦住了；如果封禁量很高但损失不变，可能封的都是已经完成转移的空账号；如果攻击迅速换入口，说明确实打到了成本，但还需要继续跟踪迁移。

最后说点实际的

看完这几个案子，我觉得有三件事比“上一个 AI 风控模型”更优先：

第一，把注册、登录、换绑、权益和支付事件真正串起来。连时间线都拼不出来，模型也只能猜。

第二，把检测对象从账号扩展到受益对象和关系网络。黑灰产最不缺的就是账号，真正昂贵的是稳定设备、支付通道、可信历史和最终变现节点。

第三，让处置尽量靠近不可逆损失。登录异常可以观察，换绑需要加验，提现和数据导出则必须更谨慎。风险控制不是每个环节都用同样的力气。

黑灰产不神秘，也不是一个“黑产画像标签”能解决的问题。它就是一门计算成本和收益的生意。防守方能做的，是用数据把同一批资源重新关联起来，在钱、数据和权益离开之前提高成本，并给真正的用户留下一条能走通的恢复路径。

参考资料