GMOの不正アクセス事件を技術的に整理する｜VPS・認証情報・権限分離の基本

2026年10月、GMOインターネットが提供する「お名前.com デスクトップクラウド」で、不正アクセスが明らかになった。

ニュースを見て、「何がどうやって乗っ取られたんだろう」「防ぐ方法はなかったのかな」と気になった。せっかくなので、ITエンジニアを目指している人にも分かるように、事件の流れと関連する技術を整理してみようと思う。

最初に一つだけ注意点がある。不正なプログラムが設置され、情報が外部に持ち出されたことは確認されている。でも、攻撃者が最初にどうやって侵入したのか、どんな脆弱性を使ったのかは、まだ公表されていない。 なので、確認できた事実と「こういう攻撃なら起こり得る」という一般的な仕組みは分けて紹介する。

※この記事の事件情報は2026年10月27日時点のもの。調査が続いているため、今後の公表で内容が変わる可能性がある。

まず、どんなことが起きた？

「お名前.com デスクトップクラウド」は、インターネット経由でWindowsのデスクトップ環境を使えるサービス。FX（外国為替の売買）の自動取引ツールを動かす用途などで使われている。

まずは、GMOの発表を時系列で見てみる。

• 10月19日：利用者からの問い合わせをきっかけに調査を開始。
• 10月20日：一部の利用者のサーバー環境に、不正なプログラムが設置されていたことを確認。
• 10月21日：被害拡大を防ぐため、全プランのサーバーを順次停止。不正なFX口座操作の報告も寄せられた。
• 10月24日：サービスのシステムにセキュリティ上の問題があったこと、環境への不正アクセスと情報の外部持ち出しを確認したと公表。
• 10月27日：攻撃者とみられる者が情報と称するものを公開したことをGMOが確認。公開内容の真偽や対象範囲は引き続き確認中。ランサムウェア攻撃は同日13時44分時点で確認されていないと報じられた。

影響を受けた可能性があるサーバーは26,739件とのこと。ただ、これは「26,739台すべてが乗っ取られた」という意味ではない。実際の被害件数とは分けて考えたほうがよさそう。

出典：GMO第2報、GMO第4報、GMO第5報、10月27日の発表を伝える報道。

そもそもVPSって何？

まず、今回のサービスがどんなものなのか。ここで知っておきたいのがVPS。

VPS（Virtual Private Server） は、物理サーバーなどの計算資源を使って、利用者ごとに仮想サーバーを用意する仕組み。見た目や操作は普通のパソコンに近いけれど、実際にはデータセンター側で動いている。

学校で例えると、大きな建物の中に、利用者ごとの教室を用意する感じ。

利用者の自宅PC
       |
       | RDP（リモートデスクトップ接続）
       v
クラウド上のWindows仮想マシン（VM）
       |
       | FX取引ソフト（MT4・MT5など）が動く
       v
証券会社・FX会社の取引サーバー

よく出てくる言葉も、このあたりで整理しておく。

自宅のPCを閉じても、クラウド上のVMではソフトが動き続けられる。だから、24時間動かしたい自動売買とも相性がいい。

「サーバーを乗っ取る」って、技術的にはどういうこと？

「乗っ取る」と聞くと、攻撃者がパソコンの画面を勝手に動かすイメージがあるかもしれない。でも、実際はそれだけじゃない。

例えば、サーバーで勝手にプログラムを実行できる状態を作られると、ファイルを読まれたり、外部へデータを送られたりする場合がある。

関連する用語として、RCE（Remote Code Execution：遠隔からのコード実行） がある。離れた場所から、本来許可されていない処理を実行できてしまう脆弱性や、その結果のこと。

ただし、GMOの事件でRCEが使われたと決まったわけではない。ここからは、あくまで仕組みを理解するための例として読んでほしい。

パターンA：利用者のVMへ直接侵入する

例えば、RDPのログイン情報が流出した場合、攻撃者がその情報を悪用してVMにアクセスしようとすることがある。ほかにも、公開されているサービスの脆弱性が入口になることがある。

攻撃者
  |
  | 盗まれた認証情報や脆弱性を悪用（一般的な例）
  v
利用者AのWindows VM
  |
  v
不正なプログラムの実行

ここで気にしたいのは、侵入後にどのくらいの権限を持てたのかということ。一般ユーザーと管理者では、できる操作がかなり違う。

パターンB：サービスの管理側を侵害する

もう一つ、クラウドサービスにはVMを作ったり再起動したりするための管理システムがある。管理画面や管理API（プログラムから管理機能を呼び出す窓口）を使うのが一般的。

もし、この管理機能の守りが不十分だと、1台だけではなく複数のVMに影響が広がることも考えられる。

攻撃者
  |
  v
クラウドの管理機能
  |         |
  v         v
利用者A VM  利用者B VM

ちなみに、この図は一般的なリスクを説明したもの。GMOの実際の構成や侵入経路がこうだった、と言っているわけではない。

だから、1台のVMしか操作できない権限を奪われたのか、複数のVMを操作できる権限を奪われたのかは、かなり大きな違いになる。

どうしてFX口座まで操作されてしまった？

では、なぜクラウド上のパソコンへの攻撃が、FX口座にまでつながるんだろう。

ここでポイントになるのが、認証情報とログイン中の状態（セッション）。

取引ツールは、基本的にFX口座へログインして使う。VMの中にログイン情報が保存されていたり、ログインしたまま使える状態だったりすると、VMへの侵入が口座の被害につながる可能性がある。

例えば、次のようなことが考えられる。

1. 認証情報の窃取：保存されたID・パスワードなどを盗み、別の環境から口座にアクセスする。
2. 取引可能な状態の悪用：攻撃者が侵害されたVM上で、ログイン済みの取引ツールなどを悪用する。

どちらもあり得る方法だけど、今回どちらが使われたのかは分かっていない。

GMOも、取引ツールや取引口座のパスワード変更に加えて、**ログオフ（セッションの切断）**を案内している。ここが少しややこしいところで、サービスによってはパスワードを変えても、すでにログインしている状態がすぐには切れない場合がある。

参考：GMO第2報：認証情報の変更とセッション切断のお願い。

どうすれば防げたんだろう？

防ぎ方は、学校の防犯をイメージすると分かりやすい。

門に鍵を付けるのはもちろん大事。でも、もし入られても教室ごとに鍵が違っていて、廊下に警報機があれば、被害を広げずに済むかもしれない。

コンピューターでも、こんなふうに守りを何段階も用意しておく。これが**多層防御（Defense in Depth）**という考え方。

ただ、どれか一つを入れれば大丈夫、というわけではない。例えばWAFはWebアプリへの攻撃に役立つけど、RDPやVMの中の怪しいプログラムまで全部守ってくれるわけじゃない。

対策1：RDPを誰でも触れる状態にしない

RDP自体は便利な仕組み。でも、管理用の接続口をインターネット全体に公開すると、攻撃される機会も増えてしまう。

例えばVPNや踏み台サーバーを経由させたり、接続できるIPアドレスを絞ったり、MFAを使ったりする。不要なアカウントを残さないことも大事。

とはいえ、利用者のPCそのものが侵害されていたら、MFAだけでは守れない場合もある。もし入られても、できることを最小限にするところまで考えたい。

対策2：別の利用者のVMを操作できないようにする

今回の話で、ぜひ覚えておきたいのがテナント分離。

テナントというのは、クラウドサービスを利用する会社や顧客などのまとまりのこと。学校でいうなら、教室を借りている人たちのようなイメージ。

例えば、管理APIにこんなリクエストを送る場面を考えてみる。

POST /api/vms/123/restart

ここで大切なのは、ログインできたかどうかだけを見ないこと。

• この人は誰なのか（認証）。
• この人はVM 123を操作してよいのか（認可）。
• 操作するための管理サービスも、VM 123に必要な権限だけを持っているか（最小権限）。

数字を123から124に変えただけで他人のVMまで操作できたら困るよね。これはWebアプリでも起こり得る、アクセス制御の問題。

Laravelなら、考え方はこんなコードに近い。

// 1ユーザーが1テナントに所属する単純な例
$vm = VirtualMachine::query()
    ->where('tenant_id', $request->user()->tenant_id)
    ->findOrFail($vmId);

// そのVMを再起動してよいか、Policyで判定する
Gate::authorize('restart', $vm);

// 実際のVM操作は、必要な対象だけを操作できる権限で実施する
$vmOperator->restart($vm->id);

もちろん、これは考え方を伝えるための例で、GMOの実際のコードではない。Laravelの認可チェックに対応するPolicyや、VMを操作するためのサービスは別に実装する必要がある。

なお、1人が複数のテナントに所属できる場合は、テナントIDの単純な比較だけでは足りない。会員情報や役割に合わせた認可が必要になる。さらに、Webアプリ側の認可が正しくても、裏の管理サービスに「全VMを自由に動かせる権限」があれば、そこを奪われたときの被害は大きくなりやすい。

APIで操作してよいかを確認することと、裏側のシステムに与える権限を絞ること。 この両方が大事なんだと思う。

対策3：不正プログラムを検知して隔離する

侵入そのものを止められなくても、いつもと違うプログラムが動いたり、大量の外部通信が始まったりしたら、それに気付ける仕組みを用意しておきたい。

• EDR：パソコンやサーバーの不審な動作を監視・調査し、製品によっては隔離などもできる仕組み。
• SIEM：複数のサーバーや機器のログをまとめ、関連付けて異常を探す仕組み。
• SOC：そのような監視や事故対応を担当するチームや組織。

例えば、短時間で複数のVMに同じ見慣れないプログラムが現れたら、ただの個別トラブルではなく、共通の仕組みを通った攻撃かもしれないと考えられる。

ただし、ログがなければ後から追いかけられないし、EDRを入れただけですべて見つけられるわけでもない。設定と運用もセットで考える必要がある。

実際に調査するとき、どんなログを見る？

いざ攻撃が起きたら、「いつ、誰が、どこから入って、何をしたのか」をログから追いかける。これがフォレンジック調査の一部になる。

Windowsなら、例えばこんなログが手がかりになる。

Sysmonは、Windowsの動きを詳しく記録できるツール。ちなみにネットワーク接続を記録するイベント3は、既定では無効なので、必要なら先に設定しておく。Windowsの標準ログも、監査設定によって残る内容が変わる。

ただし、イベント4624があったからといって、すぐに不正アクセスとは限らない。普通のログインでも記録されるので、接続元や時刻、起動したプログラムなどと合わせて見ていく。

参考：Microsoft：イベント4624、Microsoft：Sysmon。

「弱点は指摘されていた」のに、なぜ防げなかった？

GMOインターネットグループの熊谷代表は、10月25日のブログで、社内のホワイトハッカーから以前から改善点を指摘されていたと説明している。

ホワイトハッカーは、攻撃のためではなく、安全性を高めるためにシステムの弱点を探す専門家のこと。

代表の説明によると、サービスを止めないこと（可用性）なども考えて対応していたものの、結果として十分な速さや深さには至らなかったそうだ。

ただし、その指摘が具体的に何だったのか、今回の侵入口と関係していたのかは分かっていない。このあたりは、まだ決めつけずに見ておきたい。

出典：熊谷正寿代表の公式ブログ（2026年10月25日）。

ここで考えさせられるのが、弱点を見つけることと、実際に直すことは別だというところ。

本番システムだと、更新のためにサービスを止めるのが難しいこともある。とはいえ「あとで直そう」だけで終わらせず、次のようなことを決めておきたい。

• どの程度危険で、いつまでに直すのか。
• すぐに修正できないなら、管理機能の停止や接続元制限で一時的に危険を減らせないか。
• だれが判断し、期限を過ぎたらどこへ報告・相談するのか。
• 更新後、修正できたことをどう検証するのか。

こういう判断や進め方も、脆弱性管理や変更管理の一部。セキュリティ対策って、ツールを入れて終わりではないんだよね。

もし自分の利用するサーバーが侵害されたら

もし実際に被害が起きたら、今度は「どう止めるか」が大切になる。

1. 被害拡大を止める：関係者と連携して、不審な環境のネットワーク接続や取引を止める。
2. 安全な端末から認証情報を変える：パスワードを変え、可能なら既存のセッションやトークンも失効させる。
3. 証拠を残す：ログ、操作履歴、必要なディスクイメージなどを保全する。むやみに初期化すると原因調査が難しくなる。
4. 影響範囲を確かめる：別のVM、別のアカウント、連携サービスへ広がっていないかを調べる。
5. 安全な環境で復旧する：原因が残ったまま同じ環境を起動しない。

もちろん、実際には被害を止めることと証拠を残すことの両立が必要なので、セキュリティ担当者やサービス提供者と相談して進める。今回の利用者なら、まずはGMOからの最新の案内を確認するのが基本。

GMOは利用者の端末のスキャンやバックアップ、アカウントの保護などを案内し、顧客PCへの影響も調べている。ただ、顧客のPCが感染したと確定しているわけではないので、そこは分けて考えたい。

参考：GMO第8報（10月27日）。

ITエンジニアを目指すなら、ここを覚えておきたい

ここまで見ると、今回の話はインフラ担当だけの問題でもないなと思う。Webアプリを作る人にも、つながる部分が結構ある。

最後に、覚えておくと役立ちそうな用語をまとめておく。

例えば自分でAPIを作るときも、ログインできるかだけじゃなく、**「そのユーザーが、そのデータを操作していいのか」**をきちんと確認したい。

それと、何か起きたときに追いかけられるログを残しておくこと。管理者権限を必要以上に広げないこと。このあたりは地味だけど、いざというときに効いてきそう。

今回のGMOの事件は、まだ分からない部分も多い。だからこそ、公表された事実と、技術的にあり得る話を分けて考えることも意識しておきたい。侵入口の詳しい情報が出たら、また違った学びがありそうだ。

参考資料

• GMOインターネット：不正アクセスに関する第2報（2026年10月22日）
• GMOインターネット：不正アクセスに関する第4報（2026年10月24日）
• GMOインターネット：被害拡大防止のお願い・第5報（2026年10月24日）
• GMOインターネット：現在の対応・第8報（2026年10月27日）
• 熊谷正寿代表：能動的サイバー防御を具申した理由（2026年10月25日）
• テレビ朝日：GMOの情報公開確認を含む不正アクセス報道（2026年10月27日）
• Microsoft Learn：Windowsイベント4624
• Microsoft Learn：Sysmon