近日，快手平台遭遇有组织的黑产攻击，大量直播间在短时间内被劫持用于传播违规内容。这一事件不仅造成了巨大的负面影响，更暴露了当前互联网平台在应对新型网络攻击时的脆弱性。在较长时间无法解决问题后，最终的解决方案竟然是完全关闭直播入口。我们在强烈谴责黑产违法犯罪行为的同时，行业必须清醒认识到：企业当前的防护模式，在面对高度规模化、组织化、自动化的“闪电战”时已力不从心，必须要对当前的防护体系进行全面升级。
本篇文章从技术层面阐述这一事件以及我对平台防护体系改进方案的个人观点，包括以下三方面内容：
由于平台尚没有详细披露本次被攻击的方式，我们只能从当前简单的陈述之中猜测黑产可能的攻击手法。
攻击链路：钓鱼链接 → 获取老账号凭证 → 窃取有效会话 Token → 绕过二次验证 → 获取设备控制权 → 以"合法老用户”身份发起攻击。
攻击链路：接码平台/卡商获取手机号 → 自动化脚本批量注册 → 伪造或绕过实名认证 → 养号（模拟正常行为）→ 等待时机发起攻击。
账号是攻击行为实施的载体，不同的账号类型攻击手法是不同的，产生的危害力也有差异：
一般来说，老账号拥有正常的注册时间、历史行为、社交关系、消费记录等，设备指纹和登录模式可能已通过平台信任白名单。风控系统会将其判定为“低风险用户”，极难触发警报，单个老账号攻击更具有迷惑性和危害性。不过黑产获取老账号凭证方式主要通过钓鱼链接、木马病毒或者撞库等手段实现，获取难度较高，账号数量规模应该不会太大。
而新账号没有历史行为、交易、社交关系等记录，历史评级很低，容易被系统风控方案判定为高风险账号，单个账号的攻击力相对较低。不过新账号攻击可能意味着黑产已经掌握了平台账号体系漏洞，而可以进行大批量注册形成规模化攻击，如果没有及时修补危害极大。
账号凭证是一个广义的身份集合，包括登录账号（手机号/用户名）、密码（或其变种）、已登录态下的会话 Token/Cookie 、受信任设备指纹等信息。
现在企业广泛采用的实名认证体系是：用户首先提交身份证图片，然后打开手机，摄像头采集人脸视频信息，app 发出眨眼、张嘴等指令，在用户按指令进行上述操作后完成实名认证。
绕过实名认证体系也就是说黑产已经破解了当前平台认证接口的加密和签名验证等机制，可以直接发送"认证成功"这种篡改伪造的数据包到认证接口，从而绕过这一体系。
伪造实名认证体系是指黑产可以利用手机漏洞（比如：android 漏洞）在实名认证时直接注入预先准备好的人脸识别视频数据流。而这也意味着黑产已通过多种渠道获取到了大量的真实身份证图片，并根据上面的"照片"通过类似 deepfake 等技术手段预先生成眨眼、张嘴的认证视频片段。比如 App 发出"眨眼"的指令，就传入一个"眨眼"的视频片段，从而起到欺骗平台认证体系的作用。
伪造和绕过实名认证体系两者差异很大，修复漏洞的方式也截然不同。相对而言绕过实名认证体系对平台来说更容易修补，但如果黑产已经具备技术手段可以伪造实名认证体系，则潜在危害非常巨大，这就不在是一个互联网企业的问题而是所有互联网企业均要面对的问题。
首先，介绍一下直播技术基本流程：
上面是一个基本流程，真实环境中可能存在一些不同：
在了解上面流程之后就知道黑产可针对多个环节通过不同的技术手段分别进行攻击。
这里的预制违规视频都是黑产特殊处理后的视频，而不是随便找的。也就说这些视频大多都是对"AI 机审大模型"有抗体的视频。黑产通过一些工具可以对视频的特征进行轻微调整，将原违规视频转化为"对抗性样本"，起到躲避被大模型识别的效果。
黑产的攻击方式可分为多种，比如：
由黑产直接控制的发动攻击的设备称为"肉鸡"，在移动互联网时代的肉鸡和 PC 时代的肉鸡已经有些不同。移动互联网时代的肉鸡可以分为多种：
黑产通过中心化的系统来控制所有肉鸡，包括升级攻击脚本和下发指令。肉鸡的攻击形式可分为三种：
也就是由脚本控制 app 的打开、关闭、处理弹窗、自动点击直播按钮进入直播页面，随后脚本将从摄像头采集视频改为推流协议直接上传。
Hook 注入是首先逆向破解 app 客户端内的代码执行逻辑，通过 Hook 技术手段直接侵入 app 进程之内，完全绕开 app 自身的 UI 逻辑，然后直接调用内部函数，通过篡改里面的参数传入实现违规视频的上传。
攻击者首先破解平台推流接口的加密验签逻辑，然后直接模拟 http 请求发送违规视频数据包。
一次完整网络攻击，会同时使用多种手段，而攻击者也可能在攻击前进行了数月的准备工作，也就是"养号"，在这期间会让账号进行正常的登录、浏览等操作，来让它的行为轨迹看起来很合理，从而提高账号的权重。
应对网络攻击和网络攻击的溯源是多个部门互相协同的工作，而不仅是网安一个部门的职责，跨部门的协作、沟通、数据共享非常重要。
这一起网络攻击事件所需要排查的技术点和优化点很多，也都比较明显，比如几个相对重要的排查点：
这类网络攻击事件不仅暴露出企业自身防护体系的薄弱，更深层次地折射出企业在数据化运营能力和实时预警响应机制上的严重不足。其根本原因可归结为以下两点：
风控系统所依赖的、能够准确反映“当前业务状态”的实时特征极为匮乏。这种“实时特征贫血”导致风控模型在面对新型或突发攻击时反应滞后、识别能力弱。此外，现有特征往往片面、零散，容易被黑产通过模式变异或一些技术手段欺骗。
网安团队在日常监控与应急响应中，缺少跨业务线、跨功能模块的“实时交叉指标”。没有这些全局性、关联性的数据指标作为决策依据，团队很难在攻击发生时快速定位问题根源，难以实现跨环节的联动防御。
本文提出的全景式业务监控，是基于通用型流式大数据统计技术构建的新一代业务监控与预警体系。它突破了传统监控方案在实时性、覆盖面和关联分析上的局限，具备以下核心价值：
相对而言，全景式业务监控更侧重于：全链路覆盖、多维度实时指标、跨系统数据关联和面向风控与决策的实时特征供给。
举一个例子：App 某页面有一个表单模块，表单提交后数据写入 DB ，我们要实时统计表单提交量，应该如何统计呢？
按照当前企业的做法毫无疑问是统计数据库的写入量。从业务逻辑层面来说这是完全没有问题的，但如果从业务监控的角度来说，假如这个业务较为重要，这种方案就存在着明显不足。
比如：
而更为规范的做法是：
全景式业务监控提倡在一个业务的所有重要环节进行全链路监控，每个监控指标做到数据吻合。
网络攻击应急机制包括两个核心操作：1 、快速判断出黑产的攻击方式，2 、根据攻击方式的特征筛选出直播账号列表然后进行封禁。
全景式业务监控在这一过程中具有天然优势，比如：
这种攻击方式只要在 App 内推流数据包上传逻辑前添加监控埋点，并将埋点数据和推流接口的请求量数据进行比对，就可以明显判断出是否存在黑产盗刷接口的可能。而通过两方面的实时日志关联（ App 埋点日志和接口服务日志）就可以快速初步筛选出黑产攻击账号列表。
肉鸡为了击垮平台的"人审"体系，会在短时间内同时发起开播和推流，而这种操作也会形成前一刻和后一刻明显的流量异常，而通过关联两个时段的实时日志也可以初步筛选出攻击账号列表。
反馈接口是否存在过载攻击，大多数情况下可以通过反馈接口服务监控埋点和 App 上报的反馈日志埋点进行对比分析，快速判断出过载攻击的可能，而且关联实时日志库可以提取攻击设备信息然后进行阻断。
从 App 启动、用户交互、开播按钮点击、推流接口调用、数据分发到内容审核，业务流程中充满各类细节与依赖。全景式业务监控旨在为企业构建一个“遍布全身”的实时指标感知网络，支持从整体业务层面到细分维度（如 App 版本、IP 段、设备指纹、直播间等）的立体化监控，全面提升企业对此类事件的应急响应能力。
目前之所以企业的"实时指标"和"实时特征"极为匮乏，根本原因在于指标获取所采用的技术方案仍然以：Flink 、Spark 、ClickHouse 、Doris..等技术实现，这些技术方案过于臃肿、笨重难以低成本、高效率的实现大批量实时指标。
而通用型流式大数据统计技术侧重于解决"大批量数据指标的并行计算问题"，擅长应对繁杂的实时指标计算场景，对于企业应急机制建立具有非常重要的实际意义。
可参考开源项目：xl-lighthouse ，开源地址： https://github.com/xl-xueling/xl-lighthouse
目前互联网大厂的数据指标数量可以达到 10 万~30 万个，而其中的实时指标数量更为匮乏，而通用型流式大数据统计技术可将大型企业数据指标数量提升到 1000 万~3000 万个，帮助企业建立更完善的数据化运营体系，全方位提升企业对于紧急事件的应对能力！
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。