RC4は、Kerberosが数十年にわたり認証トラフィックを保護するために使用してきたレガシー暗号化アルゴリズムです。 Active Directory （AD）環境。あなたの環境が準備できているかどうかに関わらず、それは間もなく変わります。
セキュリティ強化の一環として CVE-2026-20833マイクロソフトは、Kerberos認証におけるRC4暗号化の段階的な廃止を進めています。2026年4月のWindowsアップデートは、Kerberosキー配布センター（KDC）が暗黙のフォールバックとしてRC4を受け入れなくなる最初の段階となります。RC4の依存関係をマッピングしていない環境では、本番環境での認証失敗という最悪の形でその問題に直面することになります。
セキュリティコミュニティは、RC4暗号化が脆弱であることを以前から認識しています。問題は、それがまだ環境内のどこに潜んでいるのかを把握することです。RC4は暗号学的に時代遅れであり、攻撃対象領域も十分に文書化されており、レガシーシステムとの後方互換性のためだけに存続しています。RC4は、誰も想定していなかったほど長い間、Active Directory環境で使われ続けています。
このブログでは、RC4 の依存関係の検出が非常に難しい理由、見過ごされた場合のリスク、そして Silverfort セキュリティチームが、法執行機関による強制措置を受ける前に、問題を発見して修復するための可視性を提供します。
KerberosにおけるRC4が重大なセキュリティ上の欠陥である理由
RC4の非推奨がなぜ重要なのかを理解するには、 Kerberos認証の仕組みを簡単に復習しましょう。。 時 ユーザーまたはサービス アカウントが AD 環境で認証されると、Kerberos KDC はチケットを発行します。本質的には 特定の資源へのアクセスを許可する、暗号的に保護されたパス。そのチケットを保護するために使用された暗号化アルゴリズム 決定する 攻撃者にとってどれほど難しいか クラック ボーマンは
ここでRC4が真の脆弱性を生み出します。KerberosチケットがRC4で暗号化されると、次のような攻撃にさらされます。 ケルベロストこの種の攻撃では、有効なドメインアカウントを持つ攻撃者は、正規のリソースに対してサービスチケットを要求し、それを取得し、オフラインにして総当たり攻撃で解読することができます。この場合、管理者権限は不要で、アラートも発生しません。暗号化が弱いほど、解読は速くなります。
RC4 では、特に古いパスワードや弱いパスワードを持つサービス アカウントの場合、そのプロセスは Advanced Encryption Standard (AES) 暗号化と比較して大幅に高速です。その結果、基本的なドメイン アカウントから完全なサービス アカウントの侵害に至る道筋が明確になり、そこから、 横移動 環境全体にわたって。
RC4の依存関係を見つけるのが難しい理由
RC4が周知のリスクであるにもかかわらず、なぜ多くの環境が依然としてRC4に依存しているのでしょうか？その答えは怠慢ではなく、可視性の問題です。RC4への脆弱性は、多くの場合、自ずと明らかになることはありません。何年も手つかずのまま、バックグラウンドで静かに動作していることが多いのです。
主な理由は、ADの属性が1つあることです。 msDS-SupportedEncryptionTypes。 この属性がアカウントに明示的に設定されていない場合、KDCはどの暗号化方式を使用するかについての指示を受けません。従来、これはRC4、AES-128、AES-256のいずれも使用可能であることを意味していました。ほとんどの環境では、この属性が未定義のアカウントが数千個存在し、それらはすべてKerberoasting攻撃や侵害の潜在的な標的となります。
特にリスクが高いアカウントの種類は、サービスアカウントとマシンアカウントの2つです。
サービスアカウント Active DirectoryRC4の最大の盲点
サービスアカウント これらは、アプリケーション、サービス、または自動化されたプロセスを実行するために作成されるユーザータイプのアカウントです。通常のユーザーアカウントとは異なり、パスワードは手動で管理され、多くの環境では何年もリセットされていない場合があります。
サービス アカウントのパスワードが、Windows Server 2008 (AD で AES 暗号化サポートが導入されたバージョン) より前に最後に設定されていた場合、そのアカウントには AES キーが生成されていません。ドメインをアップグレードするだけでは解決しません。パスワードのリセットのみが、RC4 の代わりに AES キーの生成をトリガーします。しかし、そのためには、どのアカウントがこの状態にあるかを把握する必要がありますが、ほとんどの環境ではそれができません。
マシンアカウント Active Directory: 異なる種類の依存関係
マシンアカウント 自動的に作成されます Active Directory ドメインに参加するエンドポイントごとに、パスワードは自動的に更新されるため、古い認証情報が問題になることはありません。サービスアカウントとは異なり、エンドポイントのパスワードは自動的に更新されます。
問題はオペレーティングシステム自体にあります。Windows Server 2008より古いバージョンのWindowsを実行しているデバイスは、AES暗号化をサポートしていません。これらのアカウントでは、RC4は単なるデフォルトオプションではなく、システムがアップグレードされるまで必須要件となります。
その結果、ほとんどの環境においてRC4への脆弱性は一箇所に集中しているわけではなく、サービスアカウントやマシンアカウント全体に分散しており、それぞれ依存の原因や修復方法が異なっている。
RC4の廃止スケジュール：各段階で何が起こるのか、そしてなぜ今それが重要なのか
マイクロソフトはRC4のサポート終了を段階的に実施することで、組織が準備する時間を与えているが、その時間は刻々と過ぎている。
2026月XNUMX日 このアップデートにより、監査フェーズが導入されました。RC4暗号化は引き続き許可されましたが、組織がRC4暗号化の使用状況を把握できるように、新たなログ記録メカニズムが追加されました。
4月2026 アップデートは、強制が開始される場所です。キー配布センター（KDC）は、現在、アカウントに対してデフォルトでAESのみのモードで動作します。 msDS-SupportedEncryptionTypes は未定義です。RC4 はもはやフォールバック オプションではなく、RC4 に依存しているサービスまたはマシン アカウントは認証エラーが発生し始めます。一時的な解決策があります: RC4デフォルト無効化フェーズ レジストリキーを使用すると、管理者は修復作業中にドメインコントローラーの動作を手動でロールバックできます。ただし、これはあくまで一時的な対応策です。
2026年7月ロールバックオプションは完全に削除されます。RC4暗号化は、個々のアカウントで明示的に構成されている場合にのみ機能しますが、Microsoftはこの安全性の低い方法を推奨していません。修復プロセスが完全に完了していない場合、残っているRC4の依存関係によって認証エラーが発生し、ロールバックする方法がなくなります。
リスクは認証失敗だけにとどまらない。 サービスアカウント 認証できないということは、アプリケーションがダウンし、自動化されたプロセスが停止することを意味します。これは、 事業全体にわたる混乱そして、7月以降も明示的に設定されているRC4の依存関係は、Kerberos認証における恒久的な脆弱性となります。
環境中のRC4曝露を見つける方法 Silverfort
Silverfort 追加の設定やスクリプト作成を必要とせず、プロアクティブな姿勢評価とリアルタイム認証監視という2つの補完的なアプローチを通じて、環境内のRC4依存関係を特定するのに役立ちます。
調査は、自然な2段階の流れで行われます。まず、リスク指標を用いて、RC4への依存関係を持つ可能性が最も高いアカウントとデバイスを事前に特定し、次に認証ログを詳細に調べて、リアルタイム認証フローで具体的にRC4を使用しているアカウントとデバイスを確認します。
ステップ 1 - リスク指標：I特定する 暗号化が脆弱なアカウント
Silverfortのアイデンティティセキュリティ態勢管理（ISPM） 環境を継続的に監視し、認証トラフィックで脆弱な暗号化が検出されると、リスク指標を自動的に引き上げます。RC4の脆弱性に直接関連する指標は次の2つです。
- 脆弱な暗号化（ユーザー）—ユーザーアカウントがRC4またはその他の脆弱なKerberos暗号化タイプを使用して認証された場合に発生します
- 脆弱な暗号化（サーバー）サービスまたは機械アカウントで同様のことが観察された場合に提起される
これらの指標は、認証トラフィックにおいて実際に脆弱な暗号化が検出されたアカウントのリストを即座に提供します。これは、設定に基づいてリスクがある可能性のあるアカウントだけでなく、脆弱な暗号化が現在実際に使用されているアカウントも対象となります。
暗号化の弱さを示す指標に加えて、2つの 追加の ISPMの分類は、全体像をより明確にするのに役立ちます。 古いパスワードを使用しているユーザー 識別する サービスアカウントは、RC4のみのキーを保持している可能性が最も高い。なぜなら、それらのパスワードはWindows Server 2008より前に作成されたものであり、AESキーは生成されていないからである。 古いオペレーティングシステム 表面デバイス しない AES暗号化をサポートしているため、どのマシンアカウントに手動でRC4例外を設定する必要があるか、または強制適用前に廃止計画を策定する必要があるかを明確に把握できます。
ステップ2—認証ログ：RC4の使用状況を確認し調査する
フラグが立てられたアカウントのリストを入手したら、 Silverfortの認証ログ さらに深く掘り下げることができます（注： アイデンティティの可視性とインテリジェンスを取得する方法については、こちらをご覧ください。) Kerberos暗号化タイプでフィルタリングします。具体的には RC4-HMAC or RC4-HMAC-EXP―認証ごとにRC4がどこで使用されているかを正確に把握できます。ステップ1の広範な脆弱な暗号化指標とは異なり、このフィルターは認証イベントごとにRC4固有の確認情報を提供します。 各認証について、以下を確認できます。
- 関係するユーザーまたはサービスアカウント
- ソースホスト
- 対象サービスまたはSPN
- チケットを発行したドメインコントローラー
これにより、どのユーザーアカウントが具体的にRC4暗号化を使用しているかを確認し、修復の優先順位を決定し、影響を受けるシステムを担当するチームと情報に基づいた意思決定プロセスを行うために必要な正確な状況を把握できます。
MicrosoftがRC4の脆弱性を見つけてくれるのを待つ必要はありません。
Silverfort Microsoft の強制適用によって認証失敗や生産性の低下が発生する前に、RC4 の依存関係を見つける可視性を提供します。 Silverfort継続的なモニタリングにより、問題解決の進捗状況を追跡できます。2026年7月の期限が近づいている今こそ、現状を把握する絶好の機会です。
どこから始めたらいいか分からない？ 私たちのダウンロード RC4修復準備チェックリスト リスクを評価し、次のステップの優先順位を決定するため。
もっと深く知りたいですか? オンデマンドウェビナーをご覧ください コラボレー Silverfortセキュリティリサーチチームのリーダーであるドール・シーガルが、RC4攻撃の経路をライブで解説します。 Silverfort 実際の環境におけるRC4の依存関係を明らかにする。
そして、もしあなたがどのように Silverfort あなたの特定の環境に合わせてお手伝いできます。 通話をスケジュールする 当社の専門家と一緒に。
