1. 项目概述当“合法”流程成为攻击者的帮凶最近在分析企业安全事件时一个趋势让我格外警惕攻击者不再仅仅依赖传统的恶意软件或漏洞利用而是开始系统性地滥用我们日常工作中高度信任的合法协议和云服务。其中基于OAuth设备代码流Device Code Flow的钓鱼攻击结合对PaaS平台即服务平台的滥用已经演变成一种极具迷惑性和破坏性的新型威胁。这种攻击最狡猾的地方在于它全程发生在微软、谷歌等官方、可信的登录页面上用户几乎无法凭肉眼辨别真伪最终导致核心的M365访问令牌和刷新令牌被窃取攻击者得以长驱直入完全绕过多因素认证这道“马奇诺防线”。这不仅仅是又一个钓鱼变种它标志着企业身份安全威胁进入了一个新阶段攻击者开始利用“信任”本身作为武器。他们不再需要伪造一个粗糙的钓鱼网站而是直接劫持合法的OAuth授权流程并利用Railway、Vercel、Heroku等知名PaaS服务来托管其恶意服务后端从而披上了一层“合法”和“可信”的外衣。对于安全团队而言这意味着传统的基于URL信誉或页面相似度的检测手段几乎完全失效防御的焦点必须从“识别恶意”转向“验证授权意图的合法性”。本文将深入拆解这种攻击的完整链条从OAuth设备码流的工作原理、攻击者如何滥用PaaS平台到最终窃取M365令牌的每一步细节。更重要的是我会结合一线防御经验分享一套从协议层、令牌层到行为层的纵深防护思路并提供一些可直接落地的检测规则与配置脚本。无论你是负责企业身份安全的工程师还是关心云上应用安全的开发者理解这种攻击模式都至关重要。2. OAuth设备码流便利性背后的安全盲区要理解攻击为何能成功首先必须吃透被滥用的协议本身。OAuth 2.0设备代码授权流RFC 8628设计初衷是为了解决输入受限设备如智能电视、游戏机、IoT设备的登录难题。这些设备没有完整的浏览器或键盘无法像传统Web应用那样完成标准的OAuth交互。2.1 标准流程是如何工作的让我们还原一个标准的、合法的设备码流交互过程。假设你想在Xbox上登录你的Netflix账户。设备发起请求你的Xbox客户端向Netflix的授权服务器Authorization Server 如Microsoft Entra ID发起一个设备授权请求。这个请求通常包含客户端的身份标识client_id。服务器返回设备码与用户码授权服务器响应一组关键信息device_code一个较长的、用于设备轮询的密钥。user_code一个简短的、易于用户在另一设备上输入的代码例如ABCD-EFGH。verification_uri用户需要访问的验证页面地址如https://microsoft.com/devicelogin。verification_uri_complete可选直接包含了用户码的完整URL。expires_in设备码的有效期通常5-15分钟。interval设备轮询令牌端点获取结果的建议间隔时间通常5秒。用户完成授权你需要在手机或电脑上打开浏览器访问verification_uri输入屏幕上显示的user_code。随后你会看到标准的OAuth同意屏幕提示“Xbox上的Netflix应用请求访问你的个人资料”你需要点击“同意”。设备轮询获取令牌与此同时你的Xbox在后台以固定的时间间隔使用device_code和client_id向授权服务器的令牌端点发起轮询请求。令牌下发一旦你在浏览器端点击了“同意”授权服务器就会在下一次设备轮询时将访问令牌Access Token和刷新令牌Refresh Token返回给Xbox。至此登录完成。这个流程的核心安全假设在于verification_uri是绝对可信的由权威的授权服务器如Microsoft提供用户有能力在受控的个人设备上完成授权操作。2.2 攻击者看到了什么漏洞攻击者敏锐地发现了这个流程中可以被扭曲的几个关键点可信URI的不可篡改性虽然verification_uri来自授权服务器但攻击者可以完全控制“诱导用户去访问这个URI”的上下文和环境。他们可以伪造一封来自“IT支持”的邮件声称“您的账户有异常活动请立即访问以下链接并输入验证码完成安全验证”而链接就是真正的https://microsoft.com/devicelogin。用户意图的不可验证性授权服务器页面只显示“某应用请求访问您的数据”但它无法向用户说明“这个请求是在什么情境下被触发的”。用户无法区分这是一个来自自己智能电视的合法请求还是一个来自攻击者恶意客户端的钓鱼请求。PaaS平台提供的“可信”后端攻击者需要运行一个服务来执行第1步发起设备授权请求和第4步轮询获取令牌。如果这个服务托管在某个可疑的IP或域名上安全设备可能很快会告警。于是攻击者转向了Railway、Vercel、Netlify、Heroku等主流PaaS平台。这些平台提供的*.vercel.app、*.railway.app域名通常在企业防火墙和邮件安全网关的白名单中因为它们被大量合法开发者使用。攻击者在此托管一个轻量级的恶意服务常被命名为“EvilTokens”或类似轻松获得了“出生清白”的基础设施。注意这里存在一个巨大的认知偏差。用户和基础安全设备倾向于信任microsoft.com这个域名但整个攻击链的起点恶意邮件和终点窃取令牌的PaaS服务才是真正的恶意部分而它们被“合法的中间人”——微软登录页面——巧妙地隔开了。3. 攻击链深度拆解一次完整的“隐形”入侵让我们跟随攻击者的视角一步步拆解这个攻击链。我将其概括为四个阶段准备、诱导、窃取、利用。3.1 第一阶段武器化准备——在PaaS上搭建“EvilTokens”攻击者首先会选择一个合适的PaaS平台。Railway因其简单的部署流程和免费的额度成为热门选择。他们创建一个新项目并部署一个简单的Web服务。这个服务的代码逻辑非常清晰一个Web界面可选用于攻击者自己管理显示钓鱼状态。核心端点/initiate当被访问时该端点会向微软的OAuth 2.0设备码端点https://login.microsoftonline.com/{tenant}/oauth2/v2.0/devicecode发起一个POST请求。请求体中携带攻击者事先注册好的一个恶意OAuth应用的client_id。这个应用通常被伪装成“Microsoft Teams Backup”、“Company Expense Reporter”等看似合理的名称以降低用户在同意时的警惕性。处理响应服务收到微软返回的device_code,user_code,verification_uri等信息。它将user_code和verification_uri存储到数据库或内存中关联一个会话ID并将user_code和标准的verification_uri即https://microsoft.com/devicelogin返回给攻击者用于下一步诱导。同时服务启动一个后台线程或任务开始用device_code轮询微软的令牌端点https://login.microsoftonline.com/{tenant}/oauth2/v2.0/token。核心端点/poll后台轮询任务持续检查授权状态。一旦用户中招并在微软页面上点击了同意微软的令牌端点就会返回访问令牌和刷新令牌。服务立即将这些令牌捕获安全地存储起来可能发送到攻击者控制的另一个服务器并标记该会话为“成功”。至此一个架设在可信PaaS域名下的、专门用于窃取令牌的“中转站”就搭建完成了。它的IP地址是PaaS平台的域名是*.railway.app流量特征与普通开发者应用无异。3.2 第二阶段社会工程学诱导——在官方页面完成“钓鱼”这是攻击最具欺骗性的环节。攻击者制作钓鱼邮件或消息。内容不再是“请点击此链接重置密码”而是升级为“【IT部门紧急通知】检测到您的账户usercompany.com在陌生设备上有登录尝试。为保障安全请立即访问微软官方登录页面https://microsoft.com/devicelogin并输入以下验证码G7BH-92KX以确认您的身份并阻止可疑活动。如非本人操作请忽略此邮件。”心理操控利用紧急性和权威性IT部门制造恐慌。技术伪装链接是100%真实的微软官方域名任何URL检查工具都会显示其为安全。请求的来源恶意PaaS服务被完全隐藏。动作转移将用户的注意力从“点击链接”转移到“输入代码”这个看似更安全的操作上。用户访问microsoft.com/devicelogin输入邮件中的user_code即G7BH-92KX。页面加载出OAuth同意屏幕显示“应用 ‘Microsoft Teams Backup’ 请求访问您的邮箱、日历、联系人…”。用户可能心存疑虑但想到链接是官方的且邮件声称是安全验证很可能点击“接受”。3.3 第三阶段令牌窃取与持久化——绕过所有认证在用户点击“接受”的瞬间攻击链的后台部分完成闭环攻击者PaaS服务上的后台轮询任务从微软令牌端点成功获取到了属于该用户的访问令牌Access Token和刷新令牌Refresh Token。访问令牌通常有效期为1小时允许攻击者立即访问用户的邮箱、OneDrive、SharePoint等M365资源。更致命的是刷新令牌其有效期可达90天甚至更长且可用来获取新的访问令牌。这意味着攻击者在未来数月内无需用户密码、无需多因素认证MFA即可随时重新获得该用户的访问权限实现了“无密码持久化访问”。3.4 第四阶段横向移动与数据渗出——令牌的威力拿到有效令牌后攻击者便拥有了一个合法的身份凭证。他们可以使用Microsoft Graph API或其他M365 API进行各种恶意操作邮箱窃密读取、转发邮件搜索敏感信息。内部钓鱼以该受害用户的身份向同事发送更具欺骗性的邮件。数据窃取下载OneDrive、SharePoint中的商业机密。权限提升如果该用户是管理员攻击者可以进一步修改全局设置、创建新账户、授予更高权限。整个过程中企业部署的传统安全防护手段面临巨大挑战邮件链接检测链接是官方的、网络流量检测流量指向微软和可信PaaS、端点防护无恶意软件执行。攻击者巧妙地躲在合法协议和可信服务的背后。4. 防御体系构建从协议管控到行为感知面对这种“合法外衣下的非法行为”防御思路必须转变。不能只盯着“是不是恶意”更要判断“是否合理”。我建议构建一个由内到外的四层纵深防御体系。4.1 第一层协议层管控——收紧OAuth设备码流的默认策略最直接的防御是在源头进行限制。在Microsoft Entra IDAzure AD中我们可以对设备码流进行精细化管理。核心策略有条件地禁用或严格审查设备码流。全局审计首先在Entra ID管理中心的“监视”-“登录日志”中筛选“客户端应用”为“设备代码流”了解组织内哪些应用、哪些用户在使用此流。这有助于建立基线。创建条件访问策略目标选择“所有用户”或“除特定服务账户外的所有用户”。云应用选择“Office 365”或“所有云应用”。条件在“客户端应用”中勾选“移动应用和桌面客户端”下的“其他客户端”。设备码流通常被归类于此。授权选择“阻止访问”。命名例如“阻止-非托管设备上的设备代码流”。这个策略会阻止大多数未经特别允许的设备码流请求。但是必须设置例外否则会影响合法的智能电视、打印机等设备登录。你需要创建安全组建立一个名为“允许-设备码流的服务主体”的安全组。识别并添加合法应用将那些必须使用设备码流的合法服务主体Service Principal对象加入此组。例如公司使用的某些IoT平台应用、会议室系统集成应用等。在阻止策略中排除该组在上述条件访问策略的“用户”或“服务主体”排除项中添加这个安全组。实操心得识别合法应用是个细致活。建议先启用策略的“仅报告”模式运行几周分析被拦截的登录日志逐一确认每个触发该流的应用是否业务必需。这是一个清理OAuth应用库存的好机会。4.2 第二层应用与令牌生命周期管理——最小权限与及时清理攻击者依赖他们注册的恶意OAuth应用。强化应用和令牌的管理能直接抬升攻击成本。收紧用户同意设置在Entra ID的“企业应用”-“用户设置”中将“用户可以同意应用程序代表他们访问公司数据”设置为“否”。这迫使所有需要公司数据权限的应用都必须经过管理员同意。启用“管理员同意工作流”让用户可以请求管理员审批应用而不是完全禁止平衡安全与效率。定期审计已同意的应用定期查看“企业应用”列表按“权限分类”筛选“高”权限的应用。特别关注那些只有少数用户同意、但权限范围极广如Mail.ReadWrite,Files.Read.All,User.ReadWrite.All的应用。利用Microsoft Graph API编写脚本定期导出所有应用的同意情况进行分析是更高效的做法。强制实施令牌生存期策略在Entra ID的“令牌生存期”配置中可以缩短刷新令牌的最大寿命。虽然不能设置得太短以免影响用户体验但将其从默认的90天调整为30或60天可以显著缩短攻击者利用被盗刷新令牌的时间窗口。配置条件访问策略中的“登录频率”强制用户定期重新认证即使他们持有有效的刷新令牌。4.3 第三层行为分析与异常检测——发现“不合理”的授权当协议层和应用层管控到位后我们需要通过日志分析来发现那些已经绕过基础防御的异常行为。这里的关键是建立“正常”行为基线并寻找偏差。可工程化的检测规则示例基于Microsoft Sentinel/SIEM你可以编写KQL查询在登录日志和审计日志中寻找以下可疑模式// 检测1同一应用在极短时间内从大量不同IP地址发起设备码流请求可能是攻击者大规模扫描或诱导 SigninLogs | where AppDisplayName has YourSuspiciousAppName // 或筛选 ClientAppUsed DeviceCode | where TimeGenerated ago(1h) | summarize StartTimemin(TimeGenerated), EndTimemax(TimeGenerated), IPCountdcount(IPAddress), UserCountdcount(UserPrincipalName) by AppDisplayName, ClientAppUsed | where IPCount 10 and UserCount 5 // 阈值可根据环境调整 | project AppDisplayName, ClientAppUsed, StartTime, EndTime, IPCount, UserCount // 检测2用户成功通过设备码流认证后短时间内从完全不同的地理位置/IP地址使用同一令牌访问资源令牌被盗用迹象 let DeviceCodeLogs SigninLogs | where ClientAppUsed DeviceCode and ResultType 0 // 成功的设备码流登录 | project UserPrincipalName, DeviceCodeAuthTimeTimeGenerated, DeviceCodeIPIPAddress, DeviceCodeLocationLocation, DeviceCodeAppAppDisplayName; let TokenUsageLogs AuditLogs | where OperationName UserLoggedIn // 或其他资源访问日志 | project UserPrincipalName, TokenUsageTimeTimeGenerated, TokenUsageIPIPAddress, TokenUsageLocationLocation, ResourceTargetResourceType; DeviceCodeLogs | join TokenUsageLogs on UserPrincipalName | where TokenUsageTime DeviceCodeAuthTime and TokenUsageTime DeviceCodeAuthTime 10m // 令牌获取后10分钟内被使用 | where TokenUsageIP ! DeviceCodeIP // IP地址不同 | extend GeoDistance geo_distance_2points(DeviceCodeLocation, TokenUsageLocation) // 计算地理距离如果日志有坐标 | where GeoDistance 100000 // 距离超过100公里视为异常 | project UserPrincipalName, DeviceCodeAuthTime, DeviceCodeIP, DeviceCodeApp, TokenUsageTime, TokenUsageIP, Resource检测思路解析检测1针对攻击准备阶段。一个正常的设备码流应用如公司会议室系统的请求IP和用户应该是相对稳定和有限的。短时间内从全球各地IP发起的请求极有可能是攻击者在进行大规模钓鱼活动。检测2针对令牌滥用阶段。如果一个用户刚在纽约通过设备码流登录可能是其智能电视5分钟后其令牌就在东京被用来读取邮件这强烈暗示令牌已被窃取并转移。4.4 第四层情境化与用户教育——最后一道防线技术手段之外人的因素至关重要。实施情境化提示虽然微软的标准同意屏幕信息有限但企业可以通过自定义安全属性或未来的条件访问特性尝试在同意屏幕上添加更多上下文信息。例如通过集成CASB或身份安全解决方案在检测到异常请求时向用户弹出额外警告“此登录请求来自一个非常用国家/地区且应用权限较高请谨慎批准。”开展针对性安全意识培训教育用户关于这种新型钓鱼攻击的特征核心信息“即使链接是microsoft.com要求你输入代码的请求也可能是骗局。”验证步骤收到此类请求时应通过独立、已知的渠道如公司内部IT支持电话、Teams直接联系IT同事进行二次验证。识别可疑点邮件是否制造不必要的紧迫感发送方地址是否可疑请求的应用名称是否陌生且权限过高建立明确的举报流程让用户可以一键举报可疑的同意屏幕或验证请求安全团队能快速响应并调查。5. 应急响应与实战排查清单当怀疑或确认发生此类攻击时时间就是金钱。以下是一个清晰的应急响应流程立即隔离在Entra ID中立即禁用疑似被盗账户。撤销该用户的所有会话令牌。在Entra ID用户管理页面找到该用户选择“注销所有会话”。证据收集搜索该用户过去24-72小时的所有登录日志SigninLogs重点关注ClientAppUsed “DeviceCode”且成功的记录。记录下AppDisplayName,IPAddress,DeviceDetail。在“企业应用”中搜索上述日志中发现的AppDisplayName找到对应的服务主体。审查其权限、同意用户和所有者。遏制清除在“企业应用”中立即删除确认恶意的应用。检查该恶意应用是否还被其他用户同意批量撤销。检查受影响用户邮箱的转发规则、可疑的邮件发送记录。溯源调查使用收集到的恶意应用ID和IP在日志中回溯寻找攻击者初始部署PaaS服务、发送钓鱼邮件的其他线索。检查是否有其他用户被同一应用攻击。系统加固根据第4章的防御建议检查并加固相关策略。考虑临时对所有用户发起一次令牌撤销和强制重认证。常见问题排查速查表问题现象可能原因排查步骤合法IoT设备无法登录条件访问策略过于严格阻止了设备码流1. 检查登录日志确认失败原因是否为“被条件访问策略拦截”。2. 确认该合法应用的服务主体是否已添加到条件访问策略的排除组中。检测规则误报率高阈值设置不合理或基线不准确1. 将检测策略先设置为“仅警报”或低严重性运行观察。2. 分析警报调整IP数量、时间窗口、地理距离等阈值。3. 将已知合法的批量操作IP或应用加入白名单。用户抱怨收到可疑验证码邮件可能正在发生小范围钓鱼试探1. 收集用户收到的验证码(user_code)。2. 在登录日志中搜索该user_code可能需要通过原始诊断数据查询。3. 定位发起该代码请求的应用和IP立即进行调查和封禁。管理员无法看到所有已同意应用权限不足或查看位置不对1. 确保使用全局管理员或特权角色管理员账户。2. 在Entra ID管理中心导航到“身份”-“应用”-“企业应用”这里查看所有服务主体和应用。使用筛选和列选择器显示“权限分类”等信息。6. 未来演进与防御前瞻攻击技术不会停滞。我们可以预见此类攻击的几种演进方向并提前思考防御策略滥用更多“可信”服务除了PaaS攻击者可能转向滥用云函数如Azure Functions、AWS Lambda、无代码平台甚至是被入侵的合法企业应用账号来发起初始请求使得流量来源更加难以甄别。协议混淆升级结合其他OAuth流进行混合攻击或利用OAuth 2.0的扩展机制添加恶意参数。针对移动端的适配设计更适配手机屏幕显示的钓鱼话术利用移动端用户对通知和快捷操作的信任。对应的防御也需要向前看持续关注OAuth动态密切关注OAuth 2.1、CIEM云基础设施权限管理等标准和技术的发展及时采纳更安全的默认配置。拥抱零信任网络访问ZTNA原则强调“从不信任始终验证”。对于内部应用应逐步采用ZTNA解决方案替代传统的VPN并对所有访问请求进行持续的设备、身份和上下文验证即使请求持有有效的OAuth令牌。深化UEBA应用用户与实体行为分析需要更精细地建模每个用户的正常OAuth授权行为模式。例如一个财务人员突然同意了一个具有“完全控制所有站点”权限的SharePoint应用这应立即触发高危警报。推动行业协作安全厂商、云服务提供商如Microsoft、Railway和安全社区需要共享此类滥用模式的IoC入侵指标建立更快的响应机制例如对用于钓鱼的PaaS账户进行更快的识别和封禁。这个案例深刻地提醒我们在现代以身份为中心的安全边界下最危险的威胁往往来自于对信任机制本身的扭曲。防御者必须将视角从传统的网络边界和恶意软件提升到身份协议、云资源配置和用户行为意图的层面。通过协议管控、生命周期管理、行为检测和持续教育构建的纵深防御才能有效应对这种穿着“合法”外衣的隐形攻击。