Certighost(CVE-2026-54121): AD CSの脆弱性で低権限ユーザーがDomain Controllerになりすまし — PoC公開済み

マレーシアの研究者H0j3n氏とAniq Fakhrul氏は2026年7月24日、Active Directory Certificate Services(AD CS)のエンロールメントフォールバック機構「chase」に存在する脆弱性CVE-2026-54121について、動作するPoCと詳細な技術解説を公開しました。研究者らはこの脆弱性をCertighostと呼んでおり、検証環境では通常のDomain Usersグループのアカウントを起点として、Domain Controllerの身分を持つ証明書をCAから取得し、最終的にDCSyncでkrbtgtアカウントのNTハッシュやKerberos鍵素材を含むアカウントシークレットを取得できることを実証しています。

Microsoftは2026年7月14日のPatch Tuesdayで既に修正パッチを配布済みで、CVSS 3.1の基本値は8.8(High)、深刻度はCriticalに分類しています。Microsoft CNAの影響製品一覧には、Windows Server 2012/2012 R2からWindows Server 2025までの各サーバ製品と、一部のWindows 10が含まれています。ただし、Certighostの実際の攻撃経路はEnterprise CAとして動作するAD CSサーバを対象とし、パッチ未適用のCAでは低権限のドメインユーザーから対象ドメインの全面的な侵害へ至る可能性があります。

AD CSとPKINITを支える証明書の身分証機能

Active Directory Certificate ServicesはMicrosoftが提供する社内公開鍵基盤(PKI)で、Enterprise CAを立てることでドメイン内のユーザー、コンピュータ、サービスに対してX.509証明書を発行できます。発行された証明書は暗号通信のTLS、電子メール署名、コード署名など多用途に使えますが、Active Directory環境で特に重要な用途は証明書ベースのKerberos認証、いわゆるPKINITです。

PKINITはRFC 4556で定義されるKerberosの拡張で、パスワードの代わりに秘密鍵と証明書を使ってKey Distribution Center(KDC)に対する事前認証(pre-authentication)を行う仕組みです。PKINITで認証されたユーザーは通常のKerberos TGTを受け取り、その後は通常のKerberosと同じ手順でサービスチケットを要求できます。証明書のSubject Alternative NameやuserPrincipalName拡張に埋め込まれた識別情報が、KerberosのプリンシパルにマッピングされるためのIDカードとして機能します。

この仕組みは、Enterprise CAが正しい相手にしか正しい証明書を発行しない、という前提の上に成立します。もしCAが「本来は発行してはならない相手に、他人の身分を主張できる証明書」を発行してしまえば、その他人としてPKINIT認証が通り、Kerberosの信頼モデル全体がその一点から崩れます。Certighostが問題化しているのは、まさにこの前提を破る経路が、AD CSのエンロールメントフォールバックに残っていたという点です。

脆弱性の中核 — enrollment fallbackのchaseパスが持つ信頼の問題

Windowsのエンロールメントプロトコル(MS-WCCE)には、CAが証明書要求を処理する途中で、要求元エンドエンティティの情報をActive Directoryから解決できなかった場合のフォールバック経路が定義されています。研究者らがchaseと呼んでいるこの経路では、要求側がcdcとrmdという2つのリクエスト属性を提供できます。cdcはCAが問い合わせるホストを、rmdはリモート検索の対象となるプリンシパルを指定します。今回のPoCでは、rmdによる検索対象としてDomain Controllerのコンピュータオブジェクトが利用されています。

本来ならCAはcdcで指定されたホストが本物のDomain Controllerかを検証したうえで問い合わせるべきですが、パッチ前のAD CSは検証をせずにcdcのホストへSMBとLDAPで接続し、そこから返ってくるマシンオブジェクトの情報を信頼していました。CAが検証せずに受け入れる情報の中には、対象マシンのobjectSidとdNSHostNameという、その後の証明書発行で身分証に埋め込まれる決定的な属性が含まれています。

この結果、CAは自分がどのDomain Controllerと話しているかを確認せずに、要求側が用意したホストの言うことを受け入れて証明書を発行してしまう構造になっていました。信頼すべきレスポンダの検証を、リクエスト属性で名前指定された任意のホストに委ねてしまう設計の欠陥で、CWE-285(Improper Authorization)に分類される所以です。

攻撃者が組み立てる攻撃チェーンの概要

研究者らが公開した攻撃チェーンは、あくまで検証環境で組み立てた概念実証です。検証環境では、Windows Server 2016以降のフォレスト機能レベル、Enterprise CA、既定のMachine証明書テンプレートとACL、ms-DS-MachineAccountQuota=10が使用されました。実環境では、証明書テンプレートの権限やMachineAccountQuotaの設定が異なる可能性があるため、自組織が同じ条件を満たすかを個別に確認する必要があります。

攻撃者はまず、デフォルトのmachine-account quotaを利用して自分の管理下にあるコンピュータアカウントを1台作成します。次に、攻撃者ホスト上で偽装したLocal Security Authority(LSA)サービスとLDAPサービスを稼働させ、CAが接続してきたSMBとLDAPの問い合わせに応答できる態勢を整えます。CAが要求属性cdcを信頼して攻撃者ホストに接続してきた際、途中で発生する認証チャレンジは、Netlogon経由で本物のDomain Controllerへリレーされます。

攻撃者ホストは、本物のDCからのレスポンスを利用してCAの認証チェックを通過しつつ、CAに返す情報として攻撃対象となるDomain ControllerのobjectSidとdNSHostNameを返します。制御下のマシンアカウントが有効なドメインプリンシパルとして認証を通過する役割を担い、CAは攻撃者ホストから返された標的DCのobjectSidとdNSHostNameを証明書の識別情報へ反映して発行します。攻撃者はこの証明書と対応する秘密鍵を使ってPKINITを実行し、標的DCとしてのKerberos資格情報キャッシュを取得します。

DCなりすましからDCSyncによるドメイン侵害まで

攻撃者が手にしたのは、対象Domain Controllerのコンピュータアカウントとして認証するために使える証明書と、対応する秘密鍵です。ここからPKINIT経由でKDCに対する事前認証を行い、対象DCとしてのKerberos TGTを取得します。この段階で攻撃者は、実質的にそのDomain Controllerを名乗るKerberosセッションを保持していることになります。

Domain Controllerのコンピュータアカウントには、Active Directoryのdirectory replication権限が付与されています。この権限を持つプリンシパルは、ドメイン内の任意のオブジェクトに対してDCSync操作を実行でき、実質的には他のDCと同じレプリケーションプロトコルを使って、認証データベースに含まれるアカウントシークレットを要求できます。研究者らは最終的にDCSyncを実行し、krbtgtアカウントのNTハッシュやKerberos鍵素材を含むアカウントシークレットを取得できることを実証しています。

krbtgtの鍵素材を取得すると、攻撃者は任意のユーザーや権限を設定したKerberos TGT、いわゆるGolden Ticketを偽造できます。そのTGTをKDCへ提示することで、ドメイン内の各サービスに対するTGSを取得できるようになります。krbtgtアカウントのパスワードを適切な間隔で2回リセットし、既存の偽造チケットを失効させるまで、永続的なアクセスに悪用される可能性があります。低権限ドメインユーザーから始まった攻撃チェーンが、AD CSのchaseパスという1点の欠陥を経由して、対象ドメインの侵害と長期的なアクセス確保へつながる構造です。

Microsoftのパッチが加えた検証ロジック

Microsoftが2026年7月14日にリリースした修正では、AD CSのポリシーモジュールを実装するcertpdef.dllに、CRequestInstance::_ValidateChaseTargetIsDCという新しい検証関数が追加されました。研究者らのバイナリ解析によれば、この関数はcdcで指定されたホスト名に対して段階的な検証を実施し、パッチ前の無条件信頼を明示的な確認プロセスに置き換えます。

具体的な検証内容としては、まずIPリテラルの直接指定を拒否します。次に、過度に長い名前や、LDAPメタキャラクタを含む名前を拒否することで、注入経路の閉塞を狙います。さらに、Active Directory上でcdcのホスト名に厳密に1件だけマッチするコンピュータオブジェクトが存在すること、そのオブジェクトのDNS名がターゲットと一致すること、userAccountControl属性にSERVER_TRUST_ACCOUNTフラグ(値8192)が立っていることを確認します。SERVER_TRUST_ACCOUNTはDomain Controller固有のフラグで、通常のマシンアカウントには立ちません。

加えて、後段の処理でSIDの一致比較が行われるため、たとえ他のチェックを何らかの方法ですり抜けたとしても、最終的にオブジェクト置換によるなりすましが阻止される多層構造になっています。パッチ前には存在しなかった複数の検証処理が追加され、ホスト名の形式、DCオブジェクトの存在、SERVER_TRUST_ACCOUNT、SIDの一致などを確認する多層的な検証へ変更されました。なお研究者の解析では、この検証処理はWindowsの機能制御フラグ(servicing feature gate、Feature_3185813818)によって制御されていました。通常の運用ではMicrosoftの更新を適用し、更新状態と再起動の完了を確認することが重要です。

影響を受けるWindowsとパッチ適用

研究者が実際にPoCを検証したのはWindows Server 2016以降のフォレスト機能レベルを使用する環境ですが、Microsoft CNAとNVDは、Windows Server 2012/2012 R2からWindows Server 2025までの各製品と、Windows 10の一部バージョンを影響対象として列挙しています。具体的にはWindows Server 2012、Windows Server 2012 R2、Windows Server 2016、Windows Server 2019、Windows Server 2022、Windows Server 2025のそれぞれのServer Coreインストールを含む構成に加え、Windows 10のバージョン1607と1809が対象に含まれます。

ただし現実的なリスクの中心はEnterprise CAが稼働しているホストです。AD CSはWindows Serverの標準ロールとして提供されており、Enterprise CAはドメインコントローラとは別のメンバサーバ上に構成されている場合もあります。Enterprise CAが稼働し、既定のMachine証明書テンプレートとACL、MachineAccountQuotaなどが研究者の検証条件と一致する環境では、パッチ未適用のchase経路が悪用される可能性があります。まずはCAサーバに2026年7月14日のセキュリティ更新プログラムを適用することが最優先の対処となります。

2026年7月のPatch Tuesdayには、Active Directory Federation Services(CVE-2026-56155)の実悪用中の脆弱性や、Active Directory Domain ServicesのRCE(CVE-2026-49164)、SharePoint、Exchange、Print Spoolerなど、企業インフラの中核に関わる多数の脆弱性が含まれています。Certighostへの対処と併せて、7月分の更新をドメインコントローラ、証明書サーバ、フェデレーションサーバに漏れなく適用する運用が求められます。

パッチ即時適用が困難な場合の一時的緩和策

研究者らはPoCと合わせて、パッチを即時に適用できない環境向けの一時的な緩和策も文書化しています。CAサーバ上で以下の2コマンドを実行し、chaseフォールバックを無効化する方法です。

certutil -setreg policy\EditFlags -EDITF_ENABLECHASECLIENTDC
Restart-Service CertSvc -Force

これはCAのポリシー設定からchaseフラグをクリアし、Certificate Servicesを再起動して反映させる操作です。ただしこの緩和策は、chase経路そのものを利用する正規のエンロールメントフローが動作しなくなる可能性を伴います。研究者らは検証室環境でのみ動作確認をしており、本番環境への適用前にステージング環境での事前検証を強く推奨しています。Microsoftが提供する7月14日のセキュリティ更新プログラムこそが恒久的な修正である以上、緩和策はあくまでパッチ適用までの時間稼ぎと位置づけるのが妥当です。

加えて、Active Directoryドメインのms-DS-MachineAccountQuotaを既定値の10から0へ変更し、一般ユーザーが新しいコンピュータアカウントを作成できないようにすることも補助的な対策になります。MachineAccountQuotaはドメイン内で通常ユーザーがコンピュータアカウントを作成できる上限を定めるActive Directory属性で、ドメインオブジェクトに設定されるものです。ただし、既存のマシンアカウントを利用できる攻撃者や、コンピュータアカウントの作成権限を別途持つユーザーには効果がないため、パッチの代替にはなりません。Microsoft Defender for Identityのセキュリティ態勢評価でも、ms-DS-MachineAccountQuotaを0に設定することが推奨されています。

開示タイムラインと運用上の教訓

Certighostの開示タイムラインは、研究者らが2026年5月14日にMicrosoftへ報告し、Microsoftが5月22日にバグを確認、7月14日に月例更新でパッチを配布、7月24日に研究者らが公開開示、という約2か月半のCoordinated Vulnerability Disclosure(CVD)の形で進められました。パッチ公開から技術情報とPoCの公開までには10日間の間隔がありました。

一方で、公開開示から動作するPoCまでのタイムラグはほぼゼロで、GitHub上に完全なPoCが同時公開されている状況です。2026年7月25日時点ではCISA KEVに登録されておらず、NVDに掲載されたCISAのSSVC評価でも実悪用状況はnoneとされていますが、動作するPoCが公開されたことで、第三者による検証や悪用コードへの転用が容易になる可能性を考慮し、運用側は速やかに対応する必要があります。

今回のCertighostは、AD CSがドメイン侵害の起点になり得るという2021年以降のCertifried(CVE-2022-26923)やESC1-ESC8シリーズと連なる文脈上にあり、AD CSを「単なる証明書発行サービス」ではなく「ドメイン識別の裏側を握る特権コンポーネント」として扱う視点の重要性を改めて示す事例です。証明書テンプレートの棚卸し、EDITF系のCA設定監査、machine-account quotaの見直し、そしてCA監査ログの中央集約は、Certighost単体への対処を超えて、AD CS運用全体の衛生を保つための継続タスクです。検知ルールを整備する場合は、CAの証明書要求・発行監査ログを中央へ集約し、低権限ユーザーが作成したマシンアカウントからの証明書要求、短時間に連続するMachineテンプレートの要求、Domain ControllerのSIDやDNS名を含む不審な証明書発行が記録されていないかを確認します。ただし、研究者は特定のイベントIDや確立済みの検知ルールを公開していないため、環境ごとの検証が必要です。

一次情報・公式情報

Microsoft Security Response Center: CVE-2026-54121 Active Directory Certificate Services Elevation of Privilege Vulnerability
NVD – CVE-2026-54121
Certighost (CVE-2026-54121) – Technical write-up by H0j3n
MS-WCCE: Windows Client Certificate Enrollment Protocol Specification(Microsoft Learn)

参考情報

Certighost Exploit Lets Low-Privileged Active Directory Users Impersonate a Domain Controller(The Hacker News、2026年7月24日)
Certighost Active Directory CS Exploit Allows Low-Privileged Users to Compromise Domain(Cyber Security News)
July 2026 Patch Tuesday: Updates and Analysis(CrowdStrike)
Microsoft Patch Tuesday for July 2026 – Snort rules and prominent vulnerabilities(Cisco Talos)
The July 2026 Security Update Review(Zero Day Initiative)