お名前.comデスクトップクラウドで不正アクセス：FX被害報告と利用者が取るべき対策

GMOインターネットが提供する「お名前.com デスクトップクラウド」で不正アクセスが発生し、FXなどの取引口座を勝手に操作されたという報告が出ています。10月22日の公式の第2報は、サーバー内の口座ログイン情報が取得され、不正利用された可能性を認めました。利用者には、別の端末からのパスワード変更とログオフを至急求めています。

本稿は2026年10月23日に確認した公表情報に基づきます。公式発表は10月22日16時59分時点の第2報を中心に、23日朝の報道も参照しました。確認済みの事実、利用者からの被害申告、一般に考えられるリスクを区別しています。

何が起きたのか

お名前.com デスクトップクラウドは、インターネット経由で利用する仮想Windows環境です。サービスの説明では、取引ソフト「MetaTrader 4／5（MT4／MT5）」と自動売買プログラム「EA」を常時動かす用途が中心になっています。自宅のパソコンを切っても取引を続けられる一方、口座を操作できる環境を外部のサーバーに置くことになります。

GMOの発表に沿うと、経緯は次のとおりです。

影響の可能性があるサーバーは26,739件です。これはあくまで可能性であって感染が確定した台数ではありませんが、かなりの数です。被害者数や被害口座数は未確定で、今後増える可能性もあります。第二報では全プランの停止を継続し、再開時期は未定としています。

第一報には、情報の悪用は確認していないという説明がありました。しかし、その後に口座の不正操作の報告が寄せられています。詳しい侵入経路、攻撃開始時期、攻撃者、確定した被害件数・総額は、確認した公式発表では明らかになっていません。

同時期にPHPの脆弱性への対応も案内されていますが、本件との因果関係は公表されていません。利用者のパスワード管理、RDPの欠陥、運営側の管理基盤の侵害など、現段階では原因特定に至っていません。

被害報告と、証券・FX事業者への影響

10月23日朝のITmedia NEWSは、意図しない取引で55万円、230万円、600万円を失ったとするX上の投稿を紹介しています。

OANDA証券の22日の案内では、会員向けマイページとMT4／MT5の両方についてパスワード変更を求め、取引履歴の確認と二段階認証の利用を呼びかけています。AIゴールド証券も、不正なログイン・取引・出金申請の監視を強化するとしています。

また、OANDA証券は出金処理の日程を一時的に変更しました。22日午前11時までに受け付けた出金依頼は、安全確認後、23日午前11時以降に順次処理する予定と案内しています。

デスクトップクラウドの侵害が重大になる理由

デスクトップクラウドには、ファイルだけでなく、ログイン済みのアプリケーションや、そのアプリが使う認証情報も存在します。取引ソフトを動かすWindows環境を攻撃者に操作されると、口座の情報を読まれるだけでなく、利用者の権限で注文を出される危険があります。

クラウドへのログインと、証券・FX会社へのログインを分けて考える必要があります。仮に口座の認証情報が外部へ持ち出されていれば、元のクラウドサーバーを停止しても、攻撃者が別の環境から口座へ接続する可能性は残ります。このため、クラウドの停止と、口座側での認証情報の変更・接続の無効化は、別々の対応になります。（クラウド上にパスワードが平文で置いているユーザーの場合は大変な被害が予想されます）

金銭被害も、外部への不正送金だけではありません。MetaTraderの仕組みでは、取引端末から送られた注文を証券・FX会社のサーバーが処理します。第三者が勝手に注文や決済を行えば、相場変動や売買価格差などを通じて損失が生じ得ます。出金を制限していても、不正な売買そのものを防げるとは限りません。

GMOは、クレジットカード情報を含む決済情報を本サービスのサーバー上で保持していないと説明しています。とはいえ、ひょっとするとパスワードが盗み出されている恐れがあるため、ユーザー側の対策も被害拡大を防ぐためには重要です。

他の利用者やサービスへの攻撃に広がる可能性

以下は、クラウド上のWindows環境が侵害された場合に一般に考えられる波及経路です。CISAの対策ガイドでも、侵害された認証情報や遠隔接続を通じた侵入拡大に対し、アクセスの制限とネットワークの分離を勧めています。

侵害された端末が大量の通信を送る攻撃に利用される仕組みは、FBIのIC3によるボットネットの解説でも説明されています。（本件の不正アクセスにDDoS攻撃などに使われたかは不明です）

クラウドを利用していた方は、自宅のパソコンにも被害が及んでいないか気になると思います。今回の公表情報だけでは、そこまでは分かりません。影響を調べるには、クラウドと自宅のパソコンとの間でファイルを共有していたか、どのような接続設定を使っていたかを今一度確認する必要があります。

利用者が今、優先して行いたい対応

最初に使うのは、影響が疑われるクラウド以外の端末です。普段使っている公式アプリやブックマークから証券・FX会社へアクセスしてください。GMOの第2報の対応依頼と、契約先の最新案内を確認しながら、次の順に進めます。

1. 1. 取引口座への不正な接続を止める。MT4／MT5などの取引パスワードと、会員ページのパスワードをそれぞれ確認して変更します。お名前.comの会員パスワードだけを変えて完了としないでください。ログオフに加え、既存の接続を一括で無効化する方法を取引先へ確認します。自分の端末でログアウトしただけでは、他の端末の接続まで切れたとは限りません。操作できない場合や不審な取引が続く場合は、口座の利用制限を含めて至急相談します。
   2. 残高だけでなく、注文と履歴を確認する。保有ポジション、未約定注文、損切り・利益確定の設定、取引履歴、出金申請、登録情報の変更を点検します。不審な注文番号や日時を控え、取引先へ連絡してください。調査のための記録保存と、追加被害を止める対応を並行して進めます。
   3. クラウド内で使った別の認証情報も点検する。メール、クラウドストレージ、業務システムなどの保存情報を洗い出し、露出が疑われるパスワードを変更します。APIキーやSSH鍵などは、必要に応じて失効・再発行します。仕事用の情報が含まれる場合は、所属先の管理担当者にも連絡してください。
   4. 多要素認証の適用範囲を確認する。提供されていれば有効にします。ただし、会員ページ、取引端末、出金で認証の仕組みが分かれていることがあります。ログイン済みの環境を操作される場合など、多要素認証だけでは防げない攻撃もあります。認証情報の変更や接続の無効化を省略しないでください。
   5. 記録を残し、便乗詐欺を避ける。取引明細、通知メール、問い合わせ番号、変更した日時を保存します。不審な添付ファイルや「復旧ツール」は実行せず、正規の窓口へ相談します。証拠になり得るクラウド環境を、調査担当者と相談せず初期化・削除しないでください。

EAが止まっても保有ポジションは残る

サーバー停止には、情報漏えいとは別の運用リスクもあります。クラウド上のEAが停止しても、証券・FX会社側で保有しているポジションが自動的に解消されるわけではありません。EAが担当していた注文の変更や決済判断が止まれば、想定していた管理が続かなくなる可能性があります。

MetaTrader 5の公式ヘルプは、端末側で動くトレーリングストップと、サーバー側で扱うストップロス・テイクプロフィットを区別しています。端末が停止するとトレーリングストップの更新は止まりますが、すでに設定されたストップロスは残ります。EA独自の決済処理を含め、何が端末側で動き、何が取引サーバーに登録済みなのかを確認してください。

復旧や別環境への移行を急ぐ場合も、侵害が疑われる環境を丸ごとコピーしたり、新しいパスワードを安全未確認の環境へ入力したりすることは避けます。調査用の記録を保全したうえで、信頼できる配布元から環境を構築し直し、EAや設定ファイルも必要性と安全性を確認して戻すことが基本です。再開時には、移行前後のEAが重複して動かないことも確認します。

復旧・補償と今後のクラウド運用への影響

今後の公式発表では、侵入経路の特定、取得された情報の範囲、不正プログラムの除去や環境再構築、安全を確認した根拠、取引被害の調査と相談手順を確認する必要があります。

また、ユーザー側の自衛も重要です。重要な情報を一つのファイルや一つのデバイスにまとめない、平文で保存しない、パスワード（一部もしくは全部）は紙に書くなど物理的に保存する、などの対策は有効です。サービスからログアウトしてログイン情報を残さないことも有効でしょう。

補償については、通常のサービス品質保証制度（SLA）と、口座で生じた損失への対応を分けて読む必要があります。公表されているSLAは月間稼働率に応じた利用料金の返金・充当を定めるもので、取引損失を一律に補填する制度ではありません。適用除外も定められており、サービス公式サイトは本件に伴う扱いを決定次第知らせるとしています。

本件を踏まえた運用上の検討としては、クラウドを選ぶ際には稼働率や料金だけでなく、管理権限の分離、異常な接続の検知、事故時の通知、接続を一括で止める手段、復旧方法まで見ておくのが良いでしょう。できる限りサイバー攻撃への対策が充実している業者を選択するということです。

とはいえ、GMOグループはセキュリティに強い企業というイメージがあっただけに、今回の事件はショッキングと言えます。ハッカーの侵入経路の特定が急がれます。

利用者側も、金融取引用の環境に日常のメールや業務用の管理情報を集めず、口座を別の安全な端末から確認できる状態を保つことが有効です。NISTの遠隔アクセスに関する指針も、接続元から遠隔接続の仕組みまで、各構成要素を想定される脅威に応じて保護する考え方を示しています。

複数の事業者に環境を分散すれば、停止の影響を分けられる場合があります。ただし、認証情報を同じまま複製すると漏えい時の影響は残り、管理対象も増えます。分散する場合には、権限と認証情報の分離、切り替え手順、重複稼働の防止を合わせて設計する必要があります。

今回の事案では、クラウド事業者による原因調査・安全な復旧と、利用者による口座・認証情報の保護を同時に進める必要があります。利用者は復旧を待つ間にも、取引先の公式窓口を通じて不正接続の停止と注文・履歴の確認を進めてください。