事件背景与漏洞概述
近期，Microsoft修复了Microsoft Entra ID中一个关键的权限绕过漏洞。该漏洞源于“Agent ID Administrator”这一特定角色在权限范围定义上的逻辑缺陷。在修复前，攻击者若能控制该角色账户，即可越权接管租户内的任意服务主体（Service Principal），进而实现权限提升或完全接管。
随着企业对AI代理（AI Agents）部署的日益增多，Microsoft推出了Agent Identity Platform以管理这些身份。然而，研究人员发现，原本仅应管理AI代理相关对象的“Agent ID Administrator”角色，在实际运行中却未能实现有效的边界隔离，导致其权限被滥用于非代理对象。
攻击链分析：从角色越权到完全控制
从我们的应急响应经验来看，攻击者往往擅长利用此类“权限边界不清”的漏洞进行横向移动。本次漏洞的攻击链逻辑非常清晰：
第一步：获取初始权限。攻击者通过钓鱼、凭据泄露等手段获得拥有“Agent ID Administrator”角色的账户权限。
第二步：越权操作。利用该角色对目标服务主体进行所有权变更（Assign Ownership），虽然该服务主体可能与AI代理毫无关联。
第三步：凭据注入。在接管服务主体所有权后，攻击者可直接为其添加新的凭据（如密钥或证书）。
第四步：身份冒充。攻击者利用添加的凭据以该服务主体的身份进行认证，从而继承该主体在租户内拥有的所有API权限、目录角色及数据访问权限。
这一环节是很多企业容易忽视的，因为服务主体往往拥有比普通用户更高的自动化权限，一旦失守，后果不堪设想。
安全挑战与隐蔽性分析
这一漏洞之所以具有高危性，原因在于其操作的隐蔽性。在审计日志中，修改所有权或添加凭据的行为往往被视为“正常的管理员操作”，缺乏明显的异常告警。此外，在UI界面中，该角色并未被明确标识为高权限角色，导致安全团队在进行权限最小化治理时，容易忽略对其的收紧。
从我们的溯源分析来看，类似攻击近年来明显增加。随着AI生态在企业内部的渗透，身份治理的复杂度呈指数级上升。当新的身份模型（如Agent ID）复用底层的服务主体架构时，若缺乏严格的范围限制（Scoping），极易产生安全真空。
Solar 应急响应建议
针对此类身份安全风险，我们建议广大用户采取以下防御措施：
第一，强化服务主体的生命周期管理。服务主体是现代云环境中的“超级用户”，应将其视为核心资产进行保护。定期盘点租户内所有服务主体的所有权关系，识别并清理不再使用的凭据。
第二，实施严格的权限审核。不要仅依赖云厂商提供的默认角色定义。对于具有管理权限的自定义角色或特殊功能角色，应通过最小权限原则（PoLP）进行隔离，并定期审计这些角色的实际变更记录。
第三，构建针对性监控策略。针对敏感操作（如添加服务主体凭据、变更所有者、修改敏感API权限）建立实时告警机制。不要依赖内置的默认告警，应根据业务环境自定义监控逻辑。
第四，关注身份架构的更新。随着Microsoft等厂商不断推出AI相关的新功能，身份模型也在快速迭代。建议安全团队在引入新身份功能时，同步评估其权限边界，避免因逻辑漏洞导致的安全隐患。
如果您想了解勒索病毒的最新发展趋势，或在实际业务中遇到类似安全事件，欢迎关注“Solar应急响应团队”。
全国热线：400-613-6816 官网：www.solarsecurity.cn / www.sierting.com