待啟用的特權使用者帳戶很容易受到入侵，因為這些帳戶通常能避開防禦措施的偵測。此外，這類帳戶可能使用預設密碼，也使它們成為攻擊者的首要目標。

注意: 此曝險指標 (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>指出：
攻擊者也鎖定了屬於受害組織已離職員工、但仍存在於系統中的休眠帳戶，</li>
</ul>
而且
在資安事端期間強制要求所有使用者重設密碼後，也發現有 SVR 攻擊者登入非作用中帳戶，並按照說明重設密碼，導致採取資安事端回應的驅逐入侵者措施後，攻擊者能夠重新取得存取權。
<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-tw/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-tw/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-tw/entra/identity/authentication/concept-password-ban-bad#license-requirements">存取必要資料</a>。如果您的租用戶沒有必要授權 (例如 Entra ID 免費版)，此曝險指標 (IoE) 不會傳回研究發現結果。
Entra ID 會利用 <a href="https://learn.microsoft.com/zh-tw/entra/identity/authentication/concept-password-ban-bad">Microsoft Entra 密碼保護功能</a> 降低因為使用者設定簡單好猜的密碼，導致容易遭受暴力密碼破解攻擊的風險。此功能使用全域禁止密碼清單，<a href="https://learn.microsoft.com/zh-tw/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 密碼保護是雲端式功能，但組織也可以將其沿用至傳統型內部部署 Active Directory (也稱為「Windows Server Active Directory」)，如「<a href="https://learn.microsoft.com/zh-tw/entra/identity/authentication/concept-password-ban-bad-on-premises">對 Active Directory Domain Services 啟用 Microsoft Entra 密碼保護的內部部署強制機制</a>」一文中所述。他們會在內部部署 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 網域控制器上的實際部署狀態。因此會有漏報的可能，即 Entra 中的設定顯示為符合規範，但代理程式並未在所有 Active Directory 網域控制器中完成部署或正常運作。</li>
</ol>

網路釣魚

內部部署環境未啟用密碼保護

訪客帳戶是外部身分，一旦獲派特權角色就可能造成安全風險。這會將租用戶的重大特權授予組織外部人員。

<a href="https://learn.microsoft.com/zh-tw/entra/external-id/what-is-b2b">B2B collaboration</a> 是 Microsoft Entra ID 的一項功能，可供您的使用者邀請訪客與貴組織協作。根據預設，這些訪客帳戶 (也稱為「外部身分」) 會取得 <a href="https://learn.microsoft.com/zh-tw/entra/fundamentals/users-default-permissions#member-and-guest-users">Microsoft 所述的存取權</a>:
<blockquote>
他們可以管理自己的設定檔、變更自己的密碼，以及擷取有關其他使用者、群組和應用程式的特定資訊。但是，他們無法讀取所有目錄資訊。
例如，訪客使用者無法列舉所有使用者、群組和其他目錄物件的清單。您可以指派管理員角色給訪客，授予他們完整的讀取和寫入權限。訪客也可以邀請其他訪客。
</blockquote>
從定義上來看，特權角色本身就擁有較高的特權。一旦訪客帳戶獲派特權角色，就會造成安全風險，並顯著增加租用戶的攻擊破綻。另外由於訪客帳戶適用的安全性原則可能較脆弱，更容易受到入侵，因此這項問題需要特別注意。此外，向訪客使用者指派特權角色會導致其行為難以追蹤，進而增加監控和稽核的難度。最糟的情況是，此類指派可能反映出帳戶已受到入侵，因為威脅執行者經常利用訪客帳戶來竊取未授權的存取權，並在系統內部進行橫向滲透。
請仔細監控這些訪客帳戶，並避免向其指派特權角色。
Microsoft 在<a href="https://learn.microsoft.com/zh-tw/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-tw/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/zh-tw/graph/api/resources/internaldomainfederation?view=graph-rest-beta#federatedidpmfabehavior-values">擔任強制執行 MFA 的角色</a>。惡意同盟網域可以謊稱偽造的驗證使用了 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://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-tw/entra/identity/role-based-access-control/permissions-reference#domain-name-administrator">網域名稱管理員</a></li>
<li><a href="https://learn.microsoft.com/zh-tw/entra/identity/role-based-access-control/permissions-reference#external-identity-provider-administrator">外部身分識別提供者管理員</a></li>
<li><a href="https://learn.microsoft.com/zh-tw/entra/identity/role-based-access-control/permissions-reference#hybrid-identity-administrator">混合身分管理員</a></li>
<li><a href="https://learn.microsoft.com/zh-tw/entra/identity/role-based-access-control/permissions-reference#global-administrator">全域管理員</a></li>
<li><a href="https://learn.microsoft.com/zh-tw/entra/identity/role-based-access-control/permissions-reference#partner-tier2-support">合作夥伴第 2 層支援</a></li>
<li><a href="https://learn.microsoft.com/zh-tw/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-tw/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> 均有相關記錄。

規避防禦

修改網域原則: 修改網域信任

憑證存取

偽造網站憑證: SAML 權杖

修改驗證流程: 混合身分

已知的同盟網域後門程式

MFA 為帳戶提供強大保護，防止出現弱式密碼或易遭洩漏的密碼。建議的安全性最佳做法和標準是啟用 MFA，特別是具有特權角色的特權帳戶。

多因素驗證 (MFA) 前稱雙因素驗證 (2FA)，可為帳戶提供強大的保護力，防範脆弱密碼或密碼遭人破解等相關弱點。建議遵循<a href="https://learn.microsoft.com/zh-tw/entra/identity/conditional-access/howto-conditional-access-policy-admin-mfa">最佳做法</a>和產業標準啟用 MFA，尤其是針對特權帳戶，因為它們是攻擊者的主要目標，一旦遭到入侵，後果可能不堪設想。
攻擊者透過任意方式取得使用者密碼後，MFA 會透過要求額外因素 (例如具有時效性的行動應用程式代碼、實體權杖、生物特徵等) 來阻止驗證。
本曝險指標會在特權角色未啟用 MFA 時發出警示，進而影響擁有該特權角色的特權帳戶。
在 Entra ID 中，您可以透過多種方式啟用 MFA: 
<ul>
<li><a href="https://learn.microsoft.com/zh-tw/entra/fundamentals/security-defaults">安全性預設值</a>: 預先設定的安全性設定，包括<a href="https://learn.microsoft.com/zh-tw/entra/fundamentals/security-defaults#require-administrators-to-do-multifactor-authentication">對管理員強制啟用多因素驗證</a>。啟用此設定後，Microsoft 建議的多種安全功能也會同步啟用。
</li>
<li><a href="https://learn.microsoft.com/zh-tw/entra/identity/conditional-access/overview">條件式存取</a>：建立原則並明確規範必須使用 MFA 的事件或應用程式。這些原則可允許管理員正常使用 MFA 登入。請注意: 此功能需要 Microsoft Entra ID P1 授權或更高版本，Microsoft Entra ID 免費版無法使用。特別推薦給擁有複雜安全需求並致力於明確定義驗證準則的成熟型組織。此曝險指標會找出具有下列設定的條件式存取原則:
<ul>
<li>「<a href="https://learn.microsoft.com/zh-tw/entra/identity/conditional-access/concept-conditional-access-users-groups#include-users">使用者</a>」設定為包括「所有使用者」或特權角色。</li>
<li>「<a href="https://learn.microsoft.com/zh-tw/entra/identity/conditional-access/concept-conditional-access-cloud-apps">目標資源</a>」設定為「所有資源」。</li>
<li>「<a href="https://learn.microsoft.com/zh-tw/entra/identity/conditional-access/concept-conditional-access-conditions#client-apps">條件 &gt; 用戶端應用程式</a>」設定為「否」(「未設定」)。或者設定為「是」，並選取以下四個選項:「瀏覽器」、「行動應用程式和桌面用戶端」、「Exchange ActiveSync 用戶端」和「其他用戶端」。</li>
<li>將「<a href="https://learn.microsoft.com/zh-tw/entra/identity/conditional-access/concept-conditional-access-grant">授予</a>」設定為「需要多因素驗證」，或將「需要驗證強度」，設定為下列其中一項:「多因素驗證」、「無密碼 MFA」或「防網路釣魚 MFA」。</li>
<li>最後，將「啟用原則」設定為「開啟」(不是「關閉」或「僅限報告」)。</li>
</ul>
</li>
<li><a href="https://learn.microsoft.com/zh-tw/entra/identity/authentication/howto-mfa-userstates">個別使用者 MFA</a>: 個別使用者 MFA 為舊型服務，<a href="https://learn.microsoft.com/zh-tw/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-tw/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-tw/entra/identity/authentication/howto-authentication-methods-activity">驗證方法活動</a>」和「<a href="https://learn.microsoft.com/zh-tw/entra/identity/authentication/howto-mfa-reporting">MFA 報告</a>」功能。
有關特權帳戶的資訊，另請參閱相關的曝險指標 (IoE)「特權帳戶缺少 MFA」IOE。
系統會略過已停用的使用者，因為攻擊者無法立即對其進行濫用。此外，由於 Microsoft Graph API 的限制，該 API 針對已停用使用者報告的 MFA 狀態可能不正確。

非特權帳戶缺少 MFA

Microsoft 針對 Active Directory 同步處理設計了兩個隱藏的內建 Entra ID 角色，專門供 Entra Connect 或 Cloud Sync 服務帳戶使用。這些角色具有隱含的特權，可能會遭到惡意攻擊者利用，藉此在難以察覺的情況下發動攻擊。

您可以使用 <a href="https://learn.microsoft.com/zh-tw/entra/identity/hybrid/connect/whatis-azure-ad-connect">Microsoft Entra Connect</a> (前稱 Azure AD Connect) 或 <a href="https://learn.microsoft.com/zh-tw/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-tw/entra/identity/role-based-access-control/permissions-reference#directory-synchronization-accounts">目錄同步處理帳戶</a>**​ (ID: <code>d29b2b05-8046-44ba-8758-1e26182fcf32</code>)。在 Tenable Research 的「[Entra ID 中具有「目錄同步處理帳戶」角色的隱蔽潛伏]」(<a href="https://medium.com/tenable-techblog/stealthy-persistence-with-directory-synchronization-accounts-role-in-entra-id-63e56ce5871b">https://medium.com/tenable-techblog/stealthy-persistence-with-directory-synchronization-accounts-role-in-entra-id-63e56ce5871b</a>) 部落格文章中，已詳細說明該角色遭到濫用的可能性。</li>
<li><a href="https://learn.microsoft.com/zh-tw/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>有 1 個角色未記錄。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-tw/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">ConvertTo-AADIntBackdoor 指令程式</a> 的 <a href="https://aadinternals.com/aadinternals/#convertto-aadintbackdoor-a">AADInternals</a>) 時，可能會留下表明可疑事件發生的線索。
與「已知的同盟網域後門程式」曝險指標 (IoE) 不同，此曝險指標 (IoE) 未必代表系統中存在由攻擊者建立的後門程式。相反，它會提供 Entra ID 租用戶中所有同盟網域的完整清單，允許您驗證每個網域的核發者 URI 是否與您設定的外部身分識別提供者 (IdP) 相符。一般情況下，這會是您的內部部署 AD FS 伺服器。核發者 URI 表示受信任同盟伺服器的 URL。
正如 <a href="https://learn.microsoft.com/zh-tw/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-tw/entra/identity/role-based-access-control/permissions-reference#domain-name-administrator">網域名稱管理員</a></li>
<li><a href="https://learn.microsoft.com/zh-tw/entra/identity/role-based-access-control/permissions-reference#external-identity-provider-administrator">外部身分識別提供者管理員</a></li>
<li><a href="https://learn.microsoft.com/zh-tw/entra/identity/role-based-access-control/permissions-reference#hybrid-identity-administrator">混合身分管理員</a></li>
<li><a href="https://learn.microsoft.com/zh-tw/entra/identity/role-based-access-control/permissions-reference#global-administrator">全域管理員</a></li>
<li><a href="https://learn.microsoft.com/zh-tw/entra/identity/role-based-access-control/permissions-reference#partner-tier2-support">合作夥伴第 2 層支援</a></li>
<li><a href="https://learn.microsoft.com/zh-tw/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-tw/office/learn-about-microsoft-365-groups-b565caa1-5c40-40ef-9915-60fdb2d97fa2">私人或公開隱私權</a>設定，依照如下原則設定群組性質:
<blockquote>
建立群組時，需要決定是將其設為私人群組或公開群組​。貴組織中的任何人都可以查看公開群組的內容，也可以加入群組。私人群組的內容只有其成員能夠查看，而想要加入私人群組則必須獲得群組所有者的批准。
</blockquote>
公開群組雖然便利，但也會產生風險，因為組織租用戶中的任何使用者 (包括訪客使用者) 都可以自由加入這些群組並取得其資料的存取權。例如:
<ul>
<li>Teams: 對話與共用檔案 (實際上<a href="https://learn.microsoft.com/zh-tw/sharepoint/teams-connected-sites">儲存在 SharePoint 網站</a>中)</li>
<li>OneDrive: <a href="https://support.microsoft.com/zh-tw/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-tw/office/create-a-group-in-outlook-04d0c9cf-6864-423c-a380-4fa858f27102">Outlook 群組信箱</a></li>
<li>OneNote: 共用筆記</li>
<li>Microsoft Planner 和 Microsoft 待辦事項任務</li>
<li>Azure 雲端資源 (因為 M365 群組可能獲派 Azure 角色)</li>
<li><a href="https://learn.microsoft.com/zh-tw/microsoft-365/admin/create-groups/office-365-groups">等</a></li>
</ul>
懷有惡意或好奇心的使用者無需使用任何駭客工具即可輕鬆探索公開群組。例如，他們可以透過 Teams 和 <a href="https://support.microsoft.com/zh-tw/office/join-a-group-in-outlook-2e59e19c-b872-44c8-ae84-0acc4b79c45d">Outlook</a> 中的「<a href="https://support.microsoft.com/zh-tw/office/find-and-join-a-team-in-microsoft-teams-9f284981-39a1-486d-b43d-ab2dcc4c1e0f">建立並加入團隊與頻道</a>」或「<a href="https://myaccount.microsoft.com/groups">我的應用程式群組存取面板</a>」等功能找到公開群組。
在 Microsoft 365 中，終端使用者可以自行建立群組並選擇設定為公開或私人，而不是像安全性群組那樣依賴 IT 管理員來建立。這通常是在 Teams (最常見)、Outlook 或 SharePoint 等應用程式中進行。因此，終端使用者經常會在一知半解的情況下選取公開的隱私選項，不明白這會允許組織 Entra 租用戶中的所有人直接加入群組，不必經過群組所有者核准，進而取得所有群組內容的存取權。
前稱「Office 365 群組」的<a href="https://learn.microsoft.com/zh-tw/microsoft-365/admin/create-groups/compare-groups?#microsoft-365-groups"> Microsoft 365 群組</a>也稱為「統一群組」，是儲存在 Entra ID 中的<a href="https://learn.microsoft.com/zh-tw/microsoft-365/admin/create-groups/compare-groups">群組類型</a>之一。此曝險指標著重於這些 Microsoft 365 群組，而不是更常見的 <a href="https://learn.microsoft.com/zh-tw/microsoft-365/admin/create-groups/compare-groups?#security-groups">Microsoft Entra 安全性群組</a>，後者的公開/私人隱私選項有所不同。
限制: 此曝險指標 (IoE) 無法自動判斷公開 M365 群組是否正當。
請注意: 私人群組也可能會在無意間洩漏機密資訊，因為根據預設，組織租用戶中的任何人都可以查看私人群組的名稱、說明和成員清單。僅憑這些中繼資料可能就足以推斷機密的詳細資料，例如潛在擷取的目標，前提是群組名稱中提及這項資訊。為了緩解此風險，Microsoft 提供了一些選項，可以在目錄清單中隱藏私人群組並且不顯示其成員清單。不過，這些設定預設為停用狀態，也就是說組織必須主動啟用這些設定才能確保私人群組的中繼資料受到保密。

收集

來自雲端儲存的資料

公開 M365 群組

臨時存取密碼 (TAP) 功能是一種臨時驗證方法，使用有時間或使用限制的密碼。雖然這是正當的功能，但在貴組織不需要的情況下，建議您將其停用以減少攻擊破綻。

<a href="https://learn.microsoft.com/zh-tw/entra/identity/authentication/howto-authentication-temporary-access-pass">臨時存取密碼 (TAP)</a> 是一種臨時驗證方法，可作為標準 Microsoft Entra 驗證 (例如密碼和 MFA) 的替代方案。TAP 專為員工入職、密碼遺失和服務中心重設等情況而設計，也可以作為實施<a href="https://learn.microsoft.com/zh-tw/entra/identity/authentication/howto-authentication-passwordless-deployment">無密碼</a>等其他驗證方法 (例如 Microsoft Authenticator、Windows Hello 企業版或 FIDO2 安全性金鑰) 的前導程序，提供限時或一次性密碼。使用者可以根據「驗證方法」主控台中設定的 TAP 原則 (透過 Azure 入口網站或 Microsoft Entra 系統管理中心設定)，在 TAP 的有效期限內使用此密碼。此原則可以全面套用至所有使用者，或選擇性套用於特定群組。啟用原則後，具有所需權限的特權使用者就能在「驗證方法」主控台中產生 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-tw/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 指令程式</a> 達成。
此曝險指標會列出您的 Entra ID 環境中所有未驗證的自訂網域​，以便您確認其正當性。

未驗證的網域

第一方服務主體擁有強大權限，然而因為他們處於隱藏狀態、數量眾多，且為 Microsoft 所有，因而會被忽略。攻擊者會將憑證新增至主體，在神不知鬼不覺的情況下利用主體特權達成特權提升和潛伏的目的。

第一方服務主體 (企業應用程式) 來自屬於 Microsoft 的應用程式 (應用程式註冊)。它們大多數在 Microsoft Entra ID 中擁有在安全性檢查中經常被忽略的機密權限。攻擊者可藉此將憑證新增至這些主體，以隱蔽地利用主體特權。​
因為擁有應用程式管理員角色的主體可以將憑證新增至應用程式 (包括擁有更高特權的應用程式)，所以這項技術使攻擊者能夠進行長期潛伏​和特權提升​。
除極少數情況外 (請參閱「建議」)，第一方服務主體不應擁有任何憑證。Microsoft 在<a href="https://learn.microsoft.com/zh-tw/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-tw/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> 均有相關記錄。
根據預設 (參數可變更)，系統會略過已停用的服務主體，因為這是攻擊者無法立即利用的資源。

偵測

曝險指標 (IoE)

MEDIUM

MEDIUM

HIGH

CRITICAL

HIGH

MEDIUM

HIGH

LOW

MEDIUM

LOW

LOW

HIGH