脆弱性の「玄関口」を封鎖せよ：RPCエンドポイントマッパーを巡るラテラルムーブメントの深淵
ネットワークの現場に長くいると、「なぜ、あんなに強固なはずの境界防御が、一瞬で崩れ去ったのか」という悲劇に何度も立ち会うことになる。その多くは、洗練されたゼロデイ攻撃というよりは、古くからある「仕様の隙間」を突いた泥臭い横展開（ラテラルムーブメント）によるものだ。
今日取り上げるのは、Windowsネットワークの屋台骨であり、同時に最大のウィークポイントでもある RPC (Remote Procedure Call) 、特に TCP/135 ポートで待ち受ける「エンドポイントマッパー」の話だ。
1. RPCエンドポイントマッパー（TCP/135）の正体
WindowsにおけるRPCは、異なるプロセス間、あるいはネットワークを介して関数を呼び出すための仕組みだ。しかし、RPCが使用するポートは動的である。そこで登場するのが Endpoint Mapper（rpcss サービス）だ。
クライアントが「特定のサービスを使いたい」と頼むと、TCP/135 で待機しているエンドポイントマッパーが、「今のそのサービスは、この動的ポートで動いているよ」と教えてくれる。この「仲介者」こそが、攻撃者が内部ネットワークを掌握するための地図となる。
2. ラテラルムーブメントの「最短ルート」
攻撃者は、侵害した端末から TCP/135 に対してクエリを投げ、ネットワーク内の全サーバーのサービス配置をマッピングする。これができれば、あとは特定のサービス（DCE/RPC の脆弱性を持つものなど）に対して、直接バッファオーバーフロー攻撃や認証回避攻撃を仕掛けるだけだ。
例えば、有名な脆弱性 MS08-067 や、近年の PrintNightmare のような事象を思い出してほしい。これらは皆、RPCの背後に潜むサービスの脆弱性を利用し、SYSTEM権限を奪取してドメイン内を蹂躙する。
3. 通信フローの泥臭い現実
デバッグ時に Wireshark を開くと、以下のような泥臭い会話が見えるはずだ。
1. Client -> Server (TCP/135): 「lsarpc（LSA RPC）の動的ポートを教えてくれ」
2. Server -> Client (TCP/135): 「それはポート 49154 で動いているよ」
3. Client -> Server (TCP/49154): 「じゃあ、そのサービスを使って認証を回避するぞ」
この通信を放置することは、鍵のかかっていない玄関のドアを放置するに等しい。
4. 実戦的防御：ネットワークレベルでの封じ込め
Web API設計やインフラ運用に携わる皆さんが、今すぐ実行すべき対策は「最小権限のネットワーク分離」だ。
A. PowerShellによるRPCインターフェースの制限確認
まずは、どのサービスが露出しているかを確認する習慣をつけよう。
# 現在のリスニングポートを確認し、不要なRPCサービスが公開されていないか精査する
Get-NetTCPConnection -LocalPort 135 | Select-Object LocalAddress, OwningProcess, State
# 特定のプロセスID (PID) からサービス名を特定する
Get-Process -Id <PID>B. Windows Firewallによる制御（推奨）
境界防御の基本だが、ドメイン環境であっても「RPCの全開放」は避けなければならない。特定の管理用端末以外からの TCP/135 へのアクセスは、グループポリシー（GPO）で徹底的に弾くべきだ。
# 特定の管理IP (192.168.10.50) からのみRPCを許可するFirewallルールの設定例
netsh advfirewall firewall add rule name="Allow_RPC_Management" ^
dir=in action=allow protocol=TCP localport=135 ^
remoteip=192.168.10.50/32 enable=yes5. 開発者へ贈る、ゼロトラストの視点
Web APIを設計する際、「社内ネットワークだから安全」という前提は捨ててほしい。APIサーバーが RPC でドメインコントローラーや他の管理サーバーと密接に連携している場合、そのAPIサーバーが踏み台にされた瞬間に、攻撃者は TCP/135 を通じて組織全体を掌握するルートを手に入れる。
- API認証の強化: ネットワークレベルの信頼に頼らず、mTLS（相互TLS）や強力なOAuth 2.0フローを実装する。
- セグメンテーション: 開発環境と本番環境、そして管理用セグメントを論理的に分離し、RPC通信を跨がせない。
- 可観測性（オブザーバビリティ）:
TCP/135への不自然なスキャンを検知するために、EDRやIDSのログをSIEMに集約し、閾値を超えた探索行為を即座に遮断するアラートを仕込む。
まとめ：泥臭い監視こそが最強の防御
技術は進歩したが、攻撃の基本原理は変わらない。RPCという古き良き遺産を使いこなすには、それ相応の「監視の目」が必要だ。「設定したから大丈夫」ではなく、「今、誰が、どのポートにアクセスしようとしているか」を常に意識する。
この地味で泥臭い確認作業こそが、ランサムウェアという荒波から自社のインフラを守る唯一の防波堤になる。皆さんのネットワークが、今日も静かな平穏を保てていることを願っている。
コメント