一、一场“巧合”的攻击暴露了更危险的趋势
2025年10月，一家位于德国的能源企业安全团队在例行日志审计中发现异常：多个高管账户在凌晨时段调用了Microsoft Graph API，读取了大量内部邮件和OneDrive文档。奇怪的是，所有登录均来自微软官方IP，且MFA（多因素认证）记录完整——没有密码爆破，没有会话劫持，也没有恶意软件痕迹。
调查深入后，真相令人震惊：攻击者使用了设备代码钓鱼（Device Code Phishing）技术。但更令分析师困惑的是，同一时间段内，另一家美国医疗公司也遭遇了几乎完全相同的攻击手法，只是目标从窃取战略情报变为部署勒索软件。
起初，安全公司以为是两个独立事件。直到他们比对了攻击基础设施——两起行动都使用了同一个名为 Graphish 的开源钓鱼套件，且轮询脚本中的User-Agent字符串高度一致。
“这不是模仿，而是共享。”一位不愿具名的威胁情报分析师告诉本报，“国家级APT组织和勒索软件团伙，正在使用同一套工具、同一种流程，甚至可能从同一个Telegram频道下载教程。”
这一发现印证了Cybersecurity Dive最新报道的核心判断：设备代码钓鱼已不再是某类攻击者的专属战术，而演变为一种“通用武器”。俄罗斯、中国、朝鲜背景的国家支持黑客，与以经济利益为导向的犯罪团伙，正前所未有地在技术层面合流。
二、何为“设备代码钓鱼”？为何它能通吃各类攻击者？
要理解这场“战术趋同”的本质，必须回到OAuth 2.0协议的设计初衷。
设备代码授权流（Device Code Flow, RFC 8628）本是为智能电视、打印机等无浏览器设备设计的身份验证机制。其核心逻辑是：让用户在有输入能力的设备（如手机）上完成授权，从而让受限设备获得访问令牌。
标准流程如下：
受限设备向授权服务器（如Azure AD）请求设备代码；
服务器返回一个短时效的device_code和用户需手动输入的user_code；
用户被引导至 https://microsoft.com/devicelogin，输入user_code；
同时，受限设备后台持续轮询令牌端点；
用户在网页端登录并同意授权后，服务器向设备返回Access Token。
整个过程不涉及密码传输，且若用户已处于登录态，MFA可自动通过。
而攻击者正是将第1步中的“受限设备”替换为自己的恶意服务器。他们提前注册一个看似合法的Azure AD应用（如“DocSync Helper”），然后诱导受害者：
访问一个伪造的“文档协作页面”；
复制屏幕上显示的“设备代码”；
前往真实的微软设备登录页（https://microsoft.com/devicelogin）；
输入代码并点击“下一步”。
此时，受害者实际上是在向攻击者控制的应用授权！一旦确认，攻击者的轮询脚本立即获得Access Token，并可调用任意Graph API权限。
# 攻击者侧：发起设备代码请求（简化版）
import requests, time
CLIENT_ID = "malicious-app-id-from-azure-ad"
SCOPES = "Mail.Read Mail.Send Files.ReadWrite.All User.Read"
# Step 1: 获取设备代码
resp = requests.post(
"https://login.microsoftonline.com/common/oauth2/v2.0/devicecode",
data={"client_id": CLIENT_ID, "scope": SCOPES}
)
data = resp.json()
print(f"请让用户访问: {data['verification_uri']} 并输入代码: {data['user_code']}")
# Step 2: 轮询等待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": data["device_code"]
}
)
if token_resp.status_code == 200:
token = token_resp.json()["access_token"]
print("✅ 成功获取Token！")
break
elif token_resp.json().get("error") == "authorization_pending":
time.sleep(5)
else:
raise Exception("授权失败")
拿到Token后，攻击者即可：
读取/发送邮件（Mail.ReadWrite）；
下载OneDrive文件（Files.ReadWrite.All）；
加入Teams会议（OnlineMeetings.ReadWrite）；
甚至创建新应用注册（Application.ReadWrite.OwnedBy），实现持久化。
“这种攻击的‘优雅’之处在于，它完全走合法通道。”公共互联网反网络钓鱼工作组技术专家芦笛解释，“微软服务器看到的是正常API调用，防火墙看到的是HTTPS流量，EDR看到的是合法进程——没有任何异常信号。”
三、从间谍到勒索：同一把钥匙，开不同的门
正是这种“高隐蔽性+低技术门槛”的特性，使得设备代码钓鱼成为各类攻击者的共同选择。
国家级APT：长期潜伏，精准收割
俄罗斯关联组织 UNK_AcademicFlare（疑似APT29）自2025年9月起，利用该技术攻击欧美政府、智库及高校。其目标明确：窃取外交电报、研究数据、人员名单。攻击者通常申请Mail.Read、Calendars.Read等低风险权限，避免触发警报，并潜伏数月不动。
中国背景的 TA2723 则更关注科技企业。Proofpoint披露，该团伙在2025年11月的一次行动中，通过设备代码钓鱼获取某半导体公司工程师的邮箱权限，进而窃取未公开的芯片设计文档。
朝鲜黑客组织 Lazarus 也被观察到测试该技术，目标指向加密货币交易所员工，试图获取内部审批流程信息。
犯罪团伙：快速变现，横向移动
与APT的“慢工细活”不同，勒索软件团伙追求速度。例如 LockBit 4.0 的附属团伙，在2025年12月针对一家北美制造企业发起攻击：
通过钓鱼邮件诱导IT管理员扫码授权；
获取Directory.Read.All权限，枚举全公司用户；
使用User.Invite API创建新账户；
通过Exchange Online PowerShell执行邮箱导出；
部署Cobalt Strike Beacon，最终投放勒索软件。
“对他们来说，设备代码钓鱼只是初始入口。”芦笛指出，“一旦拿到第一个Token，后续的横向移动、权限提升、数据外泄，都是标准化操作。”
更令人担忧的是，工具链的共享。GitHub上的红队工具 SquarePhish（由SecureWorks开源）和黑产套件 Graphish 均提供图形化界面，支持一键生成钓鱼页面、自动轮询Token、甚至集成Ngrok反向代理。这些工具在中文、俄语、英语黑客论坛广泛传播，形成“即服务”（Phishing-as-a-Service）模式。
“现在，一个懂基础Python的人，花30分钟就能搭建完整攻击链。”芦笛说，“当国家级黑客和脚本小子用同一套武器时，防御的难度就不再是技术问题，而是规模问题。”
四、为什么传统防御集体失效？
企业普遍存在的三大认知盲区，导致设备代码钓鱼屡屡得手：
盲区一：“MFA万能论”
许多管理者认为“只要开了MFA，账户就安全”。但设备代码流中，MFA是在微软官方页面完成的，攻击者无需绕过MFA，而是利用MFA的成功结果。
“MFA防的是凭证窃取，不是授权滥用。”芦笛强调，“你授权给一个恶意应用，就像把家门钥匙交给小偷——MFA只确认你是房主，却不问你要把钥匙给谁。”
盲区二：“邮件安全=全防护”
当前企业安全重心仍在邮件网关。但设备代码钓鱼邮件往往只包含一段文字：“请复制以下代码到 https://microsoft.com/devicelogin 完成验证”，无链接、无附件、无恶意域名，极难被拦截。
盲区三：“归因决定防御”
过去，APT和犯罪团伙的TTPs（战术、技术、程序）差异明显，企业可针对性布防。如今，两者使用相同工具、相同流程，归因变得模糊，导致防御策略滞后。
“你无法再通过攻击手法判断对方是间谍还是劫匪。”芦笛坦言，“这迫使我们必须放弃‘按威胁类型防御’的思路，转向‘按风险行为防御’。”
五、如何构建下一代身份防线？
面对这一混合威胁，微软与安全社区提出多层次应对方案。
（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设备接入M365，否则应默认关闭。”芦笛建议，“99%的企业根本用不到这个功能。”
若业务确需保留，可限制仅特定用户组、IP范围或合规设备使用。
（2）推行FIDO2安全密钥或证书认证
微软大力推广 FIDO2/WebAuthn 标准，支持YubiKey、Windows Hello等无密码认证方式。此类认证基于公钥加密，Token无法被中间人截获或重放，从根本上杜绝钓鱼风险。
// WebAuthn注册示例（前端）
const credential = await navigator.credentials.create({
publicKey: {
challenge: new Uint8Array([/* 随机挑战 */]),
rp: { name: "Your Company", id: "yourcompany.com" },
user: { id: new Uint8Array(userId), name: "user@yourcompany.com" },
pubKeyCredParams: [{ type: "public-key", alg: -7 }] // ES256
}
});
相比短信或TOTP，FIDO2不仅更安全，且用户体验更佳——只需按一下物理密钥。
（3）实施最小权限原则与Token监控
限制第三方应用权限范围，禁用full_access_as_app等高危权限；
启用Azure AD 风险检测（Identity Protection），监控异常Token使用（如非常规地理位置、高频API调用）；
使用Microsoft Defender for Cloud Apps设置异常活动告警，如“单用户1小时内下载10GB OneDrive数据”。
（4）员工培训升级：从“防链接”到“防授权”
培训内容需更新：
任何要求“输入代码到微软登录页”的请求都需警惕；
授权前务必确认应用名称是否可信（如“Microsoft Teams” vs “FileShare Tool”）；
定期检查 https://account.microsoft.com/privacy/ 中的应用权限列表。
六、未来展望：身份安全进入“后密码、后MFA”时代
设备代码钓鱼的泛滥，标志着一个残酷现实：传统的“用户名+密码+MFA”三层模型已不足以应对现代云威胁。
Gartner预测，到2026年，30%的大型企业将弃用密码作为主要认证方式，转向FIDO2、证书或生物识别。微软自身也宣布，2025年起新租户默认启用“无密码体验”。
“未来的身份安全，核心不是‘你是谁’，而是‘你授权了什么’。”芦笛总结道，“我们必须从‘凭证保护’转向‘授权治理’。”
而这，或许才是对抗国家级黑客与黑产合流的终极答案。
结语
在Redmond的微软总部，工程师们正加速推进Passkey（通行密钥）生态建设。而在莫斯科、平壤、深圳的暗网上，攻击者则不断优化他们的Graphish钓鱼页面。
这场攻防战的胜负，不再取决于谁的代码更精巧，而在于谁先意识到：在云时代，最大的漏洞不是技术缺陷，而是对“信任”的滥用。
参考文献
Cybersecurity Dive. State-linked and criminal hackers use device code phishing against M365 users. Dec 19, 2025.
Proofpoint Threat Insight. Access Granted: Phishing via Device Code Authorization. Dec 2025.
Microsoft Security Blog. Disrupting threats targeting Microsoft Teams. Oct 7, 2025.
OAuth 2.0 Device Authorization Grant (RFC 8628).
FIDO Alliance. WebAuthn Specification.
编辑：芦笛（公共互联网反网络钓鱼工作组）
