ESC9対ESC16：同じ欠陥、異なる影響範囲

ESC9とESC16は、Active Directory Certificate Services (AD CS)向けに分類された番号付きエスカレーション技術（ESC）の2つであり、異なる範囲で同じ脆弱性です。どちらも発行された証明書からセキュリティ識別子（SID）セキュリティ拡張を削除し、攻撃者が弱い証明書マッピングを通じて別のアカウントをなりすますことを可能にします。ESC9は単一の証明書テンプレートで行われ、ESC16は証明書機関（CA）が発行するすべての証明書で行われます。

数年前にESC9を修正したとしても、それはESC16について何も示していません。

ESC9とは何ですか？

ESC9はテンプレート設定です。テンプレートのmsPKI-Enrollment-Flag属性にCT_FLAG_NO_SECURITY_EXTENSIONが設定されている場合、そのテンプレートから発行された証明書にはSID拡張（szOID_NTDS_CA_SECURITY_EXT）が含まれません。この拡張により、ドメインコントローラー（DC）は証明書を特定のアカウントに紐付けることができます。これがない場合、DCはユーザープリンシパル名（UPN）でのマッピングに戻ります。

攻撃には3つの条件が必要です：被害者アカウントのUPNに書き込みアクセス権を持つ攻撃者（GenericWriteで十分）、フラグが設定されたclient-authenticationテンプレートの登録権限、そして強力な証明書マッピングを強制しないDC。攻撃者は被害者のUPNを特権アカウントに合わせて変更し、登録し、UPNを元に戻して、証明書で特権ユーザーとして認証します。

Oliver Lyakは2022年8月にESC9を文書化し、多くのスキャナーが検出可能で、その中にはNetwrix PingCastleも含まれます。以下のチェックリストは、自分のテンプレートを確認する方法を示しています。

ESC16とは何ですか？

ESC16はテンプレートに触れずに同じ結果に到達します。szOID_NTDS_CA_SECURITY_EXT SIDセキュリティ拡張であるOID 1.3.6.1.4.1.311.25.2がCAのDisableExtensionListポリシーモジュールのレジストリ値にリストされている場合、CAは発行するすべてのものにSID拡張を追加しなくなります。そのCAの背後にあるすべてのテンプレートは、ESC9のフラグが設定されているかのように動作し、何年もレビューされていないテンプレートも含まれます。

環境がこの設定になる理由はいくつかあります。サードパーティツールの互換性修正、移行、または拡張機能を処理できないレガシーアプリケーションなどです。これは単一のレジストリエントリで見落とされやすく、テンプレートごとに構築した保護を静かに無効にします。

この設定はテンプレート属性ではありません。これはCAの構成であり、多くの証明書衛生レビューではCA自身のポリシーモジュール設定を開くことはありません。組織はすべてのテンプレートでクリーンであることを証明するレポートを持っていても、CAを通じて依然として露出している可能性があります。数年前にESC9をスキャンし、その後CAを確認していなければ、攻撃者はESC16を通じて同じなりすまし攻撃を実行できるかもしれません。

強力な証明書マッピングはあなたを守りますか？

部分的にそうです。両方の手法はDCが弱いマッピングを受け入れることに依存しており、強力な証明書バインディングを適用するDCは両方を無効化します。2025年9月のWindowsアップデート以降、パッチ適用済みのDCは完全な適用を実行し、互換モード設定はサポートされなくなるため、完全にパッチが適用されたドメインは裸のESC9およびESC16を停止します。ただし、2つのギャップが残ります。更新を逃したDCと、攻撃者が証明書要求に自分のSIDを提供できるチェーン（ESC16とESC6またはESC15の組み合わせなど）です。すべてのDCで適用状況を確認し、CAも確認してください。

両方をどのように確認して修正しますか？

2つのチェックが必要です。ESC9はテンプレートにあり、ESC16はCAにあるためです。

ESC9（証明書テンプレート）を確認する

1. 次のスキャンを実行してください：PingCastle。
2. レポートを開き、CT_FLAG_NO_SECURITY_EXTENSIONを検索します（リスクはA-CertTempNoSecurityです）。「少なくとも1つの証明書テンプレートにCT_FLAG_NO_SECURITY_EXTENSIONフラグが設定されています」というテキストを探してください。
3. そのテキストがなければ、スキャンされたテンプレートにはフラグがありません。あれば、影響を受けたテンプレートからフラグを削除してください。

ESC16（CA）を確認してください

各CAで、次を実行してください:

      certutil -getreg policy\DisableExtensionList
      

出力にOID 1.3.6.1.4.1.311.25.2が表示される場合、そのCAは発行するすべてのものからSID拡張を削除しています。文書化された理由がない限り、リストから削除してください。

修正するには、OIDを削除し、変更を有効にするためにCertificate Servicesを再起動してください：

      certutil -setreg policy\DisableExtensionList -1.3.6.1.4.1.311.25.2
net stop certsvc
net start certsvc
      

その後、certutil -getreg policy\DisableExtensionList を再度実行して、OIDが消えていることを確認してください。拡張なしで既に発行された証明書はそのままなので、設定が悪用された疑いがある場合は確認してください。アプリケーションがこの設定を必要としていた場合は、広く展開する前にテストしてください。

次に適用を確認します：DCが強力な証明書マッピングを適用していることを確認してください。これにより両方の手法が弱まります。最新の更新が適用されたDCでは、これがデフォルトです。CAのその他の露出については、ウェブ登録時のESC8を含めて、リスキーなAD CS設定を確認してください。これらはしばしばこの二つと共に現れます。

次の変更をどうやって見つけますか？

今後のESC9について：テンプレートフラグはActive Directoryにあり、これはそれへの変更がADオブジェクトの変更であることを意味します。 Netwrix Threat PreventionはADの変更をリアルタイムで監視しブロックできるため、テンプレートにCT_FLAG_NO_SECURITY_EXTENSIONを設定する人を効果が出る前に止められ、次の評価時には見つかりません。

今後のESC16について：設定はADではなくCAサーバーのレジストリにあるため、独自の監視が必要です。SIEMにデータを送るCAホストのレジストリ監査と、上記の定期的なチェックが含まれます。Netwrixは証明書ベースのログオンと発行を関連付け、SID拡張が欠落しているシナリオを検出するため、レジストリ変更が見逃されても設定の悪用が明らかになります。