オンプレADと証明書基盤（AD CS）を全社PKI（公開鍵基盤）として運用し、年次の内部監査対象になっているような数千人規模の企業のAD/PKI管理者が、今もっとも急いで確認すべき脆弱性が公開された。Active Directory Certificate Services（AD CS、Windows Serverの証明書発行機能）の証明書発行処理を悪用し、低権限のドメインアカウントからドメインコントローラ（DC）になりすませる「Certighost」（CVE-2026-54121）である。Microsoftは2026年7月14日にパッチを配布し、その10日後の7月24日には研究者による技術詳細とPoC（概念実証コード）がGitHubで公開された[1][3]。CVSSスコアは8.8（CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H）で、Windows Server 2012からWindows Server 2025まで、Server Coreを含むAD CSの役割を持つ幅広いバージョンが対象になる[2][4]。本稿では、Certighostがなぜドメイン全体侵害に直結するのかを整理したうえで、証明書テンプレートの棚卸しとパッチ適用の優先順位づけをどう判断すべきかを示す。
予備知識
- AD CS（Active Directory Certificate Services）: Windows Serverの機能の一つで、社内向けの電子証明書を発行・管理するしくみ
- 証明書テンプレート: どんな用途・権限の証明書を誰が申請できるかを定義する設定。既定の「Machine」テンプレートも対象になる
- ドメインコントローラ（DC）: Active Directoryの認証・ディレクトリ情報を管理するサーバー。乗っ取られるとドメイン全体が危険にさらされる
- PKI（公開鍵基盤）: 証明書を使って通信や認証の正当性を保証する仕組み全体。AD CSはPKIの中核部品にあたる
Certighostが突いた証明書発行処理の全体像を、CAの設計・運用・移行という実務目線で体系的に押さえられる
Certighost（CVE-2026-54121）はAD CSの何を突く脆弱性か
Certighostは、AD CSの証明書発行処理にある「chase（追跡）」という補助機能を悪用し、ドメインコントローラになりすまして証明書を取得できる権限昇格の脆弱性である。証明書要求元の情報をディレクトリから直接解決できない場合、CA（証明機関）はchaseと呼ばれる補助的な問い合わせ処理に切り替わる[2][3]。この際、要求に含まれるcdc（照会先ホスト）とrmd（照会対象）という属性を使って、指定されたホストへSMBとLDAPで直接問い合わせに行く[3]。Microsoftの説明では、このchaseへのフォールバックが起きるのはDNS名を要求するテンプレートに限られ、かつCA側でEDITF_ENABLECHASECLIENTDCフラグが有効になっている場合だけである[2]。攻撃者は既定で許可されているマシンアカウント作成の権限（ms-DS-MachineAccountQuota）を使って自分のアカウントを用意し、cdcに自分で立てた不正なホストを指定する。CAがそのホストに問い合わせると、攻撃者はドメインコントローラのobjectSIDやdNSHostNameを装った偽の応答を返し、CAはその偽装データをそのまま証明書発行に使ってしまう[1][3]。
| 項目 | パッチ適用前 | パッチ適用後 |
|---|---|---|
| cdcホストの検証 | なし（応答をそのまま信頼） | 実ディレクトリと突合検証[3] |
| 必要な攻撃者権限 | 通常のドメインアカウントのみ | 変更なし（検証強化で悪用不可）[1] |
| 到達しうる結果 | DC証明書取得→DCSync→krbtgt窃取 | chase継続前に拒否 |
証明書がなぜ信頼の要になるのかをPKIの基礎理論から押さえられ、テンプレート棚卸しの判断軸を補強できる
PoC公開後、パッチ未適用のAD CSはどれだけ危険か
PoCの公開は、専門知識がなくてもツールを実行するだけで攻撃手順を再現できる状態を意味する。ただし「AD CSを動かしていれば即座に危ない」わけではない。Microsoftは悪用が成立するための環境条件を明示しており、次の5つがすべて同時に成り立つ場合に限られる[2]。
| 条件 | 内容 |
|---|---|
| CAの種類 | Active Directoryに統合されたEnterprise CAであること |
| 登録経路 | マシン証明書テンプレート経由で発行していること |
| アカウント作成 | ms-DS-MachineAccountQuotaが既定値のまま、または攻撃者が既にマシンアカウントを支配していること |
| ネットワーク | CAと攻撃者ホストの間でSMBとLDAPが到達できること |
| 権限 | 有効なドメインアカウントを1つ持っていること（管理者権限は不要） |
加えて前述のとおり、chaseへのフォールバック自体がDNS名を要求するテンプレートとEDITF_ENABLECHASECLIENTDC有効という2条件に縛られる[2]。自社の露出度を測る最短経路は、CVSS値を眺めることではなく、この6項目を1つずつ潰していくことである。裏を返せば、条件が1つでも外れていれば優先度は下げられる。
時系列は次のとおりである。研究者は2026年5月14日にMicrosoftへ報告し、Microsoftは5月22日に脆弱性を確認、7月14日の月例更新でパッチを提供した[3][4]。そのわずか10日後の7月24日、研究者は攻撃手法の技術詳細とPythonベースのPoCスクリプトをGitHubで公開した[1][2][3]。Microsoft自身も7月28日に公式アカウントで注意喚起し、7月31日には検知ガイダンスを公開している[2][5]。2026年7月時点で確認された脅威アクターによる悪用は観測されておらず、観測された活動はセキュリティ検証と一致すると説明されている[2]。
Microsoft released security updates on July 14, 2026, to address CVE-2026-54121 (Certighost), an elevation-of-privilege vulnerability in Active Directory Certificate Services (AD CS). An authenticated, low-privileged attacker with network access could manipulate certificate
— Microsoft Threat Intelligence (@MsftSecIntel) 元投稿を見る
CVSS 3.1で8.8という評価は、ネットワーク経由で到達可能、要求される権限は低く、ユーザー操作も不要という条件がそろっていることを示す[4]。攻撃に必要なのは、メールや共有フォルダにログインできる程度の一般社員アカウントと、CAへのネットワーク到達性だけである[1][2]。
今回取り上げるのはAD FS（Active Directory Federation Services、Windows Server上でSSO・フェデレーション認証を提供する機能）のDKM（Distributed Key Manager）[…]
証明書テンプレートの棚卸しでは何を確認すべきか
証明書テンプレートの棚卸しとは、どのCAがどのテンプレートを誰に対して発行しているかを、Certighostの悪用条件に照らして再確認する作業である。確認すべきは、Enterprise CAの一覧化、EDITF_ENABLECHASECLIENTDCフラグの設定状況、既定のMachineテンプレートが広い範囲に発行対象を許していないか、ms-DS-MachineAccountQuotaが既定値のまま放置されていないか、7月のセキュリティ更新が全CAサーバーへ適用済みか、そして証明書の発行記録が監査ログに残る設定になっているかである[2][3]。
最後の1点は見落とされやすい。AD CSの証明書サービス監査は既定で無効になっており、有効化しなければ発行の記録そのものが残らない[2]。有効化には2つの設定が要る。Advanced Audit Policyで「Certification Services」の成功・失敗を有効にする（auditpol /set /subcategory:"Certification Services" /success:enable /failure:enable）操作と、CA側の監査フィルタ設定（certutil -setreg CA\AuditFilter 127 の後にCertSvcを再起動）である[2]。両方を入れると、証明書要求の受領がイベント4886、承認と発行が4887として記録される[2]。低権限の主体がマシンテンプレート経由でドメインコントローラの識別情報を持つ証明書を受け取る、という通常なら起こり得ない発行パターンは、この記録があってはじめて追える。なおAD CSサーバーにMicrosoft Defender for Identityのセンサーを配置済みで所定の構成を終えている場合は、前提条件として監査設定が有効化されているため、この手順は省ける[2]。
| 確認区分 | 確認内容 | 目安の対応期限 |
|---|---|---|
| CA本体 | Enterprise CA役割を持つ全サーバーへの7月更新適用 | 即時 |
| CA設定 | EDITF_ENABLECHASECLIENTDCフラグの有効・無効の確認 | 即時 |
| テンプレート | DNS名を要求するテンプレートと既定Machineテンプレートの発行対象範囲の見直し | 1週間以内 |
| アカウント設定 | ms-DS-MachineAccountQuotaの既定値見直し | 2週間以内 |
| ログ監視 | 証明書サービス監査の有効化とイベント4886/4887の監視 | 2週間以内 |
2030年はRSA-2048とECC P-256が暗号標準から廃止される年だ。NIST（米国国立標準技術研究所）はNIST IR 8547で、2030年を境にRSA-2048・ECC P-256・Diffie-Hellman 204[…]
パッチ適用の優先順位はどう決めるべきか
パッチ適用の優先順位は、AD CSの役割を持つサーバーの種類と、そのCAが発行する証明書の用途によって決まる。最優先は、Active Directoryに統合されたEnterprise CAでMachineテンプレートを介した自動登録を許可し、かつEDITF_ENABLECHASECLIENTDCが有効になっているサーバーである[2]。悪用条件にAD統合のEnterprise CAが含まれるため、ADに統合していないスタンドアロンCAはこの攻撃経路の対象から外れる[2]。ただしMicrosoftはAD CS環境全体への更新適用を推奨しており、対象外だから当てなくてよいという意味ではない[2]。影響範囲はWindows Server 2012からWindows Server 2025まで、Server Core構成も含む幅広いバージョンに及ぶため、古いOSだから対象外という判断はできない点にも注意したい[2][4]。
数千人規模でEntra ID（旧Azure AD）とオンプレADを併用し、年次の内部監査があるような日本企業のID基盤担当者は、SMSや音声通話によるMFA（多要素認証）を、まだ主要な認証手段として使い続けている場合が多い。Micr[…]
オンプレAD運用の企業でCertighostの点検が遅れやすいのはなぜか
AD CSはオンプレADを社内PKI基盤として使う日本企業でも広く使われており、Certighostの悪用条件そのものは海外企業と変わらない。違うのは点検からパッチ適用までの速度である。SIer保守契約が「依頼された作業のみ実施」という範囲になっている場合、緊急パッチであっても追加の見積もりと発注承認を経なければ着手できないことがある。監査・内部統制の対象システムでは、変更のたびに事前の変更管理申請と承認記録が求められ、通常の変更管理フローに乗せると数週間かかるのも珍しくない。加えてAD CSを専任で見る担当者は少なく、ネットワークやID管理と兼務しているケースが多いため、緊急度の判断自体が後回しになりやすい。
| 観点 | 一般的な想定対応 | 日本企業で起きやすい傾向 |
|---|---|---|
| パッチ適用までの日数 | 検証後、数日で反映 | 稟議・変更管理を経て数週間かかることがある |
| 保守体制 | 内製チームが直接パッチ適用 | SIer保守契約の範囲外作業として追加調整が必要な場合がある |
| 監査対応 | 事後報告が中心 | 変更前の証跡・承認が必須になりやすい |
もう一点、日本の内部統制運用と噛み合わない事実がある。前述のとおりAD CSの証明書サービス監査は既定で無効で、有効化していなければ証明書の発行記録そのものが残らない[2]。全社PKIを内部統制の対象システムとして扱い、年次監査で「誰にどの証明書が発行されたか」を説明する建て付けにしている場合、この設定は要件と矛盾する。今回のパッチ適用を機に監査を有効化すれば、Certighostの検知手段が手に入るだけでなく、監査側の指摘を先回りして潰せる。緊急パッチの稟議に監査設定の変更を相乗りさせられるかどうかが、実務上の分かれ目になる。
IT部門の判断としては、CVSS8.8かつPoC公開済みという条件を整理し、通常の月次パッチサイクルとは別枠の緊急変更として申請すべきである。あわせて証明書サービス監査の有効化を同じ変更票に載せておきたい。決裁側の判断としては、保守契約の範囲外費用が発生する場合でも、この1〜2週間以内に追加発注の可否を決めておく必要がある。
まとめ
IT部門担当者の次の一手は、全Enterprise CAサーバーへの7月パッチ適用状況を今週中に洗い出し、未適用があれば緊急変更として申請することである。決裁側の判断材料は、CVSS8.8・PoC公開済みという条件が通常の月次パッチサイクルを待てない案件に該当し、SIer保守契約の範囲外費用が生じてもこの1〜2週間で承認すべきという点にある。証明書基盤は一度信頼を奪われるとドメイン全体に波及するだけに、テンプレートの棚卸しを一過性の対応で終わらせず、定期点検の項目に組み込む価値がある。
よくある質問（FAQ）
Q1. Certighostは自社が影響を受けるかどう確認すればいいですか？
AD CSの役割をインストールしているサーバーがあるかをまず確認し、そのうえで本文に挙げた5つの環境条件（AD統合のEnterprise CA、マシン証明書テンプレート経由の登録、ms-DS-MachineAccountQuotaの既定値、CAと攻撃者ホスト間のSMB/LDAP到達性、有効なドメインアカウント）がすべてそろうかを見る[2]。Windows Server 2012から2025まで幅広いバージョンが対象になるため、OSのバージョンだけで対象外と判断しないことが重要である[2][4]。
Q2. パッチを当てれば設定変更は不要ですか？
いいえ。パッチはCAが問い合わせ先を検証してから接続するようにするものであり、既定のMachineテンプレートやms-DS-MachineAccountQuotaの設定自体は変わらない[2]。テンプレートの棚卸しはパッチ適用とは別に必要である[3]。
Q3. 悪用の兆候はどこで確認できますか？
Microsoft Defender for Identityに「Potential Certighost (CVE-2026-54121) AD CS abuse」というアラートが用意されており、悪用に使われる異常な発行パターンを検知する[2]。ただし前提として、AD CSサーバー側で証明書サービス監査を有効にし、イベント4886/4887が記録される状態にしておく必要がある[2]。
出典
[1] Help Net Security, “PoC exploit released for critical AD CS domain-takeover flaw (CVE-2026-54121)” (2026-07-27) https://www.helpnetsecurity.com/2026/07/27/certighost-cve-2026-54121-poc-exploit-released/[2] Microsoft Tech Community, “Detecting CVE-2026-54121 (Certighost) with Microsoft Defender” https://techcommunity.microsoft.com/blog/microsoftthreatprotectionblog/detecting-cve-2026-54121-certighost-with-microsoft-defender/4542861
[3] H0j3n, “CVE-2026-54121 (Certighost) Technical Analysis” (GitHub Gist) https://gist.github.com/H0j3n/a5ef2609b5f2944ac2390a191a534c26
[4] NVD, “CVE-2026-54121″（CVSS 8.8 / CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H、対象CPE） https://nvd.nist.gov/vuln/detail/CVE-2026-54121
[5] Microsoft Threat Intelligence（@MsftSecIntel）X投稿（2026-07-28） https://x.com/MsftSecIntel/status/2081902547728515535
