偽サポート通話から AD CS の証明書で特権を得る（ESC1・ESC8）：パスワード変更では証明書は失効しない

Teams の偽サポート通話で遠隔操作を許させた後、証明書サービス AD CS の設定不備から特権アカウントの証明書を取る侵入が 2 件報告された。証明書と Kerberos チケットはパスワード変更や端末の再構築では無効にならないので、片付けでは別々に失効・確認する。

入口は Teams の脆弱性ではなく、Quick Assist の接続を利用者に承認させる手口。その後、持ち込みのポータブル Python・Bun・Java などでコードを動かした。
1 件目（ESC1）: 登録権限が広く、申請者が名義（SAN）を自由に指定できる認証用テンプレートを悪用し、特権アカウント 3 つ分の証明書を取得。約 90 分後の再侵入でさらに 8 つ分を取り、証明書で DC に認証して DCSync（認証情報の複製）を開始。Defender の自動封じ込めから除外されていた特権アカウントが残り、Rclone による持ち出しにも使われた。
2 件目（ESC8）: PetitPotam で DC に攻撃者側へ認証させ、その NTLM 認証を AD CS の Web 登録へ中継。DC のパスワードを知らずに DC 名義の証明書を得て、PKINIT で DC の TGT を取った。

テンプレートの点検: クライアント認証に使えるテンプレートで「要求で名義を指定する（Supply in the request）」が有効なものを洗い出し、登録権限を必要なグループに絞るか無効化する。承認（マネージャー承認）を必須にするのも手。
Web 登録のリレー対策: AD CS の Web 登録（certsrv）と CES を使わないなら止める。使うなら HTTPS のみにし、認証の拡張保護（EPA）を有効にして NTLM 中継を防ぐ。
遠隔操作ツールの制限: Quick Assist など業務で使わない遠隔操作ツールをアプリ制御で止める。
侵害後の片付けは 3 つを別々に:
- 不正に発行された証明書を CA で失効させる（発行ログから、申請者と名義が食い違う発行を探す）。
- 発行済みの Kerberos チケットを無効化する（対象アカウントのパスワードを 2 回変更、DC 名義なら krbtgt のリセットも検討）。
- 自動封じ込めの除外リストに特権アカウントが入っていないか確認する。
検知: 申請者と証明書の名義（SAN）が違う発行、DC 以外からの DC 名義の PKINIT、DC への想定外の NTLM 認証を監視する。