本記事はGeminiの出力をプロンプト工学で整理した業務ドラフト(未検証)です。
Active Directory環境におけるKerberos RC4暗号化の緊急廃止ガイダンスとWDSへの影響
【脅威の概要と背景】
Kerberos認証におけるRC4暗号スイートの利用は、認証情報のオフラインクラック攻撃(Kerberoasting/AS-REP Roasting)を容易にします。RC4は対称鍵の生成にNTLMハッシュを使用するため、攻撃者は取得したチケットから短時間でパスワードを解読可能です。MicrosoftはRC4の非推奨化を長期間推奨しており、現代のセキュリティ基準ではAES-256/128の強制が必須要件です。これにより、サービスアカウントの特権昇格リスクを大幅に低減できます。
【攻撃シナリオの可視化】
攻撃者は、サービスプリンシパル名(SPN)が登録されたサービスアカウント、または事前認証が無効化されたアカウントを標的に、RC4で暗号化されたKerberosチケット(TGSまたはTGT)を取得します。
graph TD
A["偵察: AD情報収集"] --> B{"標的発見: SPN登録アカウント/事前認証無効アカウント"};
B -->|RC4サポート確認| C["RC4暗号化されたTGS/TGT取得"];
C --> D["オフライン環境へチケット転送"];
D --> E["ブルートフォース/辞書攻撃"];
E --> F("NTLMハッシュ解読 -> パスワード取得");
F --> G["特権昇格/Lateral Movement"];
【安全な実装と設定】
RC4の利用を段階的に廃止し、AES-256をデフォルトとする設定を強制する必要があります。特に特権性の高いサービスアカウント(IIS, SQL, WDS関連など)から優先的に適用します。
誤用(RC4許可の状態)
RC4が無効化されていない場合、アカウントのプロパティには何も設定されていません。攻撃者はデフォルトで最も弱い暗号化タイプ(RC4_HMAC_MD5)を要求できます。
# GPOやアカウント設定によるRC4非推奨化が未実施 # サービスアカウントがデフォルトでRC4をサポート Get-ADUser -Identity "SVC_Account" -Properties * | Select-Object Kerb* # 出力結果例:KerberosEncryptionTypeはデフォルト設定のまま
安全な代替案(AES強制設定)
アカウント単位でRC4を明示的に無効化し、AES-256/128の利用を必須とします。これにより、RC4を要求する不正なチケット要求は失敗します。
1. アカウント単位でのRC4無効化(推奨)
PowerShellを使用して、特定のサービスアカウントに対し、AESサポートのみを有効にします。これは、ドメイン全体に影響を与えるGPO適用前のテストにも有効です。
# 設定値: # 0x18 (24): AES256_CTS_HMAC_SHA1_96 (0x10) + AES128_CTS_HMAC_SHA1_96 (0x8) $Account = "SVC_WDS_PXE" Set-ADUser -Identity $Account -KerberosEncryptionType 24 Write-Host "アカウント $($Account) のKerberos暗号化タイプをAESのみに設定しました。"
2. WDSサーバーへの対応
WDS環境がRC4に依存している場合(特にレガシーなPXEブートイメージや古いクライアントがある場合)、WDSを実行しているサーバーのコンピュータアカウントに対しても上記設定を適用し、RC4を廃止する必要があります。移行に際し、すべてのクライアントがAESをサポートしているかを確認してください。
【検出と緩和策】
検出ポイント:RC4利用の監視
Kerberosチケットサービス(TGS)要求のイベントログ(イベントID 4769)を監視し、RC4が使用されているかどうかを確認します。RC4の使用は即座に調査対象とするべきです。
| 監視対象 | イベントID | 検出条件 | 調査内容 |
|---|---|---|---|
| Kerberosサービスチケット要求 | 4769 | Encryption Type: 0x17 (RC4_HMAC_MD5) の場合 | RC4を使用しているアカウントとクライアントIPアドレスを特定し、AES対応を強制する。 |
| TGT要求(AS-REQ) | 4768 | Pre-Authentication required: No (事前認証無効) | AS-REP Roastingの標的となるアカウントとして特定し、事前認証を有効化する。 |
応急的な緩和策
パスワードの強化とローテーションの強制: RC4に依存するサービスアカウントに対し、最低25文字以上の複雑なパスワードを強制適用し、ローテーション頻度を高める。
グループポリシーによる全体設定 (推奨): ドメインコントローラ単位で「ネットワークセキュリティ: Kerberosが許可する暗号化の種類を構成」設定で、DESやRC4を無効化する。ただし、環境への影響が大きいため、十分なテストが必要です。
【実務上の落とし穴】
互換性の問題と誤検知
RC4の廃止は、古いOSやサードパーティのKerberos実装に依存するシステムとの互換性問題を引き起こす可能性があります。
レガシーシステム: Windows 2000/XP などのEOLシステム、または古いLinux/UNIXクライアントがRC4しかサポートしていない場合、認証が失敗し、サービス停止(可用性の低下)を招きます。
WDS/PXEブート環境: WDSで提供されるブートイメージやクライアント環境がAESに対応していない場合、ネットワークブートが失敗します。RC4廃止の前に、すべてのクライアント環境のKerberosサポートレベルを検証し、必要に応じてOSの更新または代替手段への移行が必要です。
誤検知(False Positive): RC4を利用した攻撃ではなく、単に互換性のために古いデバイスがRC4を利用している場合、イベントログが大量に発生する可能性があります。事前に棚卸しを行い、許容されるRC4利用元を把握しておく必要があります。
【まとめ】
Kerberos RC4暗号化の廃止は、Active Directory環境のセキュリティベースラインを向上させるための必須要件です。
組織として今すぐ確認・実施すべき3つの優先事項:
RC4利用状況の監査と識別: イベントログ(4769/0x17)を監視し、現在RC4を使用しているサービスアカウントおよびクライアントの棚卸しを完了する。
サービスアカウントの強制設定: 特権性の高いサービスアカウント(特にWDS関連、データベース、Webサービス)から順に、
KerberosEncryptionTypeをAESのみ(値24)に設定し、RC4を無効化する。レガシー互換性の検証と移行計画: RC4廃止による影響範囲(特に古いWDSクライアント)を評価し、移行期間を設定する。互換性の問題が解決できないレガシーシステムについては、隔離ネットワークへの移動やアクセス制限を施す。
