3行まとめ
- 2026年10月、FX自動売買向けVPS「お名前.com デスクトップクラウド」が不正アクセスを受け、影響の可能性があるサーバーは26,739件。GMOは「システムにセキュリティ上の問題が存在した」と認めたが、侵入経路は10月27日時点で未公表
- 攻撃者側は「RDPのドライブ共有で利用者の自宅PCのファイルにアクセスした」と主張している。真偽は未確認だが、接続先サーバーが乗っ取られると、共有したローカルドライブがサーバー側から読み書きできること自体はRDPの仕様どおりの動き
- 自分の
.rdpファイルのdrivestoredirectを確認し、不要ならクライアント側のレジストリDisableDriveRedirectionで止められる。確認用のPowerShellと、クライアント側・サーバー側それぞれの無効化手順をまとめた
GMOインターネットのFX自動売買専用VPS「お名前.com デスクトップクラウド」で、大規模な不正アクセスが起きた。取引口座の不正操作、約80億円の金銭要求、顧客情報の公開予告まで発展し、10月24日には政府への「能動的サイバー防御」の適用要請、27日には懸賞金の創設まで話が広がっている。
この記事では、まず公式発表で確認できる事実と、攻撃者側の主張を分けて整理する。そのうえで、事件をきっかけに注目された**RDP（リモートデスクトップ）のドライブ共有（ドライブリダイレクト）**が仕様としてどう動くのか、自分の接続設定をどう確認して止めるのかを、Microsoftのドキュメントをもとに解説する。
本記事の事件に関する記述は、第12報（2026年10月27日19時10分時点）までの公式発表と報道にもとづく。侵入経路は公式に特定・公表されていない。後述する「RDPドライブ共有の悪用」は攻撃者側の主張で、GMOは確認していない。利用者は必ず公式のお知らせを確認してほしい。
何が起きたか：公式発表の時系列
GMOインターネットは10月21日から、10月27日夜の第12報までお知らせを出している。公式発表から確認できる流れは次のとおり。
| 日付 | 出来事（公式発表ベース） |
|---|---|
| 10/19 | 利用者からの問い合わせを受けて調査開始 |
| 10/20 | 一部サーバー環境で不正なプログラムの設置を確認。新規申込とコントロールパネルを停止 |
| 10/21 | 午前4時以降、全プランのサーバーを順次停止し第1報。同日、約80億円を要求する脅迫メールを受信 |
| 10/22 | 警察に相談。取引口座で身に覚えのない操作・取引の報告を受け付け（第2報） |
| 10/24 | 第4報。「本サービスのシステムにセキュリティ上の問題が存在」し、顧客情報の外部持ち出しを確認。不正取引による実現損失の補償、全利用者への一律5,000円の見舞金、独立した基盤での代替サービス（6か月無償）を決定。政府関係機関に能動的サイバー防御の適用を要請 |
| 10/26 | 預かった利用者端末の解析を開始。10月27日12時に情報公開とランサムウェア攻撃を行うという予告を受けたと公表（第7報）。要求には応じない方針 |
| 10/27 | 正午を前に、利用者へPCのネットワーク切断と電源断を要請（第8報）。正午過ぎ、攻撃者による情報公開を確認したと告知し、「公開された情報と称するもの」にアクセス・拡散しないよう要請（第10報・第11報）。夜に、公開が確認された人への特別見舞金（上限300万円）と、総額最大100万ドルの懸賞金の創設を発表（第12報） |
最新の公式見解は第12報にまとまっている。
補償と代替サービスの条件は第4報が詳しい。
26,739件（第3報）は影響を受けた可能性があるサーバーの数で、侵害を確認した件数ではない点に注意したい。取引口座の不正操作の件数や被害総額も公表されていない。
10月25日には、グループ代表の熊谷正寿氏がブログで経緯を説明した。社内のホワイトハッカーから事前に課題を指摘され対策を始めていたが、「サービスの可用性への影響や他の対処事項との優先順位を考慮しながら慎重に対応を進めた結果」、攻撃者に「その間隙を突かれてしまいました」と認めている。
10月27日正午の期限後、攻撃者側は情報を公開したとされ、報道では1人分とされている。GMOは第11報で「公開された情報と称するもの」と表現し、アクセスや拡散をしないよう呼びかけている。そのうえで、情報の公開が確認された人への特別見舞金（情報の区分に応じて1万〜2.5万円、1公開あたり上限300万円）と、攻撃者の特定につながる情報への懸賞金（制度全体で総額最大100万ドル）を発表した。
攻撃者側の主張：RDPのドライブ共有
この事件がFX利用者以外の技術者にも注目された理由は、攻撃者側の主張の中身にある。報道や技術者の解説記事によると、攻撃者側は次のような手順を主張している。主張と検証状況は、たとえば次の記事が出典付きで整理している。
- VPS環境に侵入し、管理者の認証情報を取得
- 共通の管理基盤（Active Directory）を足がかりに、複数の顧客VPSへ横展開
- 利用者がRDPで接続した際に共有されていたローカルドライブを経由して、利用者の自宅PCのファイルにアクセス
- ブラウザの保存パスワードなどを取得
あわせて、サービスが配布していたRDP接続ファイルでドライブ共有が既定で有効になっていた、とも主張している。
繰り返すが、これらはすべて未確認の主張で、GMOの公式発表は侵入経路にも、ドライブ共有にも触れていない。攻撃者が公開する情報には虚偽が混ざる可能性もある。
ただ、主張の真偽とは別に、「接続先のサーバーが乗っ取られたとき、RDPで共有していたローカルドライブはどうなるのか」は仕様として確認できる。ここからはその話をする。
RDPのドライブ共有は「接続先を信頼する」前提の機能
ドライブ共有（ドライブリダイレクト）は、手元のPCのドライブをリモートセッション内から使えるようにするRDPの標準機能だ。MT4/MT5のEA（自動売買プログラム）や設定ファイルを手元からVPSにコピーするときに便利で、FX用VPSでもファイルの受け渡しに使われる。
有効にして接続すると、リモートセッションのエクスプローラーに、手元のPC名とドライブ文字を含む名前のドライブが現れる。セッション内からは \\tsclient\C というUNCパスでも参照できる。
[手元のPC] C:\Users\you\...
│ RDP（ドライブリダイレクト有効）
▼
[接続先VPS] \\tsclient\C ← 手元のCドライブがここに見える
ここで重要なのは、この共有はセッション内で動くプログラムからも使えるという点だ。利用者がエクスプローラーで開くのと同じように、セッション内で動くプログラムも \\tsclient\C を読み書きできる。接続先が正常なら便利な機能だが、接続先に攻撃者のプログラムが仕込まれていれば、接続している間は手元のファイルにアクセスされうる。
ドライブ共有は脆弱性として扱われているわけではない。ただし、セキュリティ基準では無効化が推奨されている。たとえばCISベンチマーク（Windows 11 Enterprise）やDISA STIGは、サーバー側のポリシー「ドライブのリダイレクトを許可しない」を有効にすることを求めている。Azure Virtual DesktopやWindows 365でも、新規作成した環境ではドライブリダイレクトが既定で無効になっている。
つまり、ドライブ共有そのものは脆弱性ではない。接続先を信頼できる前提の機能を、常時オンで使っていたことがリスクになる、という整理が正確だと思う。
自分の .rdp ファイルを確認する
ドライブ共有の設定は、.rdp ファイルの drivestoredirect プロパティで決まる。Microsoftのドキュメントによると、値の意味は次のとおり。
| 書き方 | 意味 |
|---|---|
drivestoredirect:s:（空） |
どのドライブも共有しない（既定値） |
drivestoredirect:s:* |
すべてのドライブを共有。後から接続したドライブも含む |
drivestoredirect:s:DynamicDrives |
後から接続したドライブを共有 |
drivestoredirect:s:C:\;E:\; |
指定したドライブだけ共有 |
あわせて確認したいのが redirectclipboard:i:1（クリップボード共有）だ。コピーしたパスワードなどのテキストがセッションと共有される。
手元に .rdp ファイルがいくつもある場合は、PowerShellでまとめて確認できる。リモートデスクトップ接続（mstsc.exe）が使う Default.rdp はドキュメントフォルダーの隠しファイルなので、-Force を付けて探す。
# ユーザーフォルダー配下の .rdp からドライブ・クリップボード共有の設定を抜き出す
Get-ChildItem -Path $env:USERPROFILE -Filter *.rdp -Recurse -Force -ErrorAction SilentlyContinue |
Select-String -Pattern '^(drivestoredirect|redirectdrives|redirectclipboard):' |
Select-Object Path, Line
drivestoredirect:s:* が出てきたら、その接続ではすべてのドライブを共有している。redirectdrives は現行のMicrosoftのドキュメントには載っていない古い形式のプロパティだが、古い接続ファイルに残っていることがある。redirectdrives:i:1 もドライブ共有の有効化を意味する。
GUIで確認するなら、リモートデスクトップ接続の「オプションの表示」→「ローカル リソース」タブ→「ローカル デバイスとリソース」の「詳細」を開く。「ドライブ」にチェックが入っていれば共有が有効になっている。
共有を止める方法：クライアント側とサーバー側
止め方は、手元のPC（クライアント）側で止めるか、接続先（サーバー）側で止めるかの2通りある。
クライアント側：接続先に関係なく自分のPCを守る
VPSの利用者として一番確実なのはこちら。Microsoftのドキュメントには、手元のWindowsでドライブリダイレクトを無効化するレジストリ値が載っている。
# 管理者権限のターミナルで実行。このPCから出るRDP接続でドライブ共有をしなくなる
reg add "HKLM\Software\Microsoft\Terminal Server Client" /v DisableDriveRedirection /t REG_DWORD /d 1 /f
.rdp ファイルの設定はファイルごとに管理が必要で、配布された接続ファイルを使えば元に戻ってしまう。クライアント側のレジストリなら、どの .rdp で接続しても手元のドライブは共有されない。設定後に接続し直し、セッション内のエクスプローラーに手元のドライブが出てこないことを確認しておく。元に戻すときは reg delete "HKLM\Software\Microsoft\Terminal Server Client" /v DisableDriveRedirection /f で値を消す。なお、Microsoftのドキュメントが対象としているのはローカルのWindowsデバイスで、mstsc.exe 以外のクライアントでの効き方までは確認していない。
クライアント側で全面的に止めると、特定のドライブだけを共有する設定も効かなくなるので、どちらかを選ぶことになる。ファイルを転送したいときだけ共有を使いたいなら、レジストリは設定せず、drivestoredirect:s:E:\; のように転送専用のドライブだけを指定するのが現実的な落としどころになる。USBメモリやVHDXの仮想ディスクに転送用のファイルだけを置いておけば、接続先が侵害されても見えるのはそのドライブだけになる。
サーバー側：管理しているサーバーで共有を受け付けない
自分でWindowsサーバーを運用している場合は、グループポリシーで止められる。
コンピューターの構成
└ 管理用テンプレート
└ Windows コンポーネント
└ リモート デスクトップ サービス
└ リモート デスクトップ セッション ホスト
└ デバイスとリソースのリダイレクト
└ 「ドライブのリダイレクトを許可しない」→ 有効
レジストリでは HKLM\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services の fDisableCdm（DWORD）を 1 にした状態になる。Microsoftのドキュメントによると、これを有効にするとクリップボード経由のファイルコピーもできなくなる（テキストや画像のコピーは影響を受けない）。
ただし今回のようにサーバー自体が乗っ取られている場合、サーバー側の設定は攻撃者に書き換えられうる。利用者が自分を守る手段としては、クライアント側の設定が本命になる。
利用者が今やること
デスクトップクラウドの利用者向けには、公式が具体的な対応を案内している。要点は以下。
- デスクトップクラウドのサーバー以外の端末から、取引口座のパスワードを変更する
- 取引会社のマイページなどで全セッションを切断する
- 手元のPCでウイルス対策ソフトのフルスキャンとバックアップを行う
- 攻撃者が公開したとされる情報にはアクセスせず、拡散もしない（アクセスしてしまった場合はフルスキャン）
- 便乗したフィッシングや詐欺、「被害金を取り戻す」などと費用を求める連絡には応じない（GMOがパスワードや認証コードを尋ねることはない）
あわせて、今回の件をきっかけに上記の手順でRDPのドライブ共有を見直しておくと、今後ほかのVPSやリモート環境を使うときのリスクも下げられる。
まとめ
- 「お名前.com デスクトップクラウド」の事件は、第12報（10月27日夜）の時点でも侵入経路が公表されていない。GMOが認めているのは「システムにセキュリティ上の問題が存在した」ことと、顧客情報の外部持ち出し、取引口座の不正操作の報告まで
- RDPドライブ共有を使って自宅PCに到達したというのは攻撃者側の主張で、未確認。ただし、接続先が侵害されると共有中のローカルドライブがセッション内のプログラムから読み書きできるのはRDPの仕様どおり
-
.rdpのdrivestoredirectを確認し、普段は共有しない。クライアント側のDisableDriveRedirectionなら、接続ファイルに関係なく手元のPCを守れる。転送が必要なら専用ドライブだけを共有する
VPSやクラウドPCは「接続先は事業者が守ってくれる」と考えがちだが、RDPのドライブ共有を有効にしていると、接続先のセキュリティ事故が手元のPCまで広がりうる。便利な機能ほど、どこまでを信頼しているのかを一度確認しておきたい。
この記事は Zenn にも同じ内容を投稿しています。