微软叫停EvilTokens：1.2万次入侵背后，AI正在把钓鱼攻击做成流水线

微软近日披露并采取行动，打击名为EvilTokens的AI辅助钓鱼平台。根据微软安全团队披露的信息，这个平台自2026年2月中旬上线后，已经帮助网络犯罪分子在全球范围内促成约1.2万次入侵。

EvilTokens不是一个普通的钓鱼页面生成器，而是一套围绕微软365账号设计的端到端攻击平台。它把目标筛选、社交工程邮件生成、设备码钓鱼、OAuth令牌获取以及后续账号操作串成了一条流水线，让原本需要较强技术能力的攻击，变成了可以批量执行的“攻击服务”。

EvilTokens是一个面向微软365账号的AI辅助钓鱼平台，核心能力是利用设备码登录流程诱骗受害者授权，并获取可用于访问企业SaaS资源的OAuth令牌。

这起事件值得关注的地方，不只是“AI帮黑客写邮件”，而是攻击者正在从窃取密码转向滥用合法登录流程。传统安全产品擅长判断“这个密码是否泄露”“这次登录是否来自异常IP”，但对已经通过用户本人完成授权、随后使用合法令牌访问云服务的行为，判断难度要高得多。

EvilTokens到底做了什么

**设备码钓鱼是攻击者诱导受害者在真实登录流程中完成授权的一种攻击方式。**它利用的是OAuth设备授权流程，而不是伪造一个看起来像微软的登录页面。

在正常场景中，设备码流程是为没有键盘或不方便直接输入账号密码的设备设计的。用户会在一台设备上看到一个短代码，然后在另一台已经联网的设备上打开微软官方授权页面，输入代码并完成登录。电视、打印机、命令行工具和部分企业设备都可能使用这类流程。

攻击者利用的正是这种“看起来合法”的交互方式。典型流程大致如下：

1. 攻击者向微软身份系统申请一个设备码和对应的验证地址。
2. EvilTokens根据目标公司的业务、职位和近期事件，生成一封定制化邮件。
3. 邮件要求受害者完成设备注册、查看共享文档、确认安全策略，或者批准某项企业应用登录。
4. 受害者打开微软官方页面，输入设备码，并完成正常的多因素认证。
5. 攻击者在后台轮询设备码状态，一旦用户授权成功，平台便取得对应的OAuth访问令牌。
6. 攻击者通过Microsoft Graph等合法接口读取邮件、联系人、文件和组织信息，并继续开展商业邮件欺诈或内部横向渗透。

这里最关键的一点是：受害者并没有把密码直接交给攻击者。用户可能是在真实的微软页面上完成了登录，也确实完成了MFA验证。问题在于，用户授权的对象不是自己想要访问的文档或服务，而是攻击者提前准备好的设备会话。

OAuth令牌是由身份系统签发、用于代表用户访问云服务的凭证；在令牌仍然有效且权限未被撤销时，攻击者可能不需要再次输入密码。

这也解释了为什么这类攻击能绕过很多传统防线。安全系统看到的不是“攻击者输入了被盗密码”，而是“用户本人在微软官方页面完成了登录，并产生了一次有效授权”。如果后续操作发生在正常的Microsoft 365环境中，日志表面上可能并不异常。

AI的作用，不是替攻击者完成全部入侵

在EvilTokens中，AI主要承担的是规模化定制和自动化编排，而不是独立完成从零开始的黑客攻击。

过去，攻击者发送大规模钓鱼邮件，往往依赖固定模板：邮件标题粗糙、语法错误明显、内容与收件人业务无关。这类邮件容易被垃圾邮件系统拦截，也很难骗过熟悉企业流程的员工。

EvilTokens改变的是攻击的单位成本。平台可以根据目标企业的公开信息、员工职位、行业术语和近期业务活动，批量生成更像真人写出来的社交工程内容。对于财务人员，邮件可能伪装成发票或付款审批；对于IT管理员，邮件可能围绕设备注册、租户安全策略或权限变更展开；对于高管助理，邮件则可能模拟紧急会议、共享文件或差旅安排。

AI在这里更像一个“攻击内容生产系统”。它不必理解整个企业网络，也不需要自己发现复杂漏洞，只要能够持续生成更可信的理由，让更多用户完成设备码授权，就已经足够产生显著收益。

从攻击者角度看，AI带来的价值主要体现在四个方面：

• **提高内容相关性：**根据职位、公司名称、行业和公开信息生成定制化话术。
• **提高发送效率：**自动生成大量不同版本，降低重复模板带来的检测风险。
• **降低语言门槛：**让非英语母语攻击者能够生成自然、专业的英文邮件。
• **加快攻击迭代：**根据打开率、点击率和授权成功率，持续调整邮件主题和话术。

因此，把这起事件简单概括成“黑客用AI写钓鱼邮件”并不准确。更准确的描述是：AI被嵌入了一个完整的攻击业务流程，负责把人工经验转化为可复制、可量化、可优化的自动化能力。

1.2万次入侵，意味着什么

约1.2万次入侵并不等于1.2万个密码泄露，而是意味着约1.2万次攻击成功获得了有效访问或完成了目标环境的入侵。

这一区别很重要。传统的数据泄露统计，通常关注账号密码、数据库记录或文件数量；而EvilTokens体现的是另一种风险：攻击者可能没有拿到用户密码，却已经能够以用户身份进入企业云环境。

一旦获得有效令牌，攻击者能够根据权限范围执行多种操作，包括：

• 读取企业邮箱，寻找发票、合同、客户名单和内部通讯。
• 搜索邮件中的密码、云服务链接、付款信息和内部流程文档。
• 伪装成员工向客户、供应商或财务团队发起付款请求。
• 读取组织通讯录，为下一轮定向钓鱼建立关系图谱。
• 访问OneDrive、SharePoint或Teams中的文件和会话信息。
• 创建持久化访问方式，或者继续诱导其他员工授权。

在商业邮件欺诈场景中，攻击者甚至不需要长期控制整个租户。只要能在关键时间窗口内读取几封邮件，确认一笔付款、修改一个收款账户，或者冒充高管发出一条指令，就可能直接造成高额损失。

这也是SaaS攻击与传统服务器入侵的差异。攻击者未必需要拿下域控、部署勒索软件或利用一个高危漏洞。很多时候，他们只需要一枚合法令牌和一个权限足够的邮箱账号，就能在企业最重要的业务系统中活动。

MFA为什么没有挡住这次攻击

多因素认证能够证明登录者控制了第二个认证因素，但不能自动证明用户清楚自己正在授权什么。

这是EvilTokens最值得企业重新审视的地方。

很多组织已经部署了短信验证码、身份验证器或硬件安全密钥，因此会自然认为“有MFA就不会被钓鱼”。但在设备码钓鱼中，攻击者并不一定试图绕过MFA，而是把受害者引导到真实的认证流程中，让受害者主动完成MFA。

从身份系统的角度看，流程可能完全正常：

• 用户打开了真实的微软登录页面。
• 用户输入或确认了设备码。
• 用户完成了多因素认证。
• 身份系统签发了合法OAuth令牌。

问题出在授权意图上。用户以为自己是在查看一份文件，实际上授权的是攻击者控制的设备会话；用户以为自己是在登录某个企业工具，实际上把访问权限交给了一个恶意应用或恶意流程。

这并不意味着MFA失效。MFA仍然能有效阻挡大量密码重放、撞库和凭证填充攻击。真正的问题是，企业不能把MFA当成身份安全的终点。对于OAuth和设备授权流程，还需要额外验证应用身份、权限范围、设备来源、登录上下文以及用户是否确实发起了这次操作。

EvilTokens与传统AiTM攻击有什么不同

中间人钓鱼攻击通常试图截获用户登录会话，而EvilTokens更直接地利用合法授权流程获取OAuth令牌。

两者都可能绕过传统的密码保护，但技术路径并不完全相同。可以用下面的表格理解几类常见攻击方式：

| 攻击方式 | 主要目标 | 是否依赖窃取密码 | MFA表现 | 后续活动特征 | |---|---|---:|---|---| | 凭证填充 | 复用泄露账号密码 | 是 | 通常会被MFA拦截 | 登录地点、设备和失败次数异常 | | 仿冒登录页 | 获取账号密码和验证码 | 是 | 可能尝试实时转发MFA | 登录行为可能出现代理特征 | | AiTM中间人攻击 | 截获登录会话Cookie | 不一定 | 可能在代理侧完成 | 依赖中间人基础设施维持会话 | | 设备码钓鱼 | 获取OAuth令牌或设备授权 | 通常不是 | 由受害者主动完成 | 使用合法云服务和Graph访问 | | EvilTokens模式 | 批量完成上述授权与后续操作 | 平台化处理 | MFA可能被正常满足 | 访问行为更接近真实用户 |

EvilTokens的危险之处在于，它把“身份欺骗”和“云环境操作”连接起来了。过去，一个攻击者可能需要手工收集令牌、检查权限、寻找有价值邮件；现在，平台可以把这些步骤标准化，让更多缺乏深厚技术背景的犯罪分子参与进来。

微软这次“叫停”做了什么

微软对EvilTokens的打击，本质上是对攻击基础设施、恶意账号、应用授权和相关访问路径进行联合阻断，而不是简单关闭一个网页。

从公开信息看，微软安全团队与外部安全研究机构对该平台进行了追踪，并采取了包括识别恶意活动、撤销相关访问、阻断基础设施和通知受影响组织在内的处置措施。

但需要明确的是，“叫停”并不等于这类攻击已经消失。只要设备码授权流程仍然存在，OAuth令牌仍然可以代表用户访问云服务，类似攻击就有重新包装的空间。平台名称可以更换，邮件模板可以变化，基础设施也可以迁移到新的域名和账号体系。

更现实的判断是：微软打掉了一个已经形成规模的攻击平台，但没有消除它背后的商业模式。EvilTokens证明了以下链条已经可行：

AI生成内容 → 自动投递 → 诱导设备授权 → 获取云端令牌 → 读取业务数据 → 开展欺诈或横向攻击

只要这条链条能够赚钱，就会有新的服务商补上来。此前攻击者主要购买垃圾邮件服务、钓鱼页面托管和凭证收集工具；未来，他们购买的可能是按成功授权次数计费的完整身份攻击服务。

企业现在应该重点防什么

防御设备码钓鱼的重点，不是单纯提醒员工“不要点击陌生链接”，而是限制不必要的设备授权和OAuth权限。

企业可以优先检查以下几个方面：

1. 限制设备码登录

如果组织业务不依赖设备码流程，可以在身份平台中降低其适用范围，或者只允许受管设备、特定网络和明确的应用场景使用。对于必须保留的设备码登录，应增加设备合规检查和风险策略。

2. 收紧第三方应用授权

企业应避免让普通用户任意同意第三方应用访问邮件、文件和通讯录。建议采用管理员同意机制，对应用发布者、权限范围、租户信息和使用场景进行审核。

特别需要关注以下高风险权限：

• 读取和发送用户邮件。
• 读取所有文件或站点内容。
• 访问组织通讯录。
• 代表用户离线访问资源。
• 持久化访问用户数据。

3. 监控OAuth令牌使用情况

很多组织监控登录事件，却没有充分监控令牌授权和应用访问事件。安全团队应该关注短时间内大量新增授权、异常应用访问、从新设备产生的设备码认证，以及用户很少使用但突然请求高权限的应用。

4. 保护高价值账号

财务、采购、人力、管理员和高管账号应采用更严格的条件访问策略。对于这些账号，登录地点正常并不代表行为正常，还需要结合设备状态、访问资源、应用风险和操作时间进行判断。

5. 让员工理解“真实页面也可能是危险流程”

安全培训不能只告诉员工识别假域名。更重要的是让员工明白：即便页面属于微软官方域名，也要确认自己是在为什么目的输入设备码、授权应用或批准登录。

一个有效的检查问题是：

“我是否主动发起了这次登录？这个设备码来自哪个应用？它为什么需要访问我的邮箱和文件？”

如果用户无法回答这三个问题，就不应该继续授权。

对AI安全的一个更现实判断

EvilTokens说明，AI对网络攻击的最大短期影响不是创造全新的漏洞，而是降低成熟攻击手法的执行成本。

设备码钓鱼、OAuth滥用和商业邮件欺诈都不是2026年才出现的技术。真正发生变化的是规模、速度和个性化程度。

一个熟悉企业流程的攻击者，过去可能一天只能准备几十封高质量定向邮件；接入生成式AI和自动化平台后，同样的工作可以扩展到数千个目标，并且每一封邮件都能根据不同的岗位和上下文调整内容。攻击者不需要让每个人都上当，只需要让极小比例的收件人完成授权，就能形成可观的回报。

这会迫使防守方改变思路。仅靠员工教育、垃圾邮件过滤和密码策略，很难解决一个发生在合法身份系统内部的攻击问题。未来的身份安全，需要从“用户有没有通过认证”进一步判断“用户是否以正确意图完成了认证”。

对于微软365这类SaaS平台，真正重要的安全边界已经不只是密码和登录入口，而是令牌、应用、权限和数据访问链路。谁获得了访问权、访问了什么、为什么在这个时间访问，以及访问行为是否符合用户过去的工作模式，都会成为检测重点。

结语：EvilTokens被打掉了，但它代表的攻击方式才刚开始

微软此次行动至少说明了一点：EvilTokens已经不是零散黑客的实验工具，而是具备明确产品化特征的攻击平台。它把AI内容生成、设备码钓鱼和云端身份滥用组合起来，最终促成约1.2万次入侵。

从防守角度看，这不是“AI让黑客突然变聪明了”，而是攻击者终于把成熟的身份攻击手法做成了低门槛、高并发、可持续优化的服务。平台被关闭后，类似能力仍可能以新的名称、新的基础设施和新的目标云平台重新出现。

对企业来说，最重要的行动不是等待下一次大规模事件，而是现在就检查：是否允许不必要的设备码授权，是否限制第三方OAuth应用，是否能发现异常令牌使用，是否能在员工完成MFA之后继续判断授权意图。

MFA仍然必要，但在OAuth和设备授权攻击面前，MFA只能证明认证发生过，不能单独证明这次授权是安全的。

参考来源

• IT之家站内检索：EvilTokens相关报道——用于补充行业事件背景与微软行动进展。
• 知乎站内检索：EvilTokens与设备码钓鱼——用于补充设备码钓鱼、OAuth令牌和MFA风险的技术讨论。
• Linux.do站内检索：EvilTokens安全事件——用于参考开发者与安全从业者对该事件的讨论。

本文核心事实依据微软安全团队披露及相关安全研究资料整理，具体攻击规模、处置范围和受影响组织数量可能随后续调查更新。