ネットワークの死角を突く「WinRM」：ランサムウェア拡散の凶悪な手口と、現場で施すべき鉄壁の防御策
「まさか、管理用のプロトコルが攻撃者に乗っ取られるなんて」
現場でインシデント対応をしていると、溜息交じりにそう呟く管理者によく出会います。私たちが利便性のために開放したポートが、そのまま攻撃者の「高速道路」として悪用される。これが、現在のエンタープライズ環境における最も残酷な現実です。
今回は、ランサムウェア攻撃者がドメイン環境を壊滅させるために愛用する「WinRM（Windows Remote Management）」の闇と、それを封じ込めるための実戦的な防衛論を紐解いていきましょう。
—
1. なぜ攻撃者は「WinRM」を狙うのか？
WinRMは、MicrosoftがWS-Managementプロトコルを実装したもので、Windows環境のリモート管理において非常に強力なツールです。5985/TCP（HTTP）と5986/TCP（HTTPS）で待ち受け、PowerShellの Invoke-Command などと連動することで、管理者権限さえあれば、ドメイン内の全端末を「自分の分身」として操ることができます。
攻撃者にとって、これほど都合のいい機能はありません。一度ドメイン管理者アカウントを窃取してしまえば、個別にマルウェアを仕込む手間は不要です。WinRM経由でワンライナーを実行するだけで、数分以内にネットワーク上の全PCで暗号化プロセスを走らせることができてしまうのです。
2. 攻撃の解剖：通信シーケンスのリアル
WinRMの通信は、実は非常に洗練されたSOAP（Simple Object Access Protocol）ベースのXML通信です。攻撃者は、以下のようなシーケンスで内部ネットワークを蹂躙します。
1. 認証の確立: 攻撃者は窃取した認証情報（KerberosチケットやNTLMハッシュ）を用い、ターゲット端末に対してHTTP/HTTPSでセッションを確立します。
2. シェルの生成: wsmid:Create リクエストを送り、リモート側にPowerShellのホストプロセスを立ち上げます。
3. コマンドの注入: wsmid:Send により、Base64エンコードされた悪意のあるPowerShellスクリプトを送信。
4. 結果の回収: 実行結果をXML形式で受け取り、次の攻撃の踏み台にするか、暗号化の成功を確認します。
実務で見る「悪意あるコード」の断片
攻撃者は、検知を回避するためにコマンドを難読化します。例えば、以下のようなコマンドが裏で走っているとしたら、それはもう手遅れに近いサインです。
# 攻撃者が使うであろうリモート実行コマンドの例
# Base64でエンコードされた難読化スクリプトを復号して実行する
$cmd = "JABzID0gTmV3LU9iamVjdCBJTy5NZW1vcnlTdHJlYW0oW0NvbnZlcnRdOjpGcm9tQmFzZTY0U3RyaW5nKCdQSDhz...');"
$bytes = [System.Convert]::FromBase64String($cmd)
$decoded = [System.Text.Encoding]::ASCII.GetString($bytes)
Invoke-Expression $decoded # ここでランサムウェアの本体がメモリ上で展開される3. インフラエンジニアが今すぐ打つべき防御策
WinRMを無効化できれば一番ですが、運用上それが許されない現場がほとんどでしょう。であれば、「境界」と「権限」を徹底的に絞るしかありません。
対策1：WinRMのHTTPS化と証明書認証
デフォルトの 5985（HTTP）は通信が平文です。即座に廃止し、5986（HTTPS）のみに限定してください。さらに、IP制限をかけます。
# 管理端末からのアクセスのみを許可する設定例
Set-WSManQuickConfig -Force
# 特定の管理用サブネット（例: 10.0.5.0/24）からのアクセスのみ許可
Set-Item WSMan:\localhost\Client\TrustedHosts -Value "10.0.5.*"対策2：ネットワークレベルでの「マイクロセグメンテーション」
WinRMの通信は、ドメイン内であればどこからでも届くように設計されがちです。ファイアウォール（Windows Defender FirewallやハードウェアFW）で、「管理サーバー以外の端末間でのWinRM通信を禁止」するルールをグループポリシー（GPO）で強制適用してください。
対策3：PowerShellの「Constrained Language Mode」
攻撃者が悪意あるAPIを呼び出せないよう、PowerShellを制限モードで実行させます。
# 環境変数で強制的に制限モードにする（システム全体で設定を推奨）
[Environment]::SetEnvironmentVariable('__PSLockdownPolicy', '4', 'Machine')4. 現場の教訓：デバッグと監視の極意
最後に、もし不審なWinRM通信を検知したいなら、Microsoft-Windows-WinRM/Operational イベントログを精査してください。特に、イベントID 6（認証情報）とイベントID 167（リモートシェルの作成）は、攻撃の兆候を見つけるための「金鉱」です。
また、Web APIを開発するエンジニアの方々へ。もし皆さんのAPIサーバーがADドメインに参加しているのであれば、そのサーバー自体が踏み台になるリスクを常に意識してください。Invoke-RestMethod を使った外部通信など、アプリケーションの挙動とWinRMの挙動が混ざり合うと、IDS/IPSでの検知が極めて困難になります。
「管理の利便性」と「セキュリティ」は常にシーソーの関係にあります。しかし、WinRMに関しては、利便性を少し犠牲にしてでも、ネットワークの出口と入り口を厳格に制御すること。これが、ランサムウェアから組織を守る唯一の防波堤なのです。
現場からは以上です。皆さんのネットワークが、今日も安全であることを願っています。
コメント