官方域名成“钓鱼温床”？Google Cloud自动化功能遭滥用，全球3000家企业中招
一、一封“来自Google”的邮件，竟是通往钓鱼网站的入口
2025年12月下旬，一家位于新加坡的跨国物流公司IT管理员李伟收到了一封看似再正常不过的邮件：
发件人：no-reply@notifications.google.com
主题：您有一条新的语音留言（来自+852 XXXX XXXX）
正文：点击下方链接收听您的语音消息 → https://storage.googleapis.com/xxxxx/listen-voice.html
邮件使用了标准的Google通知模板，发件域名是Google官方的notifications.google.com，链接也指向storage.googleapis.com——一个属于Google Cloud Storage的合法子域名。一切看起来都“无可挑剔”。
李伟点了进去。页面先是弹出一个Google风格的CAPTCHA验证码：“我不是机器人”。他顺手勾选，下一秒却被重定向到一个几乎与Microsoft 365登录页一模一样的界面，要求输入公司邮箱和密码。
他输入了——系统提示“登录成功”，但几小时后，公司财务部门发现有人正试图通过Outlook Web Access导出客户合同。
这不是个例。根据网络安全公司Check Point Harmony Email Security于2025年12月24日发布的报告，过去两周内，全球已有超过3,200家组织收到此类钓鱼邮件，累计投递量达9,394封。而这一切，都源于攻击者对Google Cloud一项合法自动化服务的巧妙滥用。
二、漏洞不在代码，在“信任链”：Google Cloud的“Send Email”任务被武器化
此次攻击的核心，并非利用0day漏洞或账户盗用，而是钻了企业对“官方域名”盲目信任的空子。
攻击者注册了一个合法的Google Cloud项目，启用了名为“Application Integration”的低代码自动化平台（原名AppSheet Automation）。该平台允许用户通过图形化界面创建工作流，例如：“当某事件触发时，自动发送一封邮件”。
其中，“Send Email”任务支持以no-reply@notifications.google.com为发件人发送邮件——这是Google官方用于系统通知的标准地址，且完全通过SPF、DKIM和DMARC三大邮件认证协议验证。
这意味着：
邮件头显示“Authentication-Results: pass”；
收件方邮件网关不会标记为伪造；
用户看到的是“真正的Google邮件”。
“这就像有人用你家的门禁卡进了小区，再敲你家门说‘物业来修水管’——你根本不会怀疑，”公共互联网反网络钓鱼工作组技术专家芦笛在接受本报采访时比喻道，“问题不在于门禁卡被复制，而在于我们默认‘持卡者=可信’。”
更狡猾的是，攻击者在邮件中嵌入的链接并非直接指向钓鱼页面，而是先跳转至googleusercontent.com或storage.googleapis.com下的一个HTML页面。这些域名均为Google官方所有，信誉极高，传统安全网关几乎不会拦截。
该页面通常包含一段JavaScript，执行如下逻辑：
<!-- 示例：伪装成语音留言页面的钓鱼跳板 -->
<!DOCTYPE html>
<html>
<head><title>Google Voice Message</title></head>
<body>
<div id="captcha-container">
<!-- 嵌入reCAPTCHA v2 -->
<script src="https://www.google.com/recaptcha/api.js"></script>
<div class="g-recaptcha" style="margin-top:12px">