导语

那些“已满”的座位，可能从来没被真正买走过。那些退掉的手机，可能从一开始就不是真实购买。

一批账号在热门航线放票后秒级提交订单锁住座位，支付时效一到便自动失效，随后几秒内重新占座——"占位→失效→重占"的循环贯穿整条航线销售周期，脚本驱动、间隔精确到秒级。航司的库存系统，被当成了免费停车场。

航空与电商看似相隔很远，却面临着同一类业务风险：攻击者利用正常规则反复占用或套取资源，每一笔请求都能通过审核，连起来却是一场有组织的套利。

据杭州临安警方通报，一个买家用同一张快递单号反复退款，两个月取走 8 部手机；据宁波鄞州公安通报，20 人横跨 11 省"买多退少"作案 250 余次，一家企业损失超 50 万元。

攻击者挑战的不是企业的技术防线，而是摸清楚业务流程不会回头看；系统确认了“这笔请求合规吗”，但从未问过“这个账号之前做过什么”。

库存系统被当成了「免费停车场」

安全团队最初注意到异常，是因为一条热门商务航线的“未支付取消率”突然飙升。

这些取消不是随机的。节奏高度一致：集中在放票后的前几分钟，取消时间接近支付时效的最后一刻，下一轮占座几乎在上一轮失效的瞬间完成。

进一步追踪发现，这些账号提交订单的时间间隔精确到秒级，设备指纹各不相同但底层环境指向同一批云手机或模拟器。操作者不是旅客，是代理人——用脚本管理多个账号，对热门航线反复执行“占座→等待失效→重占”。

这个循环造成两重损失：

真实旅客看到座位“已满”，被迫加价找代理人购买，原本属于航司的收入空间被截走；

库存数据严重失真——系统显示高满座率，起飞时客座率却远低于预期，运力被白白浪费。

更隐蔽的是周期性。每条热门航线放票时，同样的循环就启动一次。它不像一次欺诈那样容易识别—每一笔订单单独看都合规：账号真实、航线有效、提交和取消都在规则允许的范围内。

问题只在于，这些订单从始至终没有购买意图。它们存在的唯一目的，是锁住座位。系统确认了“这笔请求合规吗”，但从未问过“这个账号、这个凭证、这台设备，之前做过什么。”

换了行业换了手法，只认单笔不看历史

把航司占座和电商退款放在一起看，攻击链路虽然行业不同，但每一环都在做同一件事：用“单笔合规”掩盖“群体异常”。

账号从哪来——接码工厂。代理人需要大量账号分散占座，黑产需要大量账号批量领券和退款。

南充嘉陵警方通报的案件中，一个超市老板用接码平台租借 7000 余个手机号，注册 6000 余个假账号，兑换物资十余吨。

在航司中，代理人同样靠接码平台批量准备账号，再由脚本统一管理。

环境怎么伪装——设备改码。航司案中，多个账号来自同一批云手机或模拟器，每个看起来是独立设备，底层却高度一致。西安警方通报的"薅羊毛外挂软件"案中，使用者下单 6 万余次，涉案资金 1000 余万元——伪装已经产品化。

规模如何放大——自动化脚本。脚本负责在放票瞬间高频提交、管理支付时效、失效后立即重占。上海警方破获的运费险诈骗案更极端——一个团伙开了 100 多家网店，不为卖货，只为批量虚构交易骗取理赔款，13 人落网，涉案超过 300 万元。

风险怎么变成业务损失——低价变现。航司的库存被锁、收入流向代理人。电商的营销预算被假号吃掉、高价值商品在退款中流出。福建安溪一个人寄空包裹冒充退货，一年骗走 18 万元货款——系统看到"已签收"就自动退款，谁会拆箱检查？

损失形式不同，但都落在同一个地方——企业的核心资产被低成本套取。

三个「没问题」，叠在一起就是大问题

安全负责人常问：验证码上了、设备指纹采了、频控做了、黑名单加了——为什么还是被打穿？

因为每条防线回答的都是“眼前这笔有没有问题”，攻击者利用的恰恰是“每一笔都没问题、但串起来就有问题”的间隙。

第一个"没问题"：验证码通过了。 打码平台几分钱一次，对代理人可以忽略。航司案中，账号注册和订单提交都通过了验证码，但背后是脚本在跑。

第二个"没问题"：设备看起来正常。 云手机和模拟器生成完全正常的设备指纹。几十个账号来自同一台物理服务器的虚拟环境——每个都是“正常设备”，但没人发现它们共享同一台宿主机。

第三个“没问题”：流程走完了。 航司案中，订单提交合规、支付时效内操作合规、自动取消合规——每一项都对。但没人问过：这个账号上一轮也占过这条航线吗？这批账号的占座-失效-重占频率是不是异常？

三个“没问题”各自成立，但它们之间缺少一座桥。

四类能力，在资源流出前亮起红灯

三个“没问题”各自成立却串不起来看，根子在于没有一类能力能同时回答“这笔有没有问题”和“这个账号之前做过什么”。要补上这座桥，不是加一条更复杂的规则，而是把行为验证、设备风险识别、账号安全和业务风控放进业务流程，在不同风险出现时及时介入。

行为验证：在新人进入时识别机器操作。

→ 让营销补贴流向真实消费者

一批手机号短时间集中注册，进入平台后直奔领券、补贴等权益，说明资源池可能正被批量账号消耗。此时可结合交互节奏、手机号来源和注册后的行为路径，判断是否为真实用户。

正常用户直接放行；存在匀速点击、无停顿、毫秒级响应等机器特征的账号，则增加验证或延迟发放权益。

设备风险识别：在资源分配前看穿批量伪装。

→ 在库存被锁、预算被吃之前拦住批量占位

云手机、模拟器和多开工具可以不断更换设备指纹，底层环境仍会留下关联特征。通过关联设备环境、IP和操作轨迹，可以发现不同账号之间的设备复用。

当同一批设备反复占座，或集中领券、下单时，应调整资源分配或转入复核。

账号安全：从单个账号追踪到整组操作者。

→ 让“活跃数据”背后的集群信号浮出水面

单笔订单可能符合规则，但多个账号走出几乎一致的“提交、等待失效、重新占用”路径，已经偏离正常行为。

通过关联手机号、设备、IP和历史操作，可以识别隐藏在不同账号背后的同一批操作者。账号群行为相似度过高时，可增加验证、设置冷却期或限制高价值资源获取。

业务风控：在退款、核销和资源释放前完成最后核验。

→ 在退款和资源释放环节止损，让判断从“此刻这一笔”升级为“此人这一段”

结合订单、凭证和历史处置结果，对高风险请求采取增强验证、延迟处理或人工复核。支付、退货和退款结果应持续回流，为后续判断提供依据。集中取消后立即重占，应触发周期性占座核验；同一快递单号多次退款，则触发凭证唯一性校验。

END

被脚本锁住的座位，和被反复使用的快递单号，暴露的是同一件事：当系统只看当下这笔、不看这笔和上一笔的关系时，每一次攻击都会伪装成正常交易。

衡量安全投入的标准不该是“拦住了多少”。该问的是：异常占座有没有在座位被锁住前进入复核？营销资产有没有流向真实消费者？正常用户是否仍能顺畅交易？

安全投入真正的回报，在于事前阻止了多少本不该发生的损失——让座位流向真旅客，让补贴流向真用户，让退款在存疑时多停一秒。

今天就做一件事：拉一份订单日志，查一查你的热门资源上，有多少“占而不付”的循环在反复发生。