1. 项目概述当“设备码”成为攻击者的新钥匙最近在安全圈里一个名为“EvilTokens”的工具集被频繁提及它让一种针对微软生态的“设备码钓鱼”攻击变得异常简单和高效。你可能已经习惯了警惕那些伪造的登录页面要求你输入用户名和密码但这次攻击者甚至不需要你输入任何密码。他们瞄准的是另一种凭证——访问令牌。想象一下你正在使用一个合法的微软应用比如Outlook或者Teams它提示你“请在另一台设备上访问microsoft.com/devicelogin并输入代码ABCDE来完成登录”。这个流程本身是微软为了简化无头设备如命令行工具、IoT设备登录而设计的OAuth 2.0设备授权流程初衷是提升安全性。然而EvilTokens这类工具的出现将这个原本安全的流程变成了攻击者的利器。攻击者可以伪造这个流程诱导你在不知情的情况下将你的账户访问权限“授权”给了他们控制的恶意应用。这不仅仅是理论风险。结合近期网络上的热议比如“微软商店打不开”、“vscode微软登录不上”、“微软应用商店无法加载一直显示转圈状”这些现象背后除了网络问题也可能是不明身份的应用在后台滥用设备码流程干扰了正常的认证服务。更令人担忧的是攻击的门槛被大大降低。过去实施一次精密的钓鱼攻击需要搭建钓鱼网站、编写欺骗性脚本而现在借助EvilTokens这样的“钓鱼即服务”套件攻击者几乎可以一键部署将攻击目标从窃取密码转向窃取具有更高权限、更持久的访问令牌。这对于依赖微软365、Azure AD等服务的个人和企业来说构成了新的、更隐蔽的威胁。本文将深入拆解这种攻击的运作机理并基于一线防御经验提供从检测到缓解的实战指南。2. 攻击机理深度解析EvilTokens如何“无密码”窃取令牌要理解防御必须先透彻理解攻击是如何发生的。EvilTokens工具集的核心是自动化并武器化了OAuth 2.0的设备代码授权流程。让我们抛开复杂的协议描述用一场“精心设计的骗局”来类比整个过程。2.1 OAuth设备码流程的正常与异常在正常的设备码流程中当你在一台无法直接显示浏览器页面的设备比如一台Linux服务器上的Azure CLI上登录时会发生以下步骤设备向微软的身份认证服务器如login.microsoftonline.com发起请求说“我需要一个设备码来让用户授权。”认证服务器返回一个设备码如ABCDE和一个验证URL通常是https://microsoft.com/devicelogin。你需要在另一台有浏览器的设备如你的手机或电脑上打开那个URL输入设备码。浏览器会引导你完成微软的登录流程可能包括多因素认证并询问你是否授权某个应用例如“Azure CLI”访问你的账户。你点击“同意”后认证服务器会向最初请求设备码的那个设备颁发访问令牌和刷新令牌。EvilTokens的恶意之处在于它扮演了那个“无法显示浏览器的设备”。攻击者运行EvilTokens它会向微软认证服务器请求一个合法的设备码和验证URL。然后攻击者通过钓鱼邮件、即时消息、甚至是被入侵的网站将这个验证URL和设备码发送给受害者。邮件内容可能伪装成“安全警报您的账户有异常登录请立即验证”或“需要您授权一个新的合规性扫描工具”。注意这里的URLmicrosoft.com/devicelogin是完全合法的微软官方域名这极大地增加了欺骗性。传统的钓鱼攻击需要伪造一个看起来像的域名如micr0soft.com而这里连域名伪造都省了。2.2 EvilTokens的自动化攻击链EvilTokens工具集将上述过程完全自动化初始化攻击攻击者配置工具指定要窃取令牌的目标租户企业或通用消费者账户。生成钓鱼载荷工具自动请求设备码并生成一个包含唯一验证URL和设备码的钓鱼消息模板。投递与诱导攻击者通过社工手段发送消息。关键在于诱导受害者在自己的浏览器中打开那个合法的微软验证页面并输入攻击者生成的设备码。等待与捕获EvilTokens在后台轮询微软认证服务器检查用户是否“同意”。一旦受害者在不知情的情况下完成了授权他以为是在授权某个公司内部应用或解决某个问题攻击者控制的恶意应用就获得了访问令牌。令牌滥用攻击者使用窃取的访问令牌可以模拟受害者访问其微软邮箱Exchange Online、OneDrive文件、Teams聊天记录甚至通过令牌获取更高权限进行横向移动。为什么这种攻击更危险绕过密码与MFA它不窃取密码因此密码强度和多因素认证MFA在此流程的“同意”环节可能被绕过。如果用户已经登录了微软账户甚至可能一键同意无需再次输入密码或MFA。令牌的持久性访问令牌尤其是附带刷新令牌时的生命周期可能是数小时、数天甚至更久。攻击者获得令牌后在令牌失效前可以持续访问而不需要受害者的再次参与。高隐蔽性整个交互发生在受害者与真正的微软域名之间没有传统的恶意网站因此基于URL信誉的防护可能失效。3. 核心防御策略构建从检测到响应的全链条面对这种利用合法流程的攻击我们的防御思路必须从“拦截恶意域名”升级到“监控异常授权行为”和“管理应用权限”。以下是基于实战的防御体系构建。3.1 强化终端用户意识与设置第一道防线永远是“人”。但这里的教育不是简单的“不要点击陌生链接”而是更具体的场景化培训。培训要点识别合法流程的滥用教育员工任何要求你前往microsoft.com/devicelogin或类似页面输入代码的请求都必须高度警惕。除非是你自己主动在服务器、命令行或新安装的官方应用上发起登录否则应视为可疑。仔细审查同意屏幕在点击“同意”前务必仔细查看请求权限的应用名称、发布者信息和请求的权限范围。对于不认识的、名称可疑的如“Test App”、“Security Scanner v2.1”或请求权限过度的应用一律拒绝。建立内部报告流程让员工知道遇到此类不明验证请求应立即报告给IT安全部门而不是自行处理。客户端设置使用条件访问策略这是微软企业防御体系中最核心的一环。可以创建策略限制来自非合规设备、非信任地理位置或高风险IP地址的设备码流程的完成。例如一条策略可以规定“如果登录尝试使用设备码授权流程且来自非公司注册的IP段则直接阻止访问。”禁用不必要的用户同意在Azure AD企业应用中管理员可以禁用用户对应用程序的同意能力或者将同意范围限制为仅限已验证的发布者或管理员批准的权限。这能从根本上防止用户无意中授权恶意应用。3.2 云端日志监控与异常检测攻击发生在云端防御的视野也必须在云端。Azure AD提供了丰富的日志是发现EvilTokens攻击的关键。核心监控日志审核日志重点关注Consent to application同意应用程序事件。筛选出同意操作检查Target被同意的应用的AppId和DisplayName。突然出现对陌生、新创建或名称怪异的应用的同意就是高危告警。登录日志筛选DeviceCode作为登录方法。分析这些设备码登录的上下文应用登录的应用是否为公司已知、合法的应用如Azure Portal, Office 365如果是一个陌生的、低权限的“第三方OAuth应用”则需要深究。地理位置/IP登录请求的源IP是否与用户常用地、公司网络IP不符设备状态关联的设备信息是否异常构建检测规则示例 我们可以使用Azure Sentinel或任何SIEM的KQL查询来构建检测规则。以下是一个简化的示例逻辑AuditLogs | where OperationName Consent to application | where Result success | extend AppId tostring(TargetResources[0].id) | extend AppDisplayName tostring(TargetResources[0].displayName) // 加入白名单机制排除已知的、合法的应用ID | where AppId !in (known-app-guid-1, known-app-guid-2) // 查找新出现的、不常见的应用 | join kindleftouter ( AuditLogs | where TimeGenerated ago(30d) | where OperationName Consent to application | extend AppId tostring(TargetResources[0].id) | summarize FirstSeen min(TimeGenerated) by AppId ) on AppId | where FirstSeen ago(1h) // 过去一小时内首次被同意的应用 | project TimeGenerated, OperationName, InitiatedByInitiatedBy.user.userPrincipalName, AppDisplayName, AppId, IPAddress, ClientAppUsedInitiatedBy.user.appDisplayName这条规则的核心是发现“短时间内新出现的、被成功同意的非白名单应用”这极有可能是一次成功的设备码钓鱼攻击。3.3 主动狩猎与应用程序权限治理除了被动检测还需要主动清理和加固。定期审查已同意的应用路径Azure AD - 企业应用程序 - 所有应用程序。使用筛选器查看“同意于”时间并关注那些权限范围大如Mail.ReadWrite,Files.Read.All,User.Read.All但并非由IT部门管理的应用。操作对于可疑应用立即撤销其权限。在应用程序详情页的“权限”部分可以查看是哪些用户/管理员同意的并执行撤销。实施应用程序治理策略要求管理员审查对于请求高特权权限如读取所有用户邮箱、读写所有文件的应用即使发布者已验证也强制要求管理员审查后才能同意。生命周期管理设置策略自动移除长时间未使用如90天的用户分配或应用同意。利用云应用安全代理集成Microsoft Defender for Cloud Apps或其他CASB解决方案。这些工具可以识别出使用非标准或可疑OAuth应用的行为并自动触发警报或补救动作例如要求用户重新认证或直接阻止访问。4. 应急响应与事件处理实操指南当监控告警响起或者有用户报告可疑的设备码验证请求时必须有一套清晰的响应流程。4.1 事件确认与初步遏制确认攻击指标查询同意日志立即在Azure AD审核日志中根据报告的用户、时间或检测规则告警中的AppId找到具体的Consent to application事件记录。收集信息记录下恶意应用的AppId、DisplayName、请求的权限范围、同意时间、同意用户以及发起请求的IP地址和客户端信息。立即遏制撤销应用权限在Azure AD企业应用列表中找到该恶意应用进入“权限”页面点击“撤销权限”。这是最直接、最有效的止损措施立即使窃取的令牌失效。禁用或删除恶意应用如果确认该应用完全恶意且无任何业务关联可以直接将其从企业应用中删除。重置用户会话对于已被盗用令牌的用户在Azure AD用户管理页面找到该用户选择“注销所有会话”。这会立即使该用户在所有设备上的现有刷新令牌和会话令牌失效强制重新登录。通知受影响用户告知用户其账户可能已遭受入侵指导其检查邮箱规则攻击者可能设置了邮件转发、登录活动并立即更改密码尽管攻击未直接窃取密码但这是安全加固的常规步骤。4.2 深入调查与影响评估遏制后需要评估攻击的影响范围。令牌作用域分析仔细审查恶意应用获得的API权限。是Mail.Read仅读邮件还是Mail.ReadWrite可读写、发送邮件是User.Read读取基本资料还是User.Read.All读取所有用户信息这决定了攻击者可能进行了哪些操作。搜索恶意活动日志邮箱审计如果应用有邮件权限在Microsoft Purview合规门户或通过Exchange Online PowerShell搜索该用户邮箱在同意事件后是否有异常的邮件访问、删除或转发规则设置。统一审计日志在Microsoft Purview合规门户中运行更广泛的审计日志搜索使用恶意应用的AppId作为筛选条件查看它是否还访问了其他用户的资源如果权限足够。云应用安全在Defender for Cloud Apps中查看该应用或相关IP地址的异常活动时间线。4.3 事后加固与复盘事件处理后必须进行加固以防止 recurrence。更新检测规则将此次事件的恶意AppId、攻击者IP等指标加入现有的SIEM/SOC检测规则黑名单或异常模型。收紧条件访问策略分析攻击路径。如果攻击来自特定国家/地区可以在条件访问中增加对该地区的阻止或要求额外验证。考虑为所有“设备码”授权流程添加一个要求比如必须使用合规设备。开展针对性培训以本次事件为案例对全体员工进行新一轮的网络安全意识培训重点讲解设备码钓鱼的识别与应对。审查应用同意策略再次评估并可能进一步收紧Azure AD中的用户同意设置。对于非必要情况考虑完全禁止用户同意所有应用上架需经IT管理员审批。5. 高级防护与未来威胁展望随着攻击工具的普及防御方也需要更前瞻性的思考。5.1 利用身份保护与风险检测微软的Identity Protection功能基于持续的风险评估可以自动响应高风险登录。配置风险策略可以创建策略当检测到“匿名IP地址”、“不熟悉的位置”或“受恶意软件感染的链接设备”进行登录时特别是当登录方法为“设备码”时自动要求多重认证或直接阻止。这为设备码流程增加了一层动态的风险评估屏障。调查风险事件定期查看Identity Protection报告中的风险事件关注其中与“设备码”登录相关的条目这可能是自动化攻击工具未能成功获取用户同意但仍留下了试探痕迹。5.2 对开发与集成流程的安全管控很多设备码流程的滥用源于企业内部开发或集成了不安全的第三方应用。内部开发安全要求内部开发团队在注册用于集成的AAD应用时遵循最小权限原则并明确记录应用用途。禁止在生产环境中使用高权限的测试应用。第三方应用采购审查建立第三方SaaS应用引入的安全审查流程。在同意任何第三方应用访问公司数据前必须由安全团队评估其请求的权限是否必要、其OAuth实现是否安全如是否使用PKCE防止授权码拦截。5.3 威胁演变与应对思考EvilTokens代表了攻击工具“服务化”、“傻瓜化”的趋势。未来我们可能会看到更精准的社工结合攻击者可能结合从其他渠道泄露的信息如从领英获取的职位信息伪造更具针对性的钓鱼消息例如冒充公司IT部门新部署的“财务审批系统”或“安全合规扫描工具”。对条件访问策略的规避攻击者可能通过控制位于“受信任”地理位置的代理服务器或已感染的合规设备来发起攻击试图绕过基于IP和设备的策略。多阶段攻击的跳板窃取的初始令牌可能权限不高但攻击者会利用它作为立足点通过枚举API、提权漏洞或进一步的社工获取更高权限的访问。应对这些演变防御的核心将更加依赖于“零信任”原则永不默认信任始终验证。这意味着我们需要持续地验证每一个访问请求的身份、设备健康状态、请求上下文和风险评分而不仅仅是依赖一次性的认证。将设备码流程视为一个高风险的认证方法对其施加更严格的条件访问控制、更细粒度的监控和更快速的异常响应是我们构建弹性身份安全体系的必经之路。