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