Windows Kerberos の特権の昇格の脆弱性 CVE-2025-26647 とはどのような脆弱性か調査しました。 Active Directory の認証周りの脆弱性で CVSS v3 ベーススコアが 8.8 となかなかに危険な香りがするものの、ほとんど注目が集まっていない理由についても考えてみたいと思います。
対象読者
本稿は Active Directory、PKI、証明書認証あたりの技術や脆弱性がお好きな方向けの記事です。 当該脆弱性の情報が少ないので同好の士に情報共有したいというのが主な目的です。 専門用語や細かな手順などの解説は少なめで進行します🙇。
有用な攻撃手法となるかどうかだけ（あるいはエクスプロイトコードだけ）を知りたい方は、CVE-2025-26647 は無視してよいと思います。
ご自身の環境が影響を受けるかどうか、対策はどうすればよいかを知りたい方は、日本マイクロソフト社のブログに非常に詳しくまとまっていますのでそちらをご覧ください🙏。
CVE-2025-26647 とは
脆弱性発見者の情報など見当たらないため、まずは公式な情報源からどのような脆弱性なのか考えてみたいと思います。
- Microsoft Japan Windows Technology Support Blog: CVE-2025-26647 への対応とその影響について
- MSRC: Windows Kerberos Elevation of Privilege Vulnerability
- 日本語で表示すると誤訳があるため、ブラウザの言語設定を英語にしてアクセスすることをお勧めします
- Microsoft Support: Protections for CVE-2025-26647 (Kerberos Authentication)
- NVD: CVE-2025-26647 Detail
簡単にまとめてみます。
- Active Directory Domain Services (AD DS) の Kerberos 認証に関する特権昇格の脆弱性
- CVSS 評価上は攻撃が容易で影響は大きいが、悪用される可能性は低い
- Active Directory ユーザーアカウントに altSecurityIdentities 属性の設定がある場合に影響を受ける
altSecurityIdentities 属性とはなんぞや、と思われる方も多いかと思います。 詳しくお知りになりたい方は、やはり日本マイクロソフト社のブログが非常に詳しいのでそちらをご覧ください（ジャパンすごい💪）。
altSecurityIdentities はユーザーアカウントと証明書の紐付けに使われる属性で、セキュリティを高めるためのものです。 ここ数年で Active Directory の証明書認証が強化されており、アカウントへ証明書をマッピング（altSecurityIdentities 属性）するか、証明書へアカウント情報をマッピングすることが必須となっています。 しかしどうやら altSecurityIdentities 属性の設定があると CVE-2025-26647 の影響を受ける可能性があり、特権昇格が起こりうるということのようです。
さらに当該脆弱性の修正プログラム KB5057784 の説明を見ていくと、NTAuth ストアという用語が出てきます。 NTAuth ストアは、通常時 Windows が信頼する CA 証明書などが格納された OS の証明書ストアとは別の、証明書認証用の独立したストアです。 証明書認証で利用する証明書は、NTAuth ストアに入った CA 証明書の CA から発行されたクライアント証明書である必要がある、ということです。 OS の証明書ストアに入っている CA 証明書の CA が発行したクライアント証明書だからといって、証明書認証が通るようにはなりません。 もしも NTAuth ストアの仕組みがなければ、Windows がデフォルトで信頼している CA から発行されたクライアント証明書であれば、任意の Active Directory に対して証明書認証が出来るようになってしまう可能性があり危険です。
公式情報を読んだ方はお気づきになられましたでしょうか。 KB5057784 は NTAuth ストアの証明書チェーンをちゃんとチェックするようにしました〜という修正で、CVE-2025-26647 は altSecurityIdentities 属性を設定している場合は NTAuth ストアの証明書チェーンをチェックしてなかったんだよね〜、と書いてあるように読めます。前述した NTAuth ストアの仕組みがない危険な状態かもしれない、と。
PKI の嗜みのある方にとっては噴飯ものな話、、これは確かめずにはいられませんね!
検証
次の手順で検証を行いました。
- CVE-2025-26647 の修正プログラム KB5057784 が適用される前の Windows Server 2022 で AD DS を構築
- OpenSSL で PKI を 3 つ構築し、AD DS で次のように信頼
- ca1: OS の証明書ストアと NTAuth ストアで信頼する CA
- ca2: OS の証明書ストアでのみ信頼する CA
- ca3: 信頼されない CA
- ca1 でドメインコントローラー証明書を発行し、AD DS にインストール
- 証明書認証に必要な作業ですが、今回の検証では特に重要な意味はありません
- ドメインユーザーアカウントを作成
- user1 とします
- ca1 で user1 用のクライアント証明書を発行
- AD DS の user1 の altSecurityIdentities 属性に ca1 で発行したクライアント証明書の情報を設定
- ca2、ca3 で user1 の altSecurityIdentities 属性を模したクライアント証明書を発行
- ca1、ca2、ca3 で発行したクライアント証明書を使って、AD DS に証明書認証でログオンを試行
- KB5057784 を適用し、再度 8. を実行
手順の 7. が本検証の肝となる部分であり少し説明します。
例えば altSecurityIdentities 属性は X509SKI 形式で設定する方針で、ca1 のクライアント証明書の Subject Key Identifier（SKI）が 8300551F715CE58581CF06636FC8DF64B4EB1276 であるとします。
この場合、user1 の altSecurityIdentities 属性は X509:<SKI>8300551F715CE58581CF06636FC8DF64B4EB1276 と設定します。
そして ca2、ca3 で user1 のクライアント証明書を発行する際に、SKI を 8300551F715CE58581CF06636FC8DF64B4EB1276 にします。
SKI は通常公開鍵から算出されますが、OpenSSL で任意の値を設定したり、自作したプログラムで任意の値を設定したりすることが可能です。
CVSS 評価上は攻撃が容易と評価されているのは、本当にこれだけでよいからでしょう。
altSecurityIdentities 属性の値はドメインユーザーの資格情報さえあればネットワーク経由で簡単に列挙することが出来ます。
OpenSSL では任意の値の設定が難しい属性は、生成 AI に指示することで簡単にプログラムを作成できました。
検証結果
X509SKI 形式で altSecurityIdentities 属性を設定した場合の検証結果は次の通りです。 予想通り、KB5057784 適用前は NTAuth ストアの信頼の無い ca2 のクライアント証明書でも証明書認証が成功してしまいました。
| PKI | OS の証明書ストア | NTAuth ストア | KB5057784 適用前 | KB5057784 適用後 |
|---|---|---|---|---|
| ca1 | 信頼 | 信頼 | 認証成功 | 認証成功 |
| ca2 | 信頼 | 非信頼 | 認証成功 | 認証失敗 |
| ca3 | 非信頼 | 非信頼 | 認証失敗 | 認証失敗 |
X509SKI 以外の形式
X509IssuerSerialNumber 形式でも試行してみました。 altSecurityIdentities 属性に設定する値としては次の 2 つの情報を ca1 に合わせる必要があります。
- クライアント証明書の発行者
- クライアント証明書のシリアル番号
シリアル番号は単に真似るとして、ca2 のクライアント証明書の発行者が ca1 であったとするような証明書を発行することになります。 試行錯誤してみましたが、KB5057784 適用前でも ca2 で偽装した証明書では認証に失敗しました。 ca2 と ca1 の発行者名が本当に同一であれば認証を通せるかもしれませんが、現実的なシナリオでは考えにくいためここまでとしました。
他に影響を受ける可能性のあるマッピング形式として、次の 3 つが挙げられています。未検証ですが簡単に考察してみます。
- X509SHA1PublicKey: 公開鍵の偽装が必要になり、さすがに通らないと思われます
- X509IssuerSubject: X509IssuerSerialNumber と同様に発行者名の偽装が必要であり、現実的には難しいと思われます
- X509SubjectOnly: 偽装により攻撃可能と思われます
マッピング方式としては他に X509RFC822 がありますが、現在サポートされない形式であるため除外されていると思われます。 CertificateMappingMethods というレジストリ設定の仕様からそのように推測しました。
まとめと考察
この脆弱性の発見者が私ではなかったことが残念ですが、めでたく噴飯できましたので満足です🍚。少し妄想しておわりにします。
まず、なぜこのような脆弱性が作り込まれてしまったのか。 開発者の認識不足はもちろんあったでしょうが、altSecurityIdentities 属性を設定している場合は NTAuth ストアのチェックをスキップするようにした方がパフォーマンス的に有利である、という判断があったのではないかと推測します。 しかし、証明書認証時の検証処理で、最初から OS の証明書ストアは使用せずに NTAuth ストアのみ使用してチェックするようにしておけば、このような脆弱性を生み出すこともパフォーマンス問題を気にすることもなかったのではないかと思えてしまいました。 何か理由があるのかもしれませんが、AD DS 開発の歴史的経緯でそうなっているだけ、くらいしか思い浮かびません。なぞです。
次に、なぜこの脆弱性はあまり注目されていないのか。 NTAuth ストアの検証がバイパスされてしまうのは確かに危険ですが、公式情報で悪用される可能性は低いと評価されている通り、条件が非常に限定的であるためだと思われます。 Windows OS の証明書ストアでデフォルトで信頼されている CA もしくは組織内で運用されているプライベート CA から、任意のクライアント証明書を発行できるくらいの前提条件をクリアしなければならないでしょう。 また、Active Directory 証明書サービス（AD CS）を使うことで AD が証明書認証に対応しており証明書認証にまつわる脆弱性の影響を受けてしまっていたということはよくあることかもしれませんが、本格的な PKI と証明書認証を運用している組織でもなければ altSecurityIdentities 属性を設定していることも少ないでしょう。 逆説的に本脆弱性の影響を受ける組織には非常に高度なセキュリティを求められる理由があり、攻撃者にとっても高いハードルを乗り越えてでも攻撃する価値がある組織である可能性があるということかもしれません。
さいごに、altSecurityIdentities 属性は悪者ではありません。 今回は運悪く引き金になってしまいましたが、適切に運用されていればセキュリティを高めるための有用な仕組みです。 では👋