导语：2026年9月22日，微软披露其联合安全机构、技术企业及执法部门，对人工智能驱动的网络犯罪平台EvilTokens采取了跨国打击行动。该平台将设备代码钓鱼、账号接管、邮箱分析和金融诈骗建议整合为一套服务。事件表明，平台治理不能只拦截“假链接”，还必须覆盖授权令牌、异常会话、内容审核、资金风险和受害者救济等完整链路。
从盗取密码转向骗取合法授权
EvilTokens的突出风险，在于攻击者可能引导用户前往真实的微软登录页面输入设备代码。用户看到的是正规域名，也可能完成多因素认证，但实际效果却可能是把攻击者控制的设备授权给自己的账号。微软威胁情报团队指出，被窃取的访问令牌和刷新令牌还可能被用于读取邮件、建立隐藏收件箱规则或维持会话，因此仅修改密码未必能够彻底阻断已经形成的访问权限。[1]
更值得警惕的是，EvilTokens把人工智能用于入侵后的信息筛选。其工具可以分析被控制邮箱中的联系人关系、付款流程和敏感职责，并帮助攻击者选择冒充对象、设计诈骗情境。微软称，该服务与全球超过1.2万个受影响邮箱及1万多家机构有关；相关行动查封了50个运营网站，并停用了150多个配套域名。英国警方还对涉嫌参与运营的人员采取了行动。[2]
平台首先要补上账号授权审核
平台不应再把“密码正确并通过验证码”视为风险流程的终点。对于设备代码登录、异地授权、陌生客户端接入、短时间批量读取邮件以及异常调用组织目录等行为，应当实施更细粒度的动态审核。
- 限制高风险设备代码流：没有明确业务需要的组织，可默认关闭或严格限制设备代码授权；确需使用时，应绑定受管设备、可信网络和指定应用。
- 核验授权上下文：授权页面应清晰展示应用名称、设备类型、申请权限、发起地点和潜在后果，避免用户只看到一串代码便机械确认。
- 检测令牌异常：对令牌在多个地区快速切换、陌生设备持续刷新会话、批量访问邮件和新建可疑转发规则等行为及时中止并复核。
- 建立统一注销能力：账号出现风险后，应同时撤销访问令牌、刷新令牌、应用授权和已有会话，而不是只要求用户修改密码。
反欺诈审核应同时看内容、关系和交易
在“九不准”和“七条底线”所强调的守法、真实、公共秩序与合法权益保护框架下，平台既要防止违法有害信息传播，也要避免自动化工具被用于冒充身份、操纵信任关系和侵害财产权益。审核对象不应局限于单封邮件是否包含敏感词，而应判断整个行为链是否具有欺诈特征。
例如，账号在异地登录后突然检索“发票”“付款”“账户变更”等内容，随后批量联系财务人员，或要求把既有收款账户改为陌生账户，平台应把这些信号组合成高风险事件。对于紧急转账、变更供应商账户、购买礼品卡或发送加密资产等请求，可增加延迟发送、二次确认和独立渠道核验。
人工智能生成内容也不应被“一刀切”处理。平台更应关注使用目的和实际行为，包括是否冒充真实联系人、是否引用窃取的内部信息增强可信度、是否绕过组织审批，以及是否诱导用户作出不可逆的资金操作。高风险模型调用还应保留必要的安全日志，保证后续调查能够还原账号、设备、权限和操作时间线。
受害者救济不能止于冻结账号
账号被接管后，受害者通常同时面临通信泄露、联系人受骗和资金损失。平台应设置醒目的反欺诈申诉入口，并提供可执行的处置清单，而不是只发送一封模板化提醒。
- 快速止损：立即暂停异常会话，撤销令牌和第三方应用授权，检查转发规则、备用邮箱、恢复号码及新增设备。
- 保存证据：为受害者导出登录记录、授权时间、异常IP、邮件规则变更和可疑操作摘要，便于报案、保险理赔及机构内部调查。
- 联动通知：在符合法律和隐私要求的前提下，提醒可能收到冒充邮件的联系人，并向支付机构、安全响应组织或执法部门发送结构化风险信息。
- 提供资金救济通道：涉及转账、虚拟资产或银行卡支付时，应明确告知冻结、止付、追踪和争议处理的时间窗口，减少受害者在多个平台之间反复提交材料。
- 避免二次伤害：申诉页面不应要求用户重复上传无关隐私信息，也不应在调查完成前公开受害者身份或未经核实的责任判断。
总结
EvilTokens被打击并不意味着同类风险已经消失。它暴露出的根本问题是，攻击者可以利用正规的身份认证流程取得合法令牌，再借助人工智能迅速理解组织关系并实施精准诈骗。平台需要把账号安全、内容治理、交易风控和受害者救济整合起来，以最小权限、持续验证、组合信号审核和可追溯处置替代单纯依赖密码与关键词过滤的被动防线。
事件及资料日期：
2026年9月22日，微软数字犯罪部门公布EvilTokens跨机构打击行动及整体影响，参见微软官方公告。
2026年9月22日，微软威胁情报团队发布设备代码钓鱼技术分析、防护措施和检测建议，参见微软安全博客。
2026年9月22日，独立安全媒体对查封行动、设备代码攻击方式及英国警方相关行动进行交叉报道，参见The Hacker News报道。
