IntelliAI Tools

借りたサーバーが乗っ取られると、手元のPCまで届く。RDPとハイパーバイザーの構造的な弱点（2026年10月28日時点）

公開 ・ 公開と運用

2026年10月、国内の大手事業者が提供するデスクトップクラウドへの不正アクセスが報じられました。その経過を追っていて、自分がまったく想定していなかったことに気づきました。

借りているサーバーが乗っ取られたとき、被害はそのサーバーの中で止まらない可能性があります。接続している手元のPCまで届きうるのです。

この記事は、特定の事案で何が起きたかを説明するものではありません。そういう経路が構造として存在するという話です。

先に、この記事の確かさについて

扱いを分けます。

確認できていること（公式ドキュメントで裏を取りました）

確認できていないこと

つまり以下は、「構造上こうすれば成立する」という説明であって、特定の事件の調査結果ではありません。そのつもりでお読みください。

3つの段階

① 管理基盤が破られる

起点は、インターネットに面した管理画面やAPIです。個別のサーバーではなく、それらをまとめて管理している基盤の権限が奪われた場合を考えます。

ここから先が、この記事の本題です。

② ネットワークを通らずに、サーバーの中へ

管理基盤を取られたあと、攻撃者は顧客のサーバーに不正なプログラムを置く必要があります。ここでネットワーク経由である必要はありません。

仮想化基盤には、ホスト側からゲストOSを直接操作する機能が標準で備わっています。VMware の場合、Invoke-VMScript というコマンドがそれにあたります。公式ドキュメントによれば、スクリプトは管理端末からホストを経由してゲストへ転送され、ゲスト内で実行されます。

この機能の存在意義は正当なものです。多数の仮想マシンに一括で設定を入れたいとき、1台ずつリモート接続するより確実で速いからです。実際、WinRM（Windowsのリモート管理）を有効にせずに済むため、セキュリティ上むしろ望ましいとされる場面すらあります。

ところが、基盤側の権限が奪われた場合、同じ機能がそのまま攻撃に使えます。そして重要なのは次の点です。

ファイアウォールが一切効きません。

ネットワークを通っていないからです。通信を監視しても、不審な接続は記録されません。サーバー内のファイアウォールをどれだけ固めても、「外から入ってきていない」ものは止められません。

VMware 自身も、セキュリティ解説の中でこの点に触れています。vSphere に侵入された攻撃者は、無効化されていたゲスト操作機能を再び有効にできる、と。だからゲスト側でも無効化しておくことが推奨されています。

③ RDPの共有を逆流して、手元のPCへ

ここが、私がまったく想定していなかった部分です。

サーバーの中に置かれたプログラムは、利用者がリモートデスクトップで接続してくるのを待ちます。

リモートデスクトップには、手元のPCとサーバーの間でファイルをやり取りしやすくする機能があります。接続時にドライブ共有を有効にすると、サーバー側から見て \\tsclient\C というパスで、接続元のPCのCドライブが見えます。

便利な機能です。サーバーに入れたいファイルをいちいちアップロードせずに済みます。ヘルプデスクがユーザーのPCからインストーラを実行する、といった正規の使い方もあります。

しかし、サーバー側が敵になっている場合、この共有は逆向きに使われます。

接続している間、サーバー上のプログラムは \\tsclient\ 以下を普通のフォルダとして読めます。ブラウザの保存パスワード、業務ファイル、設定ファイル。手元のPCにあるものが、サーバーから見えてしまいます。

この挙動は既知で、セキュリティ製品には \\tsclient\ 経由の実行を検知するルールがあります。MITRE ATT&CK でもリモートサービスの悪用（T1021.001）に紐づけられています。知られている経路です。

クリップボード共有も同様です。コピーした内容が、接続先から読める状態になります。

何が怖いのか

この3段階を通すと、こうなります。

通常の想定 この経路の場合
侵入の入口 自分のサーバーの脆弱性 事業者の管理基盤
自分にできる予防 パッチ適用、設定の堅牢化 ない
ネットワーク防御 有効 通らないので無効
被害の範囲 契約したサーバーの中 接続した自分のPCまで

自分のサーバーをどれだけ適切に管理していても防げません。 入口が自分の管理範囲の外にあるからです。これはクラウドを借りるという形態そのものに内在する弱点で、サプライチェーンのリスクと呼ばれる類のものです。

利用者にできること

正直に書きます。できることは多くありません。

サーバーの中に置かれた情報（そこで動かしているツールの設定、保存された認証情報など）が抜かれるのは、利用者側の設定では防げません。基盤を取られている以上、サーバーの中は攻撃者から見て筒抜けです。

守れるのは、手元のPCだけです。 ③を遮断します。

接続設定を確認する

Microsoft の公式ドキュメントで定義されている設定です。.rdp ファイルをテキストエディタで開いて確認してください。

設定 意味 安全側の値
drivestoredirect:s: 手元のどのドライブをサーバーへ見せるか 空にする（何も見せない）
redirectclipboard:i: クリップボードを共有するか 0（共有しない）

ドキュメント上の既定値は、ドライブが「空（リダイレクトしない）」、クリップボードが「0」です。ただし、事業者から配布される接続用の .rdp ファイルで有効にされていることがあります。 自分のファイルを実際に開いて、こうなっていないか確認してください。

drivestoredirect:s:*
redirectclipboard:i:1

* は「すべてのドライブを見せる」という意味です。これが書かれていたら、手元のPC全体がサーバーから読める状態です。

安全側に倒すなら、こう書き換えます。

drivestoredirect:s:
redirectclipboard:i:0

接続ソフトの画面から設定する場合は、接続前の設定画面でローカルリソースに関するタブを開き、ドライブのチェックを外します。画面の文言はバージョンによって違うので、確実なのはファイルを直接見る方法です。

それでも残るもの

この設定をしても、以下は守れません。

「手元のPCへの延焼を止める」だけです。これが限界であることは、はっきり認識しておいたほうがいいと思います。

併せてやること

この話の一般化

今回たまたまデスクトップクラウドが話題になりましたが、構造はレンタルサーバーやVPS全般に共通します。

借りる側が持っている前提は「事業者の基盤は安全である」です。この前提が崩れたとき、利用者側の対策はほとんど効きません。そして、その前提が正しいかどうかを利用者が検証する手段はありません。

だからといってクラウドを使うなという話ではありません。自前で運用するほうが危ないことのほうが多いからです。ただ、「何を相手に委ねているのか」を把握しておくことと、委ねた部分が壊れたときに自分の手元まで届く経路があるなら、そこだけは塞いでおくこと。これは意味があります。

今回私が気づいていなかったのは、まさにその「手元まで届く経路」の存在でした。

まとめ

この記事は2026年10月28日時点の情報で書いています。特定の事案の調査結果ではなく、構造の説明です。 設定の詳細は、お使いの環境の公式ドキュメントで確認してください。