Microsoft RAMPは証明書機関の境界で停止します

Microsoftは7月14日にCVE-2026-54121を修正しました。研究者のH0j3nとAniq Fakhrulは10日後に動作する概念実証を公開し、Certighostと名付けました。AD CSサーバーが7月の累積更新プログラムを適用していれば保護されています。6月のビルドのままなら、公開されたエクスプロイトコードにさらされています。

攻撃自体は短時間です。管理者権限のない標準ドメインユーザーが、自分が管理するマシンアカウントの属性を操作し、証明機関内の欠陥のあるフォールバックロジックをトリガーして、PKINIT経由でドメインコントローラーとして認証される署名済み証明書を受け取ります。そこから、DCSyncはkrbtgtハッシュとGolden Ticketsをフォレスト全体で偽造する能力をもたらします。これはActive Directoryと統合されたEnterprise CAと、コンピューターアカウントを作成または制御する能力を必要とし、デフォルトのマシンアカウント割り当て10はすべてのドメインユーザーに付与されます。

チェーンを開始したアカウントは、いかなる時点でも昇格権限を持っていませんでした。ここで重要なのはこの点であり、Microsoftのprivileged accessのロードマップは、この攻撃が回避する脅威モデルに基づいて構築されているからです。

RAMPの3つのイニシアチブグループ

Rapid Modernization Planは、特権アカウントを分離して管理し、それらを所有する人の認証情報の体験を改善し、管理者用ワークステーションを展開するよう指示します。その下には、多くのセキュリティチームが現在取り組んでいる具体的な内容があります：Privileged Identity Management (PIM)、緊急アクセスアカウント、影響度によるMicrosoft Entraロールの分類、管理者向けのMFAおよびパスワードレス、レガシー認証のブロック、そしてPrivileged Access Workstationsです。

ほとんどはMicrosoft Entra IDの作業です。RAMPがオンプレミスで求めるのは、別々の管理者アカウント、それを使用する人の専用ワークステーション、そして一意のローカル管理者パスワードに集約されます。CertighostはAD CSの欠陥です。これら3つのどれも影響しません。

RAMPには証明機関のイニシアチブは含まれていません。Microsoftは意図的にそう設定しており、ガイダンスにも別のPrivileged Access Management展開ドキュメントに基づいてそう記載されています。RAMPは環境内で誰が昇格アクセスを持っているかを示します。CAがどのIDを証明書に紐付けるかは別の問題です。

Certighostが最後ではありません

証明書発行の整合性は一つのカテゴリーであり、継続的に発生しています。既知の多くの手法は「Certified Pre-Owned」以降に文書化されたESC攻撃技術で、テンプレートやCAフラグにより権限のないユーザーが所有していないIDの証明書を要求できます。Certighostは異なる形態です。テンプレートの設定は関係ありません。欠陥は証明機関自身のリクエスト処理ロジックにあり、リクエストが実際にどのディレクトリオブジェクトを指しているかの解決方法にあります。

その区別は対応方法に重要です。標準的なアドバイスである証明書テンプレートの監査では、これを見つけられなかったでしょう。

顧客がこれについて誤解していること

ほとんどの顧客は、誰かが所有しているためAD CSは管理されていると考えています。証明書機関はPKIまたはインフラチームに所属し、Identityチームはそれが処理されていると想定し、別の報告ラインがコントロールとして見なされます。ESCのパスに対して設定を監査したか尋ねると、通常はそれを知らなかったという答えが返ってきます。

これを所有するチームは可用性で評価されます。発行は成功し、更新は失効せず、認証は途切れず、CAは彼らが責任を負うすべての指標で健全です。標準ユーザーが自分に権利のないアカウントの証明書を登録しても、すべての指標で健全なままであり、まさにそのため誰もそれを見つけられません。

ガバナンスには頼るものがありません

RAMPのコントロールは特権アカウントを中心に作動します。CertighostはCA自体がそれを作成する証明書を発行するまで、決して触れません。

PIMが制御する中間アカウントも、MFAが認証を要求する管理者認証もありません。権限昇格と報酬は証明機関のリクエスト処理内で単一のトランザクションとして行われ、攻撃者の開始アカウントは他の標準ドメインユーザーと同じ階層にそのまま留まります。ステージングステップを可能にするマシンアカウントの割り当てもRAMPイニシアチブではありません。

RAMPはMicrosoft Defender for Identity (MDI)を指しており、MDIは実際の証明書カバレッジを提供します。ポスチャー評価は既知の昇格経路に対するテンプレートとCA設定を評価し、CA自体をチェックする検査にはAD CSサーバー上のMDIセンサーが必要です。この技術にはリクエストパターンで発動する名前付き検出もあります。

どちらも価値があります。どちらも登録リクエストを拒否しません。ポスチャーアセスメントは定期的に読む構成レポートであり、検出はトランザクション完了時に届くアラートです。

そのため、セキュリティチームはRAMPを端から端まで完了し、適切に実行し、MDIを並行して運用しても、証明書要求を評価して拒否するコントロールがない場合があります。Privileged Access Managementのガバナンスと証明書機関の整合性は別々の問題です。RAMPはそのうちの一つを解決しており、完了した展開を両方のカバレッジと見なすことが、このロードマップの最も一般的な誤解だと私は考えます。

誰かがRAMPの作業を終えたと言ったら、最初の質問は証明書発行機関の所有者は誰かです。もし調べる必要があるなら、それが答えです。RAMPは正しいロードマップであり、完了したということは特権アカウントが管理されているということで、これは実際の進展であり無意味ではありません。ただ、標準ユーザーの証明書要求からそのようなアカウントを発行できるシステムについては何も言っていません。そのシステムを監視することが最低限です。次に欲しいのは、その要求を拒否できる何かです。

登録リクエストのブロック

Netwrix Threat Prevention（NTP）とNetwrix Threat Manager（NTM）は両面で機能します。監視側では、NTMはDefender for Identityを通じてRAMPが指摘する領域をカバーし、AD CSの誤用や証明書の悪用パターンをリアルタイムで検出します。

防止側がそれらを区別します。NTPは、ESC1からESC7の手法を含む既知のAD CS悪用パターンに対して登録要求を評価し、証明書が存在する前にブロックして、発行された記録を生成するのではなく阻止します。姿勢評価はテンプレートが間違っていることを示し、検出は要求が不正に見えたことを示しますが、強制は3つのうち唯一トランザクションを終了させるものです。

RAMPを実行してから、証明書機関を確認してください

RAMPに従ってください。求められる作業はやる価値のある作業です。AD CSサーバーにパッチを当て、滞在中にマシンアカウントの割り当て数をゼロに設定してください。

それから証明機関を確認してください。RAMPはそこに案内しません。 テンプレートを監査してください、そしてその下にあるより難しい質問をしてください：標準アカウントが権利のない身元を主張して登録要求を提出した場合、環境内でその要求を評価するものは何で、それを止めるか記録するだけですか？