GMO 不正アクセス｜管理者権限の設計リスクと企業が確認すべき対策

はじめに

2026 年 10 月、GMO インターネットが提供する FX 自動売買向け VPS「お名前.com デスクトップクラウド」で大規模な不正アクセスが発覚しました。11 月 2 日の記者会見では、攻撃者が顧客の VPS を足がかりに管理者アカウントを窃取し、事業者側の管理サーバーを経由して顧客 VPS へマルウェアを配布したという経路が説明されています。

この事件は VPS 事業者だけの問題ではありません。利用者が管理者権限を持つ環境と、それを一括管理する環境が同じ認証基盤やネットワークでつながっている構成は、VDI、リモートデスクトップ環境、社内の Active Directory でも一般的です。自社の設計に同じ弱点がないかを確認したいと考えている情シス担当者やインフラエンジニアは多いと思います。

結論として、GMO の具体的な設計不備は未公表ですが、判明した攻撃経路と技術的に成立し得るシナリオから、企業が確認すべき管理者権限・ネットワーク分離・RDP 設定・監視の対策を整理しました。最優先は、利用者側の環境に高権限の認証情報が露出していないか、そこから管理サーバーへ到達できる経路が残っていないかの確認です。

本記事では、情報の確度を次の 5 区分で書き分けます。

確認済みの事実

GMO の公式発表（第 1〜16 報）と、11 月 2 日の記者会見で説明された内容。

関係者取材による報道

報道機関が関係者への取材に基づいて報じた内容。GMO が正式に詳細を公表したものではありません。

攻撃者の主張（未検証）

攻撃者とみられる人物が公開した声明として、報道・解説記事が真偽不明と明記したうえで紹介している内容。虚偽が含まれる可能性があります。

仮定のシナリオ

攻撃者の主張が事実だった場合に、技術的に成立する条件を検討したもの。GMO の実際の構成を示すものではありません。

一般的な対策

Microsoft の公式資料などに基づく、一般企業向けの設計・設定の推奨事項。

GMO 不正アクセスで確認されている事実と未公表の範囲

公式発表と会見から確認できるのは、攻撃の大まかな流れと時期までです。管理者アカウントを取得した具体的な仕組みや初期侵入の手口は、捜査への影響などを理由に公表されていません。

公式発表・会見で確認された攻撃経路

11 月 2 日の会見で GMO インターネットの山下副社長が説明したタイムラインと、公式発表の経緯を整理すると次のとおりです（＠IT の会見記事、GMO 公式発表 第 3 報）

影響の可能性があるサーバー数 26,739 件について、GMO は実際に侵害された件数ではないと明記しています。10 月 29 日の第 16 報までの公式発表でも、侵入経路や原因の詳細は示されていません。

参考: GMO インターネット 第 3 報
上記は対象となり得るサーバー数であり、不正アクセスまたは情報取得が確認された件数ではありません。
https://internet.gmo/news/article/248/

会見では、接続元である利用者の PC からファイルが窃取された可能性があり、その経路として RDP のドライブ共有機能が悪用されたと説明されました。ドライブ共有は利用者の利便性のために当初から有効にしており、オフへ変更しなかった点にリスク分析の甘さがあったとしています。一方、8 月の管理サーバー侵入から 10 月の発覚まで気付けなかった理由については、今後検証するとして具体的な説明はありませんでした。

図のうち、各段階の発生と時期は会見で確認された事実です。「どのように管理者アカウントを取得したか」「顧客 VPS から管理サーバーへどの経路で到達したか」は未公表のため、推測で補わないよう注意してください。

報道で伝えられている「設計上の不備」

TBS は 11 月 3 日、関係者への取材に基づき、問題のサーバーの仕様に設計上の不備があり、それを突いて管理者権限を奪われたと報じました。

参考: TBS NEWS DIG（11 月 3 日、関係者取材による報道）
この設計ミスを突いて、攻撃者がサーバーの管理者権限を奪いとることができた
https://newsdig.tbs.co.jp/articles/-/3058685

ただし、どの部分の設計がどのように不備だったのかは報じられておらず、GMO も正式な詳細を公表していません。「サーバー仕様の設計上の不備が管理者権限の奪取につながった」という点までが報道の範囲です。

2024 年の指摘と、今回の侵入との関係

会見では、グループ会社の GMO サイバーセキュリティ byイエラエが 2024 年 4 月 24 日に本サービスの課題を指摘し、同年 4 月 26 日から 5 月 20 日に計 4 回の緊急メンテナンスを実施したものの、対策は十分ではなかったと説明されました（時事ドットコム）。＠IT によると、同一環境への追跡診断は実施されておらず、指摘は事業責任者やシステム担当役員までは共有されていた一方、グループ代表には報告されていませんでした。

2024 年に指摘された課題の詳細は未公表であり、今回の管理者権限の奪取に使われた設計不備と同一かどうかは確定していません。このため本記事では、2024 年の指摘を「侵入原因」ではなく、「指摘後の是正管理が機能しなかった事例」として扱います。

管理者権限の設計リスク: 顧客環境と管理環境の権限境界

今回確認されている事実のうち、技術的に最も重要なのは「利用者側の環境で得た管理者権限で、事業者側の管理サーバーに入れた」という点です。ここからは GMO の実際の構成ではなく、一般的な参考構成として権限境界の考え方を整理します。

顧客 VPS と管理サーバーの役割の違い

利用者環境は、利用者が任意のソフトウェアを動かす以上、いつ侵害されてもおかしくない領域として扱うのが前提です。信頼レベルの低い環境から高い環境へ、認証情報や通信経路を通じて影響が及ばない設計にすることが権限境界の目的です。

管理ネットワークの分離と管理サーバーへのアクセス制御

一般的な参考構成では、次の 3 点で利用者環境から管理環境への到達を制限します。

• 通信経路の制限: 管理サーバーの管理用ポート（RDP、WinRM、SMB、管理 API 等）へは、管理専用のネットワークや踏み台からのみ到達できるようにし、利用者 VM のセグメントからの接続をファイアウォールで拒否する
• 認証情報の分離: 管理サーバーにログオンできるアカウントを、利用者 VM へのサポート作業に使うアカウントと分ける
• 管理端末の限定: 管理操作は専用の管理端末（PAW）から行い、メールや Web 閲覧に使う端末から管理サーバーへ接続しない

ネットワーク分離だけでは十分ではない点にも注意が必要です。Microsoft の AD DS ティアモデルは、境界を決めるのは IP アドレスではなく認証情報と操作端末であり、ネットワーク分割はそれを補完するものと位置付けています。境界の内側を無条件に信頼しない考え方は、関連記事『ゼロトラストとは｜NIST SP 800-207 の原則と構成のポイント』で整理しています。

この図で理解したいのは、通信経路と認証情報の 2 つの経路をそれぞれ遮断する必要があることです。どちらか一方が残っていれば、利用者環境の侵害が管理環境へ波及する余地が残ります。

攻撃者の主張が事実だった場合の成立条件: 共通管理者アカウントと Active Directory

攻撃者とみられる人物は 10 月 24 日ごろに声明を公開しました。アゴラ言論プラットフォームは、記載内容の真偽は不明と明記したうえで声明を翻訳・紹介しています（アゴラ: GMO インターネットへの挑戦状）。ここでは主張を事実として扱わず、成立するために必要な条件と、成立しない場合を整理します。

攻撃者が主張している内容（未検証）

• VPS のネットワークが Active Directory 環境で構成され、ある VPS から別の VPS へ移動できた
• すべての VPS に対して管理者権限を持つ単一のアカウントが存在した
• サポート担当者が利用者の環境へ接続した際に、そのアカウントの認証情報を取得できた
• GMO が提供した RDP ファイルでドライブ共有が有効になっていた

このうち、ドライブ共有が有効だった点は会見で GMO も認めています。それ以外の 3 点は GMO が確認した事実ではなく、公式発表でも触れられていません。なお GMO は、10 月 27 日に攻撃者が公開した情報についても、事実と異なる内容が含まれるおそれがあるとしています。

攻撃者が公開する情報には、捜査のかく乱や企業への圧力を目的とした虚偽が含まれる可能性があります。主張の真偽を判断するのではなく、「自社で同じ条件がそろっていないか」という観点で読むことをおすすめします。

技術的に成立する前提条件と、成立しない場合

「1 台の VPS の侵害から多数の VPS を掌握する」というシナリオが成立するには、複数の条件が同時にそろう必要があります。

①〜③のいずれか 1 つでも断ち切られていれば、1 台の侵害が全台の侵害に直結するシナリオは成立しにくくなります。ただし、これは今回の攻撃を確実に防げたことを意味しません。GMO の初期侵入や管理者権限の奪取の手口は未公表であり、上記と異なる経路が使われた可能性もあります。

Active Directory を使うこと自体が問題なのではない

攻撃者の主張には、VPS 環境で AD を使うこと自体を問題視する論調も見られます。しかし、AD は多数の Windows を一元管理する標準的な仕組みであり、使用そのものが脆弱性ではありません。問題になるのは、権限の割り当て、認証情報の扱い、環境間の分離です。AD の基本的な仕組みは、関連記事『Active Directory とは』で解説しています。

Microsoft の AD DS ティアモデルは、資産と管理アカウントを Tier 0（ドメインコントローラーなど ID 基盤）、Tier 1（サーバーとアプリケーション）、Tier 2（利用者端末）に分け、上位の認証情報を下位のシステムで使わないことを原則としています。

参考: Microsoft Learn: Tier model for Active Directory Domain Services
“administrators never use higher-tier credentials on lower-tier systems”
（管理者は上位ティアの認証情報を下位ティアのシステムで使用しない）
https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/tier-model

同資料では、日常業務でのドメイン管理者アカウントの使用や、複数のティアにまたがる共有サービスアカウント、ドメイン管理者権限で動作する監視・バックアップ・EDR エージェントを、境界を崩す典型例として挙げています。ティアモデルでは、サーバーは一般に Tier 1、利用者端末は Tier 2 に分類されます。顧客 VPS はサーバーですが、契約者が管理者権限を持ち事業者が中身を管理できない環境です。そのため、どのティアに当てはめるかを機械的に決めるよりも、管理基盤とは別の信頼境界に置き、「下位の環境に上位の認証情報を持ち込まない」という原則を応用する考え方が適しています。

Windows LAPS とドメイン管理者の権限分離の違い

共通管理者アカウントの対策としてよく挙がるのが Windows LAPS です。ただし、Windows LAPS が管理するのはローカル管理者アカウントのパスワードであり、ドメインアカウントの権限分離を代替するものではありません。

参考: Microsoft Learn: What is Windows LAPS
“automatically manages and backs up the password of a local administrator account”
（ローカル管理者アカウントのパスワードを自動で管理し、バックアップする）
https://learn.microsoft.com/en-us/windows-server/identity/laps/laps-overview

Windows LAPS は Windows Server 2019 以降と、サポート対象の Windows 10 / 11 で利用できます。パスワードの保存先は Microsoft Entra ID または Windows Server Active Directory のいずれかで、両方には同時にバックアップできません。設定と運用は Windows LAPS の公式資料と LAPS PowerShell モジュールのリファレンスを確認してください。

この比較図では、LAPS が「ローカル管理者の横展開」を、ティア分離が「ドメインアカウントの横展開」を、それぞれ別々に断ち切る点を押さえてください。どちらか一方だけでは、もう一方の経路が残ります。

RDP 接続時に認証情報を渡さない接続方式

攻撃者が主張する「サポート担当者の接続時に認証情報を取得できた」という状況は、通常の RDP 接続の仕様と関係します。Microsoft は、Remote Credential Guard を使わない通常の RDP 接続について、資格情報が接続先へ送られて保存されると説明しています。

参考: Microsoft Learn: Remote Credential Guard
“Credentials are sent to and stored on the remote host”
（資格情報はリモートホストへ送信され、保存される）
https://learn.microsoft.com/en-us/windows/security/identity-protection/remote-credential-guard

これを防ぐ一般的な対策として、Microsoft は Restricted Admin モードと Remote Credential Guard の 2 つの接続方式を用意しています。どちらも資格情報を接続先へ送りませんが、保護できる範囲と適切な利用場面が異なるため、同じ対策として扱わないよう注意が必要です。なお、GMO がこれらの方式を使っていたかどうかは公表されていません。

Microsoft は、ヘルプデスクのように侵害されている可能性がある接続先へ管理者が接続する用途では、Remote Credential Guard ではなく Restricted Admin モードを推奨しています。接続ごとに指定する場合は次のオプションを使います。

mstsc.exe /restrictedAdmin

クライアント側で強制する場合は、グループポリシーの Computer Configuration > Administrative Templates > System > Credentials Delegation > Restrict delegation of credentials to remote servers を有効にし、Require Restricted Admin などを選択します。接続先ホスト側では、Computer Configuration > Administrative Templates > System > Credentials Delegation の「Remote host allows delegation of nonexportable credentials」を有効にしておく必要があり、未構成の場合は Restricted Admin モードも Remote Credential Guard も利用できません。また、クライアントのポリシーで「Restrict Credential Delegation」を選択した場合は /restrictedAdmin の指定が無視され、ポリシーの構成（Remote Credential Guard 優先）が適用されます。運用で Restricted Admin モードを確実に使いたい場合は「Require Restricted Admin」を選びます（Remote Credential Guard の公式資料）。

RDP ドライブ共有のリスクと制限方法

RDP のドライブ共有（ドライブリダイレクト）は、接続元 PC のドライブを接続先のセッションから参照できるようにする機能です。GMO の会見で、利用者 PC からのファイル窃取の経路として悪用された可能性が説明されたのがこの機能です。

ドライブ共有で接続元 PC のファイルが見える仕組み

ドライブ共有を有効にして接続すると、接続先のエクスプローラーに接続元のドライブが「<ドライブ文字> on <接続元 PC 名>」の形式で表示され、セッション内のプログラムから読み書きできます。接続先がすでに侵害されている場合、そこで動くマルウェアは、接続している利用者の権限で接続元のドライブにアクセスできる状態になります。

ここで区別したいのは、ドライブ共有によるファイルへのアクセスと、接続元 PC での任意のコード実行は別の問題だという点です。ドライブ共有で可能になるのは共有されたドライブ上のファイルの読み書きであり、それ自体が接続元 PC 上でプログラムを実行させるわけではありません。ただし、書き込みが可能な以上、利用者が後から開くファイルを改ざんされる余地は残ります。また、ドライブ共有は管理者権限の窃取とは別の経路であり、今回の管理者権限の奪取の原因とは位置付けられていません。

この図では、データの流れが「接続先から接続元へ」向かう点に注目してください。接続先を信頼できない環境では、接続元のドライブを差し出す形になるため、共有の要否を接続先の信頼レベルで判断する必要があります。

.rdp ファイルとグループポリシーで制限する手順

Microsoft は 2026 年 4 月のセキュリティ更新で、.rdp ファイルを開いた際の警告を強化しました。更新後は、.rdp ファイルが要求するドライブやクリップボードなどのリダイレクトが既定でオフになり、接続ごとに表示されるダイアログで利用者が個別に許可する方式になっています。

参考: Microsoft Learn: Understanding security warnings when opening RDP files
“all redirections requested by RDP files are turned off by default unless you opt into them”
（RDP ファイルが要求するリダイレクトは、利用者が許可しない限り既定ですべてオフになる）
https://learn.microsoft.com/en-us/windows-server/remote/remote-desktop-services/remotepc/understanding-security-warnings

ただし、この変更には適用条件があり、Windows Update の適用だけで共有のリスクがなくなるわけではありません。

• 対象は .rdp ファイルを開いて開始する接続のみ: リモートデスクトップ接続に接続先のコンピューター名を直接入力する手動接続では、従来の動作が変わりません
• 信頼済み発行元の署名付きファイルは扱いが異なる: 組織がグループポリシーで信頼済み発行元の証明書を指定している場合、その証明書で署名された .rdp ファイルは警告なしで開き、ファイルに記述されたリダイレクトが有効になる構成があります（Microsoft Learn: Manage RDP file security settings with Group Policy）
• 以前の動作へ戻す設定がある: 管理者向けに HKLM\Software\Policies\Microsoft\Windows NT\Terminal Services\Client の RedirectionWarningDialogVersion を 1 にして以前のダイアログに戻す一時的な方法が用意されています。組織で設定されていないか確認が必要です
• 利用者が許可すれば共有は有効になる: ダイアログでドライブを選択すれば、従来どおり接続先から参照できます

クライアント側の更新に依存せず、接続先のグループポリシーと、配布している .rdp ファイルの設定を確認することが重要です。接続先を管理する側で制限をかける手順は次のとおりです。

drivestoredirect:s:

reg query "HKLM\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services" /v fDisableCdm

上記のコマンドと設定値は公式資料および STIG の記載に基づくもので、本記事の執筆にあたって実機での動作確認は行っていません。適用前に検証環境で確認することを推奨します。

クリップボード共有と業務への影響

クリップボードの共有も、接続先と接続元の間で双方向にデータが流れる機能です。.rdp ファイルでは redirectclipboard:i:0 で無効にできます（Supported RDP properties）。また、Microsoft の資料では、より制限の強い設定が優先されるため、接続元の端末側で無効化した場合は接続先の設定にかかわらず利用できなくなると説明されています。

ドライブ共有やクリップボード共有を一律に禁止すると、ファイルの受け渡しやコピー＆ペーストを前提にした手順が止まります。利用者環境や外部事業者の VDI など信頼レベルの低い接続先から優先して制限し、社内の管理端末どうしなど必要性が高い経路は、代替手段の準備後に段階的に適用する進め方が現実的です。

管理者操作の監視と、脆弱性指摘後の是正管理

GMO は 8 月 17 日の管理サーバー侵入から 10 月 20 日の発覚まで、顧客からの問い合わせを受けるまで不正アクセスに気付けませんでした。何の監視が不足していたかは未公表のため、ここでは一般的な監視と是正管理の仕組みとして整理します。

管理者ログオンと大量配布を検知する

管理者アカウントの悪用は、正規の認証情報を使うため不正なログインとして目立ちにくい点が特徴です。そのため、「誰が、どこから、どこへ、いつ」ログオンしたかを通常時と比較する監視が中心になります。Windows の監査ログでは次のイベントが起点になります。

いずれのイベントも、正規の管理作業で日常的に記録されます。イベント単独で不正と断定せず、アカウント、接続元、対象サーバー、時間帯を組み合わせ、通常時との差で判断することが前提です。たとえば「サポート用アカウントが、普段は接続しない管理サーバーへ、利用者 VM のセグメントから種類 3 でログオンした」という組み合わせは、個々のイベントよりも強い兆候になります。

イベントの詳細は Microsoft Learn: 4624と 4672 を参照してください。ログオンの監視に加え、管理サーバーからの短時間での大量のプログラム配布やスケジュールタスクの作成、権限グループへのメンバー追加、普段実行されないプロセスの起動なども、EDR や SIEM で相関分析する対象になります。ネットワーク側で横展開を検知する製品の選び方は、関連記事『NDR 製品の選び方』も参考にしてください。

検知後は、該当アカウントの無効化とパスワードリセット、関連セッションの切断、影響を受けたホストのネットワーク隔離を優先します。共通の認証情報が使われていた場合、1 つのアカウントを止めても同じ権限を持つ別の認証情報が残る可能性があるため、権限を持つアカウントの棚卸しを並行して行う必要があります。

脆弱性診断から修正完了までの管理

2024 年の事例で会見から読み取れるのは、指摘を受けて対策を実施したものの、その効果を再診断で確かめず、重大性の判断も経営層へ共有されなかったという流れです。これを防ぐには、診断結果を「対策した」ではなく「解消を確認した」で閉じるプロセスが必要です。

このフローで押さえたいのは、「再診断」と「エスカレーション基準」の 2 つが欠けると、対策済みという認識のまま問題が残り続ける点です。会見でも、エスカレーション基準が社内に存在しなかったことが原因の一つとして挙げられています。

自社で優先して確認すべき 5 項目

ここまでの内容を、一般企業の情シス担当者やインフラエンジニアが自社で確認する順番に並べました。上位の項目ほど、1 台の侵害が全体の侵害につながる経路を直接断つ対策です。

どこから着手するか迷う場合は、このフローの順に確認してください。優先度 1 と 2 は設定変更の影響範囲が大きいため、変更前に影響を受けるサービスアカウントや運用手順を洗い出し、変更後は該当アカウントでの管理作業と監視ログの記録を確認する流れで進めることを推奨します。

まとめ

GMO の不正アクセスで技術的に最も重要なのは、利用者環境で得た管理者権限で管理環境へ入れたという点です。具体的な設計不備は未公表ですが、権限境界、認証情報の露出、RDP の共有設定、監視、是正管理の 5 つは、どの企業でも同じ観点で点検できます。

• 確認済みの事実と、報道・攻撃者の主張を分けて判断することが重要です。
• 利用者環境は侵害を前提とし、管理環境への経路を断つ設計が基本です。
• 共通管理者アカウントの悪用は、権限範囲と到達経路の両方で防ぎます。
• Windows LAPS はローカル管理者のみを対象とし、ティア分離の代替ではありません。
• RDP ドライブ共有は、信頼できない接続先から優先して制限します。
• 管理者ログオンと大量操作の監視が、侵入の早期発見につながります。
• 脆弱性指摘は、再診断で解消を確認して初めて完了と扱います。

以上、最後までお読みいただきありがとうございました。