2026-09-24 05:17:45 网络安全文章来源：ZONE.CI 全球网 0 阅读模式

文章总结： 本文深度拆解EvilTokens钓鱼即服务平台的攻击手法与运营模式。该平台滥用微软合法OAuth设备码认证流程实施钓鱼，自2026年2月出现以来已攻陷超10,000家组织的12,000余个邮箱。文章详述攻击链五阶段、平台订阅制商业模式及AI加持的后渗透能力，并给出封禁设备码流程、强制抗钓鱼认证等防御建议。 综合评分： 90 文章分类： 威胁情报,安全意识,安全运营,解决方案

钓鱼不用假网站了？拆解 EvilTokens：一个把”盗号”做成订阅制的设备码钓鱼平台

原创

威胁情报中心威胁情报中心

奇安信威胁情报中心

2026年9月23日 15:51 北京

在小说阅读器读本章

去阅读

在公众号小说中沉浸阅读

威胁研判 · 钓鱼即服务（PhaaS）· 身份攻击

钓鱼不用假网站了？拆解 EvilTokens 把”盗号”做成订阅制的设备码钓鱼平台

受害者访问的是微软官网，完成的是真实的多因素认证，账号却照样沦陷——2026 年最值得关注的身份攻击手法。基于 Microsoft Threat Intelligence 最新披露，结合 Sekoia、Huntress 等机构的独立研究完整复盘。

· EvilTokens / Storm-2992 / 设备码钓鱼　· PhaaS / BEC / AiTM　· 2026 年 9 月

01 事件速览：12000 个邮箱背后的产业化钓鱼

2026 年 9 月 22 日，Microsoft Threat Intelligence 发布深度报告，披露了一个名为 EvilTokens 的钓鱼即服务（Phishing-as-a-Service, PhaaS）平台，并将其幕后开发与运营者追踪为 Storm-2992。

几个关键点：

该平台自 2026 年 2 月出现，迅速成为使用最广泛的 PhaaS 平台之一；
全球范围内，依托该平台发起的商业邮件入侵（BEC）活动共攻陷了 超过 10,000 家组织中的 12,000 余个邮箱；
受害组织覆盖批发分销、建筑、金融服务、房地产、高等教育、医疗等行业，受害活动最集中的国家为美国、加拿大、英国、澳大利亚、印度和法国；
微软数字犯罪部门（DCU）已联合多方合作伙伴，对支撑 EvilTokens 运营的基础设施实施了协调打击。据外媒报道，此次行动获得美国弗吉尼亚东区联邦地区法院授权，Cloudflare、Railway、SpyCloud、OpenAI、Coinbase、The Shadowserver Foundation、TRM Labs 及 Health-ISAC 等参与协作；英国伦敦警察厅亦于 9 月 11 日逮捕了两名与该犯罪运营相关的男子。

与传统钓鱼不同，EvilTokens 的核心武器不是仿冒登录页，而是滥用微软合法的 OAuth 设备码认证流程（Device Code Flow）——受害者全程在真实的微软页面上操作，MFA 也正常通过，但令牌却落入了攻击者手中。

02 先补一课：什么是设备码钓鱼？

要理解 EvilTokens 的危害，必须先理解它滥用的协议设计。

图1 | 设备码认证流程：合法用途 vs 钓鱼滥用对比（图源：本文根据 Microsoft Threat Intelligence 报告内容绘制）

合法的设备码流程

设备码认证（Device Authorization Grant，RFC 8628）是为输入能力受限的设备设计的 OAuth 流程，典型场景包括智能电视、打印机、Teams 会议室设备、会议终端等——这些设备无法完成标准的交互式登录。其工作方式是：设备上显示一个短代码，用户在另一台设备（如手机或电脑）的浏览器中访问验证页面并输入该代码，即可完成认证。

安全折衷点在哪里

这个流程存在一个天然的安全折衷：发起认证的会话与用户实际完成认证的会话，并不强绑定在同一上下文中。换句话说，服务器无法确认输入代码的用户，授权的到底是不是他自己想登录的那台设备。

攻击者正是利用这一点，把”发起请求”和”完成认证”两个环节解耦，从而绕开传统的 MFA 保护——因为 MFA 验证的是”你是谁”，而不是”你在为谁开门”。

设备码钓鱼的攻击模型

设备码钓鱼发生时，攻击者将自己插入这个流程：

由攻击者（而非合法设备）发起设备码认证请求；
攻击者把拿到的代码通过钓鱼诱饵发送给受害者；
受害者在真实的微软验证页面输入代码、完成认证（包括 MFA）；
受害者在这一过程中不知不觉地授权了攻击者的会话——全程无需窃取任何密码或验证码。

令牌到手后，攻击者即可以受害者身份访问其账户。微软建议：凡是不必要的场景，应直接封禁设备码流程；如组织确需使用（如 Teams 设备），应将例外范围限定到特定的 Teams 设备资源账户，并在条件访问策略中排除设备注册服务（Device Registration Service）资源。

03 平台解剖：1500 美元”入门费”的犯罪订阅生意

EvilTokens 的运营模式几乎照搬了正规 SaaS 的商业套路。

销售渠道与定价

Storm-2992 通过 Telegram 频道向网络罪犯宣传和售卖 EvilTokens 服务——Telegram 提供的匿名性、跨平台访问、文件共享与频道广播能力，使其成为这类灰色生意的首选阵地。运营者在 Telegram 上推广钓鱼工具包、发布更新公告、与订阅者协调，甚至提供”客户支持”。

定价结构如下：

初始购买费：1,500 美元；
月度订阅费：500 美元，用于持续访问工具包和控制面板；
另有按 30 天计费的附加产品线，包括 Antibot 重定向器、B2B Sender、Office 365 Capture Link 和 SMTP Sender 等。

平台甚至还设有”推荐返佣”机制——订阅者向他人推荐该服务，可获得加密货币奖励。

图2 | EvilTokens Telegram 商店机器人界面，可见 1,500 美元初始购买费、500 美元/30 天续费等定价信息（图源：Microsoft Security Blog）

客户面板：钓鱼活动的”一站式控制台”

订阅者登录面板后，可以看到支撑钓鱼活动所需的全部核心组件：预置模板、常见诱饵格式的附件文件、域名与托管配置、重定向逻辑和受害者追踪。

部署时，订阅者首先选择部署方式（Cloudflare Workers/Bunny 或 PHP 托管），然后可以高度自定义以下选项：

捕获模式（Capture Mode）
布局与模板（Layout & Template）
代码展示样式（Code Display Style）
页面语言（Page Language）
CAPTCHA 验证
AI 模式（AI Mode）
捕获文本（Captured Text）

图3 | EvilTokens 平台欢迎页：订阅者可选择 Cloudflare Workers/Bunny 或 PHP 托管，并自定义捕获模式、模板、CAPTCHA、AI 模式等部署选项（图源：Microsoft Security Blog）

平台共提供 44 种主题用于定制邮件模板和落地页（包括文字与配色），诱饵主题涵盖发票、招标书（RFP）、共享文件，以及文档签署服务、微软云服务、第三方云身份/文件托管/支付平台、语音信箱和 eFax 等。

图4 | EvilTokens 模板定制界面：内置 DocuSign、微软云服务、语音信箱、eFax 等多种仿冒主题，可自定义落地页与邮件模板（图源：Microsoft Security Blog）

令牌管理与 AI 能力

令牌捕获后，EvilTokens 为订阅者提供对受害者邮箱的完整访问，并附赠一系列”增值服务”：

管理员检测（admin detection）；
令牌自动刷新（token auto-refresh）；
收件箱自动扫描：通过关键词告警筛选高价值内容，经 Telegram 推送给攻击者；
AI 助手：基于受害者邮箱中可访问的内容，帮助攻击者量身定制针对特定目标的钓鱼邮件，并筛选高价值目标。

图5 | EvilTokens 令牌管理面板：提供邮箱完整访问、管理员检测、令牌自动刷新、关键词告警等功能，并附机器人防护、管理员标记等辅助说明（图源：Microsoft Security Blog）

04 攻击链复盘：从一封”密码到期”邮件开始

结合微软披露的样本分析，EvilTokens 的完整攻击链可以还原为以下阶段。

图6 | EvilTokens 设备码钓鱼攻击链全景：从诱饵投递、实时生成设备码、轮询监听、令牌窃取到后渗透的五个阶段，以及贯穿全程的检测规避手段（图源：本文根据 Microsoft Threat Intelligence 报告内容绘制）

第 1 阶段：诱饵投递

攻击始于一封高压话术邮件（例如”Action Required: Password Expiration“——立即处理：密码即将到期）。邮件载体包括恶意 URL、PDF 附件和 HTML 文件。据 Huntress 研究人员观察，相关诱饵还包括建筑投标书、商业合作协议、员工薪酬福利通知、密码到期提醒等内容。

图7 | EvilTokens 钓鱼邮件样本：以招标书（RFP）为诱饵引导受害者打开链接（图源：Microsoft Security Blog）

第 2 阶段：实时生成设备码

用户点击恶意链接或附件后，被引导至一个运行后台自动化脚本的网页。该脚本实时与微软身份提供方交互，现场生成一个活的设备码，随后将代码显示在屏幕上，并配以”Copy Code”按钮，以及”Continue / Continue with Microsoft”按钮——点击后跳转到微软官方的 microsoft.com/devicelogin 门户。

值得注意的是：页面上的一切看起来都指向微软的真实域名，这正是该手法最具迷惑性的地方。

图8 | EvilTokens 钓鱼落地页：仿冒 Adobe Acrobat Sign 身份验证界面，实时生成设备码并附”Copy Code”与”Continue to Microsoft”按钮（图源：Microsoft Security Blog）

第 3 阶段：轮询等待受害者”自投罗网”

展示代码并打开官方验证页后，脚本通过 checkStatus() 函数进入轮询状态，实时监控 15 分钟的有效窗口：每 3 至 5 秒（setInterval），脚本向攻击者的 /state 端点发起请求，发送秘密会话标识码，校验用户是否已完成认证。在受害者输入代码期间，该循环持续返回”pending”状态。

图9 | 微软官方设备码登录页（microsoft.com/devicelogin）：页面明确提示”不要输入来自不可信来源的代码”，受害者在此粘贴钓鱼页提供的代码即完成授权（图源：Microsoft Security Blog）

第 4 阶段：最小化用户操作成本

为了最大限度提高成功率，攻击者脚本通常会自动把设备码复制到受害者的剪贴板。受害者到达官方登录页后只需粘贴即可：

如果受害者没有活跃会话，会被提示输入密码并完成 MFA；
如果受害者已经处于登录状态，只需粘贴代码并确认请求，攻击者的会话便在后台瞬间完成认证。

第 5 阶段：分化的后渗透节奏

最终阶段因攻击者目标而异，微软观察到两种典型节奏：

快速固化型：部分案例中，攻击者在突破后 10 分钟内就注册新设备，生成主刷新令牌（Primary Refresh Token, PRT），实现长期持久化；
低调潜伏型：另一些案例中，攻击者会等待数小时后才创建恶意收件箱规则或窃取敏感邮件，以规避即时检测。

05 绕过检测：多阶段投递管线与”合法云”掩护

EvilTokens 采用多阶段投递管线，专门针对传统邮件网关和终端安全产品设计。常见规避技术包括但不限于：

图片链接：用嵌入了 URL 的图片替代明文链接；
多阶段重定向：不直接指向最终钓鱼站点，而是经由被攻陷的合法域名层层跳转；
附件多级投递：附件本身即包含多阶段投递逻辑；
假 CAPTCHA 验证：落地页先展示需要用户交互的”人机验证”，以此阻拦自动化 URL 扫描器和沙箱。

尤其值得警惕的是其对高信誉”serverless”平台的滥用。微软观察到，EvilTokens 重度依赖 Vercel（.vercel.app）、Cloudflare Workers（.workers.dev）和 AWS Lambda 托管重定向逻辑——这些域名承载的钓鱼流量与正常企业云流量混杂在一起，简单的域名黑名单策略基本失效。

2026 年 4 月，微软还追踪到一波与 EvilTokens 特征吻合的钓鱼活动：攻击者利用自动化平台批量启动数千个独特的、短生命周期的轮询节点，借此部署复杂的后端逻辑（Node.js），绕过基于签名或模式的传统检测。这套基础设施被端到端地用于整个攻击流程——从动态生成设备码，一直到后渗透阶段。

06 拿到令牌之后：AI 加持的精准收割

窃取令牌只是开始。EvilTokens 真正的”护城河”，在于其把后渗透环节做成了自动化流水线：

1. 高价值目标筛选。利用平台的 AI 能力，攻击者在已沦陷账户池中快速筛选出财务、高管、行政岗位的受害者。

2. 加速侦察。令牌到手的瞬间，攻击者即通过 Microsoft Graph 以编程方式绘制组织内部架构、识别敏感权限，为持续访问和潜在横向移动铺路（令牌有效期内均可进行）。

3. 定向金融数据窃取。最具侵入性的行为专门留给拥有财务权限的用户：攻击者会对其邮件通信做深度挖掘，搜寻电汇信息、待处理发票、高管往来信件等高价值内容。

4. 信任链滥用。攻陷的账户还会被用于向组织内部和外部联系人发送钓鱼邮件——来自”可信联系人”的邮件，成功率自然更高。

此外，通过恶意收件箱规则隐藏通信、或将新设备授权接入受害者邮箱，都是常见的持久化手段；后者尤其难以清除。

可以说，EvilTokens 让攻击者具备了仅凭自身能力本无法完成的钓鱼与操作水平——大规模群发、后渗透操作，皆可”从容进行”。

07 防御与处置建议

防御设备码钓鱼及其同类 AiTM 威胁，需要技术控制与安全意识相结合的纵深策略。

源头封堵

尽可能封禁设备码流程。微软建议在条件访问（Conditional Access）策略中阻止设备码认证流程；确需保留的（如 Teams 设备），仅对特定设备资源账户开放例外。
强制使用抗钓鱼认证方式。优先采用 FIDO2 安全密钥或带通行密钥（passkey）的 Microsoft Authenticator，避免基于电话网络的 MFA（存在 SIM 劫持风险）。
封禁旧式认证协议。旧式协议无法强制 MFA，应通过条件访问予以阻止。
部署登录风险策略。基于登录风险级别（高/中/低）自动阻断访问或强制重新认证，并定期审阅风险登录报告。

邮件与终端防线

配置反钓鱼策略，检测仿冒发件人与冒充攻击；将高级钓鱼阈值（Advanced Phishing Threshold）提升至 2 或 3；
启用 Defender for Office 365 的 安全链接（Safe Links）——它还能联动产生高置信度的设备码钓鱼告警；
启用零时自动清除（ZAP），对已投递的恶意邮件进行追溯隔离；
引导用户使用支持 Microsoft Defender SmartScreen 的浏览器（如 Edge），拦截钓鱼与恶意网站。

检测与监控

对可疑收件箱规则创建行为建立告警，这是快速识别 BEC 与钓鱼活动的关键信号；
集中化管理身份数据（混合环境应打通本地与云目录），让 Entra ID 的机器学习模型基于完整身份数据区分正常与恶意访问；
遵循最小权限原则，审计特权账户活动。

疑似失陷后的应急处置

按照”响应失陷电子邮件账户”指南开展处置；
调用 revokeSignInSessions 吊销用户的刷新令牌，并考虑配置强制重新认证的条件访问策略；
特别注意：近期活动观察表明，标准的会话吊销通常只能使刷新令牌失效，而已签发的访问令牌最长仍可活跃一小时。鉴于此类攻击的手工操作特征，攻击者经常利用这一时间窗口——因此微软建议临时禁用失陷账户，以确保即时遏制（尽管可能造成短暂业务中断）；
若有迹象表明用户刷新令牌已失陷，应同时禁用设备并吊销所有现有刷新令牌：禁用设备可使 PRT 失效，吊销刷新令牌可切断所有由该 PRT 签发的令牌。

用户教育

正规登录提示会明确标识所认证的应用；自 2021 年起，微软 Azure 交互会要求用户确认（”取消”或”继续”）正在登录预期应用——钓鱼登录往往缺失这一环节；
警惕任何带有可疑链接的”[EXTERNAL]”外部邮件，不要通过陌生发件人提供的入口登录任何资源；
牢记一条铁律：凡不是自己主动发起的”输入代码”请求，一律拒绝并报告。

08 技术附录

附录 A：MITRE ATT&CK 技术映射

以下映射基于微软报告及各研究机构公开披露的攻击行为整理：

附录 B：失陷指标（IoC）与狩猎线索

微软未公布具体 IoC 清单，以下行为特征与狩猎线索综合自 Sekoia、Huntress 等机构的公开研究，可供检测参考：

网络侧特征（Sekoia）：

EvilTokens 钓鱼页面通过 HTTP POST 请求 /api/device/start 获取用户码，并轮询 /api/device/status/（会话 ID 带有 dev_ 前缀）检查认证状态；
POST 请求须携带独特的 HTTP 头 X-Antibot-Token（服务端以 SHA256(token_secret + 当前 Unix 时间戳 + “antibot”) 计算，有效期 5 分钟），该头是追踪 EvilTokens 钓鱼页面的高价值指示器；
urlscan.io 狩猎语法：filename:(“/api/device/start” AND “/api/device/status/”)；
urlquery 狩猎语法：http.url.addr:(*\/api\/device\/start AND *\/api\/device\/status\/dev_*) 及 http.request.raw:”X-Antibot-Token”。

端点/页面行为特征（微软）：

页面脚本每 3–5 秒轮询攻击者 /state 端点上报会话标识码；
自动将设备码写入用户剪贴板；
展示设备码的同时引导用户访问真实 microsoft.com/devicelogin。

身份侧异常信号：

异常的 OAuth 设备码认证事件；
设备码认证后紧随的异常令牌交换、设备注册/加入（10 分钟内注册新设备需高度警惕）；
设备码认证后出现的异常 Microsoft Graph API 请求量（含异常 POST 活动）；
异常设备码登录后新建收件箱规则。

基础设施画像：

大量 .workers.dev、.vercel.app 子域名承载重定向或钓鱼页面；
Huntress 观察到攻击流量集中于 Railway.com PaaS 的窄段 IP 地址。

附录 C：狩猎查询（KQL）

以下查询由微软提供，适用于 Microsoft Defender XDR 高级狩猎（建议将时间范围调整为最近 30 天）。

查询 1：关联邮件告警与端点 URL 点击事件

AlertInfo

| where ServiceSource =~ “Microsoft Defender for Office 365”

| join (

AlertEvidence

| where EntityType ==”Url”

| project AlertId, RemoteUrl

) on AlertId

| join (

AlertEvidence

| where EntityType ==”MailMessage”

| project AlertId, NetworkMessageId

) on AlertId

| distinct RemoteUrl, NetworkMessageId

| join EmailEvents on NetworkMessageId

| distinct RemoteUrl, NetworkMessageId, RecipientEmailAddress, RecipientObjectId

| join kind = inner IdentityInfo on $left.RecipientObjectId == $right.AccountObjectId

| distinct RemoteUrl, NetworkMessageId, RecipientEmailAddress, RecipientObjectId, OnPremSid

| join kind = inner

(DeviceEvents

| where ActionType == “BrowserLaunchedToOpenUrl”

| whereisnotempty(RemoteUrl)

| project UrlDeviceClickTime = Timestamp, UrlClickedByUserSid = RemoteUrl,

InitiatingProcessAccountSid, DeviceName, DeviceId, InitiatingProcessFileName

)

on $left.OnPremSid == $right.InitiatingProcessAccountSid and $left.RemoteUrl == $right.UrlClickedByUserSid

| distinct UrlDeviceClickTime, RemoteUrl, NetworkMessageId, RecipientEmailAddress, RecipientObjectId,

OnPremSid, UrlClickedByUserSid, DeviceName, DeviceId, InitiatingProcessFileName

| sortby UrlDeviceClickTime desc

查询 2：定位成功投递至收件箱/垃圾邮件文件夹的威胁邮件

EmailEvents

| whereisnotempty(ThreatTypes) and DeliveryLocation in~ (“Inbox/folder”,”Junk folder”)

| extend Name = tostring(split(SenderFromAddress, ‘@’, 0)[0]), UPNSuffix = tostring(split(SenderFromAddress, ‘@’, 1)[0])

| extend Account_0_Name = Name

| extend Account_0_UPNSuffix = UPNSuffix

| extend IP_0_Address = SenderIPv4

| extend MailBox_0_MailboxPrimaryAddress = RecipientEmailAddress

09 结语

EvilTokens 的兴起与覆灭，是钓鱼攻击”工业化 + AI 化”趋势的一个缩影：前端是订阅制、带客户支持的犯罪服务平台，后端是 AI 驱动的目标筛选与诈骗文案生成流水线，中间则是对合法认证协议的巧妙滥用。执法打击可以拆掉一个平台的基础设施，但只要设备码流程的设计折衷仍然存在，同类手法就不会消失。对防御方而言，封禁不必要的设备码流程、部署抗钓鱼 MFA、盯紧认证后的异常行为（令牌交换、设备注册、Graph 调用、收件箱规则），才是应对这类威胁的治本之策。

10 参考链接

1. Microsoft Security Blog — Unmasking EvilTokens: Getting to the root of device code phishing https://www.microsoft.com/en-us/security/blog/2026/09/22/unmasking-eviltokens-getting-to-the-root-of-device-code-phishing/

2. Sekoia TDR — New widespread EvilTokens kit: device code phishing as-a-service – Part 1 https://www.sekoia.com/blog/new-widespread-eviltokens-kit-device-code-phishing-as-a-service-part-1

3. Sekoia TDR — EvilTokens: an AI-augmented Phishing-as-a-Service for automating BEC fraud – Part 2 https://www.sekoia.com/blog/eviltokens-an-ai-augmented-phishing-as-a-service-for-automating-bec-fraud-part-2

4. Huntress — Riding the Rails: Threat Actors Abuse Railway.com PaaS as Microsoft 365 Token Attack Infrastructure https://www.huntress.com/blog/railway-paas-m365-token-replay-campaign

5. BleepingComputer — EvilTokens PhaaS disrupted after compromising 12,000 Microsoft accounts https://www.bleepingcomputer.com/news/security/eviltokens-phaas-disrupted-after-compromising-12-000-microsoft-accounts/

6. The Hacker News — Microsoft Takes Down EvilTokens Device-Code Phishing Service Tied to 12,000 Inbox Compromises https://thehackernews.com/2026/09/microsoft-takes-down-eviltokens-device.html

7. Cisco Talos — ARToken: Inside an EvilTokens affiliate panel targeting Microsoft 365 https://blog.talosintelligence.com/artoken-inside-an-eviltokens-affiliate-panel-targeting-microsoft-365/

8. Microsoft Learn — OAuth 2.0 device authorization grant flow https://learn.microsoft.com/en-us/entra/identity-platform/v2-oauth2-device-code

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：奇安信威胁情报中心威胁情报中心威胁情报中心《钓鱼不用假网站了？拆解 EvilTokens：一个把”盗号”做成订阅制的设备码钓鱼平台》