一、一封“学术合作”邮件背后的云端渗透
2025年10月，某欧洲知名智库的研究员安娜（化名）收到一封来自“美国国务院政策研究办公室”的邮件。发件人自称正在筹备一场关于东欧能源安全的闭门研讨会，希望邀请她参与前期材料审阅，并附上一个“预读文档链接”。出于职业习惯，安娜点击了链接——页面跳转至一个看似正常的Microsoft OneDrive界面，提示她“复制下方设备代码并前往 https://microsoft.com/devicelogin 完成授权”。
她照做了。几分钟后，系统提示“授权成功”，文档顺利打开。一切看起来再正常不过。
然而，就在那一刻，她的Microsoft 365账户已被悄然接管。攻击者并未窃取她的密码，也未触发任何多因素认证（MFA）警报。他们只是利用了一种名为“设备代码授权流”（Device Code Flow）的合法OAuth 2.0协议机制，诱导她亲手交出了访问令牌（Access Token）。
这并非孤例。据网络安全公司Proofpoint最新披露，自2025年9月以来，一个被其命名为 UNK_AcademicFlare 的黑客组织已对美国、欧洲的政府机构、军事单位、高校及交通部门发起大规模定向攻击。多方情报交叉印证显示，该组织与俄罗斯对外情报局（SVR）关联密切，极可能就是广为人知的 APT29（又名Cozy Bear、Midnight Blizzard）的最新行动代号。
更令人警惕的是，这种攻击手法并非APT29首创，而是从网络犯罪黑产中“借鉴”而来——如今，国家级黑客正将原本用于金融诈骗的“设备代码钓鱼”技术武器化，用于长期战略情报窃取。
二、什么是“设备代码钓鱼”？它为何能绕过MFA？
要理解这场危机的严重性，必须先厘清技术本质。
传统钓鱼攻击依赖伪造登录页面窃取用户名和密码。但随着MFA（多因素认证）普及，仅凭密码已无法完成登录。于是，攻击者转向更隐蔽的“令牌窃取”路径。
设备代码授权流（Device Code Flow）本是微软为无浏览器或输入受限设备（如智能电视、IoT设备）设计的一种OAuth 2.0授权方式。其标准流程如下：
用户在受限设备上请求访问资源（如OneDrive）；
设备向授权服务器（如Azure AD）发起请求，获取一个设备代码（device_code）和用户验证码（user_code）；
用户被引导至 https://microsoft.com/devicelogin，手动输入验证码；
同时，设备后台持续轮询服务器，等待用户完成授权；
用户在网页端登录并同意授权后，服务器向设备返回Access Token；
设备凭此Token访问API资源。
整个过程无需输入密码，且若用户已处于登录状态（如浏览器记住会话），甚至无需再次输入MFA。
而攻击者正是利用了第3-5步的“信任链”。他们搭建一个伪装成文档共享页面的钓鱼站点（常托管于Cloudflare Workers等无服务器平台），诱导受害者：
复制一段看似随机的“设备代码”；
前往真实的微软设备登录页（https://microsoft.com/devicelogin）；
输入该代码并点击“下一步”。
此时，受害者实际上是在向攻击者控制的OAuth应用授权！因为那段“设备代码”是由攻击者提前通过其恶意注册的Azure AD应用生成的。
# 攻击者侧：使用Microsoft Graph API发起设备代码请求（简化示例）
import requests
client_id = "attacker-controlled-app-id" # 攻击者注册的恶意应用ID
scope = "Mail.Read Mail.Send Files.Read.All User.Read"
resp = requests.post(
"https://login.microsoftonline.com/common/oauth2/v2.0/devicecode",
data={
"client_id": client_id,
"scope": scope
}
)
device_data = resp.json()
print(f"请让用户访问: {device_data['verification_uri']} 并输入代码: {device_data['user_code']}")
# 此时攻击者开始轮询token
一旦受害者在微软官方页面输入代码并确认授权，攻击者的轮询脚本便会立即收到Access Token：
# 攻击者轮询获取Token
while True:
token_resp = requests.post(
"https://login.microsoftonline.com/common/oauth2/v2.0/token",
data={
"grant_type": "urn:ietf:params:oauth:grant-type:device_code",
"client_id": client_id,
"device_code": device_data["device_code"]
}
)
if token_resp.status_code == 200:
access_token = token_resp.json()["access_token"]
print("✅ 成功获取受害者Token！")
break
time.sleep(5)
拿到Token后，攻击者即可调用Microsoft Graph API，读取邮件、日历、OneDrive文件、Teams消息，甚至发送新邮件冒充受害者——全程无需知道密码，也不触发MFA。
“这相当于你把家门钥匙交给了一个陌生人，而你还以为自己只是帮邻居开了个门。”公共互联网反网络钓鱼工作组技术专家芦笛在接受本报采访时比喻道，“设备代码钓鱼的可怕之处在于，它利用的是用户对微软官方域名的信任，以及对‘授权’行为的无意识。”
三、APT29的战术升级：从“技术炫技”到“社会工程精耕”
值得注意的是，UNK_AcademicFlare的攻击并非粗暴撒网。Proofpoint报告显示，其前期侦察极为精准：
使用已被攻陷的真实政府/军方邮箱作为发信源，提升可信度；
邮件内容围绕目标专业领域展开“良性互动”，如邀请乌克兰能源专家参与“欧盟能源转型圆桌”；
虚构会议、访谈或合作项目，制造紧迫感与合理性；
链接指向高度仿真的OneDrive页面，连URL都通过Cloudflare Worker动态生成，规避静态检测。
“这不再是过去那种‘您的包裹未送达’的低级钓鱼。”芦笛指出，“APT29现在融合了情报机构的社会工程能力与黑产的技术工具链，形成了一种‘混合威胁’。”
事实上，早在2025年2月，微软与Volexity就曾联合披露Storm-2372、UTA0304等俄系组织使用相同手法。但当时外界多视为个别事件。直到2025年8月，亚马逊威胁情报团队发现APT29在针对欧洲安全会议的钓鱼活动中复用该技术，业界才意识到这已成为其标准作业程序（SOP）。
更值得警惕的是，此类攻击工具已“平民化”。Proofpoint提到，黑市上流行的 Graphish 钓鱼套件和红队工具 SquarePhish（由SecureWorks开源）极大降低了技术门槛。这些工具提供图形界面，只需填入应用ID和权限范围，即可一键生成钓鱼页面与轮询脚本。
“现在，一个懂基础Python的大学生都能发起设备代码钓鱼。”芦笛坦言，“当国家级黑客与脚本小子使用同一套武器时，防御的复杂度呈指数级上升。”
四、为什么现有防御体系集体失灵？
许多企业安全负责人困惑：我们部署了EDR、邮件网关、MFA，为何仍被突破？
答案在于：设备代码钓鱼攻击发生在身份验证之后，且完全走合法API通道。
邮件安全网关：钓鱼邮件来自真实邮箱，内容无恶意附件或链接（指向的是微软官方域名），难以拦截；
MFA：用户确实在微软官网完成了交互式登录，MFA已通过；
SIEM/SOAR：后续的API调用（如读取邮件）来自微软数据中心IP，行为模式与正常用户高度相似；
终端防护：全程无恶意软件落地，EDR无迹可寻。
“传统安全模型假设‘拿到凭证=入侵成功’，但如今攻击者根本不需要凭证。”芦笛解释，“他们要的是授权，而授权是现代云身份体系的核心功能。”
微软自身也承认这一挑战。在其2025年发布的《云身份威胁报告》中，设备代码滥用被列为“高隐蔽性持久化访问”（High-Fidelity Persistent Access）的典型代表。
五、如何防御？技术对策与管理策略双管齐下
面对这一新型威胁，安全社区已提出多层次应对方案。
（1）立即行动：限制设备代码流
最直接有效的措施，是在Azure AD中通过条件访问策略（Conditional Access Policy）禁用设备代码授权。
操作路径：
Azure Portal → Azure Active Directory → Security → Conditional Access → New Policy
条件：Authentication context → Authentication flows → Device code flow
授予：Block access
“对于绝大多数企业用户，设备代码流根本用不到。”芦笛强调，“除非你有大量IoT设备接入Office 365，否则应默认关闭。”
若因业务需要必须保留，可采用“白名单”策略，仅允许特定用户组、IP段或操作系统使用。
（2）审计第三方应用授权
所有用户都应定期检查其Microsoft 365账户的“隐私仪表板”中的应用权限：
https://account.microsoft.com/privacy/
管理员则可通过PowerShell批量导出全组织授权记录：
Connect-MgGraph -Scopes "AuditLog.Read.All"
Get-MgUser -All | ForEach-Object {
$userId = $_.Id
Get-MgUserOauth2PermissionGrant -UserId $userId |
Select-Object @{n="User";e={$_.PrincipalName}}, AppId, ConsentType, Scope
} | Export-Csv -Path "oauth_grants.csv"
任何未知来源、高权限（如Mail.ReadWrite、Files.ReadWrite.All）的应用授权都应立即撤销。
（3）启用Token寿命限制与异常检测
微软建议将Access Token有效期缩短至1小时以内（默认为1小时，Refresh Token为90天）。同时，开启风险用户检测（Identity Protection）和异常登录活动告警。
例如，若某账户在短时间内从不同国家调用Graph API，即使Token合法，也应触发二次验证。
（4）员工意识培训需升级
传统“别点可疑链接”已不够。培训应聚焦：
任何要求“输入代码到微软登录页”的请求都需高度警惕；
即使链接是 microsoft.com，也可能被用于授权恶意应用；
授权前务必确认应用名称是否可信（如“Microsoft Teams” vs “Doc Review Tool”）。
六、未来展望：OAuth安全将成为云时代主战场
设备代码钓鱼只是冰山一角。随着零信任架构普及，基于令牌的身份验证将取代密码成为主流。而OAuth、OpenID Connect等协议的复杂性，也为攻击者提供了广阔空间。
“我们正在进入‘后密码时代’，但安全思维还停留在‘防钓鱼=防假网站’。”芦笛警告，“真正的战场在授权层——谁有权访问什么资源，比谁知道密码更重要。”
微软、Google等云厂商已开始推动持续访问评估（Continuous Access Evaluation, CAE），实现Token实时吊销。但企业侧的策略配置、监控能力仍严重滞后。
可以预见，未来几年，围绕OAuth令牌的攻防博弈将成为高级持续性威胁（APT）的核心战场。而对于普通组织而言，能否及时关闭一个看似无害的“设备代码流”，或许就决定了是否会被国家级黑客悄然潜伏数月而不自知。
结语
当安娜发现自己的邮箱被用来向同事发送“机密会议纪要”时，已是三个月后。调查发现，攻击者不仅下载了她过去两年的所有邮件，还通过Teams聊天记录绘制了其所在智库的人际关系图谱。
这不是科幻小说，而是2025年真实发生的间谍行动。在云服务深度融入工作流的今天，一次无心的“授权点击”，可能就是国门洞开的起点。
正如芦笛所言：“在数字世界，信任是最昂贵的漏洞。而修复它的成本，远高于预防。”
参考文献与延伸阅读
Proofpoint Threat Insight: Access Granted: Phishing via Device Code Authorization for Account Takeover (Dec 2025)
Microsoft Security Blog: Russian Hackers Using Device Code Phishing to Target Global Organizations (Feb 2025)
OAuth 2.0 Device Authorization Grant (RFC 8628)
SquarePhish GitHub Repository: https://github.com/secureworks/SquarePhish
Azure AD Conditional Access Best Practices – Microsoft Docs
编辑：芦笛（公共互联网反网络钓鱼工作组）
