NECサイバーセキュリティ戦略統括部セキュリティ技術センターの松井です。
今回は、Active Directory Certificate Services（ADCS）におけるAttack Pathについて考察します。

Active Directory Certificate Services (ADCS) について

本ブログのトピックスであるActive Directory Certificate Services（以後ADCSと記載する）とは、Microsoft Active Directory環境における公開鍵認証基盤（PKI）機能を提供するWindowsサーバのロールです。Active Directory ドメイン環境においてエンタープライズCA（Certificate Authority）を構成します。
クライアントはエンタープライズCAに対して、証明書署名要求 (CSR)を送信し、証明書の発行をリクエストすることが出来ます。

ADCSのAttack Pathについて

次にAttack Pathとは、アイデンティティベースの攻撃を連鎖させることで権限昇格やラテラルムーブメントを行い、侵害目的を達成する攻撃の連鎖のことを指します。Attack Pathに関しては、筆者が過去に「Active DirectoryにおけるAttack Path（攻撃パス）」[1]というタイトルでブログを公開しておりますので参照していただけると幸いです。
ADCSの悪用については、Specter Ops社のメンバーの素晴らしいホワイトペーパーである「Certified Pre-Owned」[2]で詳細に語られています。本ブログでは、当該ホワイトペーパーにおいてESC1と命名されている証明書テンプレートの誤った構成に基づくAttack Pathを見ていきます。

証明書テンプレートの誤った構成に基づくAttack Path（ESC1）

クライアントが証明書の発行をリクエストする際、証明書署名要求 (CSR)にて証明書のテンプレートを指定します。証明書テンプレートは、ADCSの管理者によって既存のテンプレートを複製し変更することが可能ですが、テンプレートのオプション次第では権限昇格に対して悪用可能な証明書が発行できます。

今回、筆者の検証ラボにおいて次の特定の条件を満たす証明書テンプレートを作成しました。この条件では、一般権限のユーザが任意のユーザのクライアント証明書を要求することが可能です。

• 要求者が SubjectAltName (SAN) を指定可能
• マネージャー承認が無効
• 承認された署名が不要
• クライアント認証として利用可能な拡張機能（EKU）
• 権限の低いユーザに登録権限が付与

作成した証明書テンプレートは、Microsoft Management Console（MMC）ユーティリティを用いてADオブジェクトとして確認することができます。

MMCユーティリティでは、証明書テンプレートをはじめとしてADCSに関わる各種オブジェクトと属性を確認することができます。以下は各オブジェクトの関係性を整理したものです。[3]

この関係性から、一般ユーザが任意のユーザの権限にエスカレーションするAttack Pathは以下のように表現されます。

本Attack Pathをラボで検証してみます。事前に準備した証明書テンプレートの設定により、一般ユーザがドメイン管理者のためのクライアント証明書を発行することができます。

証明書の操作には、「Certify」と呼ばれるADCSの調査や証明書の要求のために利用されるツール[4]を使用しました。ツールの実行オプションには、悪用する脆弱なテンプレートである「CertTemplate1」と、SubjectAltName (SAN)として「Administrator」を指定していることがポイントです。
実行結果より、ドメイン管理者のクライアント証明書を取得できたことが分かります。今回、証明書テンプレートの設定において、証明書の拡張機能としてクライアント証明書としての利用が設定されています。そのため、ケルベロス認証の認証プロセスにおいてクライアント証明書の利用が可能です（PKINIT）。

本攻撃では、ドメイン管理者のクライアント証明書を不正に取得することで、ドメイン管理者として認証することができ、結果としてドメイン管理者のTicket Granting Ticket（TGT）を取得できます。以下はケルベロスチケットの操作に使われるツール「Rubeus」[5]を使用し、ドメイン管理者のTGTを取得してローカルにキャッシュし、klistコマンドで正しくキャッシュされているかを確認している様子です。

Rubeusの実行オプションでは、事前に取得したクライアント証明書を指定しており、実行結果よりTGTが取得できている様子が分かります。
klistコマンドの結果の通り、ドメイン管理者のTGTがキャッシュされました。試しにPsExecを用いてドメインコントローラへラテラルムーブメントを行い任意のコマンドを実行することで、確かにドメイン管理者へ権限昇格できたことが分かります。

緩和策

本攻撃に対する対策としては、ADCSサーバの有無の確認や証明書テンプレートの棚卸が効果的です。本攻撃の影響を受けると判明した場合は、証明書テンプレートのプロパティの構成を適切に修正することを推奨します。本番環境での設定変更がすぐに難しい場合は、クライアント証明書を用いたTGTリクエスト（PKINIT）に特徴的なログ[6]に対して脅威ハンティングや監視を行うことを推奨します。

さいごに

今回は、ADCSにおけるAttack Pathを紹介しました。本攻撃のための条件が成立する場合、数ステップの手順で容易にドメイン管理者に到達できます。ドメイン管理者に代表されるTier0アセットへ到達する経路を事前に把握し対処することが内部侵害の被害を未然に防ぐために重要となります。

参考文献

[1]Active DirectoryにおけるAttack Path（攻撃パス）| NEC
https://group.nec/jp/ja/solutions/cybersecurity/blog/231117

[2]Certified Pre-Owned | SpecterOps
https://specterops.io/wp-content/uploads/sites/3/2022/06/Certified_Pre-Owned.pdf

[3]Analyzing and Executing ADCS Attack Paths with BloodHound
https://www.x33fcon.com/slides/x33fcon24_-_Jonas_B%C3%BClow_Knudsen_and_Andy_Robbins_-_Analyzing_and_Executing_ADCS_Attack_Paths_with_BloodHound.pdf

[4]GhostPack/Certify
https://github.com/GhostPack/Certify

[5]GhostPack/Rubeus
https://github.com/GhostPack/Rubeus

[6]4768(S, F): A Kerberos authentication ticket (TGT) was requested. | Microsoft
https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-10/security/threat-protection/auditing/event-4768

執筆者プロフィール

松井　祐輔（まつい　ゆうすけ）
セキュリティ技術センター

脅威インテリジェンス、内部侵入攻撃対策を専門とする。
大規模国際イベントや官民向けのサイバーセキュリティ対応業務を経て、現在はNEC CSIRT Cyber Threat Intelligenceなどの業務に従事。
CISSP、CISA、2×SANSメダル、5×Splunk Botsトロフィー、Offensive Securityメダル、3×Taniumメダルを保持。
YamatoSEC上忍、AD Hack WGリード、Hardening Project Kuromame6 メンバー、Offensive Security Lab Japan実行委員