从未使用的特权用户帐户容易遭到入侵，因为它们通常能够逃避防御措施的检测。此外，帐户可能配置了默认密码，使其成为攻击者的主要目标。

注意：此 IoE 依赖 Microsoft Entra ID P1 或 P2 许可来访问必要的数据。如果您的租户没有所需的许可证（例如 Entra ID 免费版），此 IoE 将不会返回发现结果。
从未使用过的用户指在 Entra ID 中创建、自创建以来在一定时间内（默认为 90 天，可自定义）从未成功进行过身份验证的用户帐户。
此类帐户由于各种原因会增加攻击面，例如：
<ul>
<li>后门程序帐户允许不再需要访问权限的人员（如前员工或从未使用过该帐户的实习生）继续访问。</li>
<li>继续使用默认密码会增加帐户遭到入侵的风险。例如，<a href="https://www.cisa.gov/news-events/cybersecurity-advisories/aa24-057a">CISA 警报</a>指出：<blockquote>
攻击活动还针对那些不再在受害组织工作但其帐户仍保留在系统中的用户的休眠帐户
</blockquote>
</li>
</ul>
，警报还提到：
<blockquote>
在某次事件中，所有用户被迫重置密码后，发现 SVR 攻击者登录了处于非活动状态的帐户，并按照指示完成了密码重置。这造成攻击者在事件响应驱逐活动后重新获得访问权限。
</blockquote>
<ul>
<li>造成诸如许可证等资源的浪费。通过定期识别、停用或移除不必要的用户，组织可以优化资源分配并节省不必要的成本。</li>
</ul>
此外，请考虑相关的“休眠用户”IoE，该指标可识别所有以前处于活动状态但现在处于非活动状态的用户。
特权用户面临的风险更高。对于非特权用户，另请参阅相关 IOE“从未使用的非特权用户”。
注意：
<ol>
<li>此 IoE 依赖用户对象的 <code>signInActivity</code> 属性中的 <code>lastSuccessfulSignInDateTime</code> 属性。与属性 <code>lastSignInDateTime</code> 不同，其优点在于仅报告成功的登录，从而避免因失败的登录尝试而引起的干扰。<code>lastSuccessfulSignInDateTime</code> 属性于 2023 年 12 月开始可用。</li>
<li>要访问 <code>signInActivity</code> 资源类型，每个租户都需要拥有 <a href="https://learn.microsoft.com/zh-cn/graph/api/resources/user?view=graph-rest-beta#:~:text=Details%20for%20this%20property%20require%20a%20Microsoft%20Entra%20ID%20P1%20or%20P2%20license%20and%20the%20AuditLog.Read.All%20permission">Microsoft Entra ID P1 或 P2 许可证</a>。否则，此 IoE 将无法检测从未使用的用户，并会因此跳过整个分析过程。</li>
<li>由于这一属性对于从未登录或最后一次登录发生在 <a href="https://learn.microsoft.com/zh-cn/graph/api/resources/signinactivity?view=graph-rest-beta#:~:text=Effective%20December%201%2C%202023">2023 年 12 月之前</a>的用户来说是空白的，因此缺少评估间隔所需的必要数据。鉴于此，Tenable Identity Exposure 无法正确检测最后的登录日期，可能会导致误报。</li>
</ol>

初始访问

有效帐户：云端帐户

从未使用的特权用户

Microsoft Entra 密码保护是一项安全功能，可防止用户设置容易被猜中的密码，以增强组织的整体密码安全性。

注意：此 IoE 依赖 Microsoft Entra ID P1 或 P2 许可来<a href="https://learn.microsoft.com/zh-cn/entra/identity/authentication/concept-password-ban-bad#license-requirements">访问必要的数据</a>。如果您的租户没有所需的许可证（如 Entra ID 免费版），此 IoE 将不会返回发现结果。
Entra ID 利用 <a href="https://learn.microsoft.com/zh-cn/entra/identity/authentication/concept-password-ban-bad">Microsoft Entra 密码保护</a>来缓解用户设置容易被猜中的密码所带来的风险，这些密码容易受到暴力攻击。此功能采用了全局禁用密码列表，该列表<a href="https://learn.microsoft.com/zh-cn/entra/identity/authentication/concept-password-ban-bad#:~:text=The%20global%20banned%20password%20list%20is%20automatically%20applied%20to%20all%20users%20in%20a%20Microsoft%20Entra%20tenant.%20There%27s%20nothing%20to%20enable%20or%20configure%2C%20and%20can%27t%20be%20disabled">默认启用且不可禁用</a>，其中包含常用的弱密码，并由 Microsoft 维护和定期更新。
尽管 Microsoft Entra 密码保护是一项基于云的功能，但组织可以按照“<a href="https://learn.microsoft.com/zh-cn/entra/identity/authentication/concept-password-ban-bad-on-premises">为 Active Directory 域服务强制执行本地 Microsoft Entra 密码保护</a>”中的描述，将其扩展到经典的本地 Active Directory（也称为“Windows Server Active Directory”）。组织通过在本地 Active Directory 域控制器上安装专用的 Microsoft 代理，同时通过基于云的 Entra 门户配置密码保护策略，来促进这一集成。
此风险暴露指标可评估两个决定 Microsoft Entra 密码保护在本地环境中的强制执行状态的设置：
<ul>
<li>“在 Windows Server Active Directory 上启用密码保护”应为“是”。</li>
<li>“模式”应为“强制”。</li>
</ul>
注意：
<ol>
<li>此 IoE 仅对与本地 Active Directory（即 Microsoft Entra Connect 或 Microsoft Entra Cloud Sync）同步的租户执行。其分析依据是<code>组织</code>的 <code>onPremisesSyncEnabled</code> 属性。</li>
<li>要为本地 Active Directory 域启用 Microsoft Entra 密码保护（如建议部分所述），组织需要在本地环境中的所有域控制器上部署代理。此 IoE 会检查 Entra ID 门户中的相关设置，但无法验证代理在本地 Active Directory 域控制器上的实际部署状态。因此可能会出现误报，即尽管代理未在所有 Active Directory 域控制器上完全部署或正常运行，但 Entra 中的配置看起来仍然合规。</li>
</ol>

网络钓鱼

本地环境未启用密码保护

来宾帐户是外部身份，当获得特权角色分配时，可能会造成安全风险。这将授予外部个体在您组织内的租户中相当大的特权。

<a href="https://learn.microsoft.com/zh-cn/entra/external-id/what-is-b2b">B2B collaboration</a> 是 Microsoft Entra ID 的一项功能，可让用户邀请来宾与您的组织进行协作。默认情况下，这些来宾帐户（也称为“外部身份”）会获得如下访问权限，如 <a href="https://learn.microsoft.com/zh-cn/entra/fundamentals/users-default-permissions#member-and-guest-users">Microsoft 所述</a>：
<blockquote>
他们可以管理自己的配置文件、更改自己的密码，并检索有关其他用户、组和应用程序的某些信息。但是，他们无法读取所有目录信息。
例如，来宾用户无法枚举所有用户、组和其他目录对象的列表。您可以将来宾用户添加为管理员角色，并授予其完整的读取和写入权限。来宾用户还可以邀请其他来宾。
</blockquote>
特权角色天然具有更高的特权。获得特权角色分配的来宾帐户会带来安全风险，并显著增加租户的攻击面。这尤其令人担忧，因为来宾帐户可能应用了较弱的安全策略，使其更容易遭到入侵。此外，为来宾用户分配特权角色会降低可追踪性，使得监控和审计其活动变得更加困难。在最坏的情况下，此类分配甚至可能表明已经发生入侵，因为威胁制造者常常利用来宾帐户进行未经授权的访问，并在环境中横向移动。
仔细监控这些来宾帐户，并确保不要为它们分配特权角色。
Microsoft 在“<a href="https://learn.microsoft.com/zh-cn/entra/fundamentals/configure-security#guests-are-not-assigned-high-privileged-directory-roles">配置 Microsoft Entra 以提高安全性</a>”一文中还建议“来宾用户不应被分配具有高特权的目录角色”。

有效帐户：默认帐户

侦查

收集受害者网络信息

主动扫描

特权提升

帐户操纵：其他云端角色

具有特权角色的来宾帐户

Microsoft Entra ID 允许通过联合功能将身份验证委派给其他提供者。然而，有更高特权的攻击者可以通过添加恶意联合域来利用该功能，从而实现持久性和特权提升。

Microsoft Entra 租户可以<a href="https://learn.microsoft.com/zh-cn/entra/identity/hybrid/connect/whatis-fed">与外部域联合</a>，以便与另一个域建立信任，从而进行身份验证和授权。组织使用联合功能，将 Active Directory 用户的身份验证委派到本地 Active Directory Federation Services (AD FS)。（请注意：外部域不是 Active Directory“域”。）
然而，如果恶意攻击者在 Microsoft Entra ID 中获得了更高的特权，他们可以添加自己的联合域或编辑现有的联合域来添加包含自己设置的辅助配置，从而滥用这种联合机制来创建后门程序​。此攻击将导致以下操作：
<ul>
<li>冒充​：恶意联合域可以生成令牌，允许攻击者以任何 Microsoft Entra 用户的身份来进行身份验证，且无需知道或重置密码。这包括“仅限云”用户（并非混合用户）和外部用户。这允许对 Microsoft Entra ID、Microsoft 365 (O365)，以及其他依赖 Microsoft Entra ID 作为身份验证提供商 (SSO) 的应用程序进行攻击，即便您已强制使用 MFA（见下方）。</li>
<li>特权提升​：攻击者可以冒充任何用户，尤其是特权 Microsoft Entra 用户。</li>
<li>多因素身份验证绕过​：受信任的外部域可以利用联合身份验证<a href="https://learn.microsoft.com/zh-cn/graph/api/resources/internaldomainfederation?view=graph-rest-beta#federatedidpmfabehavior-values">处理强制执行 MFA 的角色</a>。然后，恶意联合域可以错误地声称伪造的身份验证使用了受 Microsoft Entra ID 信任的 MFA，并且不会再次提示进行 MFA。即便在受到 MFA 保护的情况下，攻击者也可以通过这种方法冒充所有用户。</li>
<li>持久性​：添加恶意联合域是一种隐蔽的技术，允许入侵 Microsoft Entra 租户并占用高级特权的攻击者稍后重新获得访问权限。</li>
</ul>
此风险暴露指标根据其创建或转换的某些后门域特征，可检测 <a href="https://aadinternals.com/">AADInternals</a> 黑客工具包​，尤其是 <code>ConvertTo-AADIntBackdoor</code> 和 <code>New-AADIntBackdoor</code> cmdlet 创建的联合域后门程序。
同时，请参考相关的风险暴露指标“联合签名证书不匹配”。
用于将身份验证证明从恶意联合域传输到目标 Microsoft Entra ID 的联合协议可以是 WS-Federation 或 SAML。使用 SAML 时，这种攻击类似于“<a href="https://services.google.com/fh/files/misc/remediation-and-hardening-strategies-for-microsoft-wp-en.pdf#page=9">Golden SAML</a>”攻击，主要区别如下：
<ul>
<li>攻击者不是窃取现有联合功能的合法 SAML 签名密钥，而是使用自己的密钥注入他们的新域。</li>
<li>攻击者将伪造的令牌提供给联合服务（而不是特定服务），以对多个系统进行未经授权的访问。</li>
</ul>
<code>microsoft.directory/domains/allProperties/allTasks</code> 和 <code>microsoft.directory/domains/federation/update</code> 权限可授予管理员修改联合域的能力。截至 2023 年 11 月，包括潜在的自定义角色在内，以下内置 Microsoft Entra 角色具有此权限：
<ul>
<li><a href="https://learn.microsoft.com/zh-cn/entra/identity/role-based-access-control/permissions-reference#domain-name-administrator">域名管理员</a></li>
<li><a href="https://learn.microsoft.com/zh-cn/entra/identity/role-based-access-control/permissions-reference#external-identity-provider-administrator">外部身份提供程序管理员</a></li>
<li><a href="https://learn.microsoft.com/zh-cn/entra/identity/role-based-access-control/permissions-reference#hybrid-identity-administrator">混合身份管理员</a></li>
<li><a href="https://learn.microsoft.com/zh-cn/entra/identity/role-based-access-control/permissions-reference#global-administrator">全局管理员</a></li>
<li><a href="https://learn.microsoft.com/zh-cn/entra/identity/role-based-access-control/permissions-reference#partner-tier2-support">合作伙伴 Tier2 支持</a></li>
<li><a href="https://learn.microsoft.com/zh-cn/entra/identity/role-based-access-control/permissions-reference#security-administrator">安全管理员</a></li>
</ul>
APT29 黑客组织在 2020 年 12 月滥用这种方法对 SolarWinds 发起了臭名昭著的“Solorigate”攻击，<a href="https://www.microsoft.com/zh-cn/security/blog/2020/12/28/using-microsoft-365-defender-to-coordinate-protection-against-solorigate/">Microsoft</a> 和 <a href="https://services.google.com/fh/files/misc/remediation-and-hardening-strategies-for-microsoft-wp-en.pdf#page=22">Mandiant</a> 对此均有记录。

防御逃逸

域策略修改：域信任修改

凭据访问

伪造 Web 凭据：SAML 令牌

修改身份验证流程：混合身份

已知的联合域后门程序

MFA 为帐户提供强大保护，防止出现弱密码或泄露密码。根据安全最佳实践和标准，我们建议您启用 MFA，尤其是对于分配了特权角色的特权帐户。

多因素身份验证 (MFA) 之前被称为双因素身份验证 (2FA)，为帐户提供针对弱密码或已泄露密码相关漏洞的强大保护。为遵循<a href="https://learn.microsoft.com/zh-cn/entra/identity/conditional-access/howto-conditional-access-policy-admin-mfa">最佳实践</a>和行业标准，我们建议您启用 MFA，尤其是对于特权帐户，此类帐户是攻击者的主要目标，任何入侵都可能造成严重结果。
攻击者通过任意方法获得用户密码后，MFA 会通过要求额外的因素（例如来自移动应用程序且有时效的代码、物理令牌、生物识别功能等）来阻止身份验证。
当特权角色未要求进行 MFA，影响到被授予该特定特权角色的特权用户时，此风险暴露指标会向您发出警报。
借助 Microsoft Entra ID，您可以通过不同的方法启用 MFA：
<ul>
<li><a href="https://learn.microsoft.com/zh-cn/entra/fundamentals/security-defaults">安全默认设置</a>：预配置的安全设置，包括<a href="https://learn.microsoft.com/zh-cn/entra/fundamentals/security-defaults#require-administrators-to-do-multifactor-authentication">对管理员强制使用多因素身份验证</a>。启用此设置会同时激活 Microsoft 建议的多个安全功能。
</li>
<li><a href="https://learn.microsoft.com/zh-cn/entra/identity/conditional-access/overview">条件访问</a>：此策略会指定需要进行 MFA 的事件或应用程序。此类策略允许管理员进行常规 MFA 登录。注意：此功能需要 Microsoft Entra ID P1 或更高级别的许可证，并且不包含在 Microsoft Entra ID 免费版中。特别建议有复杂安全需求，试图精确定义身份验证标准的成熟组织使用此功能。此风险暴露指标会查找具有以下设置的条件访问策略：
<ul>
<li>“<a href="https://learn.microsoft.com/zh-cn/entra/identity/conditional-access/concept-conditional-access-users-groups#include-users">用户</a>”设置为包括“所有用户”或特权角色。</li>
<li>“<a href="https://learn.microsoft.com/zh-cn/entra/identity/conditional-access/concept-conditional-access-cloud-apps">目标资源</a>”设置为“所有资源”。</li>
<li>“<a href="https://learn.microsoft.com/zh-cn/entra/identity/conditional-access/concept-conditional-access-conditions#client-apps">条件 &gt; 客户端应用</a>”设置为“否”（“未配置”）。或者，此项设置为“是”，并勾选以下四个选项：“浏览器”、“移动应用和桌面客户端”、“Exchange ActiveSync 客户端”和“其他客户端”。</li>
<li>“<a href="https://learn.microsoft.com/zh-cn/entra/identity/conditional-access/concept-conditional-access-grant">授予</a>”设置为“需要进行多因素身份验证”或设置为“要求身份验证强度”，并选择以下选项之一：“多因素身份验证”、“无密码 MFA”或“防网络钓鱼 MFA”。</li>
<li>最后，将“启用策略”设置为“开启”（而非“关闭”或“仅报告”）。</li>
</ul>
</li>
<li><a href="https://learn.microsoft.com/zh-cn/entra/identity/authentication/howto-mfa-userstates">每用户 MFA</a>：每用户 MFA 是一项旧版服务，<a href="https://learn.microsoft.com/zh-cn/entra/identity/monitoring-health/recommendation-turn-off-per-user-mfa">Microsoft 建议</a>使用较新的安全默认值或条件访问策略进行替换。因此，由于 Microsoft Graph API 缺乏支持，此风险暴露指标无法确定具有特权角色的用户是否正在使用并强制执行旧版每用户 MFA。
</li>
</ul>
安全默认设置和条件访问是互斥的，您不能同时使用它们。请注意，<a href="https://learn.microsoft.com/zh-cn/entra/identity/conditional-access/concept-conditional-access-users-groups#include-users">条件访问策略只能以内置 Entra 角色为目标</a>，不包括管理单位范围的角色和自定义角色。

帐户操纵

暴力破解：密码猜测

暴力破解：密码喷洒

暴力破解：凭据填充

修改身份验证流程：多因素身份验证

特权角色未要求进行 MFA

MFA 为帐户提供强大保护，防止出现弱密码或泄露密码。根据安全最佳实践和标准，我们建议您启用 MFA，即使针对非特权帐户。没有注册 MFA 方法的帐户无法从中获益。

注意：此 IoE 依赖 Microsoft Entra ID P1 或 P2 许可来访问必要的数据。如果您的租户没有所需的许可证（例如 Entra ID 免费版），此 IoE 将不会返回发现结果。
多重身份验证 (MFA)，即之前的双因素身份验证 (2FA) 可为帐户提供强大的保护，防止出现弱密码或泄露密码​。根据安全最佳实践和标准，我们建议您启用 MFA，即使针对非特权帐户。
攻击者通过任意方法获得用户密码后，MFA 会通过要求额外的因素（例如来自移动应用程序且有时效的代码、物理令牌、生物识别功能等）来阻止身份验证。
在帐户没有已注册的 MFA 方法，或者您在没有注册 MFA 方法的情况下强制执行 MFA （上述两种情况可能会允许具有密码的攻击者注册他们自己的 MFA 方法并造成安全风险）时，此风险暴露指标会向您发出警报。然而，此风险暴露指标无法报告 Microsoft Entra ID 是否强制执行 MFA，因为条件访问策略可能根据动态标准要求执行 MFA。
您也可以使用 Entra ID 中的“<a href="https://learn.microsoft.com/zh-cn/entra/identity/authentication/howto-authentication-methods-activity">身份验证方法活动</a>”和“<a href="https://learn.microsoft.com/zh-cn/entra/identity/authentication/howto-mfa-reporting">MFA 报告</a>”功能。
有关特权帐户的内容，请参见相关的 IOE“特权帐户缺少 MFA”。
已禁用的用户将被忽略，因为攻击者无法立即滥用这些用户，并且 Microsoft Graph API 存在报告的已禁用用户的 MFA 状态不正确这一限制。

非特权帐户缺少 MFA

Microsoft 针对 Active Directory 同步设计了两个隐藏的内置 Entra ID 角色，专门用于 Entra Connect 或 Cloud Sync 服务帐户。这些角色具有隐式特权，恶意攻击者可借此发起隐蔽攻击。

您可以使用 <a href="https://learn.microsoft.com/zh-cn/entra/identity/hybrid/connect/whatis-azure-ad-connect">Microsoft Entra Connect</a>（之前称为 Azure AD Connect）或 <a href="https://learn.microsoft.com/zh-cn/entra/identity/hybrid/cloud-sync/what-is-cloud-sync">Microsoft Entra Cloud Sync</a>（之前称为 Azure AD Connect Cloud Sync）将 Microsoft Entra ID 与 Active Directory 同步。Microsoft 提供了两个专门为这些同步工具使用的服务帐户而设计的内置角色。
<ul>
<li>主要角色为**<a href="https://learn.microsoft.com/zh-cn/entra/identity/role-based-access-control/permissions-reference#directory-synchronization-accounts">目录同步帐户</a>**​（ID：<code>d29b2b05-8046-44ba-8758-1e26182fcf32</code>）。Tenable Research 博客文章详细介绍了滥用该功能的风险：<a href="https://medium.com/tenable-techblog/stealthy-persistence-with-directory-synchronization-accounts-role-in-entra-id-63e56ce5871b">使用 Entra ID 中的“目录同步帐户”角色实现隐蔽持久性</a>。</li>
<li><a href="https://learn.microsoft.com/zh-cn/entra/identity/role-based-access-control/permissions-reference#on-premises-directory-sync-account">本地目录同步帐户</a>​（ID：<code>a92aed5d-d78a-4d16-b381-09adb37eb3b0</code>）是 Tenable 于 2024 年 7 月首次确定的新角色。此角色与“目录同步帐户”角色具有相似的描述和相同的权限。然而，<a href="https://www.tenable.com/blog/despite-recent-security-hardening-entra-id-synchronization-feature-remains-open-for-abuse#:~:text=What%20about%20the%20new%20On%20Premises%20Directory%20Sync%20Account%20Entra%20role%3F">Tenable Research 发现</a>，Microsoft Entra Connect 或 Entra Cloud Sync 未使用此角色，并且目前没有已知的合法使用情况，这引发了对其用途和可能遭到滥用的担忧。</li>
</ul>
攻击者可以通过将这些角色分配给受其控制的安全主体（如用户、服务主体或组）来加以利用，从而实现特权提升或长期驻留。这些角色特别具有吸引力，原因如下：
<ul>
<li>他们仍然拥有特权。尽管在 2024 年 8 月的安全加固更新过程中，Microsoft 删除了这些角色的多个敏感 Entra ID 权限，但 <a href="https://www.tenable.com/blog/despite-recent-security-hardening-entra-id-synchronization-feature-remains-open-for-abuse#:~:text=Directory%20Synchronization%20Accounts%20Entra%20role%20remains%20privileged">Tenable Research 发现</a>，他们仍然保留通过特定 API 进行访问的隐式权限。因此，这些角色会继续提供强大的访问权限。</li>
<li>他们的运作方式具有隐蔽性。由于管理员很少手动分配这些角色，因此这些角色在 Azure 和 Entra 门户中都已被隐藏。他们不会出现在 Entra 角色列表中，也不会出现在给定主体的“已分配的角色”部分下，这使他们非常适合隐蔽使用。</li>
<li>一个角色未记录在案。Microsoft 尚未记录“本地目录同步帐户”角色，这进一步增加了滥用行为未被检测到的风险。</li>
</ul>
此风险暴露指标使用以下逻辑来检测分配给这些角色的可疑安全主体：
<ul>
<li>对于“目录同步帐户”角色：检测依赖多种启发式算法来识别与 Microsoft Entra Connect 或 Microsoft Entra Cloud Sync 使用的典型服务帐户不符的分配对象。</li>
<li>对于“本地目录同步帐户”角色：任何分配都会被标记为可疑，无论条件如何，因为此角色没有已知的合法用途。</li>
</ul>

持久性

发现

权限组发现：云端组

可疑的 AD 同步角色分配

恶意联合域配置是一种常见威胁，攻击者将其用作进入 Entra ID 租户的身份验证后门程序。验证现有和新添加的联合域对于确保其配置可靠且合法至关重要。此风险暴露指标提供了联合域及其相关属性的完整列表，有助于您对其安全状态做出明智决定。

Microsoft Entra 租户可以<a href="https://learn.microsoft.com/zh-cn/entra/identity/hybrid/connect/whatis-fed">与外部域联合</a>，以便与另一个域建立信任，从而进行身份验证和授权。组织使用联合功能，将 Active Directory 用户的身份验证委派到本地 Active Directory Federation Services (AD FS)。（请注意：外部域不是 Active Directory“域”。）
然而，如果恶意攻击者在 Microsoft Entra ID 中获得了更高的特权，他们可以添加自己的联合域或编辑现有的联合域来添加包含自己设置的辅助配置，从而滥用这种联合机制来创建后门程序​。
联合域上设置的后门程序依赖于专门伪造的令牌签名证书，该证书被插入到配置中，可以通过主要或<a href="https://medium.com/tenable-techblog/stealthy-persistence-privesc-in-entra-id-by-using-the-federated-auth-secondary-token-signing-cert-876b21261106">次要令牌签名证书</a>进行设置。使用常见的开源攻击者工具（如 <a href="https://github.com/Gerenios/AADInternals">AADInternals</a> 和 <a href="https://aadinternals.com/aadinternals/#convertto-aadintbackdoor-a">ConvertTo-AADIntBackdoor cmdlet</a>）时，有一些迹象表明可能存在可疑活动。
与“已知的联合域后门程序”风险暴露指标 (IoE) 不同，此 IoE 并不一定意味着存在由攻击者创建的后门程序。相反，它会提供 Entra ID 租户中所有联合域的完整列表，使您能够验证每个域的颁发者 URI 是否与您配置的外部身份提供程序 (IdP) 匹配。通常情况下，这将是您的本地 AD FS 服务器。颁发者 URI 表示受信任的联合服务器的 URL。
正如 <a href="https://learn.microsoft.com/zh-cn/entra/identity/hybrid/connect/how-to-connect-fed-single-adfs-multitenant-federation">Microsoft 所述</a>，联合到 AD FS 的域的默认颁发者设置为 <code>http://&lt;ADFSServiceFQDN&gt;/adfs/services/trust</code>。但是，如果您使用不同的联合身份提供程序，此值会有所不同。
<code>microsoft.directory/domains/allProperties/allTasks</code> 和 <code>microsoft.directory/domains/federation/update</code> 权限可授予管理员修改联合域的能力。截至 2023 年 11 月，包括潜在的自定义角色在内，以下内置 Microsoft Entra 角色具有此权限：
<ul>
<li><a href="https://learn.microsoft.com/zh-cn/entra/identity/role-based-access-control/permissions-reference#domain-name-administrator">域名管理员</a></li>
<li><a href="https://learn.microsoft.com/zh-cn/entra/identity/role-based-access-control/permissions-reference#external-identity-provider-administrator">外部身份提供程序管理员</a></li>
<li><a href="https://learn.microsoft.com/zh-cn/entra/identity/role-based-access-control/permissions-reference#hybrid-identity-administrator">混合身份管理员</a></li>
<li><a href="https://learn.microsoft.com/zh-cn/entra/identity/role-based-access-control/permissions-reference#global-administrator">全局管理员</a></li>
<li><a href="https://learn.microsoft.com/zh-cn/entra/identity/role-based-access-control/permissions-reference#partner-tier2-support">合作伙伴 Tier2 支持</a></li>
<li><a href="https://learn.microsoft.com/zh-cn/entra/identity/role-based-access-control/permissions-reference#security-administrator">安全管理员</a></li>
</ul>

域或租户策略修改：信任关系修改

联合域列表

存储在 Entra ID 中的 Microsoft 365 组可以是公共组，也可以是私有组。公共组会带来安全风险，因为租户中的任何用户都可以加入这些组并访问其数据（Teams 聊天/文件、电子邮件等）。

Microsoft 365 组是多种 Office 365 应用程序，尤其是在 Microsoft Teams 中，每个团队都对应一个关联的 M365 组。您可以创建这些组，随后使用<a href="https://support.microsoft.com/zh-cn/office/learn-about-microsoft-365-groups-b565caa1-5c40-40ef-9915-60fdb2d97fa2">私有或公共隐私</a>设置进行配置，具体操作如下：
<blockquote>
在创建组时，您需要决定是要将其设置为私有组还是公共组​。组织中的任何人都可以查看公共组中的内容，并且组织中的任何人都可以加入该组。私有组中的内容仅限组成员查看，想要加入私有组的人必须获得组所有者的批准。
</blockquote>
公共组在提供方便的同时也会带来风险，因为组织租户中的任何用户（包括来宾用户）都可以自由加入这些组，并访问其中的数据。例如：
<ul>
<li>Teams：对话和共享文件（实际<a href="https://learn.microsoft.com/zh-cn/sharepoint/teams-connected-sites">存储在 SharePoint 站点中</a>）</li>
<li>OneDrive：<a href="https://support.microsoft.com/zh-cn/office/create-a-new-shared-library-from-onedrive-for-work-or-school-345c8599-05d8-4bf8-9355-2b5cfabe04d0">共享库</a></li>
<li>Exchange Online：<a href="https://support.microsoft.com/zh-cn/office/create-a-group-in-outlook-04d0c9cf-6864-423c-a380-4fa858f27102">Outlook 组邮箱</a></li>
<li>OneNote：共享笔记</li>
<li>Microsoft Planner 和 Microsoft To Do 任务</li>
<li>Azure 云资源（因为 M365 组可以获得 Azure 角色分配）</li>
<li><a href="https://learn.microsoft.com/zh-cn/microsoft-365/admin/create-groups/office-365-groups">等</a></li>
</ul>
恶意用户或好奇心强的用户无需使用任何黑客工具就能轻易发现这些公共组。例如，用户可以通过 Teams 中的“<a href="https://support.microsoft.com/zh-cn/office/find-and-join-a-team-in-microsoft-teams-9f284981-39a1-486d-b43d-ab2dcc4c1e0f">创建和加入团队及频道</a>”功能、<a href="https://support.microsoft.com/zh-cn/office/join-a-group-in-outlook-2e59e19c-b872-44c8-ae84-0acc4b79c45d">Outlook 中的相关功能</a>，或“<a href="https://myaccount.microsoft.com/groups">我的应用组访问面板</a>”等更多方式找到这些公共组。
在 Microsoft 365 中，最终用户通常可以通过诸如 Teams（最常用）、Outlook 或 SharePoint 等应用程序自行创建组，并决定其是公共还是私有组，而不必像创建安全组那样依赖 IT 管理员。因此，最终用户通常会选择公共隐私设置，而没有充分意识到这将允许组织内 Entra 租户的任何人在无需组所有者批准的情况下加入该组，从而获得组内所有内容的访问权限。
<a href="https://learn.microsoft.com/zh-cn/microsoft-365/admin/create-groups/compare-groups?#microsoft-365-groups">Microsoft 365 组</a>，即所谓的“统一组”（之前称为“Office 365 组”），是存储在 Entra ID 中的一种<a href="https://learn.microsoft.com/zh-cn/microsoft-365/admin/create-groups/compare-groups">组类型</a>。此风险暴露指标特别关注这些 Microsoft 365 组，而不是更为人所知的 <a href="https://learn.microsoft.com/zh-cn/microsoft-365/admin/create-groups/compare-groups?#security-groups">Microsoft Entra 安全组</a>，后者并不具备相同的公共/私有隐私选项。
限制：此风险暴露指标 (IoE) 无法自动判断公共 M365 组是否合法。
注意：私有组也可能无意中暴露敏感信息，因为默认情况下，其名称、描述和成员列表对组织租户内的任何人都可见。仅这些元数据就可能足以推断出机密详情，例如，如果潜在获取目标包含在组名称中，就可以推测出获取的目标。为缓解这一风险，Microsoft 提供了从目录列表中隐藏私有组和隐藏其成员列表的选项。但这些设置默认情况下已禁用，这意味着组织必须主动启用这些设置，以确保私有组的元数据保持机密。

合集

云存储中的数据

公共 M365 组

临时访问通行证 (TAP) 功能是一种临时的身份验证方法，使用有时限或限制使用的通行码。虽然这是合法功能，但如果您的组织不需要，禁用此功能以减少攻击面会更安全。

<a href="https://learn.microsoft.com/zh-cn/entra/identity/authentication/howto-authentication-temporary-access-pass">临时访问通行证 (TAP)</a> 是一种临时的身份验证方法，提供标准 Microsoft Entra 身份验证方法（例如密码和 MFA）的替代方案。TAP 专门用于员工入职、密码丢失和帮助台重置等场景，或作为实施其他身份验证方法（如<a href="https://learn.microsoft.com/zh-cn/entra/identity/authentication/howto-authentication-passwordless-deployment">无密码身份验证</a>，包括 Microsoft Authenticator、Windows Hello for Business 或 FIDO2 安全密钥）的引导手段，并引入了有时限或单次使用的通行码。用户可以在 TAP 的有效期内使用此通行码，具体取决于所配置的 TAP 策略，您可以在“身份验证方法”控制台（通过 Azure 门户或 Microsoft Entra 管理中心访问）中设置该策略。此策略可以广泛应用于所有用户，也可以选择性地应用于特定组。激活策略后，具有所需权限的特权用户可以在“身份验证方法”控制台中生成一个 TAP。主要注意事项包括：
<ul>
<li>TAP 会绕过 MFA​，因为前者被视为一种强身份验证方法。</li>
<li>如果具有更高特权的恶意攻击者利用 TAP，则可能带来潜在的安全风险。在这种情况下，攻击者可以在不知道密码且无需重置密码的情况下访问帐户​，这使得攻击更加隐蔽。请注意，TAP 不会替换用户的密码​。因此，尽管设置了后门程序 TAP，目标用户仍然可以使用他们的常规密码或其他身份验证方法登录。</li>
</ul>
如果您的组织使用 TAP，请确保其仅用于新员工入职或新设备的初始配置。因此，通过 TAP 进行的登录应该仅偶尔发生，并且在严密监督下进行。
该合法功能可能是有意启用的，并且目前在租户中处于活动状态。在这种情况下，您可以在选项中将该租户添加为例外，同时请注意扩大的攻击面。相反，如果未使用该功能，建议将其禁用，以减少潜在的攻击面。

冒充

已启用临时访问通行证功能

您必须确认 Entra ID 中所有自定义域的所有权。仅暂时保留未经验证的域 - 您应该验证或移除此类域，以保持域列表的整洁，并促进高效的审核。

Microsoft Entra 租户可以<a href="https://learn.microsoft.com/zh-cn/entra/identity/hybrid/connect/whatis-fed">与外部域联合</a>，以便与另一个域建立信任，从而进行身份验证和授权。
然而，如果恶意攻击者在 Microsoft Entra ID 中获得了更高的特权，他们可以通过添加自己的联合域或编辑现有的联合域来添加包含自己设置的辅助配置，从而滥用这种联合机制来创建后门程序​。
最好避免在 Entra ID 中长时间配置未验证的自定义域。
在 Microsoft 于 2020 年春季修复此问题之前，攻击者甚至可能使用未经验证的新域创建联合域后门程序。这可通过开源攻击工具 <a href="https://github.com/Gerenios/AADInternals">AADInternals</a> 中的 <a href="https://aadinternals.com/aadinternals/#new-aadintbackdoor-a">New-AADIntBackdoor cmdlet</a> 来实现。
此风险暴露指标列出了您 Entra ID 环境中所有未经验证的自定义域​，以便您验证其合法性。

未经验证的域

第一方服务主体拥有强大的权限，然而因为他们处于隐藏状态、数量众多，而且为 Microsoft 所有，所以会被忽略。攻击者会向这些主体添加凭据，以隐蔽的方式利用主体的特权来提升特权和获得持久性特权，从而获益。

第一方服务主体（企业应用程序）来自 Microsoft 的应用程序（应用程序注册）。他们中的大多数在 Microsoft Entra ID 中拥有一些在安全检查过程中经常被忽略的敏感权限。攻击者可以借此向这些主体添加凭据，以隐蔽的方式利用主体的特权获益。​
因为拥有应用程序管理员角色的主体可以将凭据添加至应用程序（包括拥有更高特权的应用程序），所以这项技术提供持久性​能力和特权提升​。
除极少数情况（参阅“建议”）外，第一方服务主体不应该拥有任何凭据。Microsoft 在“<a href="https://learn.microsoft.com/zh-cn/entra/fundamentals/configure-security#microsoft-services-applications-dont-have-credentials-configured">配置 Microsoft Entra 以提高安全性</a>”一文中还建议“Microsoft 服务应用程序不应配置凭据”。
APT29 威胁组织在 2020 年 12 月滥用这种方法对 SolarWinds 发起了臭名昭著的“Solorigate”攻击，<a href="https://www.microsoft.com/zh-cn/security/blog/2020/12/28/using-microsoft-365-defender-to-coordinate-protection-against-solorigate/">Microsoft</a> 和 <a href="https://services.google.com/fh/files/misc/remediation-and-hardening-strategies-for-microsoft-wp-en.pdf#page=28">Mandiant</a> 对此均有记录。
已禁用的服务主体默认（此参数可以更改）被忽略，因为攻击者无法立即使用这些服务主体。

检测

风险暴露指标

MEDIUM

MEDIUM

HIGH

CRITICAL

HIGH

MEDIUM

HIGH

LOW

MEDIUM

LOW

LOW

HIGH