文章总结： 本文深度剖析MicrosoftEntraID中无防护高权限群组的安全风险，定义三类无防护群组特征并演示三个真实攻击场景：绕过条件访问策略、通过PIM窃取全局管理员权限、从云端攻陷本地域控。文章提供自动化检测工具EntraFalcon的开源地址，并给出修复方案核心原则——将关键群组纳入受限制管理管理单元或重建为可分配角色群组以实现更高等级保护。 综合评分： 85 文章分类： 渗透测试,漏洞分析,安全建设,解决方案,云安全

常见Entra ID安全评估发现（二）：盘点那些“无防护”的高权限群组

幻泉之洲

2026年4月19日 11:46 北京

在小说阅读器读本章

去阅读

许多企业使用 Microsoft Entra ID 群组来分配关键权限或定义安全策略。然而，大量这类权限群组本身缺乏防护，能被服务台级别的管理员或不受信的应用程序随意修改。一个疏忽，整套安全体系就可能从内部瓦解。本文深度剖析了这一常见安全隐患的三个真实攻击场景，并告诉你如何发现及加固。

“无防护”群组的定义

在 Entra ID 里，安全群的防护属性主要看三条：其一，是否由本地域控同步；其二，是否为“可分配角色的群组”；其三，是否位于“受限制管理管理单元”内。满足任一条，修改成员就需要特定高权限。

反之，如果这三条都不沾边，那么这个群组就是“无防护”的。这意味着，很多低级别的内置管理员角色，都能修改它的成员。这些角色包括：用户管理员、群组管理员，乃至知识管理员、Windows 365 管理员、目录写入者等。

说实话，这些角色很多时候会分配给服务台或一线支持人员。他们确实需要一些修改用户信息的权限，但绝不是让他们能碰到那些给管理员分配权限的群组。

三大攻击场景与实战推演

问题不在于群组本身可以被修改，而在于谁可以用这些群组来干什么。

场景一：绕过条件访问策略

想象一下，公司有个条件访问策略，要求“市场部”群组的成员必须用 MFA 登录。这个“市场部”群组恰恰是无防护的。

一个心怀不满的、拥有“用户管理员”权限的服务台员工，就可以轻易把销售总监从这个群里踢出去。下次销售总监登录时，MFA 就不再是强制要求，安全防线就此打开缺口。

更要命的是，如果策略里用了非安全性的 Microsoft 365 群组（还设置成公开可见），理论上任何内部用户都可能自己加进去，从而绕过策略。虽然现实中我们见得不多，但这个设计本身就很危险。

场景二：通过PIM for Groups窃取全局管理员

这个场景稍微复杂，但威力巨大。我们用PIM来管理群组成员资格，本身是好事。但如果配置不当，会给攻击者“搭梯子”的机会。

假设有个高权限的“可分配角色群组”叫 PFG_GlobalAdmin，它被分配了全局管理员角色。它的“合格成员”是一个无防护的普通群组 PFG_EligibleMembers。一个只拥有“知识管理员”权限的攻击者，可以分两步走：

1. 把自己加到那个无防护的“合格成员”群组里。
2. 在PIM里激活他在高权限群组中的成员资格。

没了。就这么简单，全局管理员到手。下面的截图展示了整个攻击链：

这个漏洞的精髓在于，PIM for Groups允许用非“可分配角色”的群组作为高权限角色的“合格成员”来源。这就形成了一个权限管理的断层。

场景三：从云端攻陷本地域控

这是我看过最精彩的横向渗透案例之一，完全打破了云和本地之间的安全边界。

在一次真实评估中，我们发现一个无防护群组 PROD_SUB_OWNERS，被分配了某个Azure生产订阅的“所有者”角色。这个订阅里，恰好有一个通过 Azure Arc 纳管的本地域控制器。

攻击链条就此成立：

• 攻击者通过一个已被入侵的企业应用（服务主体）登录。
• 这个应用有修改群组成员的权限（如 Group.ReadWrite.All）。
• 攻击者将该服务主体添加到无防护的 PROD_SUB_OWNERS 群组。
• 由于该群组是订阅所有者，攻击者现在可以访问订阅内的所有资源，包括那台域控制器。
• 利用 Azure Arc 的“运行命令”功能，直接在域控制器上以 SYSTEM 权限执行任意命令。

整个剧本的PowerShell代码都摆在面前，步步为营：

PS> $ApplicationId = “560480dc-8142-4b82-b81f-94a68e801877” PS> $ClientSecret = “EUG[CUT-BY-COMPASS]” … PS> Connect-MgGraph -TenantId $TenantID -ClientSecretCredential $ClientSecretCredential Welcome to Microsoft Graph!

Connected via apponly access using 560480dc-8142-4b82-b81f-94a68e801877

然后，找到并加入那个无防护的高权限群组：

PS> Get-MgGroup -All -Property Id,DisplayName,Description,IsAssignableToRole,OnPremisesSyncEnabled | Where-Object { -not $_.IsAssignableToRole -and -not $_.OnPremisesSyncEnabled} | Select-Object Id,DisplayName,Description

Id                                   DisplayName       Description —                                   ———–       ———– 37ae860a-f7c5-4b9c-8c7e-d4d4ce3952fd PROD_SUB_OWNERS   Owner role on the production subscription

最后，在云端向本地域控发起致命一击：

PS> New-AzConnectedMachineRunCommand … -SourceScript “whoami” … -MachineName “DC01” nt authority\system

PS> New-AzConnectedMachineRunCommand … -SourceScript “Get-ADDomain” … … DistinguishedName                  : DC=lab,DC=local DNSRoot                            : lab.local

一个在云端被入侵的应用程序，通过一个无防护的Azure角色分配群组，最终拿到了整个本地Active Directory的控制权。这种攻击路径，传统边界安全设备根本防不住。

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

手动在成千上万个群组里筛查是不现实的。好在有自动化工具。

Compass Security开源的 EntraFalcon 工具就能帮上大忙。它会枚举租户中的所有群组，检查它们是否受保护（同步、可分配角色、或在RMAU中）。对于无防护的群组，它还会进一步分析：

• 是否被用于Azure角色分配？
• 是否在 PIM for Groups 中被配置为高权限角色的“合格群组”？
• 是否被用于条件访问策略？

一旦发现，就会在安全发现报告里生成一条记录（发现ID: GRP-005），并提供完整的上下文信息。

报告是交互式HTML的，点进去就能看到细节。比如哪个无防护群组是订阅的所有者：

或者哪个无防护群组是全局管理员角色的合格成员来源：

以及哪个无防护群组被条件访问策略引用：

这个工具免费、开源，是进行Entra ID安全状况自检的利器。GitHub地址：https://github.com/CompassSecurity/EntraFalcon

修复方案：给权限加上锁

知道了风险，修复思路就清晰了。核心原则是：用于分配敏感权限或执行关键安全控制的群组，其本身必须受到更高等级的保护。

首选方案是使用受限制管理管理单元。把那些关键群组（以及群组里的用户）都放进去。这样，只有那些权限范围被限定在该管理单元内的管理员才能操作，服务台那种全局性的低权限管理员就碰不到了。

对于规模较小的租户，一个更简单的替代方案是：将这些群组重建为“可分配角色的群组”。即使你现在不打算用它来分配Entra ID角色，这个属性本身就会激活一套保护机制：只有特权角色管理员或指定的群组所有者才能管理它。同时，该群组的成员和所有者也会受到保护，防止低权限管理员重置他们的密码或MFA。

安全从来不是一劳永逸的配置，而是一个持续发现和加固的过程。从今天起，检查一下你的Entra ID里，那些承载着核心权限的群组，是不是正“赤身裸体”地暴露在过多的修改者面前。

免责声明：

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

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

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

本文转载自：幻泉之洲 《常见Entra ID安全评估发现（二）：盘点那些“无防护”的高权限群组》