AD CS Domain Escalation
Last updated
Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
これは、投稿のエスカレーション技術セクションの要約です：
エンタープライズ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の指定が許可されます。
この構成は、低特権ユーザーが任意のSANを持つ証明書をリクエストできることを許可し、KerberosまたはSChannelを介して任意のドメインプリンシパルとしての認証を可能にします。
この機能は、製品や展開サービスによるHTTPSまたはホスト証明書のオンザフライ生成をサポートするため、または理解不足のために有効にされることがあります。
このオプションで証明書を作成すると警告が表示されることが記載されていますが、既存の証明書テンプレート（WebServerテンプレートなど、CT_FLAG_ENROLLEE_SUPPLIES_SUBJECTが有効なもの）を複製してから認証OIDを含めるように変更した場合は、警告は表示されません。
脆弱な証明書テンプレートを見つけるには、次のコマンドを実行できます：
この脆弱性を悪用して管理者を偽装するには、次のコマンドを実行できます:
次に、生成された証明書を.pfx形式に変換し、再度Rubeusまたはcertipyを使用して認証することができます:
The Windows binaries "Certreq.exe" & "Certutil.exe" can be used to generate the PFX: https://gist.github.com/b4cktr4ck2/95a9b908e57460d9958e8238f85ef8ee
ADフォレストの構成スキーマ内の証明書テンプレートの列挙、特に承認や署名を必要とせず、クライアント認証またはスマートカードログオンEKUを持ち、CT_FLAG_ENROLLEE_SUPPLIES_SUBJECTフラグが有効なものは、次のLDAPクエリを実行することで行うことができます:
二番目の悪用シナリオは、最初のもののバリエーションです：
エンタープライズCAによって、低特権ユーザーに登録権限が付与されます。
マネージャーの承認要件が無効化されます。
認可された署名の必要性が省略されます。
証明書テンプレートのセキュリティ記述子が過度に許可されており、低特権ユーザーに証明書登録権限を付与します。
証明書テンプレートは、Any Purpose EKUまたはEKUなしとして定義されています。
Any Purpose EKUは、攻撃者が任意の目的（クライアント認証、サーバー認証、コード署名など）で証明書を取得することを許可します。ESC3に使用される技術と同じ技術を使用して、このシナリオを悪用することができます。
EKUなしの証明書は、下位CA証明書として機能し、任意の目的で悪用される可能性があり、新しい証明書に署名するためにも使用できます。したがって、攻撃者は下位CA証明書を利用して、新しい証明書に任意のEKUやフィールドを指定することができます。
ただし、ドメイン認証のために作成された新しい証明書は、下位CAが**NTAuthCertificatesオブジェクトによって信頼されていない場合、機能しません。とはいえ、攻撃者は依然として任意のEKUと任意の証明書値を持つ新しい証明書を作成することができます。これらは、広範な目的（例：コード署名、サーバー認証など）で悪用される可能性**があり、SAML、AD FS、またはIPSecなどのネットワーク内の他のアプリケーションに重大な影響を与える可能性があります。
ADフォレストの構成スキーマ内でこのシナリオに一致するテンプレートを列挙するには、次のLDAPクエリを実行できます：
このシナリオは最初と二番目のものに似ていますが、異なるEKU（証明書要求エージェント）と2つの異なるテンプレートを悪用しています（したがって、2セットの要件があります）。
証明書要求エージェントEKU（OID 1.3.6.1.4.1.311.20.2.1）は、Microsoftの文書で登録エージェントとして知られており、ある主体が他のユーザーの代理で証明書に登録することを許可します。
「登録エージェント」はそのようなテンプレートに登録し、結果として得られた証明書を使用して他のユーザーの代理でCSRに共同署名します。その後、共同署名されたCSRをCAに送信し、「代理で登録することを許可する」テンプレートに登録し、CAは**「他の」ユーザーに属する証明書**で応答します。
要件 1:
エンタープライズCAによって低特権ユーザーに登録権が付与されます。
マネージャーの承認要件は省略されます。
認可された署名の要件はありません。
証明書テンプレートのセキュリティ記述子は過度に許可的で、低特権ユーザーに登録権を付与します。
証明書テンプレートには証明書要求エージェントEKUが含まれており、他の主体の代理で他の証明書テンプレートの要求を可能にします。
要件 2:
エンタープライズCAは低特権ユーザーに登録権を付与します。
マネージャーの承認はバイパスされます。
テンプレートのスキーマバージョンは1または2を超え、証明書要求エージェントEKUを必要とするアプリケーションポリシー発行要件を指定します。
証明書テンプレートで定義されたEKUはドメイン認証を許可します。
CAに対して登録エージェントの制限は適用されません。
このシナリオを悪用するには、CertifyまたはCertipyを使用できます。
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が誰でもすべてのテンプレートにエンロールすることができます。
証明書テンプレートのセキュリティ記述子は、テンプレートに関するADプリンシパルが持つ権限を定義します。
攻撃者がテンプレートを変更し、前のセクションで概説された悪用可能な誤設定を導入するために必要な権限を持っている場合、特権昇格が促進される可能性があります。
証明書テンプレートに適用される主な権限には以下が含まれます：
Owner: オブジェクトに対する暗黙の制御を付与し、任意の属性を変更することを可能にします。
FullControl: オブジェクトに対する完全な権限を付与し、任意の属性を変更する能力を含みます。
WriteOwner: オブジェクトの所有者を攻撃者の制御下にあるプリンシパルに変更することを許可します。
WriteDacl: アクセス制御の調整を可能にし、攻撃者にFullControlを付与する可能性があります。
WriteProperty: 任意のオブジェクトプロパティの編集を許可します。
前のような特権昇格の例：
ESC4は、ユーザーが証明書テンプレートに対して書き込み権限を持っている場合です。これは、例えば、証明書テンプレートの構成を上書きして、テンプレートをESC1に対して脆弱にするために悪用される可能性があります。
上記のパスで見ると、JOHNPCのみがこれらの権限を持っていますが、私たちのユーザーJOHNはJOHNPCへの新しいAddKeyCredentialLinkエッジを持っています。この技術は証明書に関連しているため、私はこの攻撃も実装しました。これはShadow Credentialsとして知られています。ここでは、被害者のNTハッシュを取得するためのCertipyのshadow autoコマンドの小さなスニークピークを示します。
Certipy は、単一のコマンドで証明書テンプレートの設定を上書きできます。デフォルトでは、Certipyは設定を上書きしてESC1に対して脆弱にします。また、-save-oldパラメータを指定して古い設定を保存することもでき、これは攻撃後に設定を復元するのに役立ちます。
証明書テンプレートや証明書認証局を超えた複数のオブジェクトを含むACLベースの関係の広範なネットワークは、AD CSシステム全体のセキュリティに影響を与える可能性があります。これらのオブジェクトは、セキュリティに大きな影響を与える可能性があり、以下を含みます：
CAサーバーのADコンピュータオブジェクトは、S4U2SelfやS4U2Proxyなどのメカニズムを通じて侵害される可能性があります。
CAサーバーのRPC/DCOMサーバー。
特定のコンテナパス CN=Public Key Services,CN=Services,CN=Configuration,DC=<DOMAIN>,DC=<COM> 内の任意の子孫ADオブジェクトまたはコンテナ。このパスには、証明書テンプレートコンテナ、認証局コンテナ、NTAuthCertificatesオブジェクト、エンロールメントサービスコンテナなどのコンテナやオブジェクトが含まれますが、これに限定されません。
低特権の攻撃者がこれらの重要なコンポーネントのいずれかを制御できる場合、PKIシステムのセキュリティが侵害される可能性があります。
CQure Academyの投稿で議論されている主題は、Microsoftによって概説された**EDITF_ATTRIBUTESUBJECTALTNAME2フラグの影響にも触れています。この設定は、認証局（CA）で有効にされると、任意のリクエストの代替名にユーザー定義の値を含めることを許可します。これには、Active Directory®から構築されたリクエストも含まれます。したがって、この規定により、侵入者はドメイン認証のために設定された任意のテンプレートを通じて登録できるようになります。特に、標準のユーザーテンプレートのように特権のないユーザー登録に開放されているものです。その結果、証明書が取得され、侵入者はドメイン管理者またはドメイン内の他のアクティブなエンティティ**として認証できるようになります。
注意: 証明書署名要求（CSR）に代替名を追加する方法は、certreq.exeの-attrib "SAN:"引数を通じて行われ（「名前値ペア」と呼ばれる）、ESC1のSANの悪用戦略とは対照的です。ここでの違いは、アカウント情報がどのようにカプセル化されるかにあります—拡張ではなく、証明書属性内にあります。
設定が有効になっているかどうかを確認するために、組織はcertutil.exeを使用して以下のコマンドを利用できます：
この操作は本質的にリモートレジストリアクセスを利用するため、代替アプローチとしては次のようなものがあります:
ツールのような Certify と Certipy は、この誤設定を検出し、悪用することができます：
これらの設定を変更するには、ドメイン管理者権限または同等の権限を持っていると仮定して、次のコマンドを任意のワークステーションから実行できます：
この構成をあなたの環境で無効にするには、フラグを次のように削除できます:
2022年5月のセキュリティ更新以降、新しく発行された証明書には、リクエスターの objectSid プロパティを組み込んだセキュリティ拡張が含まれます。ESC1の場合、このSIDは指定されたSANから派生します。しかし、ESC6の場合、SIDはリクエスターの objectSidを反映し、SANではありません。
ESC6を悪用するには、システムがESC10（弱い証明書マッピング）に対して脆弱であることが重要であり、これにより新しいセキュリティ拡張よりもSANが優先されます。
証明書認証局のアクセス制御は、CAのアクションを管理する一連の権限を通じて維持されます。これらの権限は、certsrv.mscにアクセスし、CAを右クリックしてプロパティを選択し、次にセキュリティタブに移動することで表示できます。さらに、PSPKIモジュールを使用して、次のようなコマンドで権限を列挙できます：
これは、主な権限、すなわち ManageCA と ManageCertificates に関する洞察を提供し、それぞれ「CA管理者」と「証明書マネージャー」の役割に関連しています。
証明書機関で ManageCA 権限を持つことは、PSPKIを使用して設定をリモートで操作することを可能にします。これには、SAN仕様を任意のテンプレートで許可するために EDITF_ATTRIBUTESUBJECTALTNAME2 フラグを切り替えることが含まれ、ドメイン昇格の重要な側面です。
このプロセスの簡素化は、PSPKIの Enable-PolicyModuleFlag コマンドレットを使用することで達成でき、直接的なGUI操作なしで変更を行うことができます。
ManageCertificates 権限を持つことで、保留中のリクエストの承認が可能になり、「CA証明書マネージャーの承認」保護を効果的に回避できます。
Certify と PSPKI モジュールの組み合わせを使用して、証明書をリクエスト、承認、ダウンロードすることができます：
前の攻撃では、Manage CA 権限を使用して EDITF_ATTRIBUTESUBJECTALTNAME2 フラグを 有効化 し、ESC6攻撃を実行しましたが、CAサービス（CertSvc）が再起動されるまで効果はありません。ユーザーが Manage CA アクセス権を持っている場合、そのユーザーは サービスを再起動することも許可されます。しかし、これは ユーザーがリモートでサービスを再起動できることを意味するわけではありません。さらに、ESC6は2022年5月のセキュリティ更新のため、ほとんどのパッチ適用環境では そのままでは機能しない可能性があります。
したがって、ここで別の攻撃が提示されます。
前提条件：
ManageCA 権限のみ
Manage Certificates 権限（ManageCA から付与可能）
証明書テンプレート SubCA は 有効化 されている必要があります（ManageCA から有効化可能）
この手法は、Manage CA および Manage Certificates アクセス権を持つユーザーが 失敗した証明書リクエストを発行できる という事実に依存しています。SubCA 証明書テンプレートは ESC1に対して脆弱ですが、管理者のみがテンプレートに登録できます。したがって、ユーザーは SubCA への登録を リクエスト できますが、これは 拒否され、その後 マネージャーによって発行されます。
自分自身に Manage Certificates アクセス権を付与するには、新しい役員として自分のユーザーを追加できます。
SubCA テンプレートは、-enable-template パラメータを使用して CA で 有効化 できます。デフォルトでは、SubCA テンプレートは有効になっています。
この攻撃の前提条件を満たしている場合、SubCA テンプレートに基づいて証明書を要求することから始めることができます。
この要求は拒否されますが、プライベートキーを保存し、要求IDをメモしておきます。
私たちの Manage CA と Manage Certificates を使用して、ca コマンドと -issue-request <request ID> パラメータを使って 失敗した証明書 リクエストを 発行 することができます。
そして最後に、reqコマンドと-retrieve <request ID>パラメータを使用して発行された証明書を取得できます。
AD CSがインストールされている環境では、脆弱なウェブ登録エンドポイントが存在し、少なくとも1つの証明書テンプレートが公開されている場合、ドメインコンピュータの登録とクライアント認証を許可する（デフォルトの**Machine**テンプレートなど）、スプーラーサービスがアクティブな任意のコンピュータが攻撃者によって侵害される可能性があります!
AD CSは、管理者がインストールできる追加のサーバーロールを通じて提供されるHTTPベースの登録方法をいくつかサポートしています。これらのHTTPベースの証明書登録インターフェースは、NTLMリレー攻撃に対して脆弱です。攻撃者は、侵害されたマシンから、受信NTLMを介して認証される任意のADアカウントを偽装することができます。被害者アカウントを偽装している間、これらのウェブインターフェースにアクセスすることで、攻撃者は**UserまたはMachine証明書テンプレートを使用してクライアント認証証明書を要求することができます**。
ウェブ登録インターフェース（http://<caserver>/certsrv/で利用可能な古いASPアプリケーション）は、デフォルトでHTTPのみを使用し、NTLMリレー攻撃に対する保護を提供しません。さらに、Authorization HTTPヘッダーを通じてNTLM認証のみを明示的に許可しており、Kerberosのようなより安全な認証方法は適用できません。
証明書登録サービス（CES）、証明書登録ポリシー（CEP）Webサービス、およびネットワークデバイス登録サービス（NDES）は、デフォルトでAuthorization HTTPヘッダーを介してネゴシエート認証をサポートしています。ネゴシエート認証はKerberosとNTLMの両方をサポートしており、攻撃者はリレー攻撃中にNTLMにダウングレードすることができます。これらのウェブサービスはデフォルトでHTTPSを有効にしていますが、HTTPSだけではNTLMリレー攻撃から保護されません。HTTPSサービスのNTLMリレー攻撃からの保護は、HTTPSがチャネルバインディングと組み合わさった場合にのみ可能です。残念ながら、AD CSはIISでの認証のための拡張保護を有効にしておらず、チャネルバインディングに必要です。
NTLMリレー攻撃の一般的な問題は、NTLMセッションの短い期間と、攻撃者がNTLM署名を必要とするサービスと相互作用できないことです。
それにもかかわらず、この制限は、ユーザーのために証明書を取得するためにNTLMリレー攻撃を利用することで克服されます。証明書の有効期間がセッションの期間を決定し、証明書はNTLM署名を義務付けるサービスで使用できます。盗まれた証明書の利用方法については、次を参照してください：
NTLMリレー攻撃のもう一つの制限は、攻撃者が制御するマシンが被害者アカウントによって認証される必要があることです。攻撃者は待つか、この認証を強制しようとすることができます：
Certifyのcasは、有効なHTTP AD CSエンドポイントを列挙します：
msPKI-Enrollment-Servers プロパティは、エンタープライズ証明書認証局 (CA) によって証明書登録サービス (CES) エンドポイントを保存するために使用されます。これらのエンドポイントは、ツール Certutil.exe を利用して解析およびリスト化できます:
```powershell Import-Module PSPKI Get-CertificationAuthority | select Name,Enroll* | Format-List * ```
Certipyによる証明書のリクエストは、アカウント名が$で終わるかどうかに基づいて、デフォルトでMachineまたはUserテンプレートに基づいて行われます。代替テンプレートの指定は、-templateパラメータを使用することで実現できます。
PetitPotamのような技術を使用して認証を強制することができます。ドメインコントローラーを扱う場合は、-template DomainControllerの指定が必要です。
新しい値 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 フラグが含まれている。
証明書が msPKI-Enrollment-Flag 設定内で CT_FLAG_NO_SECURITY_EXTENSION フラグでマークされている。
証明書によってクライアント認証 EKU が指定されている。
他のアカウントを妥協するために、任意のアカウントに対して GenericWrite 権限が利用可能である。
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 を使用して取得されます：
その後、JaneのuserPrincipalNameがAdministratorに変更され、意図的に@corp.localドメイン部分が省略されます:
この変更は制約に違反しません。Administrator@corp.localはAdministratorのuserPrincipalNameとして区別されます。
これに続いて、脆弱性があるとマークされたESC9証明書テンプレートがJaneとして要求されます:
userPrincipalNameがAdministratorを反映しており、“object SID”が欠如していることが記載されています。
JaneのuserPrincipalNameは元のJane@corp.localに戻されます：
発行された証明書で認証を試みると、Administrator@corp.localのNTハッシュが得られます。証明書にドメインの指定がないため、コマンドには-domain <domain>を含める必要があります:
ドメインコントローラー上の2つのレジストリキー値がESC10によって参照されています：
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に設定されている場合。
ケース 2
CertificateMappingMethodsにUPNビット（0x4）が含まれている場合。
StrongCertificateBindingEnforcementが0に設定されている場合、GenericWrite権限を持つアカウントAは、任意のアカウントBを危険にさらすために悪用される可能性があります。
例えば、Jane@corp.localに対してGenericWrite権限を持つ攻撃者が、Administrator@corp.localを危険にさらそうとします。この手順はESC9と同様で、任意の証明書テンプレートを利用することができます。
最初に、JaneのハッシュがShadow Credentialsを使用して取得され、GenericWriteを悪用します。
その後、JaneのuserPrincipalNameがAdministratorに変更され、制約違反を避けるために@corp.local部分が故意に省略されます。
これに続いて、デフォルトの User テンプレートを使用して、Jane としてクライアント認証を有効にする証明書が要求されます。
JaneのuserPrincipalNameは元のJane@corp.localに戻されます。
取得した証明書を使用して認証すると、Administrator@corp.localのNTハッシュが得られます。これは、証明書にドメインの詳細が含まれていないため、コマンドでドメインを指定する必要があります。
CertificateMappingMethods に UPN ビットフラグ (0x4) が含まれている場合、GenericWrite 権限を持つアカウント A は、userPrincipalName プロパティを欠く任意のアカウント B を危険にさらすことができます。これには、マシンアカウントや組み込みのドメイン管理者 Administrator が含まれます。
ここでの目標は、Jane のハッシュを Shadow Credentials を通じて取得し、GenericWrite を利用して DC$@corp.local を危険にさらすことです。
JaneのuserPrincipalNameはDC$@corp.localに設定されます。
クライアント認証のための証明書がデフォルトの User テンプレートを使用して Jane として要求されます。
JaneのuserPrincipalNameは、このプロセスの後に元に戻ります。
Schannelを介して認証するために、Certipyの-ldap-shellオプションが利用され、認証成功はu:CORP\DC$として示されます。
LDAPシェルを通じて、set_rbcdのようなコマンドはリソースベースの制約付き委任（RBCD）攻撃を可能にし、ドメインコントローラーを危険にさらす可能性があります。
この脆弱性は、userPrincipalNameが欠如しているか、sAMAccountNameと一致しない任意のユーザーアカウントにも拡張されます。デフォルトのAdministrator@corp.localは、昇格されたLDAP権限とデフォルトでuserPrincipalNameが存在しないため、主要なターゲットとなります。
CAサーバーがIF_ENFORCEENCRYPTICERTREQUESTで構成されていない場合、RPCサービスを介して署名なしでNTLMリレー攻撃を行うことができます。こちらを参照。
certipyを使用して、Enforce Encryption for Requestsが無効になっているかどうかを列挙できます。certipyはESC11の脆弱性を表示します。
リレーサーバーを設定する必要があります：
注意: ドメインコントローラーの場合、DomainControllerで-templateを指定する必要があります。
または、sploutchyのimpacketのフォークを使用します:
管理者は、証明書機関を「Yubico YubiHSM2」のような外部デバイスに保存するように設定できます。
USBデバイスがCAサーバーにUSBポート経由で接続されている場合、またはCAサーバーが仮想マシンの場合はUSBデバイスサーバーが接続されている場合、YubiHSM内でキーを生成および利用するために、キー ストレージ プロバイダーに認証キー（時には「パスワード」と呼ばれる）が必要です。
このキー/パスワードは、レジストリのHKEY_LOCAL_MACHINE\SOFTWARE\Yubico\YubiHSM\AuthKeysetPasswordに平文で保存されます。
こちらを参照してください。
CAの秘密鍵が物理USBデバイスに保存されている場合、シェルアクセスを取得すると、その鍵を復元することが可能です。
まず、CA証明書を取得する必要があります（これは公開されています）そして：
最終的に、certutil -sign コマンドを使用して、CA証明書とその秘密鍵を使用して新しい任意の証明書を偽造します。
msPKI-Certificate-Policy 属性は、発行ポリシーを証明書テンプレートに追加することを許可します。ポリシーを発行する責任のある msPKI-Enterprise-Oid オブジェクトは、PKI OIDコンテナの構成命名コンテキスト (CN=OID,CN=Public Key Services,CN=Services) で発見できます。このオブジェクトの msDS-OIDToGroupLink 属性を使用して、ポリシーをADグループにリンクすることができ、システムは証明書を提示するユーザーをグループのメンバーであるかのように認可できます。こちらを参照。
言い換えれば、ユーザーが証明書を登録する権限を持ち、その証明書がOIDグループにリンクされている場合、ユーザーはこのグループの特権を継承できます。
Check-ADCSESC13.ps1 を使用してOIDToGroupLinkを見つけます:
ユーザーの権限を見つけるには、certipy find または Certify.exe find /showAllPermissions を使用します。
John が VulnerableTemplate を登録する権限を持っている場合、そのユーザーは VulnerableGroup グループの特権を継承できます。
必要なことは、テンプレートを指定するだけで、OIDToGroupLink 権利を持つ証明書を取得します。
クロスフォレスト登録の設定は比較的簡単です。リソースフォレストのルートCA証明書は管理者によってアカウントフォレストに公開され、リソースフォレストのエンタープライズCA証明書は各アカウントフォレストのNTAuthCertificatesおよびAIAコンテナに追加されます。この配置は、リソースフォレストのCAがPKIを管理するすべての他のフォレストに対して完全な制御を持つことを明確にします。このCAが攻撃者によって妥協された場合、リソースフォレストとアカウントフォレストのすべてのユーザーの証明書が偽造される可能性があり、それによってフォレストのセキュリティ境界が破られることになります。
マルチフォレスト環境では、認証されたユーザーまたは外部プリンシパル（エンタープライズCAが属するフォレスト外のユーザー/グループ）に証明書テンプレートの登録および編集権限を公開するエンタープライズCAに関して注意が必要です。 信頼を越えた認証の際、認証されたユーザーSIDがADによってユーザーのトークンに追加されます。したがって、ドメインが認証されたユーザーの登録権限を許可するテンプレートを持つエンタープライズCAを持っている場合、異なるフォレストのユーザーがテンプレートに登録される可能性があります。同様に、テンプレートによって外部プリンシパルに明示的に登録権限が付与されると、クロスフォレストアクセス制御関係が作成され、あるフォレストのプリンシパルが別のフォレストのテンプレートに登録できるようになります。
両方のシナリオは、あるフォレストから別のフォレストへの攻撃面の増加につながります。証明書テンプレートの設定は、攻撃者によって悪用され、外部ドメインでの追加権限を取得することができます。
AWSハッキングを学び、実践する：HackTricks Training AWS Red Team Expert (ARTE) GCPハッキングを学び、実践する：HackTricks Training GCP Red Team Expert (GRTE)
