これは Active Directory Security Advent Calendar 2025 の10日目の記事です。
はじめに
ADCSの脆弱性を放置しておくといきなりドメイン環境の管理者権限まで取られてしまうので、気を付けましょうといった内容になります。
一般的なドメインユーザからドメイン管理者になるまでの流れをESC8というADCSの脆弱性の検証しながら、どういった対策が出来るかを考えていこうと思います。
ADCSとは？
公式サイトでは以下の様に紹介されてます。
Active Directory 証明書サービス (AD CS) は、セキュリティで保護された通信および認証プロトコルで使用される公開キー 基盤 (PKI) 証明書を発行および管理するための Windows Server の役割です。
社内WebのHTTPS化やICカードでのログイン、オンプレメールサーバのS/MIMEなど多用途で利用されるサービスだと思います。
ADCSの脆弱性
結構あります。ESC1からESC16まで執筆時点だとあります。設定ミス起因やCVEが付いてるモノまで様々です。
以下のHackTricksに一覧があります。
各ESCについて詳しくは取り上げませんが、気になる人は確認してみてもいいかもしれません。
NECさんがESC1について紹介をしてくれてたりします。
ESC8
HackTricksから引用します。
Several HTTP-based enrollment methods are supported by AD CS, made available through additional server roles that administrators may install. These interfaces for HTTP-based certificate enrollment are susceptible to NTLM relay attacks. An attacker, from a compromised machine, can impersonate any AD account that authenticates via inbound NTLM. While impersonating the victim account, these web interfaces can be accessed by an attacker to request a client authentication certificate using the User or Machine certificate templates.
簡単に言うと、ターゲットとなるドメインアカウント（ユーザだったりコンピュータだったり）の認証リクエストを本来のリクエスト先からADCSに強制的に向きを変え（中間者攻撃）、ADCSにそのアカウントの証明書を発行させます。
その後、その証明書を悪用しターゲットに成りすますことが可能といった脆弱性になります。
ADCSがリクエスト元を検証しないエンドポイント（基本HTTPが空いてたりします）を持ってる場合に発火します。以下とかですね。
http://[ADCS IP]/certsrv
NTLM relay
この脆弱性を悪用するにはNTLM relayという攻撃をする必要性があります。
認証リクエストをADCSに向きを変える方法ですね。
ADにはKerberos認証とNTLM認証の大きく二つの認証方法があります。詳しい認証の仕組みはここでは触れません。このNTLM認証の方をNTLM relayでは悪用するのですが、今後廃止に向かいます。
基本的にSMB経由でターゲットのNTLM認証を発火させることが多いのですが、様々なプロトコルにNTLM認証をリレーできます。The Hacker Recipesに対応表があるので、NTLM relayのリレープロトコルが気になる人は確認してみてください。
Phishing起因でターゲットに認証させる方法もあるのですが、これはターゲットの動作に左右されます。この不確定要素を排除し、攻撃者が強制的にNTLM認証をターゲットに発火させる方法もありますね。この強制認証発火のためには、何かしらのドメインアカウントの認証情報が必要だったりします。
このNTLM認証を攻撃者の環境に対してターゲットに実施させ、攻撃者はその通信をADCSにリレーすることでESC8を実施することになります。
検証
このESC8を使ってDomain Admins権限を奪取します。
環境
DCがあり、別のサーバでADCSサービスを起動していると仮定します。
また、ドメインユーザはすでに奪取されているものとします。
LAB-DC: 172.16.19.3
ADCS: 172.16.19.5
Exploitフロー
攻撃を行うフローを簡単に記載します。
-
LAB-DC$（コンピュータアカウント）に対して攻撃者マシン向けにNTLM認証を強制させる - 攻撃者マシンでNTLM relayを実施しADCS01にNTLM通信をリレー
-
LAB-DC$のドメコン証明書を取得 - ドメコン証明書を使って
LAB-DC$の認証情報を抽出 -
LAB-DC$の認証情報を利用してDCsync攻撃を実施 - Domain Adminsの権限のあるユーザの認証情報を抽出
シーケンスで記載するとこんな感じです。
実践
ESC8の脆弱性の確認
certipyというToolを使って確認します。
ADCSにESC8の脆弱性が存在することがわかります。ESC11についてはRPCのエンドポイントの脆弱性ですが、今回はこの詳細については触れません。
NTLM relay攻撃
中間待ち受け
ADCSへリレーするための中間者の設定をします。これもcertipyで設定します。
certipy relay -tareget 172.16.19.5 -template DomainController
上記コマンドを実施すればNTLMの通信を待ち受ける状態で起動できます。証明書はドメコン証明書を要求するように設定しておきます。
NTLM認証試行の強制
別のターミナルでLAB-DC$に攻撃者マシンへ認証を強制するようにします。
petitpotamを利用して実施します。MS-EFSRのプロトコルを悪用し認証試行を強制できるものです。CVE-2021-36942辺りで話題になったやつですね。
気になる方は以下を読んでみてください。
実際に強制させます。
LAB-DCに対して攻撃マシン（172.16.19.19）に強制させてます。EfsRpcOpenFileRawの関数に関してはCVEに対するPatchがあるのでWindows Updateをしていれば効きません。ただ他の悪用可能関数に関してはPatchが現在も出てない（ADが死ぬとか不具合ありでMSさんも四苦八苦...）ので、EfsRpcEncryptFileSrv関数で攻撃が成功します。
ちなみにめちゃ最近出てきたv3のMDIセンサーだとこの段階で検知できそう？？な気がします。多分。
MDE（MS Defender for Endpoint）をDCに突っ込んでいる場合はMDI（MS Defender for Identity）のv3を展開できるのでここらのRPCの監査も出来るようです。詳しくは分からない！
ほほう？強そうだな？
続きに戻ります。先ほどの待ち受けを見てみます。
リレーが成功し、lab-dc.pfxの証明書が生成されました。ドメコン証明書ですね。
今回はpetitpotamを利用しましたが、認証強制の方法は様々あります。\\pipe\spoolssの名前付きパイプ（Print Spoolerサービス由来の有名な経路）経由で強制させる方法とかもあったりします。RPCの管理辛い...
DCSync攻撃
DCの証明書を取得できたので、DCのコンピュータアカウントに成りすまして、DCからオブジェクトの認証情報をぶっこ抜く「DCSync攻撃」が出来ます。ドメコンのアカウントだと基本的にどれでも実行できます。
DCsyncを行う前に証明書からNTLMのハッシュ（Password相当の使いまわしが可能）とTGT（Kerberousの認証済チケットみたいなやつ）を取得します。
v2のセンサーのMDIは大方この辺りでKerberousの認証系（事前認証で怪しい証明書が使われてますよとか）のAlertを上げてくれるかも？と思いますが、権限昇格の最終段階あたりなのでこのAlertを見た場合はだいぶ急がないといけませんね。
取得できたのでDCSyncでDomain Admins権限を持っているAdministratorのNTLMハッシュを抜きます。
※スクショ省略
ちなみにMDIはこのDCSync攻撃ほぼほぼ拾ってくれます。DCSync系Alertが見えると絶望のぐぬぬ...
抜いた後はそのハッシュを使ってコマンドラインへアクセスします。WinRM（Windows リモート管理）のプロトコルでDCへ侵入します。
Domain Admins権限の奪取に成功しています。
ESC8への対策
メイン対策 - EPAとHTTP無効化
EPAをADCSサーバで有効にし、HTTPのエンドポイントを閉じましょう！
以下が参考になると思います。
「HTTPエンドポイントを無効化するだけでHTTPSで保護されないの？」と疑問に思うかもしれないですが、HTTPSのエンドポイントに対して同様の中間者を建てるだけで、攻撃は成立します。
攻撃者マシンとADCSの間でSSLのセッションキーが作成されるだけで、ターゲット（検証の場合はLAB-DC）からの認証かどうかは見てくれてません。
なのでEPAとHTTPSエンドポイントの両方が必要です。
※一応この対策はESC8に絞った対策で、NTLM relayがなくなったわけではないです。
その他の対策
基本的にNTLM relayに焦点を当てた対策となります。
NTLM認証の廃止
NTLM認証を廃止していればリレーできませんしね。
将来廃止だしね…
SMB/LDAP署名の強制
リレーすることを困難にしてやりましょう！署名だ署名だ！
RPCの強制認証自体は防げませんがリレーは困難になります。
HTTP...(´・ω・)
netshでRPCのインターフェース無効化
netshの機能を使ってpetitpotamが利用するRPCのインターフェースを無効化することで今回のフローに関しては防げます。以下が参考になったりします。
ただ、これはpetitpotamで利用するインターフェースですし、他のRPCも同様に精査していかないといけないので暫定対処って感じです。
強制認証は一部防げてもNTLM relayができなくなったわけでもないので、まだ前項の署名の方がいいと思います。
RPCのサービスを停止
強制認証できるRPCが起動するサービス自体を落としてしまうのも手です。Print Spoolerサービスを無効化したりですね。といっても前項と同じで強制認証は一部防げてもNTLM relayができなくなったわけではないです...
まとめ
ESC8でDomain Adminsが取られるまでを検証しつつ、どういった攻撃ポイントについてどういった対策ができるかを確認していきました。
無造作にADCSをちょろっと建ててると、デフォルトの状態で大体このExploitフローが刺さるかも…
対策しっかり入れていきましょう！
ご参考になれば幸いです。