文章总结： 文章揭露黑客利用GoogleCloud服务滥用官方域名发信，绕过传统邮件验证机制。攻击通过Google云存储重定向与AWS托管的虚假微软登录页实施跨云钓鱼，并利用假验证码对抗扫描。建议企业调整网关信任策略，封禁特定发件人，限制OAuth权限，并加强员工对跨平台登录的安全培训。 综合评分： 88 文章分类： 威胁情报,安全意识,安全运营,社会工程学,实战经验

这是一个“完美”的局：谷歌发信、微软收割，你的安全网关还好吗？

原创

Hankzheng

技术修道场

2026年1月7日 07:59 广东

大家好，最近我在看威胁情报的时候，注意到 Check Point 发布了一份非常有意思（也很吓人）的报告。说实话，咱们做 IT 运维和安全的，平时最头疼的就是钓鱼邮件。但通常情况下，我们还能教员工：“看发件人域名啊！不是公司域名的都是骗子！”

但是，如果这封钓鱼邮件，真的是从 Google 的官方服务器发出来的呢？

没错，今天的这个 Case，就是黑客利用 Google Cloud 的 Application Integration（应用集成）服务，给自己披上了一层近乎无敌的“官方马甲”。

这不仅仅是一次简单的钓鱼，而是一场利用了 Google、AWS 和 Microsoft 三大云巨头基础设施的“借刀杀人”大戏。今天，我就带大家拆解一下这背后的技术逻辑。

01 当“信任”成为漏洞：SPF 和 DMARC 是怎么失效的？

咱们先看这次攻击最核心的“骚操作”——滥用 Google 的“Send Email”任务。

Google Cloud 有个服务叫 Application Integration，你可以把它理解为一个企业级的自动化工作流平台（类似高端版的 Zapier 或者 n8n）。在这个平台里，有一个标准动作叫“Send Email”。

黑客发现，这个功能允许用户配置自定义内容的邮件，并且——这是重点——邮件的发件人地址显示的是：

noreply-application-integration@google[.]com

大家看出问题了吗？

对于绝大多数企业的邮件安全网关（SEG）来说，google.com 是绝对的白名单。

• SPF 检查？

  Pass！因为邮件确实是从 Google 的 IP 发出来的。

• DKIM 签名？

  Pass！Google 的服务器亲笔签名。

• DMARC 策略？

  Pass！

这就意味着，传统的邮件身份验证机制瞬间失效。黑客不需要费尽心机去伪造域名，他们直接“寄生”在了 Google 的合法基础设施上。

虽然 Google 文档里限制了这个功能最多只能发给 30 个收件人，但黑客显然不在乎这个限制——他们通过大量创建实例，在短短两周内（2025年12月的数据）就精准发送了近 9400 封邮件，瞄准了全球 3200 多个企业客户。

02 环环相扣：多阶段重定向与 CAPTCHA 盾牌

光有一个合法的发件人还不够，黑客的后续链路设计得也相当“鸡贼”。他们设计了一个多阶段的重定向（Redirection chain），目的只有一个：欺骗你的眼睛，同时也欺骗安全扫描器。

我们来复盘一下这个攻击链条：

1. 诱饵（The Lure）： 邮件内容伪装成“语音邮件提醒”或者“文件共享通知”（比如“Q4 财务报表已共享”），诱导你点击。

2. 第一跳（First Hop）： 链接指向 storage.cloud.google.com。 技术解读： 这是一个受信任的 Google Cloud Storage 域名。很多防火墙看到这也不会拦截。

3. 第二跳（Second Hop）： 用户点击后，重定向到 googleusercontent.com。 技术解读： 在这里，黑客部署了一个假的 CAPTCHA（人机验证）或者是图片验证。

为什么要这么做？ 这不是为了防用户，而是为了防安全厂商的爬虫。自动化的安全沙箱通常无法通过 CAPTCHA，因此无法检测到后面真正的恶意载荷。这就相当于给恶意链接加了一层“防扫描盾牌”。

4. 终局（The Payload）： 一旦真实用户通过了验证，页面就会跳转到一个伪造的 Microsoft 365 登录页。

注意到了吗？发件人是 Google，中间跳板是 Google，最后偷的却是微软的账号。 这不仅降低了用户的警惕心，还把“跨云作战”玩明白了。

03 升级版玩法：OAuth 授权钓鱼 & AWS 乱入

这事儿还没完。根据 xorlab 和 Ravenmail 的最新补充分析，这波攻击还有变种。

有些黑客不满足于仅仅骗取你的账号密码（毕竟现在大家都有 MFA 多因素认证了），他们开始搞 OAuth 同意钓鱼（Consent Phishing）。

• 攻击手法：

  诱导你点击授权一个名为“Document Viewer”之类的恶意 Azure AD 应用。

• 后果：

  一旦你点了“Accept”，黑客就拿到了访问令牌（Access Token）和刷新令牌（Refresh Token）。这意味着即便你改了密码，黑客依然可以通过 API 长久地访问你的邮件、OneDrive 文件甚至 Azure 资源。

而且，为了进一步混淆视听，有些假的登录页面甚至是被托管在 AWS S3 存储桶上的。

Google 发信 -> AWS 托管页面 -> 偷取 Microsoft 凭据。好家伙，三大云厂商被他们一家伙全串起来了，这让单一维度的防御手段非常被动。

04 作为技术人，我们该怎么防？

目前 Google 官方表示已经封禁了相关的恶意活动，并正在优化 Application Integration 的防滥用机制。但作为企业 IT 管理者，我们不能只指望云厂商修 Bug。

针对这种利用“合法服务”的攻击，我有几点建议：

1. 重写安全规则：

   不要在邮件网关上无脑信任 google.com 或 outlook.com 及其子域。需要结合上下文分析。

2. 关注异常行为：

   如果你们公司平时业务根本不涉及 Google Cloud 的 Application Integration 服务，可以在网关层面直接将 [email protected] 列入黑名单或隔离区。

3. 加强 OAuth 审计：

   去 Azure AD（现在叫 Entra ID）后台看看，限制用户能够自主授权的第三方应用权限。对于普通员工，最好禁止他们随意同意 OAuth 请求。

4. 安全意识培训要升级：

   告诉员工，“官方邮件”也不一定是真的官方。特别是涉及到跨平台跳转（比如 Google 邮件让你登微软账号）的情况，100% 是诈骗。

写在最后

这次的攻击案例非常典型，它标志着“Living off the Cloud”（寄生云端）攻击手法的成熟。黑客不再需要自己搭建基础设施，而是直接滥用我们信任的云服务。

对于咱们做技术的来说，这意味着“基于信誉”的防御体系（Reputation-based defense）正在面临前所未有的挑战。

互动话题： 你们公司的邮件网关最近有拦截到类似的“官方”钓鱼邮件吗？欢迎在评论区留言交流！

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：技术修道场 Hankzheng《这是一个“完美”的局：谷歌发信、微软收割，你的安全网关还好吗？》