在 Entra ID 中擁有特權角色的混合帳戶 (即從 Active Directory 同步) 會帶來安全性風險，因為入侵 AD 的攻擊者可利用此類帳戶轉而入侵 Entra ID。Entra ID 中的特權帳戶必須為僅限雲端帳戶。

如果貴公司已設定<a href="https://learn.microsoft.com/en-us/entra/identity/hybrid/what-is-inter-directory-provisioning">目錄同步</a>選項，例如與「<a href="https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/whatis-azure-ad-connect">Microsoft Entra Connect</a>」(前稱「Azure AD Connect」) 或「<a href="https://learn.microsoft.com/en-us/entra/identity/hybrid/cloud-sync/what-is-cloud-sync">Microsoft Entra Cloud Sync</a>」(前稱「Azure AD Connect Cloud Sync」) 同步目錄，以將使用者 (及其他內容 ) 從內部部署 Active Directory 同步至雲端 Entra ID，建議您為 Entra ID 中的特權角色使用混合 AD 帳戶。然而，這樣做會讓攻擊者有機會在入侵 Active Directory 後擴展對 Entra ID 的惡意控制​。他們會運用多項技術假冒任何 AD 使用者，也會將這種假冒方式套用至 Entra ID。
為此，Microsoft 在「<a href="https://learn.microsoft.com/en-us/entra/architecture/protect-m365-from-on-premises-attacks">保護 Microsoft 365 不受內部部署攻擊</a>」文章中對此做法提出警告，認為「Microsoft 365 中不應存在任何具有管理權限的內部部署帳戶」，同時 Microsoft 還建議您確保「任何內部部署帳戶均未擁有 Microsoft 365 進階權限」。

Modify Authentication Process: Hybrid Identity

[MITRE ATT&CK®] T1556.007 (Modify Authentication Process: Hybrid Identity)

與 AD (混合帳戶) 同步的特權 Entra 帳戶

Protecting Microsoft 365 from on-premises attacks

第一方服務主體擁有強大權限，然而因為他們處於隱藏狀態、數量眾多，且為 Microsoft 所有，因而會被忽略。攻擊者會將憑證新增至主體，以隱蔽地利用主體特權來提升權限和進行長期潛伏。

第一方服務主體 (企業應用程式) 來自屬於 Microsoft 的應用程式 (應用程式註冊)。它們大多數在 Microsoft Entra ID 中擁有在安全性檢查中經常被忽略的機密權限。攻擊者可藉此將憑證新增至這些主體，以隱蔽地利用主體特權。​
因為擁有應用程式管理員角色的主體可以將憑證新增至應用程式 (包括擁有更高特權的應用程式)，所以這項技術使攻擊者能夠長期潛伏​和提升權限​。
除極少數情況外 (請參閱「建議」)，第一方服務主體不應擁有任何憑證。
APT29 威脅集團曾在 2020 年 12 月濫用此方法對 SolarWinds 發動惡名昭彰的「Solorigate」攻擊，<a href="https://www.microsoft.com/en-us/security/blog/2020/12/28/using-microsoft-365-defender-to-coordinate-protection-against-solorigate/">Microsoft</a> 和 <a href="https://www.mandiant.com/sites/default/files/2021-11/wp-m-unc2452-000343.pdf#page=29">Mandiant</a> 均有相關記錄。

Azure AD privilege escalation - Taking over default application permissions as Application Admin

Account Manipulation: Additional Cloud Credentials

[MITRE ATT&CK®] T1098.001 (Account Manipulation: Additional Cloud Credentials)

擁有憑證的第一方服務主體

Microsoft Entra ID 可透過同盟的方式，將驗證工作委派給其他提供者。但是，獲得較高權限的攻擊者可以新增惡意同盟網域來利用此功能，進而達到潛伏和權限提升的目的。

Microsoft Entra 租用戶可以<a href="https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/whatis-fed">與外部網域同盟</a>，以便與另一個網域建立信任來進行驗證和授權。組織使用同盟功能將 Active Directory 使用者驗證委派至他們的內部部署 Active Directory Federation Services (AD FS)(註: 外部網域不是 Active Directory「網域」)。
不過，如果惡意攻擊執行者在 Microsoft Entra ID 中獲得較高權限，就能新增同盟網域或編輯現有同盟網域，以新增次要設定與自己的設定，進而不當利用這種同盟機制並建立後門程式​。藉由發起此攻擊，攻擊者可以: 
<ul>
<li>假冒​: 惡意同盟網域可產生權杖，讓攻擊者無需知道密碼或重設密碼，就能透過任何 Microsoft Entra 使用者的身分來進行驗證。這包括「僅限雲端」使用者 (非混合使用者) 和外部使用者。即便您已強制使用 MFA (請見下文)，這仍允許對 Microsoft Entra ID、Microsoft 365 (O365)，以及其他依賴 Microsoft Entra ID 作為身分識別提供者 (SSO) 的應用程式發動攻擊。</li>
<li>權限提升​: 攻擊者可以假冒任何使用者，尤其是特權 Microsoft Entra ID 使用者。</li>
<li>多因素驗證繞過​: 有了同盟驗證，受信任的外部網域可以<a href="https://learn.microsoft.com/en-us/graph/api/resources/internaldomainfederation?view=graph-rest-beta#federatedidpmfabehavior-values">擔任強制執行 MFA 的角色</a>。惡意同盟網域可以謊稱偽造的驗證使用了受 Microsoft Entra ID 信任的 MFA，並且 Microsoft Entra ID 不會再次提示使用 MFA。即便在有 MFA 保護的情況下，攻擊者也可藉此假冒所有使用者。</li>
<li>長期潛伏​: 新增惡意同盟網域是一種隱蔽技術，允許入侵 Microsoft Entra 租用戶並佔有高等權限的攻擊者之後重新取得存取權。</li>
</ul>
本曝險指標根據 <a href="https://aadinternals.com/">AADInternals</a> 駭客工具組建立或轉換的後門程式網域的特定特徵，偵測所建立的同盟網域後門程式​，尤其是 <code>ConvertTo-AADIntBackdoor</code> 和 <code>New-AADIntBackdoor</code> 指令程式。
另外，也會參照相關的「同盟簽署憑證不相符」曝險指標。
將驗證證明從惡意同盟網域傳輸至目標 Microsoft Entra ID 時，所用的同盟通訊協定可能是 WS-Federation 或 SAML。使用 SAML 時，這種攻擊與「<a href="https://www.mandiant.com/sites/default/files/2021-11/wp-m-unc2452-000343.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/en-us/entra/identity/role-based-access-control/permissions-reference#domain-name-administrator">網域名稱管理員</a>」</li>
<li>「<a href="https://learn.microsoft.com/en-us/entra/identity/role-based-access-control/permissions-reference#external-identity-provider-administrator">外部身分識別提供者管理員</a>」</li>
<li>「<a href="https://learn.microsoft.com/en-us/entra/identity/role-based-access-control/permissions-reference#hybrid-identity-administrator">混合身分管理員</a>」</li>
<li>「<a href="https://learn.microsoft.com/en-us/entra/identity/role-based-access-control/permissions-reference#global-administrator">全域管理員</a>」</li>
<li>「<a href="https://learn.microsoft.com/en-us/entra/identity/role-based-access-control/permissions-reference#partner-tier2-support">合作夥伴第 2 層支援</a>」</li>
<li>「<a href="https://learn.microsoft.com/en-us/entra/identity/role-based-access-control/permissions-reference#security-administrator">安全管理員</a>」</li>
</ul>
APT29 威脅組織在 2020 年 12 月不當利用此方法，對 SolarWinds 發動惡名昭彰的「Solorigate」攻擊，<a href="https://www.microsoft.com/en-us/security/blog/2020/12/28/using-microsoft-365-defender-to-coordinate-protection-against-solorigate/">Microsoft</a> 和 <a href="https://www.mandiant.com/sites/default/files/2021-11/wp-m-unc2452-000343.pdf#page=23">Mandiant</a> 均有相關記錄。

Modify Trusted Domains [Mandiant]

Security vulnerability in Azure AD & Office 365 identity federation

How to create a backdoor to Azure AD - part 1: Identity federation

Deep-dive to Azure Active Directory Identity Federation

Domain Policy Modification: Domain Trust Modification

Forge Web Credentials: SAML Tokens

[MITRE ATT&CK®] T1484.002 (Domain Policy Modification: Domain Trust Modification)

[MITRE ATT&CK®] T1606.002 (Forge Web Credentials: SAML Tokens)

已知的同盟網域後門程式

MFA 為帳戶提供強大保護，防止出現弱式密碼或易遭洩漏的密碼。建議的安全性最佳做法和標準是啟用 MFA，即使是非特權帳戶亦是如此。未註冊 MFA 方法的帳戶無法受到此機制保護。

多因素驗證 (MFA) 或之前的雙因素驗證 (2FA) 可為帳戶提供強大保護，防止出現弱式密碼或易遭洩漏的密碼​。建議的安全性最佳做法和標準是啟用 MFA，即使是非特權帳戶亦是如此。
攻擊者透過任意方式取得使用者密碼後，MFA 會透過要求額外因素 (例如具有時效性的行動應用程式代碼、實體權杖、生物特徵等) 來阻止驗證。
如果帳戶未註冊 MFA 方法，或者您未註冊 MFA 方法而強制執行 MFA，本曝險指標會向您發出警示。上述兩種情況都可能會使擁有密碼的攻擊者註冊自己的 MFA 方法，而造成安全性風險。然而，本曝險指標無法報告 Microsoft Entra ID 是否強制執行 MFA，因為視動態標準而定，條件存取原則可能需要 MFA。
您也可以使用 Entra ID 中的「<a href="https://learn.microsoft.com/en-us/entra/identity/authentication/howto-authentication-methods-activity">驗證方法活動</a>」和「<a href="https://learn.microsoft.com/en-us/entra/identity/authentication/howto-mfa-reporting">MFA 報告</a>」功能。
有關特權帳戶的資訊，另請參閱相關的「特權帳戶缺少 MFA」IOE。

Account Manipulation

Brute Force

Modify Authentication Process: Multi-Factor Authentication

Valid Accounts: Cloud Accounts

[MITRE ATT&CK®] T1098 (Account Manipulation)

[MITRE ATT&CK®] T1110 (Brute Force)

[MITRE ATT&CK®] T1556.006 (Modify Authentication Process: Multi-Factor Authentication)

[MITRE ATT&CK®] T1078.004 (Valid Accounts: Cloud Accounts)

非特權帳戶缺少 MFA

Microsoft 在 Entra ID 中公開 API，以允許第三方應用程式在 Microsoft 服務中執行動作。特定權限可能會對整個 Microsoft Entra 租用戶帶來嚴重威脅。因此，必須仔細審查這些權限的指派情況。

Microsoft 透過 Entra ID 中的應用程式公開 API，以允許第三方應用程式在 Microsoft Entra ID 本身、Microsoft 365 (O365)、Azure 雲端等產品中執行動作。「API 權限」會保護這些 API 的存取權，只有需要這些 API 的服務主體才能擁有權限。此權限核准程序叫做「應用程式角色指派」或「同意授予」。
若服務主體擁有某些 Microsoft API 的特定權限 (請見下文)，可能會對整個 Microsoft Entra 租用戶帶來嚴重威脅​，因為服務主體會擁有強大的權限，卻同時比高權限管理員角色 (例如全域管理員) 不顯眼。攻擊者可濫用這一點繞過多因素驗證 (MFA) 並阻止使用者重設密碼。
在正當的情況下，權限會增加租用戶的攻擊破綻。在不正當的情況下，可能是提升權限或長期潛伏等惡意嘗試。
如 Microsoft 說明文件<a href="https://learn.microsoft.com/en-us/entra/identity-platform/permissions-consent-overview">權限和同意簡介</a>所述，Microsoft Entra ID 有兩種類型的 API 權限:
<ul>
<li>應用程式權限: 由管理員同意，權限適用於所有租用戶。</li>
<li>委派權限: 由使用者或代表整個組織的管理員同意。請注意，這些權限會根據登入使用者的特權 (即權限和使用者特權等級的交集) 限制應用程式執行動作的能力。因此，正如<a href="https://learn.microsoft.com/en-us/security/zero-trust/develop/developer-strategy-delegated-permission">制定委派權限策略</a> 中所述，這些委派權限的危險性取決於應用程式使用者的實際權限。例如: 如果普通使用者委派了「Group.ReadWrite.All」權限，實際上會允許應用程式只修改使用者可以編輯的群組，而不是所有群組。</li>
</ul>
本曝險指標會檢查這兩種類型的權限，並只會報告有關服務主體的內容，因為 API 權限僅適用於服務主體而非使用者。
本曝險指標也會著重於允許存取 <a href="https://learn.microsoft.com/en-us/graph/overview">Microsoft Graph API</a> 和舊型 <a href="https://learn.microsoft.com/en-us/graph/migrate-azure-ad-graph-overview">Azure AD Graph API</a> 的權限。具體而言，下列危險權限會帶來安全性風險:
<ul>
<li><code>RoleManagement.ReadWrite.Directory</code>: 允許攻擊者將自己升級為全域管理員角色</li>
<li><code>AppRoleAssignment.ReadWrite.All</code>: 允許攻擊者授予自己 <code>RoleManagement.ReadWrite.Directory</code> 權限 (請見上文)。</li>
</ul>
擁有這些危險權限的正當應用程式要求可能過於廣泛的權限。這也可能表示出現一種叫做「非法同意授予」的網路釣魚攻擊，在這種攻擊中，攻擊者會成功取得管理員同意。

偵測

曝險指標 (IoE)

High

High

Critical

Medium

High