TikTok 4万企业号成钓鱼靶场：黑客用Cloudflare当

3月24日，一批新注册的域名开始活跃。它们托管在Cloudflare上，用Google Storage做跳板，专门盯着一类人——TikTok企业号持有者。

Push Security的最新报告显示，这不是随机扫射，而是一场精密设计的钓鱼战役。攻击者要的不是普通用户，而是能花钱投广告、能触达百万流量的商业账户。

为什么是企业号？

个人号被盗，损失几条视频。企业号沦陷，意味着广告预算、品牌背书、甚至整个营销链路被劫持。

Push Security在报告中点明：TikTok企业号的"高滥用潜力"让它成为香饽饽。恶意广告、虚假推广、加密货币骗局——这些都需要一个看起来合法的发布渠道。企业号的蓝V标识和投放权限，恰好提供了这层伪装。

这并非TikTok首次被盯上。此前平台已出现过恶意视频传播信息窃取木马、假促销页面收割加密货币的案例。但针对企业号的定向攻击，精准度上了个台阶。

攻击链：三层跳转，机器人绕道

钓鱼页面的设计堪称"反侦察教科书"。

第一步，受害者收到链接。Push Security未能确定最初的投递渠道，但推测与Sublime Security此前记录的手法类似——可能是邮件、私信，或伪装成商务合作的邀请。

第二步，链接先跳转到合法的Google Storage地址。这一步是为了绕过邮件安全网关的域名黑名单，让链接看起来"干净"。

第三步，Cloudflare Turnstile（人机验证服务）登场。它像一道安检门，挡住自动化分析工具和安全爬虫。只有真人浏览器能通过，安全厂商的机器人被拦在外面，无法及时标记恶意页面。

第四步，通过验证后，页面再次跳转，落到真正的钓鱼站点。这些域名结构相似，全部托管在同一Google Storage存储桶中，注册时间集中在3月24日，注册商是NiceNIC——一家被网络安全研究者频繁点名的"犯罪友好型"服务商。

整个链条的设计思路很清晰：用合法服务做掩护，用验证机制做过滤，把攻击藏在正常的网络流量里。

假页面长什么样？

Push Security捕获了两个主要模板。

一个是高仿TikTok企业号后台，另一个是伪装成Google招聘的"预约通话"页面。两者都先用一个简单的表单收集信息，验证访客是否使用企业邮箱——这一步是在筛选高价值目标。

通过筛选后，受害者才会看到伪造的登录页。这里藏着真正的杀招：反向代理（Reverse Proxy）。

攻击者的服务器坐在用户和真正的TikTok/Google服务之间，实时转发请求。用户输入账号密码，代理先截获一份，再转发给官方服务器；官方返回的会话Cookie，代理同样复制留存。

这意味着即使用户开启了双因素认证（2FA），攻击者依然能劫持会话。因为2FA验证的是"此刻登录的人是否合法"，而反向代理让攻击者以"合法用户"的身份通过验证，然后带着偷来的Cookie直接接管账户。

一个被忽视的弱点：Google单点登录

Push Security特别提到一个细节：大量TikTok企业号用户习惯用Google单点登录（SSO）登录。

「这意味着，任何用Google账号登录TikTok的人，会在一次攻击中同时丢掉两个账户的控制权。」

攻击者的反向代理同样适用于Google的OAuth流程。用户以为自己在授权TikTok访问Google信息，实际上是把Google账户的钥匙也交给了中间人。企业邮箱、云盘、广告账户——Google生态内的所有资产一并暴露。

这种"一鱼两吃"的设计，让攻击的ROI（投资回报率）直接翻倍。

与Google Ad Manager战役的关联

Push Security将此次行动与去年的另一场攻击联系起来——那一场的目标是Google Ad Manager账户。

两次战役的技术手法高度重合：Cloudflare托管、机器人过滤、反向代理、针对广告平台。攻击者似乎已经形成了一套可复用的"商业账户劫持"方法论，只是在不同平台间切换目标。

这背后有一个值得警惕的趋势：广告平台的账户正在成为网络犯罪的基础设施。控制一个历史清白、有投放记录的企业号，比从零搭建恶意网站要高效得多。平台的风控系统对老账户更信任，用户对企业号的推广内容警惕性更低。

钓鱼攻击正在从"广撒网"转向"养号经营"。

防御建议与现实落差

报告给出的建议清单很标准：警惕陌生邀请、核对域名、使用通行密钥（Passkeys）。

但现实中，商务合作的私信每天都在涌入，域名核对需要用户记住官方URL的每一个细节，而Passkeys的普及率在企业级SaaS中仍然有限。TikTok企业号后台是否支持Passkeys，目前未见明确说明。

更实际的困境是：当攻击者用Cloudflare和Google Storage这类日常可见的服务搭建基础设施，传统的"看域名识风险"方法已经失效。用户看到的可能是turnstile.cloudflare.com的验证页面——完全合法，只是被嵌在了恶意流程中。

Push Security的研究人员承认，他们无法确定最初的钓鱼链接是如何投递的。这个信息缺口本身就很说明问题：攻击者的入口渠道可能比我们想象的更多样，也更隐蔽。

目前，TikTok尚未就此次钓鱼战役公开回应。企业号持有者或许该问自己一个问题：当你的登录流程被中间人完整复制时，双因素认证还能保护什么？