現場のエンジニアへ告ぐ：RDPを「無防備な玄関」にするな。CVE-2018-0886とブルートフォースの悪夢
夜中の3時、VPNのログに異常なスパイクが発生した経験はあるだろうか。身に覚えのないIPから、執拗に叩き込まれる3389/TCPへの接続要求。これこそが、現代のランサムウェア攻撃における「最初のノック」だ。
インフラエンジニアとして現場に立っていると、いまだに「RDPを直接インターネットに公開している」という、正気を疑う設定に出くわすことがある。今回は、RDPのブルートフォース攻撃と、かつて世界を震わせた CredSSP（CVE-2018-0886）の脆弱性を軸に、攻撃者がどのような足取りでエンタープライズの深部へ侵入するのか、その冷徹なシーケンスを紐解こう。
—
1. 攻撃の序章：RDPブルートフォースの泥臭い現実
攻撃者はまず、ShodanやCensysのようなスキャンエンジンを使い、グローバルIPに3389/TCPが開放されている死に体を探す。彼らの狙いは、「認証の総当たり」だ。
認証シーケンスの脆弱性
RDP接続において、初期段階でNLA（Network Level Authentication）が有効でない場合、OSはセッションを確立する前にログイン画面を提示する。攻撃者は、この「認証前の対話」を利用して、辞書攻撃を仕掛ける。
# 攻撃者がよく使うツール「Hydra」の例。
# RDPのユーザー名リストとパスワードリストをぶつける単純かつ凶悪な手法
hydra -L userlist.txt -P passlist.txt rdp://<ターゲットのIPアドレス>ここで重要なのは、「ログに残る」ということよりも「突破されるまで繰り返される」という事実だ。Web APIのレート制限のような仕組みがRDPの標準認証には乏しいため、パスワードが貧弱であれば、数時間で「門」は開かれる。
—
2. 核心：CVE-2018-0886（CredSSP）の悪夢
ブルートフォースで突破できない場合、あるいは管理者権限の奪取を急ぐ場合、彼らはプロトコル層の脆弱性を突く。その代表格が CredSSP（Credential Security Support Provider）の脆弱性だ。
何が問題だったのか？
CredSSPは、RDPセッションの認証情報を暗号化して転送するためのプロトコルだ。しかし、この実装には「中間者攻撃（MitM）」を許容してしまう設計上の欠陥があった。攻撃者が通信経路に割り込むことで、本来サーバーへ送られるはずの認証情報を傍受し、あるいは認証プロセスをバイパスして、管理者権限でのログインを成功させてしまうのだ。
防御の要：GPOでの強制設定
この脆弱性への対策は、もはや「必須」の教養だ。以下のGPO（グループポリシー）設定を確認してほしい。
1. 「コンピューターの構成」>「管理用テンプレート」>「システム」>「資格情報の委任」へ移動。
2. 「暗号化オラクル修復」の設定を開く。
3. これを「有効」にし、保護レベルを「脆弱」から「緩和」へと引き上げる。
# レジストリ値での直接制御例（管理者はこうやって一括適用する）
# 0x2 は「緩和」レベルを指す
reg add "HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\System\CredSSP\Parameters" /v AllowEncryptionOracle /t REG_DWORD /d 2 /f—
3. 水平展開：侵入後の「悪のルーチン」
一旦RDP経由で初期侵入に成功すると、攻撃者は即座にMimikatzのようなツールを駆使し、メモリ上の平文パスワードやハッシュを盗み出す。ここからが本当の地獄だ。彼らは SMB（445/TCP）を介してネットワーク内を横方向（ラテラルムーブメント）に移動し、ドメインコントローラーへの特権昇格を狙う。
防御策としてのインフラ設計
Web APIを設計する際、認証にOAuth2やJWTを採用し、トークンの有効期限を厳格に管理するように、RDPに対しても同様の「ガード」が必要だ。
- VPN経由での接続制限:
3389/TCPをグローバルに開放することは、自ら鍵を掛けずに家を留守にするのと同義。 - MFA（多要素認証）の強制:
DuoやMicrosoft Authenticatorなど、認証に物理的なデバイスを介在させる。 - ジャンプサーバー（踏み台）の構築: 管理者は必ず隔離されたジャンプサーバーを経由し、そこからRDPを行う。そのジャンプサーバー自体も、条件付きアクセス（Conditional Access）で厳重に保護する。
—
4. エンジニアへの提言：境界防御の再定義
最後に、読者諸君に伝えたい。ゼロトラストの時代において「境界」はネットワークの物理的な箱ではなく、「ID」そのものだ。
RDPの脆弱性を突かれるのは、プロトコルの責任以上に、「レガシーな認証方式を放置している運用者」の責任だ。もし、あなたの管理している環境で、何年もアップデートされていないWindows Serverが直接インターネットを向いているなら、今すぐネットワークの設計を見直してほしい。
実務で使える簡易チェックコマンド（PowerShell）
サーバー上のRDP設定が適切か、現在のステータスを確認するスニペットだ。
# NLA（ネットワークレベル認証）が有効かを確認するコマンド
# 0なら無効、1なら有効。0の場合は即座に設定を変更せよ
Get-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp' -Name UserAuthenticationネットワークセキュリティは、「一度設定して終わり」の作業ではない。パケットが行き交うたびに、そこに潜むリスクを想像し、絶えずチューニングし続ける泥臭いプロセスだ。それができるエンジニアこそが、真の「スペシャリスト」と呼ばれる。
さあ、ログを開こう。あなたのネットワークを叩いているのは、誰か？
コメント