お名前.com不正アクセスについて考えてみた

お名前.comのVPSサービス「お名前.com デスクトップクラウド」のWindows Serverが不正アクセスを受け、顧客情報が外部に持ち出されたという事件がありました。これについて考察してみたいと思います。

※本記事は2026年10月31日時点の情報をもとにしています。

※2026年11月2日追記：GMOインターネットグループが記者会見で、侵入の経路と時期を公表しました。本文は公表前の考察としてそのまま残し、記事末尾に答え合わせを追記しています。

前提

本文を書いた時点（2026年10月31日）では、GMOインターネットは不正アクセスがあったことは認めていましたが、攻撃方法などは公表していませんでした。本文では、攻撃者側の主張が正しいと仮定して考察しています。

GMOの公表情報は https://group.gmo/info/alert/ をご確認ください。

攻撃者の主張も未確認です

攻撃者の主張は、GMOによって事実確認されたものではありません。GMOも、攻撃者を名乗る者からのメッセージに注意するよう呼びかけています。

僕は攻撃者のサイトやX（旧Twitter）を見ているわけではありません。ニュース記事などで報じられた攻撃者の主張と、実際に自分でWindows Serverを立てたときの経験、お名前.comのガイドページなどをもとにした推測になります。

なお、本記事のテーマは「どうやって被害がここまで広がったのか」です。そのため、攻撃者が主張しているRDP接続時のドライブ共有については扱いません。

参考にした記事

攻撃者側の主張

報道によると、攻撃者は以下のような主張をしています。

  1. VPS（Windows Server）をActive Directory（以下AD）で管理していた
  2. 複数の環境に共通するアカウント（特権管理者アカウント）が存在していた。また、サポート業務に伴う認証情報の扱いにも問題があった
  3. RDP（リモートデスクトップ）で接続する仕組みだった

これが正しいと仮定して、推測していきます。

GMOインターネットには複数のサービスがある

本題に入る前に、GMOインターネットはドメインやレンタルサーバーなど、複数のサービスを提供しています。

VPSでも、お名前.com デスクトップクラウドのほかにConoHa VPSがあり、こちらでもWindows Serverが提供されています。今回被害を受けたのは「お名前.com デスクトップクラウド（FX自動売買専用VPS）」で、2026年10月31日時点では、ConoHa VPSについて同様の被害の公表は確認できていません。

同じWindows Serverなのに違いはあるのか？

GMOインターネットが提供しているWindows Serverには、次の2つがあります。

  • お名前.com デスクトップクラウド（FX自動売買専用VPS）
  • ConoHa VPS for Windows Server

中の仕組みはおそらく違うと思いますが、どちらも「Windows Server」を提供するサービスで、接続方法もRDPです。そこで、両者の構成の違いから考えてみます。

※仮想基盤や物理ネットワークの違いなど、バックボーンの構成は外からわからないため考慮していません。

接続方法の違い

デスクトップクラウドの初期設定ガイド（https://www.onamae-desktop.com/guide/setting/ ）を確認すると、以下のような手順になっています。

  1. RDPファイルをダウンロード
  2. ダウンロードしたファイルを実行
  3. パスワードを入力して接続

一方、ConoHaのご利用ガイド（https://support.conoha.jp/ws/remotedesktop/ ）を確認すると、次のとおりです。

  1. サーバーのIPアドレスを確認
  2. セキュリティグループを選択
  3. サーバーのIPアドレスを入力
  4. ユーザー名を入力（Administrator）
  5. パスワードを入力

デスクトップクラウドは、RDPファイルをダウンロードして実行する方式でした。

これはおそらく、利用者層の違いによるものだと思います。ConoHa VPSは、サーバー構築をするエンジニアの利用が前提です。一方、デスクトップクラウドはFXの利用者向けで、エンジニアではない方が中心です。

エンジニアではない方にとって、ConoHaのような設定は大変です。あらかじめ設定済みのRDPファイルをダウンロードしてクリックするだけのほうが、使いやすくユーザーに優しい設計だと思います。

デスクトップクラウドの接続方法をよく見てみる

デスクトップクラウドのガイドの画像をよく見ると、接続画面に次の項目があります。

  • RDゲートウェイサーバー
  • リモートコンピューター
  • パスワード入力欄（●●●●●●●）

その後、接続が完了しています。

ConoHaではサーバーのIPアドレスを入力していますが、デスクトップクラウドでは「RDゲートウェイサーバー」を経由しています。

デスクトップクラウドはRDゲートウェイ経由で接続している

僕もさくらのVPSでWindows Serverに接続したり、普段からRDPを使ったりしていますが、接続方法はConoHaと同じで、

  • IPアドレス
  • ユーザー名
  • パスワード

を入力するだけです。RDゲートウェイサーバーを入力することはありません。

RDゲートウェイサーバーとは何？

簡単に言うと、「リモートデスクトップ専用の受付窓口」です。

会社の受付をイメージしてください。来訪者（利用者）はまず受付で本人確認をしてもらい、OKなら受付の人が奥の部屋（各VPS）まで案内してくれます。外から直接、奥の部屋のドアを叩くことはできません。

通常のRDPは、各サーバーの3389番ポートへ直接接続します。一方、RDゲートウェイは443番（HTTPS）で受け付け、本人確認をしてから奥のサーバーへ通信を中継します。

ゲートウェイは、HTTPSの証明書の関係で gw○○○.jp のようなドメイン名で指定するのが一般的です。奥のサーバーはゲートウェイ側で名前解決されるため、外からは見えない内部の名前やIPアドレスで指定されていると考えられます。この方式なら、各VPS（以下、仮想マシンとしてVMと呼びます）に外から直接RDPで接続させない構成にでき、入口のゲートウェイだけで多数のVMへの接続を受け付けられます。

RDゲートウェイの脆弱性

過去には、RDゲートウェイの脆弱性としてBlueGate（CVE-2020-0609/0610、2020年1月修正）がありました。BlueGateは「認証前に外部からコードを実行できる脆弱性」です。

今回この脆弱性が突かれたかどうかはわかりません。仮に未修正だった場合は、外部からゲートウェイそのものを乗っ取られた可能性も考えられます。

また、入口はゲートウェイの脆弱性だけとは限りません。どこかの利用者1人のIDとパスワードが盗まれ、正規の利用者としてゲートウェイを通過された可能性もあります。

AD（Active Directory）とは？

ADサーバーって何？

ADサーバーと聞いても、「なにそれ？」という方が多いと思います。一般家庭ではまず使わないので、なおさらだと思います（正式には「ドメインコントローラー」と呼びます）。

ADサーバーの役割の一つは、配下のマシンに設定をまとめて適用することです（グループポリシー）。

設定を1台ずつ変更するのは大変です。1〜2台ならなんとかなりますが、従業員30名の会社なら30台すべてに同じ設定をしなければなりません。ADサーバーを使えば、ADサーバー側で設定するだけで、配下のマシンすべてに設定を適用できます。

もう一つの大きな役割が、アカウントの一元管理です。IDとパスワードをADサーバーでまとめて管理するので、配下のどのマシンにも同じアカウントでログインできます。たとえば、「共通アカウント（特権管理者アカウント）」で全部のVMにログインする、といったことが可能です。

便利な反面、この共通アカウントを盗まれると、配下のマシンすべてに入られてしまいます。建物の全部屋を開けられるマスターキーのようなものです。

デスクトップクラウドのAD環境について

攻撃者は、VPSがADで管理されていたと主張しています。

RDゲートウェイ自体はADがなくても構築できるため、ゲートウェイ経由であることだけでAD配下とは断定できません。ただ、2万台を超えるサーバー（GMOの公表では影響の可能性があるサーバーは26,739件）を管理する規模を考えると、RDゲートウェイや各VMがADドメインに参加していた可能性は高いと考えられます。ゲートウェイが複数台に分かれていたとしても、認証の裏側は1つのADで束ねられていた可能性があります。

攻撃者の主張を正とすると……

ガイドから、RDPかつRDゲートウェイ経由で接続していたことは確実です。共通アカウントについてはわかりませんが、すべてのVMがADに参加していて、かつ全台に入れる共通の管理者アカウントがあったとすれば、1か所から入られただけで全体に影響が及ぶことはあり得ます。

アカウントロックはなかったのか？

僕は以前、さくらのVPSのWindows Serverでアカウントロックを経験しています。詳細はWindowsServerでRDPにIP制限をかけてみるをご参照ください。

アカウントロックは、パスワードを何度も間違えたときに、Windowsがアカウントを守るために一時的にログインできなくする機能です。インターネットに公開されたRDPは、botによる総当たり攻撃を受けやすく、その結果ロックされることがあります。なお、標準のAdministratorアカウントがロック対象になるかどうかはOSのバージョンによって異なります。

今回、攻撃者の主張からは、アカウントロックに関する話は出ていません。おそらくロックは起きていなかったのではないかと思います。

デスクトップクラウドは各VMが外から直接見えない構成と考えられるため、さくらのVPSのような総当たり攻撃は起きにくい構成です。また、攻撃者の主張どおり共通アカウントでログインしたのであれば、毎回ログインに成功しているため、アカウントロックが働く余地はありません。

共通アカウント（特権管理者アカウント）の危険性

ここからは、攻撃が成功した経緯ではなく、共通の特権管理者アカウントそのものの危険性について考えます。

SOCから見た特権アカウントの扱い

普段SOCアナリストとしてログを監視している立場から言うと、特権管理者アカウントがADサーバー（ドメインコントローラー）にログインしたり、権限昇格が行われたりした場合、SIEMによっては「クリティカルアラート」が出るほどの重大なイベントです。実際に、僕が扱っているSIEMでも、こうしたイベントはクリティカルアラートとして検知されます。

さらに、1つの特権アカウントが短時間に多数のサーバーへログオンするような動きがあれば、それ自体も明らかな異常です。

管理者権限はお客様（契約者）にある

ヘルプページ（https://help.onamae.com/answer/13775 ）を見ると、管理者権限はお客様（契約者）に渡されています。また、https://help.onamae.com/answer/13766 には、お客様の責任において実施してください、といった一文もあります。

※https://help.onamae.com/answer/13766 より

※https://help.onamae.com/answer/13775 より

つまり、各VMの管理者は契約者自身です。そのうえで、攻撃者の主張する共通アカウントが存在したとすると、それとは別に全VMに入れる管理者アカウントを事業者側が持っていたことになります。

Linuxでいうと

LinuxのVPSでは、rootアカウント（管理者アカウント）がユーザー側に提供されます。今回のケースは、それとは別に、全サーバーで同じパスワードのsudo権限付きアカウントを事業者側が持っているようなものです。 ※あくまでたとえです。実際にそうなっていたかはわかりません。

ユーザーサポートのために必要なアカウント？

攻撃者は、サポート業務に伴う認証情報の扱いにも問題があったと主張しています。

利用者から問い合わせがあったときに、事業者側が調査のためにログインする必要がある場面はあると思います。再インストールや監視、パスワードリセットなどのために、事業者が管理用のアカウントを持つこと自体は珍しくありません。

問題は、そのアカウントが全VMで共通だった（とされる）点です。本来であれば、VMごとに別のパスワードにする、必要なときだけ権限を付与する、といった方法で、1つのアカウントが盗まれても被害が全体に広がらない設計にできます。

推測まとめ

冒頭の攻撃者の主張について、根拠ごとに整理すると次のとおりです。

  • 確認できたこと：RDPで接続していた。RDゲートウェイを経由していた（ガイドより）。
  • 可能性が高いこと：RDゲートウェイや各VMがADに参加していた（構成と規模より）。
  • わからないが否定もできないこと：全VMに共通の特権管理者アカウントが存在した（影響範囲の広さより）。

ConoHaとの違い

2026年10月31日時点では、ConoHaのWindows Serverで同様の被害は確認できていません。

ConoHaのガイドを見る限り、ConoHaはさくらのVPSと同じく、1台ごとにグローバルIPが割り振られ、そのIPアドレスに直接接続する方式です。ユーザー名もAdministrator（ローカルアカウント）で接続しているので、AD配下にはなかったのではないかと思います。

一方、デスクトップクラウドは各VMに外から直接RDPで接続できない構成で、RDゲートウェイの奥でAD配下にあった可能性があります。

これはどちらが安全かという話ではありません。直接公開の構成は、さくらのVPSで経験したように総当たり攻撃を受けやすく、ゲートウェイ方式自体はむしろ一般的に安全な設計です。違いの本質は、1台ずつ独立しているか、ADで束ねられているかです。ConoHaは1台ずつ独立しているため、1台が侵害されても他に広がりにくい構成です。ADで束ねられた構成は管理しやすい反面、共通の特権アカウントがあると、被害が全体に広がり得ます。

多くの利用者を効率よく管理するために束ねた仕組みが、裏を返せば被害を広げる経路にもなり得る。今回の件は、そのことを改めて考えさせられる事例だと思います。

【2026年11月2日追記】記者会見で公表された経路と答え合わせ

2026年11月2日、GMOインターネットグループが記者会見を開き、侵入の時期と経路を公表しました。会見のスライドによると、被害が広がった流れは次のとおりです。

  1. 犯人が、お客様VPSの1台に侵入
  2. そのVPSで管理者権限を窃取
  3. 窃取した権限で管理サーバーに侵入
  4. 2026年9月20日〜10月14日にかけて、管理サーバーから他のお客様VPS（最大26,739VM）にファイルを配布

参考：GMO、不正アクセスで記者会見　熊谷社長らが出席（2026年11月2日）｜THE PAGE（YouTube）

答え合わせ

入口は「お客様VPS」だった

本文では、入口の候補としてRDゲートウェイの脆弱性（BlueGateなど）と、正規の利用者としてゲートウェイを通過される可能性を挙げていました。公表された図の起点は「お客様VPSに侵入」なので、ゲートウェイそのものを乗っ取ったのではなく、1台の利用者VPSが入口だったことになります。ただし、その1台目にどうやって入ったのかは公表されていません。

1台から全体に広がる構造は、本文の推測どおり

1台のVPSで管理者権限を奪い、管理サーバーを経由して全VPSにファイルを配布できた、という流れは、本文で書いた「全台に入れる共通の特権アカウントがあれば、1か所から入られただけで全体に影響が及ぶ」という推測と一致します。ADかどうかについては、スライドでは「管理サーバー」とされていて、明言はされていません。

アカウントロックについて

公表された流れでは、外からの総当たり攻撃ではなく、奪った管理者権限で内部を移動しています。毎回ログインに成功しているので、アカウントロックが働かなかったという本文の推測とも矛盾しません。

グローバルIPについて

なお、2023年のサーバー移行の告知には、移行後にグローバルIPアドレスが変更になるため、証券会社への提示に注意するよう書かれています。外から直接RDPで接続できない構成でも、外へ出るときのIPアドレスはVMごとに固定されていた可能性があります。

参考：【重要】サーバーマイグレーションのお知らせ（お名前.com）

SIEMがあれば検知できたのか

SOCアナリストの立場から見ると、今回公表された流れには、検知できたはずのポイントがいくつもあります。

  • 利用者のVPSを踏み台に、窃取した管理者権限で管理サーバーへアクセスする（本来ありえない接続元）
  • 管理サーバーから、2万台を超えるVPSへ短期間にファイルを配布する
  • 配布されたファイル（不正なプログラム）が各VPSに設置される

特に、2万台を超えるVPSへのファイル配布は、ログの量だけで明らかな異常です。それでも、配布は9月20日から10月14日まで3週間以上続き、GMOが調査を始めたのは10月19日の利用者からの問い合わせがきっかけでした。

GMOインターネットグループには、24時間365日監視のSOCサービスを提供しているGMOサイバーセキュリティ byイエラエがあります。ただ、このサービスはWAFやEDRなどのセキュリティ製品のログやアラートを分析するもので、デスクトップクラウドがその監視の対象だったのかもわかりません。利用者からの問い合わせで発覚したことを考えると、SIEMなどによる監視が導入されていなかったか、導入されていても十分に機能していなかった可能性があります。

参考：SOC サイバー攻撃防御・分析（GMOサイバーセキュリティ byイエラエ）

SIEMは入れるだけでは意味がありません。ログが集められていて、検知ルールがあり、アラートを見て動く人がいて、初めて機能します。

2024年の時点で指摘されていた

会見では、2024年4月24日に、グループ会社のGMOサイバーセキュリティ byイエラエの専門家から改善点を指摘されていたことも説明されました。その後、2024年4月26日〜5月20日に緊急メンテナンスを計4回実施したものの、対策は深さと速さの両面で十分ではなかったとしています。当時のリスク分析で何が不足していたのかは、今後検証するとのことです。

指摘された内容は公表されていません。ただ、約2年半前に専門家から改善点を指摘されていたにもかかわらず、結果として1台のVPSから全体に広がる構造が残っていた、という点は重く受け止めるべきだと思います。

追記のまとめ

外から見える情報だけで考えた本文の推測は、入口の細かい部分を除けば、大筋で公表内容と一致していました。

便利さのために束ねた仕組みは、1か所が破られたときに全体へ広がる経路になります。だからこそ、束ねる側の特権アカウントを守ること、そして異常をログで検知して止める仕組みを持つことが重要だと、改めて感じました。

« 海上釣り堀で爆釣？しました