「第三者による不正アクセス」とは？実際に何をされたのか？7つの実例で見る手口。

ニュースで「第三者による不正アクセスを受けた」と聞いても、攻撃者がどこから入り、何を持ち出したのかは、はっきりしません。この記事では、Integral Security Report の台帳で公開している497件（2026年10月26日時点）をもとに、「不正アクセス」とは何か、公表された事案では実際にどんな手口が使われていたのかを、7つの実例で読み解きます。

不正アクセスとは何か

そもそも、連日のようにニュースで飛び交う「不正アクセス」とは何でしょうか？ 法律上の「不正アクセス行為」は、不正アクセス行為の禁止等に関する法律（不正アクセス禁止法）の第2条第4項が定めています。条文を要約すると、次の3つの類型があります。

いずれも、管理者や本人の承諾を得て行う場合は除かれます。ポイントは、IDとパスワードなどによる「制限」を破って、使えないはずの状態を使えるようにすることです。第1号は「認証情報を使う」、第2号と第3号は「弱点を突く」と覚えると、本記事で見る手口と対応づけやすくなります。

この定義から、公表文の「不正アクセス」について、次の点が言えます。

1. 手口は分かりません。 脆弱性を突いた場合も、盗んだIDとパスワードを使った場合も、定義が広く「不正アクセス」になります。不正アクセスだとわかっても、詳細を知らなければ対策できません。
2. 外部の攻撃者とは限りません。 さいたま市は、2026年1月23日の発表で、公民館の時間外管理業務に従事していた委託業務従事者1名が、利用者登録・変更申請書を不正に閲覧し、8団体のシステムID・パスワードを取得して、公共施設予約システムの抽選予約に計15件申し込んでいたと公表しました。市はこれを「公共施設予約システムへの不正アクセス」と題し、不正アクセス禁止法に違反するものとしています。

書かれていた手口は、3系統に分かれる

本サイトのデータから、侵入口が書かれた192件を、入口の種類と、根拠の強さで分けて集計したものが以下です。

• 2大要因で全体の8割強（83%）を占有: 「外から見える入口」（46%）と「アカウントの悪用」（37%）が大半を占めています。
• 外部公開資産の脆弱性が最大の侵入経路: 「公開サーバの脆弱性」（33件）や「VPN・境界機器」（23件）が主な標的となっています。
• アカウント悪用は「認証情報の流用」（46件）が主体: フィッシング（25件）よりも、窃取・流用された既存の認証情報の悪用が多く見られます。
• サプライチェーンリスクが15%: 自社以外の「委託先・外部サービス」経由のインシデントも29件発生しています。
• 情報源の差異: 「認証情報の窃取・流用」や「VPN・境界機器」は、当事者組織の公表件数よりも報道・セキュリティ研究者による確認件数が上回っています。

7件の実例で見る手口

ここから、手口が比較的詳しく書かれた7件を、1件ずつ見ます。事例1〜3は「外から見える入口」、事例4〜6は「アカウントの悪用」、事例7は「委託先・外部サービス」です。

• 外から見える入口（事例1〜3）: インターネット側から到達できる機器やサーバー、サービスの弱点が起点になった事案です。
• アカウントの悪用（事例4〜6）: 脆弱性ではなく、正規のアカウントや認証情報が使われた事案です。不正アクセス禁止法の第1号（他人のIDやパスワードを入力する行為）に近い手口です。ただし、個別の事案が法律上の不正アクセス行為に当たるかは、本記事は判断しません。
• 委託先・外部サービス（事例7）: 自社ではなく、利用しているサービスや委託先の基盤が狙われ、被害が複数の組織に広がった事案です。

各事例は見出しと区切り線で分かれていて、冒頭の表で分類・タイプ・入口・被害・書かれていないことをつかめます。続けて、侵入までの流れと被害の詳細を並べました。手口は各組織の公式発表の原文で確認しており、公式が書いていることと、本記事の補足は分けて記しました。

事例1：デジタル庁「ガバメントソリューションサービス（GSS）」（2026年9月11日発表）

VPN機器は、社外から社内のネットワークに接続するための機器です。脆弱性は、ソフトウェアや機器の欠陥のうち、攻撃に悪用できるものです。

侵入までの流れ

1. VPN機器の脆弱性を利用して、システムに侵入された。この脆弱性は攻撃前に公表されていたもので、公表時の評価は「中（CVSSのMedium）」だった。CVSSは、脆弱性の危険度を点数や段階で表す指標。デジタル庁は、一般的な対応より早く対処を進めたが、修正プログラムの適用前に悪用されたと説明している。
2. 保守運用担当者のアカウントを使われた。
3. サーバー上の大量のファイルにアクセスされた。

被害

• 漏えいした可能性のある個人情報は約24.6万件。
• 6月25日に検知し、7月9日に侵入が判明した。

書かれていないこと

• 製品名とCVE番号（脆弱性ごとに付く世界共通の番号）。今後のセキュリティ確保に支障を及ぼすおそれがあるとして、公表されていない。

---

事例2：Helpfeel「Gyazo」（第三報、2026年10月21日）

侵入までの流れ

1. 画像アップロードサーバーの、動画などを変換する処理に脆弱性があった。外部から送られた入力値が適切に処理されないまま、サーバー上のコマンド（サーバーへの命令）として解釈されてしまう。
2. 第三者がこれを悪用して、変換処理用のサーバー上で任意のコマンドを実行した。
3. 同じサーバーから到達できたデータベースに接続し、大量のデータを外部のサーバーへ送信した。不正な活動が確認されたのは、9月11日午後から12日未明まで。

被害

• ユーザーに関する情報が約2,362万件（アカウント数）。
• 画像のメタデータ（撮影日時や大きさなどの付随情報）が約4.9億件、削除済み画像のメタデータが約1.74億件。
• 画像ファイル本体が大量に流出した記録はないとしている。

---

事例3：アフラック生命保険「よりそうネット」等（調査結果、2026年7月31日）

侵入までの流れ

1. 攻撃に使われたアクセスと、データ照会の手口に対する制御が不十分だった。
2. システムには不正アクセスを検知・遮断する機能があったが、アクセスの形式が通常の利用時と同様だったため、直ちに検知できなかった。
3. 短時間に大量のデータ照会があった場合に、監視・制御する機能も不足していた。

設計時のセキュリティレビューと、リリース前の侵入テストは実施していましたが、今回の手口のリスクは想定できていませんでした。

被害

• 情報漏えいが最初に発生したのは6月10日で、6月25日に判明した。
• 契約者は約440万人。うち約22万人は、保険料振替口座の情報を含む。

書かれていないこと

• 具体的な攻撃経路と、手口の詳細。

---

事例4：アスクル（第13報、2025年12月12日）

多要素認証は、パスワードに加えて、スマートフォンへの通知やコードなど、別の種類の確認を組み合わせるログイン方式です。

侵入までの流れ

1. 「例外的に多要素認証を適用していなかった」業務委託先に付与していた管理者アカウントの、IDとパスワードが漏洩した。漏れ方は、何らかの方法としか書かれていない。
2. そのアカウントが不正に利用された。

VPN機器のベンダーが2025年9月末頃に脆弱性を公表していましたが、脆弱性を悪用した侵入の痕跡は確認されませんでした。一方で、当時のログ（操作の記録）が削除されており、原因の完全な究明は困難としています。

被害

• 10月19日にランサムウェア攻撃を検知した。ランサムウェアは、データを勝手に暗号化し、元に戻すのと引き換えに金銭を要求するマルウェアです。
• 同日に、受注・出荷業務が停止した。
• 流出した情報は、事業所向けサービスのお客さま情報の一部が約59万件、個人向けサービスが約13万2,000件など。

---

事例5：マネーフォワード（第四報、2026年6月23日）

GitHubは、プログラムのソースコードを保管・共有するサービスです。リポジトリは、その保管場所です。

侵入までの流れ

1. GitHubの認証情報（ログインに使う情報）が漏えいした。漏れ方は、書かれていない。
2. その認証情報で、GitHub上のリポジトリの中身に到達された。

被害

• 影響は、GitHub上のリポジトリに含まれていたものに限定されるとされている。
• 氏名またはメールアドレスが、お客さま124名分、お取引先さま28名分、従業員（退職者を含む）2,300名分。
• 単体では個人を特定できない固有識別子が、60,449名分。

---

事例6：CAMPFIRE（調査結果、2026年6月2日）

侵入までの流れ

1. 従業員が発行したGitHubの認証情報が、従業員が個人開発で使っていたサーバー上に、意図せずアップロードされた。それを第三者に不正利用された。
2. 攻撃者は、GitHub上で閲覧できるようになった情報をもとに、社内業務用クラウド環境に関連する認証情報を探して取得した。
3. その認証情報で、クラウド環境の管理領域の一部に不正アクセスしたと判断されている。

被害

• 対象ユーザーは、重複を除いて225,846件。
• 4月3日未明に、不審な操作を検知した。
• 外部専門機関のフォレンジック調査（記録をもとに、侵入の経緯や被害を調べる調査）が完了したのは、5月30日。

---

事例7：KDDI「ISP事業者向けメールシステム」（2026年7月6日発表、7月21日更新）

ISPは、インターネット接続やメールのサービスを提供する事業者です。KDDIは、他社のISP事業者が使うメールシステムを提供していました。

侵入までの流れ

1. システムの一部として導入していた、第三者製ソフトウェアの脆弱性を悪用された。この脆弱性は、6月17日の確認時点で、ソフトウェアのベンダーが認識していないものだった。
2. 一部のISP事業者で、2026年5月16日から被害が発生していた。

被害

• メールアドレスが漏えいしたのは12,231,954名。うちパスワードも漏えいしたのは7,616,173名。
• auメールなど、KDDI自身のメールサービスは影響がないとされている。
• ニフティ、BIGLOBE、J:COMも、自社のメールサービスへの不正アクセスとして公表している（各社の発表の題名で確認）。

書かれていないこと

• 侵入されたサーバーや、情報が取得された流れ。

企業が確認したいこと

手口が書かれていない事案が半数ある以上、他社の事例だけから「自社が同じ手口を受けるか」を判断するには限界があります。手口が分からなくても有効な備えを、本記事の事例に沿って3つに絞ります。

1. 外から到達できる機器・サーバーの一覧を持つ。 入口が書かれた事案の46%は、外から見える入口でした（公表資料に明記された事案では50%）。デジタル庁は、VPN機器の脆弱性が起点でした。Gyazoは画像変換用のサーバー、KDDIは導入していた第三者製ソフトウェアが起点でした。どの機器とソフトウェアがインターネットから到達できるかを把握していなければ、脆弱性が公表されたときに、修正すべき対象が分かりません。
2. 正規のIDとパスワードでの侵入を前提にする。 入口が書かれた事案の37%は、アカウントの悪用でした。アスクルは多要素認証の例外にしていた委託先の管理者アカウント、マネーフォワードとCAMPFIREはGitHubの認証情報が起点でした。多要素認証の適用範囲に例外がないか、使われていないアカウントが残っていないか、認証情報をリポジトリなどに置いていないかを確認してください。
3. 侵入の記録を残す。 アスクルは、当時のログが削除されていたため、原因の完全な究明は困難としています。CAMPFIREは、検知からフォレンジック調査の完了まで、約2か月かかっています。入口を特定できない理由のすべてが記録の不足とは限りません（このデータから言えるのは、アスクルのように記録が残っていないと究明が難しい、という個別の例です）。記録の種類と保管期間を、事故が起きる前に決めておいてください。

「第三者による不正アクセス」という公表文からは、手口は分かりません。ただ、手口まで書かれた事案を読むと、入口は、外から到達できる機器の弱点、正規のアカウント、委託先や外部サービスの3つに整理でき、備えもそれぞれ具体的に決められます。次に「不正アクセス」というニュースを見たときは、入口が書かれているか、書かれていないかに注目してください。書かれている場合は、この3つのどれに当たるかを考えると、自社で確認すべきことが見えてきます。