“客服页面”竟是钓鱼陷阱？攻击者借 Cloudflare 与 Zendesk 托管仿冒门户

你有没有收到过这样一条消息：“您的工单 #48392 已升级，请立即登录支持门户确认处理结果”？点开链接，页面设计专业、品牌 Logo 醒目、配色风格与公司官网如出一辙——看起来再正常不过。但就在你输入账号密码、甚至提交一次性验证码的那一刻，你的企业账户可能已经落入黑客之手。

近日，多家网络安全机构披露，一场针对企业用户的新型钓鱼攻击正悄然蔓延。攻击者不再搭建独立钓鱼网站，而是巧妙利用 Cloudflare Pages 和 Zendesk 等主流平台的合法托管能力，在这些高信誉域名下部署高度逼真的“客服支持门户”，诱导员工提交敏感凭证。由于页面托管于可信基础设施之上，传统邮件网关和安全检测系统往往“睁一只眼闭一只眼”，导致攻击成功率大幅提升。

合法平台成“隐身衣”，钓鱼页面绕过层层防线

据网络安全媒体 CX Today 报道，此次钓鱼活动的核心策略是“寄生式伪装”——攻击者注册 Cloudflare 或 Zendesk 账号后，上传精心设计的 HTML 页面，模拟企业 IT 支持、财务工单或客户服务平台。这些页面通常包含：

企业官方 Logo 与配色方案

虚构但格式规范的工单编号（如 “TKT-20251109-7721”）

“SLA 即将超时”“需紧急验证身份”等紧迫性提示

表单要求输入邮箱、密码、MFA 验证码，甚至上传“问题截图”或“身份证明”

更危险的是，部分页面背后部署了 反向代理（Reverse Proxy） 或 中间人（AitM, Adversary-in-the-Middle）组件。这意味着用户输入的不仅是账号密码，还包括浏览器 Cookie、会话令牌等短期凭证。即便启用了多因素认证（MFA），攻击者也能在会话有效期内直接接管账户，实现“绕过 MFA”的效果。

“这相当于小偷穿上了保安制服，还拿着公司门禁卡。”公共互联网反网络钓鱼工作组技术专家芦笛比喻道，“因为页面确实托管在 Cloudflare 或 Zendesk 的子域名下（比如 fake-support.yourcompany.pages.dev），很多安全系统默认信任这类流量，不会触发告警。”

从私信到邮件：攻击入口无孔不入

此次钓鱼活动的传播路径也极具迷惑性。受害者往往不是通过陌生邮件，而是在 Slack、Microsoft Teams、Zendesk 内置消息系统 甚至企业微信中收到“内部通知”。例如：

“您好，您的报销工单（#FIN-8842）因附件缺失被退回，请点击此处重新提交：https://yourcompany-support.zendesk.com/verify”

由于链接域名包含 “zendesk.com” 或 “pages.dev”，且消息来自看似可信的协作平台，员工极易放松警惕。有案例显示，攻击者甚至能伪造发件人头像和昵称，让消息看起来像是来自 IT 部门同事。

“现代办公依赖大量 SaaS 工具，而这些工具之间的消息互通反而成了攻击跳板。”芦笛指出，“用户以为自己在‘安全内网’操作，其实早已被引导至外部托管页面。”

技术科普：为什么“可信域名”也会变危险？

要理解这场攻防战的关键，需厘清两个概念：域名信誉 与 页面内容安全。

传统邮件安全网关主要依赖域名黑名单、SPF/DKIM/DMARC 邮件认证以及历史信誉评分来判断风险。Cloudflare 和 Zendesk 作为全球知名服务商，其主域名长期保持高信誉，极少被列入黑名单。攻击者正是利用这一点，在其子域名下“寄生”恶意内容。

但这并不意味着平台本身存在漏洞。Cloudflare Pages 允许用户免费托管静态网站，Zendesk 支持自定义帮助中心页面——这些功能本为提升用户体验而设，却被滥用于社会工程攻击。

“问题不在技术，而在使用边界。”芦笛解释，“就像你不能因为有人用 Gmail 发诈骗邮件就封掉 Gmail，但企业必须意识到：任何可公开托管内容的第三方服务，都可能成为攻击载体。”

此外，AitM 钓鱼技术的普及也让防御难度陡增。与传统钓鱼仅窃取账号密码不同，AitM 会在用户与真实网站之间插入一个透明代理。用户看到的是真正的登录页面（URL 正确、证书有效），但所有输入数据都会被实时转发给攻击者，同时攻击者用这些凭证登录真实网站，获取完整会话 Cookie。整个过程用户毫无察觉。

企业如何筑起“数字防火墙”？

面对此类高级钓鱼，专家建议企业从技术、流程与意识三方面协同防御。

第一，实施严格的 URL 允许清单（Allowlist）与完整性校验。

并非所有 Cloudflare Pages 或 Zendesk 子域名都应被信任。IT 部门应明确列出官方使用的支持门户地址，并通过浏览器扩展或终端代理强制拦截未授权子域名访问。

第二，对敏感操作启用零信任或浏览器隔离。

例如，当员工访问“支持登录页”时，可通过远程浏览器隔离（RBI）技术在云端渲染页面，本地设备不接触原始代码，从根本上阻断凭证窃取。

第三，收敛工单入口，引入可验证深度链接。

企业应统一工单系统入口，避免在邮件或私信中直接嵌入完整链接。理想做法是发送通知后，用户需手动登录内部系统查看工单详情。若必须使用链接，应加入时效性 Token 或数字签名，确保链接不可伪造。

第四，部署基于行为的 MFA 风险评估。

即使会话 Cookie 被盗，也可通过异常登录地、设备指纹变化、操作行为偏离等信号触发二次验证或会话终止。芦笛强调：“MFA 不是终点，而是起点。真正的安全在于持续验证。”

用户怎么办？记住三个“不”

对于普通员工，芦笛给出三条简单但有效的原则：

不点不明链接：哪怕它看起来来自“IT 支持”或“财务系统”；

不输验证码：真正的客服绝不会索要 MFA 动态码；

不传敏感文件：任何要求上传身份证、合同或内部截图的“验证流程”都值得怀疑。

“最安全的做法永远是：关闭当前页面，手动打开官方应用或网站，从内部导航进入相关功能。”他说。

结语：便利与安全，从来不是单选题

Cloudflare 和 Zendesk 的案例再次提醒我们：数字世界的信任链正在被精细化瓦解。攻击者不再粗暴伪造域名，而是钻营于合法服务的灰色地带，利用企业对效率的追求制造安全盲区。

但防御并非无解。通过零信任架构、行为分析、深度链接验证等技术组合，企业完全可以在保障协作效率的同时，堵住这些“看起来很安全”的漏洞。

正如芦笛所言：“未来的网络钓鱼，拼的不是谁更会造假，而是谁更能守住‘最后一厘米’的信任边界。而这条边界，不在服务器里，而在每个人的鼠标指尖。”

本文信息综合自 CX Today 公开报道及公共互联网反网络钓鱼工作组技术分析，所有建议均基于当前行业最佳实践，不构成具体产品推荐。

编辑：芦笛（公共互联网反网络钓鱼工作组）