GMO RDP ドライブリダイレクト再現実験
GMO お名前.com デスクトップクラウド事案で攻撃者が主張した「配布された .rdp でドライブリダイレクトが既定で有効なら、サーバー側から接続元のファイルが見える」という仕組みを、自宅の2台で再現検証した。
ドライブリダイレクトは、接続元のドライブをリモート側の RDP セッションで利用する機能。今回は実データを使わず、ダミーファイルの列挙と読み取り、禁止設定による遮断、その解除後の再確認までを行った。
この環境では、禁止ポリシー値を設定しただけでは効かず、サーバー役の再起動後に初めて遮断が実効化した。 設定を削除して再起動すると、遮断中に差し替えたマーカーの新文面を読めた。見える → 見えない → 再び見える、という A-B-A の対照を完走した。
本実験は GMO の実環境で実際に起きたことの証明ではない。配布設定や攻撃の実態と、自宅環境で確認できた挙動を区別している。
実験環境の詳細
2026-11-01 の実験時に使用した機材・設定・記録先。実施後の状態は「後片付けと環境の復元」に記す。
| コンピューター名・機種 | MASUP001（HP ProBook 450 15.6 inch G9 Notebook PC） |
|---|---|
| OS | Windows 11 Pro（ビルド 26300） |
| CPU・メモリ・ストレージ | Intel Core i7-1255U / RAM 8GB / SSD 256GB |
| ローカルアカウント | MSP01（管理者） |
| LAN IP | 192.168.2.174（DHCP） |
| MAC・Wi-Fi SSID | MAC：30:03:C8:71:08:61Wi-Fi SSID： YKSmas318 |
| プローブ・タスク | C:\ProgramData\rdp-probe.ps1スケジュールタスク名： RDPProbe |
| プローブ結果 | C:\Users\Public\rdp-probe-result.txt |
| 実施前状態の記録 | C:\ProgramData\rdp-phase-a-before-20261101-1703.json |
| 禁止ポリシー | HKLM\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services の fDisableCdm |
| RDP レジストリ | fDenyTSConnections（実験で 1→0、復元で 0→1） |
| コンピューター名・メモリ | DESKTOP-ATQ36KS / RAM 15.9GB（実測 16GB 級） |
|---|---|
| LAN IP | 192.168.2.170 |
| Tailscale IP・名前 | 100.80.142.40desktop-atq36ks.tail70852b.ts.net |
| アカウント | wirel（SSH 用）、masu-p（接続操作用） |
| クライアント | Microsoft Remote Desktop クライアント MSI 1.2.7422.0C:\Program Files\Remote Desktop\msrdc.exe |
| ダミーフォルダ・ファイル | C:\Users\Public\rdp-dummymarker-1.txt / marker-2.txt / marker-3.txt |
| 接続ファイル | C:\Users\masu-p\Downloads\masumi-rdp-test.rdp接続先： 192.168.2.174ユーザー： MASUP001\MSP01drivestoredirect:s:* |
| 起動用タスク名 | MuseLaunchRDP |
| 接続の状態記録・操作 | C:\Users\Public\rdp-once-status.txtTailscale Serve の HTTPS 9443 経由のワンタイムページで本人が接続操作。 |
| 管理端末 | MacBook Air / LAN IP：192.168.2.82 / SSH ユーザー：yuika |
|---|---|
| ファイアウォールの接続元制限 | 192.168.2.82 と 192.168.2.170 の2か所。 |
| SSH 規則名 | Muse SSH from home LAN |
| ネットワーク | 192.168.2.0/24 |
方法：2台とダミーファイルで確かめる
- サーバー役（
MASUP001）は Windows 11 Pro。クライアント役（DESKTOP-ATQ36KS）は Windows で、Microsoft Remote Desktop MSI 版（msrdc 1.2.7422.0）を使用した。 - クライアント役に、目印の文章だけを入れたダミーファイルを3件用意した。最初の状態では各62バイト。実験用の接続ファイルで全ドライブのリダイレクトを要求し、本人の操作を経て接続した。
- サーバー役の、接続が成立した当該 RDP セッション内でプローブ（確認用プログラム）を実行した。リダイレクト先の列挙、ダミーファイル一覧、マーカー1件の先頭行を観測した。
- 同じ構成で、禁止値なし（A）、禁止値の設定（B）、禁止値を保持した再起動（B＋再起動）、禁止値の削除と再起動（A2）を比較した。禁止値はレジストリへ直接設定した
fDisableCdm=1（DWORD）。
判定は、列挙が成功したか、一覧が用意した3件と一致したか、マーカーの1行目が期待した文面と一致したかを分けて行う。各試行の新しい記録と実行セッションを照合し、プローブが実際に動いたことを確かめた。接続失敗やプローブ未実行を「遮断できた」とは数えない。
なお、A でも \\tsclient 最上位の列挙は「パスが存在しない」と失敗した。一方、ドライブ配下のダミーフォルダを直接指定すると、一覧と先頭行を取得できた。最上位の列挙結果と、ファイルへ直接到達できるかは別々に扱う必要があった。
結果：原記録の対照表
| 条件 | ログオン形態 | ダミー列挙 | マーカー読取 |
|---|---|---|---|
| ポリシーなし | 新規 | 成功（3点） | 成功（一致） |
| ポリシー値のみ | 引き継ぎ | 成功 | 成功 |
| ポリシー値のみ | 新規（ログオフ後） | 成功 | 成功 |
| ポリシー＋再起動 | 新規 | 失敗（不在） | 失敗（不在） |
| ポリシー削除＋再起動（A2） | 新規 | 成功（3点） | 成功（差し替え後の新文面と一致） |
表の「3点」はダミーファイル3件の意味。最上位の列挙を含む全判定の成功を意味しない。狭い画面では表を横にスクロールできる。
A ではダミーが見えた。B はセッション引き継ぎ後も見え、完全ログオフ後の新規ログオンでも見えた。禁止値の存在は読み戻しで確認しており、値の書き込みだけでは遮断されなかった。
B＋再起動では、プローブ上で \\tsclient 自体が不在となり、ダミーフォルダへの直接アクセスとマーカー読み取りも「不在」で失敗した。プローブの実行を確認したうえでの失敗である。A の観測を踏まえ、最上位の不在だけを遮断の根拠にはしていない。
A2 では禁止値を削除して再起動し、新規ログオンで再び3件を列挙できた。マーカーの文面は遮断中に変更しており、読めたのは差し替え後の新文面だった。古い文面や過去の成功記録を再確認しただけではない。これにより A-B-A の対照が成立した。
重要な発見：設定値と、実際に効く時点は違った
禁止値を設定したあと、再接続だけでなく完全ログオフ後の新規ログオンも試した。それでも読み取りは成功した。結果が変わったのは、禁止値を保持したままサーバー役を再起動した後だった。
今回確認できたのは、Windows 11 Pro にレジストリを直接設定した条件で、再起動を経て遮断が実効化したという事実。グループポリシー経由でも同じ反映手順になるか、Windows Server 系でも同じかは未検証である。
経緯の時系列
すべて 2026-11-01、日本時間（JST）。時刻は実施記録に基づく。
| 時刻 | 操作・観測 |
|---|---|
| 21:42:16 | 本人の操作を経て接続が成立。 |
| 21:44:26 | A。ダミー3件の列挙とマーカー先頭行の一致を確認。 |
| 21:52:13 | B。禁止値設定後、セッション引き継ぎで再接続しても読み取り成功。この試行だけでは不十分として、新規ログオンを追加。 |
| 22:00:18 | B。完全ログオフ後の新規ログオンでも、列挙・読み取り成功。 |
| 22:04:32 | サーバー役を再起動。再起動後も禁止値が保持されていることを確認。 |
| 22:11:28 | B＋再起動。新規ログオン後、プローブの実行を確認。リダイレクト先、ダミーフォルダ、マーカーはいずれも不在。 |
| 22:14 頃 | 遮断中にマーカーの文面を変更。禁止値を削除し、サーバー役を再起動。 |
| 22:39:31 | A2。新規ログオン後、3件の列挙と差し替え後の新文面の読み取りに成功。A-B-A を完走。 |
| 22:48 | X に結果の続報を投稿。 |
| 22:54〜22:56 | 後片付けと復旧確認を完了。 |
攻撃者の主張・GMO の公表・今回の観測を分ける
攻撃者の主張
検証対象は、冒頭に記した「配布された接続ファイルでドライブリダイレクトが既定有効なら、接続元のファイルがサーバー側から見える」という主張の技術的な部分である。今回の実験で、GMO が実際に配布した接続ファイルの既定値を確認したわけではない。
GMO の公表内容
本実験では GMO の公表原文との照合や、GMO の実環境・被害範囲の調査は行っていない。そのため、公表内容との一致・矛盾や、当該事案で何が実際に起きたかの判定には用いない。
今回の観測
自宅環境の認証済み RDP セッションで、クライアント役のダミーファイルが読めることと、禁止値・再起動による前後差を確認した。これは仕組みの再現であり、攻撃の実在や実データの窃取を証明するものではない。
限定と未検証
- サーバー役は Windows 11 Pro、設定はレジストリ直接書き込み。グループポリシー経由での適用と Windows Server 系は未検証。
- 使用したクライアントは GMO 利用者の標準クライアントとは別系統。設定の既定値、警告画面、利用者の操作まで同等とは仮定しない。
- 観測したのは、接続・認証が成立した当該 RDP セッション内からのアクセス。未接続・未認証、別ユーザーのセッションやサービスからの同等アクセスは検証していない。
- 試したのはダミーの列挙とマーカーの先頭行読み取り。全ファイルの読み取り、大量コピー、書き込み、実データの窃取や外部流出を実証したものではない。
- ドライブリダイレクトの遮断は、あらゆるデータ転送経路の遮断や、すでに読まれたデータの回収を意味しない。
後片付けと環境の復元
後片付けは完了し、実験用の接続設定は復元済み。サーバー役の RDP を無効化し、待ち受けがないことを確認した。実験で変更したファイアウォール規則を元に戻し、接続セッションを終了。プローブ C:\ProgramData\rdp-probe.ps1 と実験用タスク RDPProbe・MuseLaunchRDP、ダミーフォルダ C:\Users\Public\rdp-dummy 内の marker-1.txt・marker-2.txt・marker-3.txt などを撤去した。証跡は撤去前に手元へ保全した。
接続ソフトなど一部の導入物は保持し、従来の管理設定や本人が指定した電源設定は復旧対象から除いている。すべての導入物を削除したという意味での完全初期化ではない。
X での報告
本ページは実測の結果記録を基準に、実施手順の要点を合わせて作成した公開用の要約。