一、一封“来自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" data-sitekey="攻击者控制的公钥"></div>
<button onclick="verifyAndRedirect()">播放语音</button>
</div>
<script>
function verifyAndRedirect() {
// 实际并不验证CAPTCHA，仅作为心理障眼法
// 用户以为通过验证才可继续，实则立即跳转
window.location.href = "https://fake-m365-login[.]xyz/auth";
}
</script>
</body>
</html>
注：真实样本中，CAPTCHA常为静态图片或虚假验证，目的仅为增加“合法性”感知。
一旦用户点击“播放”或完成CAPTCHA（无论真假），就会被重定向至托管在第三方域名（如.xyz、.top）上的高仿Microsoft 365、Okta或Salesforce登录页。凭据提交后，攻击者不仅获取账号密码，还可能诱导用户输入MFA验证码，实现完全账户接管。
三、为何传统防御体系集体失灵？
这场攻击之所以高效，正是因为它精准绕过了当前企业邮件安全的三大支柱：
1. SPF/DKIM/DMARC全部“Pass”
SPF：邮件由Google IP发出，匹配_spf.google.com记录；
DKIM：Google自动为notifications.google.com签名；
DMARC：策略为p=reject，但因前两者通过，结果为“pass”。
“很多企业把DMARC当成终极防线，认为‘只要通过就是真邮件’，”芦笛指出，“但DMARC只验证‘发件域名是否被冒用’，不验证邮件内容是否恶意。一旦攻击者能从合法渠道发信，这套体系就形同虚设。”
2. URL信誉检测失效
初始链接如https://storage.googleapis.com/abc123/login.html属于Google高信誉域名，VirusTotal、Cisco Talos等主流信誉库均标记为“安全”。即使该页面仅存在几分钟，也足以完成钓鱼。
3. 沙箱难以捕获动态跳转
多数邮件沙箱在分析链接时，仅抓取首层页面。若该页面无明显恶意脚本（如无eval()、无外连可疑IP），就会判定为“干净”。而真正的钓鱼发生在二次跳转之后，沙箱往往无法模拟用户交互（如点击按钮）。
“攻击者正在把‘信任基础设施’变成攻击基础设施，”芦笛说，“Google、Microsoft、Cloudflare……这些高信誉域名成了他们的‘隐身衣’。”
四、技术深潜：从Google Cloud工作流到凭据收割机
要复现此类攻击，攻击者只需完成以下几步（均在Google Cloud免费额度内）：
步骤1：创建Google Cloud项目并启用Application Integration
# 通过gcloud CLI（非必需，GUI即可）
gcloud projects create phishing-campaign-2025
gcloud services enable appintegration.googleapis.com
步骤2：配置“Send Email”任务
在工作流编辑器中，设置：
发件人：系统自动使用no-reply@notifications.google.com
收件人：从CSV导入目标邮箱列表
正文：嵌入伪装链接，如：
<a href="https://storage.googleapis.com/phish-bucket/voicemail.html">收听留言</a>
步骤3：上传钓鱼跳板页面至Google Cloud Storage
gsutil mb gs://phish-bucket-2025
gsutil cp voicemail.html gs://phish-bucket-2025/
gsutil acl ch -u AllUsers:R gs://phish-bucket-2025/voicemail.html # 设为公开可读
步骤4：部署最终钓鱼页面（外部服务器）
使用开源工具如Muraena或Evilginx2搭建反向代理钓鱼框架，自动抓取目标登录页、记录凭据、转发会话Cookie，实现透明代理式钓鱼。
整个过程无需黑客技术，仅需基础云操作知识。而Google Cloud对此类“合法使用”的监控极为有限——毕竟，每天有数百万开发者使用相同功能发送通知邮件。
五、防御升级：从“信域名”到“看行为”
面对这种“合法通道+恶意内容”的混合攻击，企业必须重构邮件安全策略。芦笛提出四层应对方案：
1. 邮件网关需支持“上下文深度分析”
不仅检查发件人域名，还需分析邮件内容语义。例如：
“Google通知”却要求登录Microsoft账户？矛盾！
链接虽属googleusercontent.com，但路径含/login/、/auth/等敏感词？
建议启用AI驱动的内容理解引擎（如Proofpoint TAP、Mimecast ICED）。
2. 实施URL重定向链追踪
部署支持多跳URL解析的安全网关。当检测到链接跳转超过两层，且最终域名与初始域名无关时，应触发告警或阻断。
例如，使用Python requests库模拟跳转链：
import requests
def trace_redirects(url, max_hops=5):
session = requests.Session()
resp = session.get(url, allow_redirects=False)
hops = [url]
while resp.status_code in (301, 302, 307) and len(hops) < max_hops:
next_url = resp.headers['Location']
hops.append(next_url)
resp = session.get(next_url, allow_redirects=False)
return hops
# 示例：检测是否最终跳转至非Google域名
chain = trace_redirects("https://storage.googleapis.com/.../voicemail.html")
if not all("google.com" in u for u in chain):
print("SUSPICIOUS REDIRECT CHAIN:", chain)
3. 强制内部用户访问SSO门户，而非直接登录SaaS
企业应配置Azure AD或Okta作为唯一入口，禁止员工直接访问login.microsoftonline.com。这样即使凭据泄露，攻击者也无法绕过企业级条件访问策略（如设备合规性检查）。
4. 员工安全意识培训需“去神话化”
“不要再告诉员工‘看发件人是不是官方邮箱’，”芦笛强调，“要教他们：任何要求你输入密码的链接，哪怕来自Google、Apple、银行，都必须手动输入官网地址，而不是点链接。”
六、Google的回应与行业反思
截至发稿，Google尚未就此次事件发布官方安全公告，但Check Point表示已与Google安全团队协调，后者已对部分滥用项目采取限制措施。
然而，问题根源并未解决。类似滥用已非首次：
2023年，攻击者利用Microsoft Azure Logic Apps发送钓鱼邮件；
2024年，AWS SES被用于投递DocuSign仿冒邮件。
“云服务商提供强大自动化工具是好事，但必须配套更细粒度的滥用检测，”芦笛说，“比如，对新创建项目批量发送邮件的行为进行速率限制，或对包含外部重定向的HTML页面自动扫描。”
更深层的问题在于：整个互联网的信任模型建立在“域名=身份”的假设上，而这一假设正在崩塌。当攻击者能租用顶级云服务、生成合法证书、通过所有邮件认证，传统边界防御便宣告失效。
七、结语：在“合法”的外衣下，警惕每一次点击
这次Google Cloud钓鱼事件，是一记响亮的警钟：最危险的攻击，往往披着最合规的外衣。
它不再依赖漏洞利用或社会工程话术，而是利用企业对技术巨头的天然信任，将整个数字生态的信任链转化为攻击杠杆。防御者若仍停留在“防伪造”阶段，注定被动挨打。
未来的邮件安全，必须走向“零信任”：不因来源合法而放松警惕，不因链接可信而放弃验证。正如芦笛所言：“在这个时代，安全不是判断‘它是不是真的’，而是假设‘它可能是假的’，然后去证明。”
而对于每一位普通用户，请记住：
真正的Google永远不会通过邮件让你“登录Microsoft账户”。
真正的安全，始于你不点那个链接的那一刻。
参考资料：
Check Point Research: “Official Google Domain Exploited in Sweeping Phishing Campaign”, Dec 24, 2025
SC Media: https://www.scworld.com/brief/official-google-domain-exploited-in-sweeping-phishing-campaign
Google Cloud Documentation: Application Integration – Send Email Task
MITRE ATT&CK Technique T1566.002: Phishing via Service Trusted by Target
RFC 7489: DMARC Specification
声明： 本文技术细节基于公开研究报告及行业通用知识，代码示例仅用于教育演示。所有建议均符合当前网络安全最佳实践，不构成对任何厂商的指控或背书。
编辑：芦笛（公共互联网反网络钓鱼工作组）
