Microsoftは、Windowsの認証基盤であるActive Directoryにおいて、長年デフォルトでサポートされてきた暗号化アルゴリズム「RC4」を廃止する計画を正式に発表した。これは、1999年のActive Directory登場以来、実に26年近くにわたり企業のネットワークセキュリティにおける「アキレス腱」であり続けた技術との決別を意味する。

RC4の脆弱性は、昨今の医療大手Ascensionへのサイバー攻撃や、米上院議員による「重大なサイバーセキュリティ上の過失」との糾弾に見られるように、もはや看過できないリスクとなっていた。本稿では、Microsoftが下したこの決定の全貌、その技術的背景にある「Kerberoasting」攻撃のメカニズム、そしてIT管理者が直ちに取り組むべき具体的な移行プロセスについてを見ていきたい。

AD

2026年半ば、RC4は「デフォルト無効」へ

Microsoftの主要プログラムマネージャーであるMatthew Palko氏の発表および公式ブログによると、同社は2026年半ばを目処に、Windows Server 2008以降のKerberos Key Distribution Center (KDC) におけるドメインコントローラーのデフォルト設定を変更し、RC4を無効化する方針を固めた。

変更の核心

この変更が適用されると、システムは以下の挙動をとることになる。

  • AES-SHA1の強制: Kerberos認証において、より強固なAES-SHA1暗号化のみが許可される。
  • RC4の無効化: ドメイン管理者が明示的に設定しない限り、RC4を使用した認証は拒否される。

Windowsクライアント自体は、Windows Server 2008（Vista世代）の頃からAESをサポートしており、すでにデフォルトでAESを使用した認証を行っている。しかし、サーバー側（Active Directory）は、後方互換性を維持するために、「RC4での認証要求があればそれに応答する」という受動的な姿勢を維持し続けてきた。この「古い鍵でも開けられるドア」を残していたことが、ハッカーにとっての格好の侵入口となっていたのである。

なぜRC4はこれほど危険なのか：Kerberoastingの脅威

なぜMicrosoftは、これほど長い間サポートしてきた技術を今になって「殺す」必要があるのか。その答えは、RC4の構造的な欠陥と、それを悪用した攻撃手法「Kerberoasting（ケルベロースティング）」にある。

1987年の遺物と現代の攻撃

RC4（Rivest Cipher 4）は、1987年にRSA Securityの著名な暗号学者Ron Rivest氏によって開発されたストリーム暗号だ。1994年にそのアルゴリズムが漏洩して以降、数々の暗号学的弱点が指摘され、SSL/TLSなどのプロトコルからは約10年前に排除されている。しかし、Windowsの内部認証（Active Directory/Kerberos）においては、互換性の亡霊として生き残り続けてきた。

Kerberoasting：塩なし、1回ハッシュの脆さ

Microsoftの認証チームを率いるSteve Syfuhs氏の解説によると、Kerberoasting攻撃がRC4を標的にする最大の理由は、Active DirectoryにおけるRC4の実装仕様にある。

  1. ソルト（Salt）の欠如: 通常、パスワードをハッシュ化（不可逆変換）する際は、ランダムなデータ（ソルト）を加えてレインボーテーブル攻撃などを防ぐ。しかし、RC4ベースのKerberos認証では、このソルトが使用されていない。
  2. 貧弱なハッシュ関数: 使用されているハッシュ関数は、極めて高速だが強度の低い「MD4」であり、しかもハッシュ計算はわずか「1回」しか行われない。

これに対し、今回標準となるAES-SHA1の実装では、ソルトが使用される上に、ハッシュ計算を数千回繰り返す（ストレッチング）ことで、解析にかかる時間を意図的に引き延ばしている。

Syfuhs氏によると、AESでハッシュ化されたパスワードを解読するには、RC4の場合と比較して約1000倍の時間とリソースが必要になるという。逆に言えば、RC4が有効である限り、攻撃者はネットワーク内を盗聴して得た認証チケットをオフラインで解析し、極めて短時間で管理者権限を持つアカウントのパスワードを特定できてしまうのである。

実際の被害：Ascension事件

この脆弱性は机上の空論ではない。2024年に発生した米医療大手Ascensionへのサイバー攻撃では、RC4の不備が侵入の「重要な役割」を果たしたとされる。この攻撃により140の病院で業務が停止し、560万人の患者記録が流出するという、人命に関わる甚大な被害が発生した。Ron Wyden上院議員がMicrosoftを激しく非難したのは、こうした実害が背景にある。

AD

「技術的負債」との長い戦い

MicrosoftがこれまでRC4を廃止できなかった理由は、企業のIT環境における「互換性の呪縛」にある。Syfuhs氏がBlueskyで吐露したように、過去25年間に出荷されたすべてのOSに組み込まれ、長年デフォルトであった暗号アルゴリズムを削除することは容易ではない。

しかし、Microsoftは過去10年間にわたり、RC4の脆弱性を「外科的」に修正しつつ、AESへの移行を促すマイナーな改善を積み重ねてきた。その結果、現在のテレメトリデータにおいてRC4の使用率は「桁違い」に低下し、ほぼゼロに近づいたという。これにより、ついに「完全廃止」という抜本的な対策に踏み切る土壌が整ったと言える。

管理者が今すぐ行うべきアクション：検出と移行

2026年の強制無効化を待つのは得策ではない。攻撃者は今もRC4の穴を探しているからだ。Microsoftの公式ブログでは、IT管理者が自社のネットワーク内に潜む「RC4依存」を洗い出し、対処するための具体的なツールと手順を公開している。

1. 監査ログによる検出（イベントID 4768, 4769）

Windows Server 2019以降のKDCでは、セキュリティイベントログに新たなフィールドが追加されている。

  • イベントID 4768 (TGT要求) / 4769 (サービスチケット要求)
  • 注目すべきフィールド:
    • msds-SupportedEncryptionTypes: アカウントがサポートする暗号化タイプを表示。ここにAESが含まれていない場合、設定の見直しが必要だ。
    • Session Encryption Type: 実際に使用された暗号化アルゴリズム。ここが「RC4」となっている通信は、即座に調査対象となる。

2. PowerShellスクリプトの活用

手動でのログ確認は現実的ではないため、MicrosoftはGitHubリポジトリ「Microsoft Kerberos-Crypto」にて、以下のPowerShellスクリプトを提供している。

  • List-AccountKeys.ps1:
    Active Directory内のアカウントが保持している鍵の種類を一覧表示する。もし「RC4」しか持っていないアカウントが見つかった場合、そのアカウントはAESに対応できていない。
    • 対処法: 該当アカウントのパスワードをリセットするだけで、自動的にAES鍵（AES128-SHA96およびAES256-SHA96）が生成されるケースが多い。
  • Get-KerbEncryptionUsage.ps1:
    イベントログを解析し、実際にどの暗号化タイプが使用されているかを可視化する。
    • コマンド例: .\Get-KerbEncryptionUsage.ps1 -Encryption RC4 を実行すれば、RC4を使用している通信のみをフィルタリングして特定できる。

3. レガシーシステムへの対応

第三製の古いアプリケーションや、Windows以外の古いデバイス（プリンターやスキャナーなど）の中には、いまだにRC4しかサポートしていないものが存在する可能性がある。これらはネットワークの死角になりやすいため、上記のログ監査を通じて確実に特定し、機器の更新や設定変更を行う必要がある。

AD

セキュリティの近代化へ

MicrosoftによるRC4の廃止決定は、単なる機能の削除ではなく、四半世紀にわたる古いセキュリティパラダイムからの脱却を意味する。AES-SHA1への完全移行は、Kerberoastingという長年の脅威に対する最も効果的な防御策となる。

IT管理者にとっては、2026年の期限までに隠れたレガシー設定を洗い出す作業が発生するが、これは組織のセキュリティ衛生を劇的に向上させる好機でもある。Ascensionのような悲劇を繰り返さないためにも、今こそ「26年前の鍵」を捨てる時だ。

Sources