カテゴリー: SQAT® Security 瓦版

投稿日:

ニチレイが個人情報漏洩を確認 ―第7報で判明した被害と企業が備えるべきこと

Share
ニチレイが個人情報漏洩を確認アイキャッチ画像

株式会社ニチレイは2026年9月18日、7月に発生したシステム障害に関する第7報で、サイバー攻撃を受けたサーバーの一部から個人情報の漏えいを確認したと発表しました。配送先や取引先の役職員、従業員・退職者とその家族、求職者などが対象です。7月24日には入出庫・冷凍食品出荷業務が全拠点で通常稼働へ移行していましたが、その後も調査は続き、8月の「漏えいのおそれ」の公表を経て、9月に漏えいが確認されました。本記事では、公式発表をもとに新たに判明した事実を整理し、業務復旧と漏えい調査を並行して進めるために企業が備えておきたいポイントを解説します。

※本記事は2026年10月5日時点までで確認できる公表資料に基づき作成しています。

本件については、これまでの経緯もあわせて解説しています。あわせてぜひご覧ください。

漏えいが確認された対象と件数

第7報で示されたのは3区分です。ニチレイグループ各社が受託した配送業務の配送先のお客さまは3,308件で、情報の項目は氏名、住所、電話番号です。取引先の役職員は6,849件で、会社名、所属、役職、氏名、住所、電話番号、メールアドレスが挙げられています。グループ従業員と2021年以降の退職者、その家族、求職者の区分は43,709件です。氏名や連絡先、生年月日、従業員番号などに加え、給与賞与情報、在留資格、所属・異動等の人事情報が含まれています。ただし、1件ごとに公表された全項目が含まれるわけではありません。クレジットカード情報は含まれないとしています。

第7報で公表された3区分の件数を単純に合計すると53,866件です。ただし、これは本記事で各区分を加算した値であり、ニチレイが「漏えいした人数」として公表した数字ではありません。影響を確認する際は、合計値だけでなく、対象区分と漏えいが確認された情報の項目を分けて見る必要があります。

7月の業務復旧から9月の漏えい確認まで

7月13日の第1報では、不正アクセスによるシステム障害と、ニチレイロジグループ各社の冷蔵倉庫の入出庫業務、ニチレイフーズの冷凍食品出荷業務への影響が公表されました。第7報によると、同社は発生当日にシステムを遮断し、緊急対策本部を設置しています。7月24日の第5報では、受発注制限を解除して全拠点を通常稼働へ移行したと発表しました。

その後、8月14日の第6報で一部従業員情報の漏えいのおそれを公表し、9月18日の第7報で漏えいの確認と対象区分・件数を明らかにしました。第7報には9月11日に個人情報保護委員会へ報告したことも記載されています。業務の復旧日を、そのまま調査や対象者対応の完了日と捉えないことが、公表内容を理解する上での要点です。

第7報の時点でも原因分析と影響範囲の調査は続いています。確認した同社の発表には、具体的な侵入経路や悪用された脆弱性、ランサムウェアの使用を特定する説明はありません。攻撃の名称や原因を補って解釈せず、公表済みの事実と調査中の事項を分けて捉える必要があります。

図：ニチレイの漏えい情報と復旧後の調査

出典：株式会社ニチレイ「当社グループでのシステム障害発生について（第5報）」（2026年7月24日）、「当社グループでのシステム障害発生について（第7報）」（2026年9月18日）をもとに作成
※件数を人数と同一視しません。各記録にすべての情報項目が含まれるわけではありません。

対象者への案内と二次被害への注意

ニチレイは対象者へ順次個別に連絡しており、連絡先が分からないなど個別通知が難しい場合は公表をもって案内に代えるとしています。また、第7報の公表時点では、不正利用等の二次被害は確認されていません。この説明は9月18日時点の確認状況として読む必要があります。同社は、ニチレイや公的機関、金融機関を装った不審なメール、SMS、電話への注意も呼びかけています。不審な連絡に記載されたURLへのアクセス、個人情報の提供、添付ファイルの開封を避け、関連する不審な事象は公表資料に記載された窓口へ相談するよう案内しています。対象者は個別の通知内容と公式発表を確認し、自分に関わる情報の範囲を把握することが大切です。

業務復旧と調査を並行できる体制

ここからは、公表事実と公的な手引きを踏まえた企業一般への提案です。IPAの「中小企業のためのセキュリティインシデント対応の手引き」は、被害拡大を防ぐ初動、関係者への報告・公表、証拠保全と復旧・再発防止を整理しています。事業を早く再開する準備と、被害を正確に把握して説明する準備を、同じ対応計画に組み込むことが重要です。

物流や出荷を支えるシステムでは、停止した場合にどの業務へ影響が及ぶかを平時に整理しておくと、遮断や復旧の判断を具体化できます。IT部門だけでなく、現場責任者と経営層が、優先して再開する業務、代替手段、再接続を判断する責任者を共有しておくことを勧めます。サイバー攻撃では被害範囲がすぐに分からない場合もあるため、安全性を確認する工程を復旧計画に含めることが欠かせません。

証拠・ログを残す

漏えい調査に備えて、端末やサーバー、ネットワーク機器の記録をどの担当者が保全し、専門家に何を渡すかも決めておきます。IPAは、不用意な操作で記録を消さないことや、必要に応じたフォレンジック調査を挙げています。復旧作業の担当者と調査担当者が作業内容を共有し、記録の確保を確認した上で修復を進める手順にしておけば、後から事実を確かめるための手掛かりを残せます。

説明体制では、業務の稼働状況、漏えいが確認された情報、調査中の事項、対象者への連絡状況を分けて管理する方法が考えられます。問い合わせ窓口と公表担当者が同じ更新情報を参照できるようにし、追加の事実が判明した場合の確認・承認手順まで準備しておくと、復旧後も必要な説明を続けやすくなります。これは、IPAが示す状況に応じた継続的な報告・公表を、自社の運用に落とし込むための提案です。

個人情報の保管場所・権限を把握する

今回公表された対象には、配送先や取引先だけでなく、従業員、退職者、家族、求職者が含まれます。この範囲を自社点検の手掛かりにすると、顧客データベース以外に人事・採用関連のファイルや共有領域も確認対象となります。どの部署が何の目的で保有し、どのシステムに保存しているかを整理することが、影響範囲を調べる際の基礎になります。

あわせて、業務上必要な担当者だけが情報へアクセスできるか、異動や退職に伴う権限変更が反映されているかを点検します。個人情報保護委員会の通則ガイドラインも、担当者と取り扱うデータベースの範囲を限定するアクセス制御、アクセス者の識別・認証、不正アクセス対策などを示しています。給与や人事に関する情報を扱う部門も含め、保存場所と利用権限を確認することが実務上の出発点です。

IT-BCPとフォレンジックを平時から準備する

ニチレイは第7報で、グループ全体のセキュリティと監視体制の強化に加え、事業継続計画の見直しを進めるとしています。自社でも、通常の障害復旧手順に、攻撃の封じ込め、証拠保全、情報漏えい調査を組み合わせて対応できるかを確認しておきたいところです。

サイバー攻撃を想定した復旧計画の具体化には、ブロードバンドセキュリティ（BBSec）の「ランサムウェアに対応したIT-BCP策定支援」を活用できます。同サービスはランサムウェアを含むサイバー攻撃を対象に、企業の状況やニーズに応じたIT-BCPの策定・見直しを支援します。現行計画の対象や復旧判断の手順を整理する際の相談先として、ご検討ください。

情報漏えいの疑いが生じた際には、業務復旧を進めながら、調査に必要な証拠を適切に保全し、被害状況を確認する必要があります。BBSecの「デジタルフォレンジック」では、事象の把握や証拠保全・データ収集、原因や影響範囲の調査をご支援します。平時から調査支援を依頼する手順まで整えることで、業務復旧と事実確認を進める体制を具体化できます。平時のご相談はSQAT.jpよりお問い合わせください。

インシデントレスポンス／フォレンジック

【参考情報】

編集責任：木下

ウェビナー開催のお知らせ

最新情報はこちら

Security NEWS TOPに戻る
バックナンバー TOPに戻る

投稿日:

ニチレイへのサイバー攻撃で何が起きた？ RansomHouseの主張と情報漏えいの可能性・供給網への影響

Share
「ニチレイへのサイバー攻撃で何が起きた？RansomHouseの主張と情報漏えいの可能性・供給網への影響」アイキャッチ画像

2026年7月13日、ニチレイは不正アクセスによるシステム障害を公表しました。影響は冷蔵倉庫の入出庫や冷凍食品の出荷に及び、7月24日に全拠点が通常稼働へ移行しました。その後、RansomHouseを名乗るグループによる犯行声明や、20万件以上のファイル公開が報じられています。本記事では、その後に明らかになった情報を踏まえ、公式発表で確認できる事実と攻撃者側の主張、第三者の観測を分けて整理し、食品・物流サプライチェーンへの影響と企業に求められる備えを解説します。

ニチレイが公式に確認したのは、サーバーへのサイバー攻撃、システム障害に伴う入出庫・出荷業務への影響、被害サーバーの一部に個人情報が保管されていたことです。一方、RansomHouseの関与、ランサムウェアによる暗号化、公開ファイルの真正性、情報漏えいの対象人数と範囲、侵入経路は、2026年8月13日時点で公式に確定していません。

→【続報】2026年9月18日、ニチレイは第7報で個人情報の漏えいを確認し、対象区分と件数を公表しました。最新の公表内容はこちらの記事で解説しています。
「ニチレイが個人情報漏洩を確認 ―第7報で判明した被害と企業が備えるべきこと」

※本記事は2026年8月13日時点で確認できる公表資料に基づき作成しています。RansomHouseの主張と20万件報道は、公式発表と混同しないよう補足情報として区分しています。

7月31日時点の公式発表に基づく経緯や、業務再開までの対応、BCPの観点はこちらの記事で解説しています。
前回記事（速報版）　：「ニチレイへのサイバー攻撃で食品物流に影響―業務再開までの経緯と企業が見直すべきBCP」

ニチレイへのサイバー攻撃で何が起きたのか

今回のニチレイへのサイバー攻撃は、情報システムだけの障害ではありませんでした。冷蔵倉庫の入出庫や冷凍食品の出荷が止まり、モノの流れそのものに影響が及んだ点が特徴です。食品物流は、保管温度や納品時間が厳しく管理される業務です。受発注や在庫、倉庫作業を支えるシステムが使えなくなれば、倉庫に商品があっても通常どおりに動かせない状況が起こり得ます。

ニチレイは障害発生当日に緊急対策本部を設置し、個人情報や顧客データの保護を優先してグループ内システムを遮断しました。遮断は被害拡大を防ぐために重要な措置ですが、その判断によって業務への影響が表面化することもあります。サイバーインシデントでは、「止めないこと」と「安全を確認できない状態で動かさないこと」の間で、経営判断が求められます。

ニチレイのサイバー攻撃を時系列で整理

7月13日～24日：サイバー攻撃の確認から通常稼働への移行

ニチレイは7月13日、不正アクセスによるシステム障害が発生したと発表しました。7月15日には自社サーバーへのサイバー攻撃を確認し、被害サーバーの一部に個人情報が保管されていたことから、個人情報保護委員会へ漏えいの可能性がある事案として速報しています。その後、7月17日から一部制限のもとで業務を順次再開し、7月24日には受発注制限を解除。影響を受けた全拠点が平常時の通常稼働へ移行しました。

※発生から業務再開までの詳しい経緯は、前回の速報版で解説しています。

8月7日：業績への影響を公表

8月7日の2026年12月期第1四半期決算説明資料（決算期変更に伴う変則決算）で、ニチレイはシステム障害による売上面のマイナス影響を最大50億円、営業利益への影響を8億円と見込み、緊急対応で発生したコストや今後見込まれる損失として特別損失10億円を織り込みました。金額の意味が異なるため、これらを単純に合算して「被害総額」とみなすことはできません。

8月10日：「20万件以上」のファイル公開が報じられる

8月10日、テレビ朝日ANNニュースはS&Jの観測として、RansomHouseを名乗るグループが少なくとも20万件以上のファイルを公開し、個人情報も含まれているとみられると報じました*1。ニチレイは追加で情報が公開されていることを把握しているものの、コメントを差し控えると回答したとされています。なお、8月13日時点で、ニチレイの公式サイトには第5報以降、漏えい範囲や対象人数を確定する追加発表は掲載されていません。

ニチレイから個人情報は漏えいしたのか

結論からいえば、ニチレイは「個人情報の漏えいの可能性」を公表していますが、実際に社外へ流出した情報の項目や対象人数、件数は明らかにしていません。公式に確認できるのは、被害サーバーの一部に個人情報が保管されていたこと、個人情報保護委員会へ報告したこと、対象者へ通知したことまでです。この対象者への通知が行われたこと自体も、個人情報の社外流出が確定したことを意味するものではありません。

個人情報保護法では、不正アクセスなどによる個人データの漏えいが発生した場合だけでなく、発生したおそれがある場合にも、一定の要件のもとで個人情報保護委員会への報告と本人通知が必要になります*2。したがって、「個人情報保護委員会へ報告した」という事実だけで、漏えいが確定したとは判断できません。調査が進むにつれて公表内容が更新されることもあるため、初報だけで結論づけず、続報を追う必要があります。

「20万件以上」は20万人分の個人情報ではない

報道で使われた「20万件以上」は、文書や画像、フォルダー内のデータなどを含むファイル数です。1人に複数のファイルがひもづく場合もあれば、個人情報を含まない業務資料が数えられている可能性もあります。反対に、1つのファイルに複数人の情報が含まれる可能性もあります。そのため、ファイル数から被害人数を換算することはできません。さらに、公開されたとされるファイルのすべてがニチレイから窃取された真正なデータなのか、S&Jがどの範囲を確認したのかについて、ニチレイによる公式な検証結果は出ていません。

RansomHouseとは？ニチレイへの犯行は確認されたのか

RansomHouseは、被害組織からデータを窃取し、公開をちらつかせて金銭を要求する恐喝活動で知られるグループです。パロアルトネットワークスのUnit 42は、RansomHouseをRansomware as a Service（RaaS）として分析し、データ窃取と暗号化を組み合わせる二重脅迫、ESXi環境を狙う管理ツール「MrAgent」と暗号化ツール「Mario」の利用を報告しています*3。

ただし、これはRansomHouse一般の活動に関する技術分析です。ニチレイの環境でMrAgentやMarioが使われたこと、サーバーやファイルが暗号化されたことを示すものではありません。RansomHouseを名乗るグループは犯行を主張していますが、ニチレイは攻撃主体を公式に特定しておらず、侵入経路や攻撃手法も公表していません。

サイバー攻撃は食品・物流サプライチェーンへどう波及したか

ニチレイの事例で見落とせないのは、被害が自社のサーバー内にとどまらず、商品の保管と配送を待つ取引先や、その先の店舗運営へ波及し得ることです。食品物流は、多数の荷主、倉庫、輸配送会社、小売・外食企業をつなぐ共通基盤です。中核となる事業者の機能が止まれば、取引先自身のシステムが侵害されていなくても、商品を受け取れないという形で事業が止まります。

同時期、日本ケンタッキー・フライド・チキン株式会社（以降KFC）も、食材配送を委託する物流会社で発生した不正アクセス起因のシステム障害により、商品の一部品切れ、販売メニューの制限、営業時間の短縮などが生じたと公表しました*4。7月22日には全店舗への食材納品体制が整い、通常営業へ戻っています。KFCは物流委託先の社名を公表していないため、ニチレイの事案との関係を公式情報だけで断定することはできません。一方、この事例は、物流委託先のシステム障害が消費者向けサービスにまで波及し得る構造を示しています。

「サプライチェーン攻撃」と「サプライチェーンへの影響」は別物

ここで用語を分けて考える必要があります。サプライチェーン攻撃は一般に、取引先や委託先、利用するソフトウェアやサービスを足がかりとして標的へ侵入する攻撃を指します。今回、ニチレイへの侵入経路は公表されていないため、攻撃経路という意味でサプライチェーン攻撃だったとは断定できません。

一方で、サイバー攻撃による業務停止が供給網の先へ広がる「サプライチェーンリスク」は明確に表面化しました。侵入経路の問題と、事業依存関係による影響の連鎖は別の論点です。この二つを混同しないことが、ニュースを正確に読み、自社の対策へ落とし込む第一歩になります。

ニチレイが公表した業績への影響

ニチレイの2026年12月期第1四半期決算説明資料では、事業停止に伴う売上面のマイナス影響を最大50億円と見込んでいます。内訳は食品事業が20億円、低温物流事業が30億円です。営業利益への影響は8億円で、食品事業2億円、低温物流事業4億円、持株会社のシステム対応費用2億円とされています。さらに、緊急対応で発生したコストと今後発生が見込まれる損失として、10億円の特別損失を織り込みました。

※ニチレイが公表した売上への影響、営業利益への影響、特別損失は、それぞれ意味の異なる数字です。これらを単純に合算して「サイバー攻撃による被害総額」とみなすことはできません。

親会社株主に帰属する当期純利益の予想は252億円から204億円へ48億円下方修正されましたが、この48億円すべてがサイバー攻撃による損失ではありません。中東情勢によるコスト増や食品・物流事業の進捗など、複数の要因が含まれています。なお、連結売上高の通期予想自体は海外事業の伸長を反映して上方修正されています。

企業が学ぶべきサイバー攻撃対策

重要業務と外部依存を、システム単位ではなく事業単位で洗い出す

まず必要なのは、どのシステムが止まると、どの業務、取引先、商品、売上に影響するのかを平時に把握することです。自社システムの一覧だけでは足りません。物流、決済、クラウド、保守会社、受発注先など、重要業務を支える外部依存まで含め、許容停止時間と代替手段を整理します。委託先が止まった場合の連絡順序、手作業へ切り替えられる範囲、代替事業者の有無も、BCPとインシデント対応計画の両方で確認しておく必要があります。

また、インシデント対応訓練では自社がサイバー攻撃を受けるケースだけでなく、物流会社やクラウドサービス、主要な仕入先など、重要な委託先・取引先のシステムが停止するケースも想定することが重要です。自社システムが正常でも外部サービスが利用できない状況で、どこまで業務を継続できるのかを確認しておく必要があります。

「業務復旧」と「情報漏えい対応」を別の時計で管理する

ニチレイは7月24日に通常稼働へ移行しましたが、その後もダークウェブ上でのデータ公開が報じられました。ここから分かるのは、システム復旧の完了と、情報漏えい調査の完了は一致しないということです。前者は業務を安全に再開できるかという可用性の問題、後者は何が持ち出され、誰にどのような影響があるかという機密性と法令対応の問題です。復旧宣言後も、フォレンジック調査、漏えい範囲の特定、本人通知、二次被害の監視、対外説明を継続できる体制が欠かせません。

遮断・復旧・証拠保全を同時に進められる初動体制をつくる

攻撃を疑った場合は、インシデント対応責任者や専門家の判断のもと、必要に応じて感染が疑われる端末やサーバーをネットワークから隔離し、被害拡大を抑える必要があります。一方、電源断や安易な初期化によって調査に必要な証拠を失うおそれもあります。誰が遮断を判断し、どのログを保存し、外部の専門会社や警察、監督機関へいつ連絡するのかを事前に決め、机上訓練で確かめておくことが重要です。

経済産業省・独立行政法人情報処理推進機構（IPA）の「サイバーセキュリティ経営ガイドライン Ver3.0 実践のためのプラクティス集 第4版」でも、インシデント発生に備えた体制構築とサプライチェーン全体での対策を経営課題として位置づけています。

バックアップは取得だけでなく、隔離と復旧テストまで行う

ランサムウェアを含む破壊的な攻撃に備えるには、バックアップを本番環境と同じ認証基盤やネットワークに置き続けないことが重要です。実際に戻せるかを定期的に試し、復旧に必要な時間が事業側の許容範囲に収まるかまで確認して、初めてBCPとして機能します。

よくある質問

▼ ニチレイへの攻撃はランサムウェアだったのですか？
▼ 20万件とは20万人分の個人情報ですか？
▼ 個人情報の漏えいは確定していますか？
▼ ニチレイのシステムと業務は復旧していますか？
▼ 今回の事案はサプライチェーン攻撃ですか？

まとめ―復旧の速さだけでは測れないサイバー攻撃の損失

ニチレイへのサイバー攻撃は、冷蔵倉庫と冷凍食品出荷の停止、取引先への影響、個人情報漏えいの可能性、財務損失という複数の問題を同時に突きつけました。全拠点が通常稼働へ戻った後にデータ公開が報じられた経緯は、事業継続と情報保護を別々に備える必要性を示しています。

企業が見るべきなのは、自社への侵入を防げるかだけではありません。重要な委託先が止まったときに業務を続けられるか、攻撃を検知した直後に安全に遮断できるか、バックアップから所定時間内に戻せるか、漏えい調査と対外説明を長期にわたって続けられるかまでが、現在のサイバー攻撃対策です。平時のうちに外部専門会社との連絡経路や調査体制を整え、実際のシナリオで検証しておくことが、被害の大きさを左右します。漏えい調査と対外説明を長期にわたって続けられるかまでを想定することが、現在のサイバーリスク対策には求められます。

参考情報

公開日：2026年8月13日
更新日：2026年10月6日

編集責任：木下

BBSecの脆弱性診断・セキュリティ対策支援サービス

BBSec（ブロードバンドセキュリティ）では、Webアプリケーション診断、プラットフォーム診断、クラウド環境診断、脆弱性管理支援など、企業のセキュリティリスクを可視化する各種サービスを提供しています。外部サービスや委託先を含めたセキュリティ体制の見直し、情報漏えいリスクへの備え、インシデント発生前の予防対策を検討している企業は、ぜひご相談ください。

ウェビナー開催のお知らせ

  • 2026年8月19日（水）14:00～15:00「セキュリティ対策の有効性を検証する ―ペネトレーションテストの実施ポイントと脆弱性診断との違い―」
  • 2026年8月26日（水）「AI時代に見直すセキュリティ対策 ～ASMの考え方で始める攻撃対象領域の可視化とリスク対策～」

    • 最新情報はこちら

    Security Serviceへのリンクバナー画像
    BBsecコーポレートサイトへのリンクバナー画像
    セキュリティ緊急対応のバナー画像

    Security NEWS TOPに戻る
    バックナンバー TOPに戻る

    投稿日:

    ニチレイへのサイバー攻撃で食品物流に影響―業務再開までの経緯と企業が見直すべきBCP

    Share
    ニチレイへのサイバー攻撃で食品物流に影響アイキャッチ画像

    2026年7月、ニチレイがサイバー攻撃を受け、冷蔵倉庫の入出庫業務や冷凍食品の出荷業務に影響が生じました。同社は被害拡大を防ぐためグループのシステムを遮断し、一部制限のもとで業務を順次再開。7月24日には、影響を受けた業務が通常稼働へ移行しました。本事案は、サイバー攻撃が情報漏えいだけでなく、物流や取引先を含む事業継続にも影響を及ぼすことを示しています。本記事では、公式発表に基づいて対応の経緯を整理し、企業が見直すべきBCPについて解説します。

    ※本記事は2026年7月31日時点で確認できる公表資料に基づき作成しています。公表されていない製品名、CVE番号、攻撃者、侵入手法の詳細については推測を加えずに構成しています。

    【続報】2026年9月18日、ニチレイは個人情報の漏えいを確認したと発表しました。最新の公表内容はこちらの記事で解説しています。
    「ニチレイが個人情報漏洩を確認 ―第7報で判明した被害と企業が備えるべきこと」

    ニチレイへのサイバー攻撃とは

    2026年7月13日、株式会社ニチレイは不正アクセスによるシステム障害が発生したと公表しました*5。影響が出たのは、ニチレイロジグループ各社の冷蔵倉庫における入出庫業務と、ニチレイフーズの冷凍食品出荷業務です。同社は発生当日に緊急対策本部を立ち上げるとともに、お客さまや取引先の個人情報・顧客データなどの保護を最優先し、グループで使用するシステムの遮断措置を講じたことを、2日後の第2報*2で明らかにしています。その後、7月17日から一部制限のもとで業務を順次再開し、7月24日には、影響を受けた入出庫業務と冷凍食品出荷業務の受発注制限を解除して、全拠点を平常時の通常稼働へ移行しています。

    この事案が示したのは、サイバー攻撃の被害が情報漏えいだけにとどまらないことです。攻撃を受けた疑いが生じれば、被害拡大を防ぐためにシステムを止める判断が必要になる場合があります。受発注、在庫管理、倉庫の入出庫、出荷といった業務がITでつながる現在、封じ込め措置そのものが事業停止リスクを伴います。本件からは、侵入を防ぐ対策だけでなく、システムを遮断した後も業務を継続し、段階的に復旧する計画が欠かせないことが分かります。サイバーセキュリティ対策とBCPは、一体で検討すべき課題です。

    7月13日から24日まで―公式発表で追う対応と復旧

    7月13日：不正アクセスによるシステム障害を公表

    ニチレイは7月13日、不正アクセスによるシステム障害が同日に発生したと発表しました。第1報の時点では、個人情報や顧客データが社外へ流出した事実は確認されていないとしていました。一方、冷蔵倉庫の入出庫業務と冷凍食品の出荷業務にはすでに影響が生じており、障害の範囲は公表時点で日本国内に限られると説明しています。

    ここで注意したいのは、7月13日が「攻撃者の侵入日」と確認されたわけではない点です。公式発表から断定できるのは、不正アクセスによるシステム障害が7月13日に発生し、同日公表されたことまでです。攻撃者が最初に侵入した日時や、不正アクセスを検知した正確な時刻・契機は明らかにされていません。

    7月15日：サイバー攻撃を確認、個人情報漏えいの可能性を報告

    7月15日の第2報で、ニチレイは調査の結果、自社サーバがサイバー攻撃を受けたことを確認したと発表しました。さらなる被害拡大を防ぐため、攻撃の詳細は非開示としています。また、被害を受けたサーバの一部に個人情報が保管されていたため、個人情報保護委員会へ「漏えいの可能性がある事案」として第一報を行いました。

    同社は発生当日の7月13日にグループで使用するシステムを遮断しており、この遮断措置に伴って冷蔵倉庫の入出庫と冷凍食品出荷に影響が生じたと説明しています。なお、7月16日付のIR情報では、連結業績への影響は精査中とされ、重要な影響が判明した場合は速やかに開示すると説明しています。

    7月17日：受発注を制限しながら部分稼働

    7月17日、ニチレイは外部のセキュリティ専門会社の支援のもと、影響を受けた業務を順次再開しました。ただし、直ちに平常運転へ戻ったわけではなく、顧客や取引先からの受発注を一部制限し、冷蔵倉庫と食品工場を部分稼働させる形での再開でした。この段階でも、原因と影響範囲は調査中とされていました。

    7月22日から24日：対象者への通知と通常稼働への移行

    7月22日の第4報*3では、外部のセキュリティ専門会社に加え、警察および関係機関と連携して対応していることが公表されました。被害サーバの一部に個人情報が保管されていたため、対象者へ別途通知を行っていることも明らかにされています。

    7月24日、ニチレイは受発注制限を解除し、影響を受けていた入出庫業務と冷凍食品出荷業務について、全拠点が平常時の通常稼働へ移行したと発表しました。ただし、これは影響業務の通常稼働への移行を示すものであり、原因調査や影響範囲の特定まで完了したことを意味するものではありません。

    なぜ食品サプライチェーンへの影響が注目されたのか

    ニチレイが2026年5月12日に公開した「事業概要説明資料」によると、同社の低温物流事業は全国75カ所に冷蔵倉庫を保有し、冷蔵倉庫の保管能力で国内1位です。さらに、ニチレイグループ外の取扱比率が90％を超えるとされています。今回、75カ所すべてに同じ程度の支障が生じたと公表されているわけではありません。ただし、この事業構造から、低温物流業務の中断がニチレイグループ以外の荷主にも波及し得ることが分かります。

    実際、ミールキット宅配サービスのヨシケイは7月27日、ニチレイグループのシステム障害により倉庫からの商品出庫に支障が生じ、一部エリアで代替品や代替食材を届ける場合があると公表しました*4。ニチレイは7月24日に影響業務の通常稼働への移行を発表していますが、自社の業務が再開しても、取引先側では在庫調整や代替品の手配などが続く場合があります。ヨシケイの発表は、障害の影響が取引先の商品供給にまで波及したことを示す事例といえます。

    なお、サイバー攻撃の影響が取引先へ波及したことと、取引先などを侵入経路とする「サプライチェーン攻撃」は区別する必要があります。ニチレイは侵入経路を公表していないため、本件をサプライチェーン攻撃と分類することはできません。一方、業務停止の影響が取引関係を通じて広がるリスクは、物流や食品製造だけでなく、決済、医療、クラウドサービスなどにも共通します。

    個人情報は漏えいしたのか

    2026年7月31日時点で、ニチレイは個人情報の漏えいを確定したとは発表していません。公表されているのは、被害サーバの一部に個人情報が保管されていたこと、漏えいの可能性がある事案として個人情報保護委員会へ第一報を行ったこと、対象者へ別途通知したことです。

    個人情報保護委員会は、不正の目的をもって行われたおそれがある個人データの漏えい等について、実際の漏えいが確定した場合だけでなく、それがある段階も報告対象になると示しています*5。このため、個人情報保護委員会への報告が行われたことだけをもって、外部流出が確定したとは判断できません。

    対象人数、顧客・従業員などの属性、情報項目、持ち出しの有無、不正利用の有無も公表されていません。したがって、現段階で「顧客情報が流出した」「大規模な個人情報漏えいが起きた」と書くのは不正確です。新たな公式発表が出た場合は、漏えいの事実、対象範囲、二次被害の有無を分けて確認する必要があります。

    ※その後、9月18日の第7報で個人情報の漏えいが確認されました。最新情報はこちら。

    ランサムウェア攻撃だったのか

    ニチレイは、攻撃手法、侵入経路、悪用された脆弱性、マルウェアの種類、データ暗号化や身代金要求の有無、攻撃者について公表していません。このため、本件をランサムウェア攻撃、ゼロデイ攻撃、あるいは特定の攻撃グループによる犯行と断定できる公式情報はありません。

    攻撃者を名乗る第三者の主張が報じられた場合でも、それだけで攻撃手法や犯行主体が確定するわけではありません。本記事では、ニチレイまたは捜査機関が確認した情報と、外部からの未検証の主張を区別して扱います。

    ニチレイの事例から企業が見直すべきサイバー攻撃対策

    重要業務とシステムの依存関係を可視化する

    対策の出発点となるのは、止まると事業や顧客に大きな影響が出る業務を特定し、それを支えるシステム、データ、拠点、委託先を対応付けることです。受発注システムだけを復旧しても、在庫情報、倉庫作業、輸配送との連携が戻らなければ商品は届きません。業務影響分析（BIA）を用いて復旧の優先順位を整理し、目標復旧時間（RTO）や目標復旧時点（RPO）に加え、システム停止中も最低限維持すべき業務とその水準を、IT部門と現場部門で共有しておくことが有効です。

    多層防御によって被害範囲を限定する

    ニチレイは侵入経路や攻撃手法を公表していないため、本件の原因に特定の対策不足を結び付けることはできません。以下は、同種の業務停止に備えるための一般的な対策です。

    サイバー攻撃への備えでは、侵入を防ぐだけでなく、侵入された場合にも被害を広げない対策が必要です。重要システムやネットワークの分離、特権アカウントの適切な管理、多要素認証、ログの保全・監視などを組み合わせ、攻撃者による内部での移動や権限拡大を抑制します。

    経済産業省・独立行政法人情報処理推進機構（IPA）の「サイバーセキュリティ経営ガイドライン Ver3.0 実践のためのプラクティス集 第4版」も、侵入を防ぐ入口対策に加え、内部での活動拡大を防ぐネットワーク対策、外部への不正通信を防ぐ出口対策、重要データを守る対策を組み合わせる多層防御を示しています。

    「システムを止めた状態」で続ける手順を用意する

    不正アクセスの疑いがある状況では、ネットワークの遮断や機器の隔離、サービス停止が必要になることがあります。IPAの「中小企業のためのセキュリティインシデント対応の手引き」でも、被害拡大の可能性がある場合の初動対応として、ネットワーク遮断や対象機器の隔離、システム・サービスの停止を挙げています。

    だからこそ、BCPはバックアップからシステムを戻す手順だけでは不十分です。システムを遮断した際に利用する代替手順を、業務内容に応じて事前に設計しておく必要があります。例えば、受発注や入出庫を電話、メール、紙の帳票などへ一時的に切り替える場合も、処理可能な件数、誤処理を防ぐ照合方法、記録の保全、平常系へ戻す際のデータ反映まで検証しなければなりません。机上演習に加え、主要システムを利用できない状況を想定し、代替手順が実際に機能するか確認することが重要です。

    復旧可能なバックアップと復旧手順を検証する

    バックアップは、データを保存しているだけでは事業復旧を保証できません。本番環境と同時に暗号化・削除されないよう、ネットワークから分離した媒体や異なる環境にも保管し、バックアップデータの完全性を定期的に確認する必要があります。

    さらに、復元テストを実施し、重要なシステムやデータを想定した時間内に復旧できるかを検証します。復旧の順序、必要な担当者、利用する機器や認証情報、システム間の依存関係も事前に整理しておくことが重要です。

    サイバー攻撃を受けた環境を安全確認なしに復元すると、侵害された設定やマルウェアまで戻してしまうおそれがあります。原因調査や安全性の確認と並行して、どの時点のデータを、どの環境へ、どの順番で戻すかを判断できる復旧手順を整備しておく必要があります。

    初動対応をIT部門だけに背負わせない

    インシデント発生時には、封じ込め、証拠保全、原因調査、復旧に加え、顧客や取引先への連絡、個人情報保護委員会などへの報告、警察との連携、経営判断が並行して進みます。ニチレイも緊急対策本部を設置し、外部のセキュリティ専門会社、警察、関係機関と連携しました。

    平時から、経営、情報システム、事業部門、法務、広報、個人情報保護担当の役割と連絡順序を決め、フォレンジック調査や復旧を依頼する外部専門家の連絡先を整えておくべきです。対応手順は、社内システムが利用できない状況でも参照できる場所に保管します。また、調査に必要なログやデータを不用意に消去しないよう、対象機器の隔離方法や外部専門家へ連絡する判断基準を訓練しておくことが重要です。

    取引先を含めて復旧情報を共有する

    自社が通常稼働へ戻っても、取引先側では在庫不足、納品遅延、代替商品の手配、顧客への案内が続く可能性があります。サプライチェーン全体の復旧を早めるには、「何が止まっているか」「どの業務をいつ再開するか」「制限が残るか」を、攻撃者に利する情報を避けながら継続的に共有することが重要です。

    公表文のひな型だけでなく、重要取引先への連絡経路、問い合わせ窓口、更新頻度、技術情報と事業影響を分けて説明するルールまで準備しておくと、混乱を抑えやすくなります。セキュリティ部門が把握する復旧状況を、物流、営業、調達、顧客対応の言葉へ変換する役割も必要です。

    よくある質問

    ▼ ニチレイのシステム障害はいつ発生しましたか
    ▼ どの業務に影響が出ましたか
    ▼ 個人情報は漏えいしましたか
    ▼ ランサムウェア攻撃だったのでしょうか

    まとめ―サイバー攻撃対策は業務復旧まで設計する

    ニチレイへのサイバー攻撃では、冷蔵倉庫の入出庫と冷凍食品出荷に支障が生じ、制限付きの再開を経て通常運用へ戻りました。一方、2026年7月31日時点では、攻撃手法や侵入経路、個人情報の外部流出の有無、最終的な影響範囲は公表されていません。

    今回の事例から企業が学ぶべきなのは、侵入防止策だけではありません。被害拡大を防ぐためにシステムを遮断しても重要業務を続けられるか、安全性を確認しながらどの順番で復旧するか、取引先へ何を伝えるかまで含めて設計する必要があります。サイバー攻撃をIT障害として閉じず、経営と現場を巻き込んだサイバーBCPとして準備することが、事業とサプライチェーンの強靱性を左右します。

    【参考情報】

    公開日：2026年8月5日
    更新日：2026年10月6日

    編集責任：木下

    BBSecの脆弱性診断・セキュリティ対策支援サービス

    BBSec（ブロードバンドセキュリティ）では、Webアプリケーション診断、プラットフォーム診断、クラウド環境診断、脆弱性管理支援など、企業のセキュリティリスクを可視化する各種サービスを提供しています。外部サービスや委託先を含めたセキュリティ体制の見直し、情報漏えいリスクへの備え、インシデント発生前の予防対策を検討している企業は、ぜひご相談ください。

    ウェビナー開催のお知らせ

  • 2026年8月19日（水）14:00～15:00「セキュリティ対策の有効性を検証する ―ペネトレーションテストの実施ポイントと脆弱性診断との違い―」
  • 2026年8月26日（水）「AI時代に見直すセキュリティ対策 ～ASMの考え方で始める攻撃対象領域の可視化とリスク対策～」

    • 最新情報はこちら

    Security Serviceへのリンクバナー画像
    BBsecコーポレートサイトへのリンクバナー画像
    セキュリティ緊急対応のバナー画像

    Security NEWS TOPに戻る
    バックナンバー TOPに戻る

    投稿日:

    タイムズカーで約660万アカウントの情報漏洩 ―本人確認書類の保管とWebセキュリティを考える

    Share
    タイムズカーで約660万アカウントの情報漏洩アイキャッチ画像

    2026年9月、タイムズカーのWebシステムが不正アクセスを受け、約660万アカウントの情報漏洩が確認されました。続報では、運転免許証画像などの本人確認書類が漏洩したアカウント数が約160万件と公表されています。本記事では、公式発表をもとに被害の範囲と利用者への案内を整理し、会員情報を扱う企業が見直したいデータ管理とWebセキュリティについて考えます。

    ※本記事は2026年10月5日時点までで確認できる公表資料に基づき作成しています。

    2026年9月にタイムズカーで何が起きたのか

    タイムズカーは9月25日9時07分に不正アクセスを検知し、同日の第1報で個人情報漏洩の可能性を発表しました。翌26日7時25分までに侵入経路と攻撃元からの通信を遮断し、遮断後にアクセスできないことを確認したとしています。その後、28日の第2報で第三者による情報取得を確認したと公表し、調査の進展に伴って発表内容を更新しました。公式発表では、具体的な侵入手法や悪用された脆弱性の詳細は示されていません。同社は外部専門機関による原因・影響範囲の調査を進め、再発防止策は続報で公表する方針です。また、サービス提供への影響は確認されず、通常どおり継続していると説明しています。サービスの稼働状況と個人情報への影響は、それぞれ確認する必要があります。

    約660万件と約160万件、それぞれの対象範囲

    第2報の約660万件は、漏洩したアカウントの数です。対象にはタイムズカーの会員と退会者、入会手続きが完了していない申込者のほか、タイムズビジネスサービスの会員と退会者も含まれます。現在利用している会員だけの人数として受け取らないことが大切です。漏洩した情報の項目については、公式FAQでも詳細が示されています。氏名、住所、生年月日、電話番号、メールアドレスに加え、法人会員の所属部署名、運転免許情報、本人確認書類情報、パスワード、連携サービスIDが挙げられています。一方、クレジットカード情報は保有しておらず、今回の対象には含まれないと説明しています。

    9月29日の第3報で示された約160万件は、運転免許証画像などの本人確認書類が漏洩したアカウント数です。書類には現住所確認書類、学生プランの学生証、家族プランの家族確認書類の画像も含まれます。約660万件と約160万件は数えている情報の範囲が異なるため、単純に足して被害規模を示すことはできません。同社はパスワードを復元できない形式で保存していたと説明し、パスワードそのものが第三者に認識できる状態で漏えいした事実は確認していないとしています。不特定多数への情報公開や、本件に起因する不正利用も公表時点では未確認です。これらは同社が示した調査状況として読み、今後の更新も確認する必要があります。

    図：タイムズカーで確認された情報漏洩の範囲

    タイムズカーで確認された情報漏洩の範囲
    出典：タイムズモビリティ株式会社 第2報（2026年9月28日）・第3報（2026年9月29日）をもとに作成
    ※約160万件は約660万件に含まれます。いずれもアカウント数で、対象となる情報は利用者によって異なります。

    利用者は個別通知と公式窓口を確認する

    本人確認書類の漏えいが確認された会員への個別メールは9月29日から始まりました。第3報では、詳細について外部専門機関の調査結果を踏まえ、2週間程度を目途に改めて案内する方針を示しています。その後、10月1日にはFAQと退会者向けの問い合わせ案内が追加され、退会者への通知も同日から順次開始されたと説明されています。

    同社は、会社を装ったメールやSMS、電話への警戒を求めています。心当たりのない連絡に含まれるリンクや添付ファイルを開かず、パスワード、認証コード、クレジットカード情報を入力しないことが基本です。通知の内容や対象かどうかに疑問がある場合は、公式発表から問い合わせ先を確認してください。同社がメール、SMS、電話でパスワードやカード情報を尋ねることはないと案内しています。

    本人確認書類は保有目的とアクセス権限を一緒に見直す

    ここからは本件の原因を推定するものではなく、今回の事例を踏まえて、個人情報を扱う企業が確認したい一般的な対策を整理します。本人確認のために受け取る画像についても、会員台帳と同様に、何を、どこで、何のために保有しているかを把握することが出発点になります。退会や申込中断を含む業務の各段階とデータの保管場所を対応させ、取扱責任者や閲覧できる担当者まで確認すると、見直す対象が具体的になります。

    10月1日の公式FAQでは、タイムズカーは氏名・住所・生年月日を税法等に基づき7年間、運転免許情報と画像をなりすまし対策や問い合わせ対応のため7年間保管すると説明しています。保有データを点検する際は、このように項目ごとに保管の理由を確認する視点が必要です。退会情報があることだけで、個別企業の保管の適否や漏えい原因を判断することはできません。

    一方、個人情報の保存期間について、個人情報保護委員会のFAQでは、個人情報保護法が一律の保存期間や廃棄時期を定めているわけではないと説明しています。そのうえで、利用する必要がなくなった個人データは遅滞なく消去するよう努める必要があるとしています。自社では、保存の根拠と業務上の必要性を確かめ、期限を決めるだけで終わらせず、削除の対象を抽出して処理できる運用になっているか確認したいところです。

    保管が必要なデータには、業務に応じたアクセス制御が欠かせません。個人情報保護委員会の通則編ガイドラインも、担当者や取り扱うデータの範囲を限定すること、正当なアクセス権を持つ従業者を識別・認証することを求めています。本人確認担当、問い合わせ担当、システム管理担当で必要な権限を整理し、画像を閲覧・取得できる範囲が過大になっていないか点検することが、企業向けの具体的な確認例になります。

    個人情報を扱うWeb機能を継続して点検する

    保存ルールや社内権限の確認に加え、利用者からデータへ至る機能も検証する必要があります。会員登録、ログイン、登録情報の変更、書類のアップロードなど、個人情報を扱う処理を洗い出し、どの処理を点検済みか整理します。APIを利用している場合は、その通信や処理も対象に含めます。本件でAPIが悪用されたと確認されたわけではなく、ここで挙げるのは自社システムを点検する際の観点です。

    たとえば、本人がログインできることと、その本人に許可された情報だけを閲覧できることは、確認すべき内容が異なります。ログイン時の認証、ログイン状態を維持するセッション、ユーザー権限、重要情報の取り扱いを関連づけて確認することで、画面の通常操作だけでは見えにくい問題の検証につながります。本人確認画像を扱う機能を追加・変更したときにも、その機能を含めて診断範囲を見直すことが考えられます。

    点検は新規公開時だけで完了するものではありません。個人情報保護委員会のガイドラインは、システムの設計段階で安全性を確保し、継続して見直すことを対策の例に挙げています。自社の改修予定と診断計画を合わせ、見つかった課題の担当者と修正予定を決め、修正後の確認まで行う運用に結びつけることが重要です。

    個人情報の管理とWebの安全性をあわせて見直す

    ここまで挙げたWeb側の確認を自社だけで行うことが難しい場合は、外部の脆弱性診断を活用する方法もあります。ブロードバンドセキュリティ（BBSec）では、「Webアプリケーション脆弱性診断」を提供しています。同サービスは、自動診断と技術者による手動診断を組み合わせ、検出した問題の深刻度と推奨対策を報告するサービスです。Webアプリケーションに加え、APIもオプションとして診断できます。会員登録やログイン、登録情報の変更、書類のアップロードなど、個人情報を扱う機能を含め、どこまでを診断対象とするかについてサービスページから相談できます。

    個人情報を扱う体制や運用から整理したい企業には、「自己問診型 個人情報に関わる情報セキュリティアセスメント」も用意されています。オンラインの自己問診をもとにコンサルタントが評価し、課題や優先順位、対策案を示すサービスです。データを保有する理由と扱い方を整理する作業を、Web機能の技術的な点検と併せて進めることで、自社で優先すべき改善を具体化できるでしょう。

    【参考情報】

    個人情報を扱うWebサイトのセキュリティや、情報管理の体制・運用に課題を感じている場合は、現在の対策状況に応じた確認方法をご案内します。まずはお気軽にご相談ください。

    編集責任：木下

    ウェビナー開催のお知らせ

    最新情報はこちら

    Security NEWS TOPに戻る
    バックナンバー TOPに戻る

    投稿日:

    Gyazoの情報漏洩から考える ―画像メタデータと削除後のデータ管理

    Share
    Gyazoの情報漏洩から考える ―画像メタデータと削除後のデータ管理アイキャッチ画像

    画像共有サービス「Gyazo」で2026年9月に発生した不正アクセスでは、ユーザー関連データに加え、画像に付随するメタデータの流出が確認されました。第二報では、過去に削除した画像のメタデータも対象だったことが明らかになっています。公表された数値を被害人数や画像本体の流出件数と取り違えず、画像と関連情報を一体で守る視点が必要です。本稿は公式情報を基に、影響と対策を整理します。

    ※本記事は2026年10月5日時点までで確認できる公表資料に基づき作成しています。

    Gyazoへの不正アクセスの概要

    運営会社のHelpfeelによると、9月11日、画像アップロードサーバーの脆弱性を悪用した第三者が、システム上で任意のコマンドを実行しました。同社は同日夜に異常を検知し、12日未明までに確認された侵入経路と不正な接続を遮断しました。その後、データベース内のユーザー情報と画像メタデータの流出を確認しています。公表内容から、脆弱性の具体的な種類や開発・運用上の原因まで断定することはできません。

    同社は二次被害防止のため画像配信の停止などを実施し、サービス提供も一時停止しました。追加の検証と対策を経て、9月27日にサービスを再開しています。再開後も調査と対策は継続する方針です。また、第二報時点で「Helpfeel」「Cosense」のシステムからの情報漏洩や攻撃の痕跡は確認されていません。これらのサービス上でGyazo画像を表示できない影響と、各サービス自体の侵害は区別する必要があります。

    約2,362万件のユーザー関連データが流出

    流出したユーザー関連データは約2,362万件です。第二報の内訳は、メールアドレス未登録の匿名ユーザーが約1,801万件、登録のあるユーザーが約562万件でした。丸め処理により内訳の合計は総数と一致しません。この数値はデータの件数であり、そのまま個人情報が漏洩した人数や国内の被害人数を表すものではありません。対象情報には、名前、メールアドレス、パスワードのハッシュ値、利用者ID、ログインセッションIDなどがありますが、含まれる項目はユーザーごとに異なります。クレジットカード番号などの決済情報は含まれていません。流出対象とされたX連携用トークンも、第二報では単体でXへのログインや操作はできないと確認され、関連するOAuth認証情報は予防的に無効化されています。

    画像メタデータと削除済み画像への影響

    画像に関して公表されたのは、主に2019年1月以前にアップロードされた画像のメタデータ約4.9億件と、条件を絞って取得された240万件です。第二報では、削除済み画像のメタデータ約1.74億件も加わりました。いずれも画像ファイル本体の流出件数ではなく、これらの数値から画像ファイル本体の流出・閲覧状況や、その対象数を判断することはできません。第一報では、流出したメタデータに画像URLを構成する情報が含まれており、それを用いて画像が不正に閲覧されるおそれがあることや、非公開画像のファイル一覧が取得されていたことも公表されています。一部の非公開画像が第三者に閲覧された可能性についても、完全には否定できないとされています。

    削除済み分は、主に2023年2月以前に画像またはアカウントを削除したものです。基準となる時期はアップロード日ではありません。対象の画像ファイルは閲覧できない状態で、今回追加で確認された流出に削除済み画像の本体は含まれていないと説明されています。一方、画像に関連する情報は残り、流出対象となっていた点が、データ管理を考える上での重要な論点です。

    メタデータには、画像URLを構成する画像ID、アップロード元IPアドレス、User-Agent、OCRテキスト、画像タイトル、取得元URL、画像に含まれる場合の位置情報、非公開画像のパスフレーズ（ハッシュ値）などが含まれます。画像そのものではなくても、内容や利用状況に関わる情報を持ちます。第一報では、流出情報を使った画像の不正閲覧のおそれや、一部の非公開画像が閲覧された可能性も示されています。「メタデータだけだから影響は小さい」と判断することは適切ではありません。

    図：Gyazoで流出したユーザー関連データと画像メタデータ

    Gyazoで流出したユーザー関連データと画像メタデータ
    出典：Helpfeel「「Gyazo」への不正アクセスによる情報漏えいに関するお知らせとお詫び（第二報）」（https://corp.helpfeel.com/news/news-20260925-01）を基に弊社作成。
    ※ユーザー関連データと画像メタデータは集計対象が異なります。各数値は被害人数や画像ファイル本体の流出件数を示すものではありません。ユーザー関連データの内訳は概数のため、合計と総数が一致しない場合があります。

    利用者が確認したいポイント

    利用者向けには、Gyazoのパスワード変更と、同一または類似したパスワードを使う他サービスの変更が案内されています。本件を装う不審なメールやメッセージにも注意が必要です。変更や確認は、公式サイトと公式ヘルプの案内に沿って進めてください。再開時には、不正アクセス発生前の画像を原則として所有者だけが閲覧できる状態とし、利用者自身が配信の再開を選ぶ方式が採られました。再開すると従来の閲覧範囲が適用されるため、業務情報や個人情報が写っていないか、共有先が適切かを確認してから操作することが大切です。なお、9月29日の追記ではGyazo Teamsについて、配信停止中でも同じチームのメンバーが閲覧できる仕様変更が示されています。「自分のみ」の画像は対象外で、パスワード保護画像には引き続きパスワードが必要です。

    無料プランでも、特別措置として発生前にアップロードした過去の画像を確認できます。ただし、公式ヘルプでは、配信を再開した画像をアクセス制御で再び本人だけに限定する機能は、現時点でProとTeamsのみとされています。無料プランの利用者は、まとめて再開する前にこの制約も確認してください。

    企業が見直したいデータ管理

    ここからは、本件の原因の推定ではなく、画像やファイルを扱う企業への一般的な提案です。まず、保護対象を画像本体だけに限定せず、OCR結果、位置情報、タイトル、識別子などの関連データまで洗い出します。どこに何の目的で保存し、誰が参照できるかを整理すれば、画像を削除した後に何が残る設計なのかも点検しやすくなります。今回、削除済み画像の関連情報まで流出対象となったことは、自社で「削除後にどのデータが残るのか」を確認する一つの契機になります。

    削除機能の確認では、画面から見えなくなることと、関連データの保存が終了することを分けて考えます。業務上の必要に応じて保存期間と削除対象を定め、画像の削除時や退会時に、関連情報が想定どおり処理されるかまで確かめることを提案します。例えば、画像削除後にOCR検索や管理画面から関連情報が参照できるか、保存期限後に不要な情報が残らないかを検証します。保存を続ける情報には、その理由と閲覧権限を明確にします。

    さらに、画像URLや識別子を知っていることだけに保護を頼らず、情報の機密性に応じて閲覧者の権限を確認する設計が必要です。OWASPも、リクエストごとの権限検証と、画像などの静的なファイルを含めたアクセス制御を推奨しています。共有範囲の変更、退会、チームからの離脱など、利用者の状態が変わる場面をテストに含めると、権限の残り方を確認できます。

    設計レビューと脆弱性診断を活用する

    アップロード機能は、受け入れるファイルの種類、処理に使うライブラリ、保存先、ファイルや処理プロセスに与える権限をまとめて確認したい領域です。OWASPは、ファイル形式の検証、ライブラリの安全な設定と更新、最小限の権限などを組み合わせる対策を示しています。開発時に決めた安全要件が、改修後や運用中も満たされているかを継続して検証することが大切です。

    ブロードバンドセキュリティ（BBSec）の「Webアプリケーション脆弱性診断」は、外部からの動的診断に自動ツールと手動診断を組み合わせ、攻撃の入口となり得る問題箇所を確認します。API診断もオプションで提供しています。また、「Shift Leftコンサルティング」は、要件定義や設計のレビュー、開発標準・ガイドラインの作成を支援します。既存システムの脆弱性を確認したい場合は「Webアプリケーション脆弱性診断」、開発上流工程からセキュリティ要件や設計を見直したい場合は「Shift Leftコンサルティング」をご活用いただけます。自社のシステムや開発状況に応じた対策について、BBSecへお気軽にご相談ください。

    【参考情報】

    編集責任：木下

    ウェビナー開催のお知らせ

    最新情報はこちら

    Security NEWS TOPに戻る
    バックナンバー TOPに戻る

    投稿日:

    佐川急便「お荷物問い合わせサービス」に不正アクセス、個人情報流出の可能性

    Share
    佐川急便「お荷物問い合わせサービス」に不正アクセス、個人情報流出の可能性アイキャッチ画像

    佐川急便は2026年9月30日、Webサイトの「お荷物問い合わせサービス」で第三者による不正アクセスを確認したと発表しました。10月1日の第2報では個人情報が外部に流出した可能性を公表し、同日の第3報で専用コールセンターの開設を案内しています。対象には荷物の送り主と届け先、運賃契約者、スマートクラブ登録者の情報が含まれる可能性があり、件数や影響範囲、原因の調査が続いています。本記事では、公表された事実と、企業が同様の事態に備えて確認しておきたい対応を整理します。

    ※本記事は2026年10月4日時点までで確認できる公表資料に基づき作成しています。

    不正アクセス確認から個人情報流出の可能性公表まで

    第1報によると、不正アクセスを確認した日は9月30日です。佐川急便は確認後に同サービスへのアクセスを一部制限し、荷物の問い合わせが利用しづらくなる場合があると案内しました。翌10月1日の第2報では、調査によって個人情報の外部流出の可能性が判明したと説明し、被害拡大を防ぐために一部のWebサービスを停止していることを公表しています。

    その後の公表でも、影響範囲と原因は引き続き調査中とされています。確認できた公表内容からは、侵入に使われた具体的な手法や脆弱性、対象人数を確定できません。「不正アクセスを確認したこと」と「個人情報が流出した可能性」を分けて捉える必要があります。公表されていない攻撃経路を推測し、自社の対策を特定の製品や手法だけに絞ることも避ける必要があります。

    流出した可能性がある情報と「約100日間」の意味

    第2報では、対象となる可能性がある人と情報を三つに分けています。荷物の送り主と届け先については、氏名、住所、電話番号が対象とされ、法人の場合は法人名と担当者名が含まれます。この区分について、9月30日からさかのぼる約100日間の累計データと説明されています。運賃契約を結んでいる法人・個人についても、氏名または法人名と担当者名、住所、電話番号が挙げられています。スマートクラブ登録者については、氏名、住所、電話番号に加え、メールアドレスと会員IDが対象とされています。一方、クレジットカード情報とパスワードは含まれないとしています。対象件数と範囲は調査中です。

    ここでいう「約100日間」は、荷物の送り主・届け先に関する対象データの説明です。不正アクセスが約100日間継続していたという意味ではありません。 また、運賃契約者やスマートクラブ登録者にも一律に適用される期間とは示されていません。対象には荷物の届け先も含まれる可能性があるため、自ら発送や会員登録をしていない場合でも、届け先として情報が登録されている可能性があります。個々の対象については、今後の佐川急便の公式案内を確認する必要があります。

    図：佐川急便が公表した流出可能性の対象

    出典：佐川急便「「お荷物問い合わせサービス」への不正アクセスによる個人情報流出の可能性について（第2報）2026年10月1日」（https://www2.sagawa-exp.co.jp/information/detail/420/）を基に弊社作成。
    いずれも流出した可能性がある情報であり、流出の確定や対象人数を示すものではありません。「約100日間」の記載は、送り主・届け先の区分に付されたものです。

    Webサービスの停止と集荷・配達の状況を区別する

    第2報の停止対象には、インターネット貨物お荷物問い合わせとそのAPI、飛脚宅配便受付、飛脚往復便受付と同ゴルフ受付、商品回収返金サービス、配達予定時・不在発生後の受取先変更、回収くんが挙げられています。一方、荷物の集荷・配達は通常どおり行っていると説明しています。Webで追跡や手続きができないことと、配送そのものが停止していることは分けて捉える必要があります。

    第3報では、個人情報流出の可能性に関する専用コールセンターの開設も案内されています。受付時間など最新の問い合わせ方法については、佐川急便の公式案内を確認してください。集荷や配達状況など荷物に関する問い合わせについては、最寄りの営業所へ連絡するよう案内されています。

    佐川急便は、同社を装う不審な連絡への注意も呼びかけています。不審な連絡に記載されたURLへのアクセスや、個人情報の入力・提供をしないよう注意が必要です。利用者向けに案内する企業も、佐川急便からの注意喚起と公式窓口を共有し、追加情報の確認先をそろえておくとよいでしょう。

    配送を委託する企業は顧客情報の受け渡しを確認する

    今回の公表を受け、配送を利用する企業が自社の備えとして確認したいのは、どの業務で、誰の情報を、どの相手に渡しているかです。例えばEC事業では、購入者と届け先が異なる場合があります。発送担当者の情報だけを確認しても、顧客への説明に必要な範囲を把握できるとは限りません。ここからは佐川急便の調査結果とは切り分け、配送データを扱う企業が平時から確認しておきたい一般的な備えについて整理します。

    配送会社に渡している情報を整理する

    まず、自社の受注記録や出荷記録と、配送会社に渡す情報の項目を対応づけます。注文番号、発送日、送り状番号などを使って、対象期間の出荷と届け先を社内で確認できる状態を整えておきます。これは流出を確定する作業ではなく、配送会社から追加情報が示されたときに、自社との関係を確認するための準備です。整理した資料にも個人情報が含まれるため、閲覧できる担当者と共有先を定めて扱いましょう。

    関係部門で確認状況を共有する

    配送会社や業務委託先との連絡では、対象期間、情報項目、確認済みの内容、調査中の内容を記録します。社内でも物流、情報システム、顧客対応などの関係部門で情報を共有し、顧客への説明や公表を誰が判断・承認するかを決めておくことが重要です。調査中の事項を断定せず、情報の更新日時と確認中の事項を明確にすることで、社内外への説明の食い違いを抑えられます。

    影響範囲を調べられるログと初動の役割分担を備える

    自社でWebサービスや配送連携システムを運用している場合は、異常を検知した後に何を調べられるかも確認しておきたい点です。JPCERT/CCは、複数のサーバーや機器のログを適切に採取・分析することで、侵入や攻撃の影響範囲を捉えられる可能性があると説明しています。一方、必要なログが取得されていない、または十分な期間保存されていないため、全容を解明できなかった例についても触れています。

    そのため、ログを保存するだけでなく、どのシステムの、どの操作を確認するために記録するのかを決めておくことが重要です。アクセス時刻や利用アカウント、データの参照・出力に関する記録を実際に取得できるか確認します。保存期間や上書きされる条件、ログを取り出す担当者も整理しておけば、調査を始める際の迷いを減らせます。記録に痕跡が見つからない場合には、そもそもその操作を記録できる設定だったかを確かめることも必要です。

    こうした技術面の準備と併せて、異常の受付、深刻度の判断、サービスの停止や制限を決める責任者、委託先への連絡担当を定めておきます。調査に必要な記録の保全と、顧客対応に必要な事実の整理を並行して進められる体制が望まれます。今回の事案で公表されている原因や対応の評価とは切り分け、自社で同様の連絡を受けた場合に必要な情報と判断を点検しておくことが、具体的な備えにつながります。

    インシデントに備えてログと初動対応を見直す

    ログの取得範囲や分析方法を整理したい場合は、BBSecの「セキュリティログ分析／活用支援」が選択肢になります。既存ログの分析、取得環境の整備に向けた助言、統合ログ管理・分析環境の構築から運用までを支援するサービスです。自社の記録で何を確認でき、どこに不足があるかを検討する際に活用できます。また、「インシデント初動対応準備支援」では、企業の現状に合わせ、初動対応フローやガイドラインの作成を支援します。調査の根拠となるログと、関係部門が動くための手順を平時から整えておきたい企業は、ブロードバンドセキュリティ（BBSec）にご相談ください。

    【参考情報】

    編集責任：木下

    ウェビナー開催のお知らせ

    最新情報はこちら

    Security NEWS TOPに戻る
    バックナンバー TOPに戻る

    投稿日:

    AIはSIに変わったのか ―米国の呼称変更とASIの違いから考えるAIセキュリティ

    Share
    AIはSIに変わったのかアイキャッチ画像

    「AIがSIに変わった」――2026年9月、そんなニュースが注目を集めました。米国では、トランプ大統領が従来のArtificial Intelligence（AI）をSuper Intelligence（SI）と呼ぶ方針を示し、9月29日には連邦行政機関でSIの呼称を使用する大統領令が発令されました。一方、中国側の公式発表では引き続き「人工知能」と表記されています。ここで注意したいのは、米国政府が使う「SI」と、AI研究で語られてきた「ASI（Artificial Superintelligence）」は同じ意味ではないことです。言葉の変化と技術の進化を切り分けたうえで、企業がいま向き合うべきAIセキュリティ上の課題を考えます。

    米国はAIからSIへ　中国側は「人工知能」と表記

    発端は9月22日の国連総会でのトランプ米大統領の発言です。米ホワイトハウスが公開した演説の抜粋には、従来「Artificial Intelligence」と呼んでいた技術を今後「Super Intelligence」と呼ぶ趣旨が記されています。その後、9月25日のホワイトハウスの成果文書は、米中首脳が対象となる新興技術について「artificial intelligence」ではなく「super intelligence」を用いることで合意したと発表しました。米中SI対話を設け、リスクと便益について意見を交換し、関連事案の連絡経路も設けるとしています。次回の対話は同年11月までと記されています。

    一方、中国外交部が翌日に公表した「八点成果共識」では、同じ対話と事案の連絡経路について「人工智能」と記載されています。また、呼称について問われた中国外交部の報道官は、米国側の立場を重視し、その呼称を尊重するとの見解を示しました。中国側の公式発表では引き続き「人工智能」が使われており、米中間で対話の枠組みが確認された一方、両国の公式文書で使用される呼称は異なっています。

    さらに9月29日、トランプ大統領は大統領令「Inaugurating the Era of Super Intelligence」に署名しました。大統領令では、連邦行政機関が公式文書やWebサイト、報告書などで「Artificial Intelligence（AI）」に代えて「Super Intelligence（SI）」を使用する方針が示されています。ただし、この大統領令におけるSIは、当面、米国法ですでに定義されているAIが包含する技術やシステムを指すとされています。つまり、米国政府がAIからSIへ呼称を変更したことと、技術的に「超知能」が実現したことは分けて考える必要があります。

    SIとASIは同じ超知能を意味するのか

    混乱を招くのは、Super Intelligenceという表現が、AI研究で長く論じられてきたsuperintelligence（超知能）を連想させる点です。哲学者ニック・ボストロムは、科学的創造性や社会的能力を含む、実質的にあらゆる領域で最も優れた人間の知能を大きく上回る知性として定義しました。人工的な超知能を表す際にはASI（Artificial Superintelligence）という略語も使われます。

    9月29日の大統領令では、当面のSIについて、既存法で定義されているAIが包含する技術・システムを指すと明記されています。特定のモデルがASIに到達したという性能評価や技術上の達成を発表したものではありません。また、AGI（汎用人工知能）も別の概念です。例えばOpenAIは、多くの経済的価値のある仕事で人間を上回る高度に自律的なシステムと定義していますが、AGIの定義が一つに統一されているわけではありません。

    表記指すもの今回のニュースとの関係
    AIArtificial Intelligence（人工知能）の総称中国側の公式文書では「人工知能」と表記。既存の技術資料などでも広く使用されている
    SI米政権がAIに代えて使用するSuper Intelligenceの呼称米国ではAIに代わる呼称として採用。ASIへの技術的な到達を意味するものではない
    AGIArtificial General Intelligence（汎用人工知能）の概念今回のSIへの呼称変更がAGIの実現を示すわけではない
    ASIArtificial Superintelligence（人工超知能）の概念人間の知能を大きく上回る知性を指す文脈で使われる。今回の米国政府によるSIの呼称とは同一視できない

    名前が変わっても企業のAIセキュリティ課題は変わらない

    「超知能」という言葉に目を奪われがちですが、企業がまず確認すべきなのは、現在導入している生成AIやAIエージェントが、どの情報を読み、どのシステムを操作できるかです。外部のWebページや文書を読み込むAIには、そこに紛れ込んだ不正な指示で本来の動作を変えられるプロンプトインジェクションのリスクがあります。OWASPは、外部コンテンツによる間接的な攻撃や、権限を与えすぎたエージェントによる意図しない操作を具体的なリスクとして挙げています。たとえば社内文書を検索して回答する仕組みと、メール送信や顧客データ更新まで実行できる仕組みでは、同じ不正な指示を読み込んでも影響が異なります。利用目的に合わせてアクセス権を最小限にし、重要な操作には人の承認を挟み、ツールの実行履歴を確認できるようにすることが重要です。こうした対策は、AIを何と呼ぶかによって変わりません。

    米中間で設けるとされた事案の連絡経路も、企業の個別の事故対応手順を代替するものではありません。自社では、利用するAIサービス、投入するデータ、外部連携、権限、異常時の停止・連絡先を整理しておく必要があります。NISTの生成AI向けリスク管理資料も、設計から利用・評価まで組織的にリスクを扱うための枠組みを示しています。

    AI利用のルールと技術面を一緒に見直す

    今回の一連の発表では、米国側がSIという呼称を採用するとともに、米中間でAIのリスクと便益について協議する枠組みが示されました。一方、こうした呼称や政策上の動きとは別に、企業では現在利用しているAIの状況を把握し、入力情報の扱い、権限設定、人による確認、インシデント発生時の対応などを継続的に見直すことが求められます。

    BBSecは、AIサービスの提供者・利用者を対象としたセキュリティガイドラインの整備支援など、AI利用におけるセキュリティ対策を支援しています。自社のAI利用ルールやシステム上の対策について、見直し方や進め方にお困りの場合は、お気軽にご相談ください。

    関連記事：

    AIエージェントのセキュリティ対策を詳しく知りたい方へ
    AIエージェントに与える権限や外部通信、人による承認、操作ログなど、企業が確認しておきたいセキュリティ対策を事例とともに解説しています。
    「OpenAIのAIエージェントが外部Wikiへ書き込み ―企業が見直すべき権限・通信・監視」

    【参考情報】

    編集責任：木下

    ウェビナー開催のお知らせ

    最新情報はこちら

    Security NEWS TOPに戻る
    バックナンバー TOPに戻る

    投稿日:

    EvilTokensとは？Microsoft 365を狙うデバイスコードフィッシングとAI悪用

    Share
    EvilTokensとは？アイキャッチ画像

    Microsoft 365の正規のサインイン画面を利用し、利用者に攻撃者側のアクセスを承認させる「デバイスコードフィッシング」が悪用されています。Microsoftが2026年9月に活動基盤を妨害した「EvilTokens」は、この手口によるアカウント侵害に加え、AIを使って侵害した受信箱を分析し、詐欺の標的やなりすまし相手を選ぶ機能も備えていました。本記事では、EvilTokensの仕組みと、Microsoft 365を利用する企業が確認しておきたい認証設定、監視、侵害後の対応について解説します。

    EvilTokensとは

    EvilTokensは、デバイスコードフィッシングによるアカウント侵害や、AIを使った侵害後の情報収集などを支援するPhishing-as-a-Service（PhaaS）プラットフォームです。Microsoftは2026年9月22日、同サービスの活動基盤を妨害したと発表しました。同社によると、世界の1万を超える組織で、1万2,000を超える受信箱が侵害されています。この数字はメール侵害の規模を示したものであり、金銭被害が発生した組織数を示すものではありません。

    Microsoft 365を利用する企業が見直したいのは、認証画面のURLだけで安全を判断する運用です。EvilTokensは、利用者に正規のMicrosoftの画面で操作させ、攻撃者が開始した認証要求を承認させます。アカウントを守るには、MFAの導入に加え、自社で利用を認める認証方式や、侵害が疑われた場合の対応を確認する必要があります。

    正規の認証画面でも侵害につながる理由

    デバイスコード認証は、入力操作に制約のある機器などへサインインするための仕組みです。機器側に表示されたコードを、別の端末のブラウザーで入力して認証を完了します。デバイスコードフィッシングでは、この認証要求を攻撃者が開始し、コードを利用者に入力させます。問題は、コードにひも付く認証要求の主体です。画面自体がMicrosoftの正規サイトでも、そこで承認する要求が攻撃者によって開始されたものであれば、攻撃者側にアクセスが与えられます。偽サイトへパスワードを送信していなくても成立する手口です。利用者がMicrosoftにサインインしていない場合には、正規の画面でパスワードやMFAによる認証を求められることがあります。MFAを設定していても、利用者が攻撃者の要求を正規の認証画面で承認すると、侵害につながる場合があります。

    図1：EvilTokensによるデバイスコードフィッシングと侵害後の流れ

    出典：Microsoft「Disrupting EvilTokens: The AI Chatbot Built for Cybercrime」「Unmasking EvilTokens: Getting to the root of device code phishing」を基に弊社作成
    ※図は攻撃の概略を示したものです。AIによる分析後に、必ずなりすましや金銭被害が発生することを示すものではありません。

    AIは受信箱から取引関係や送金担当者を探す

    EvilTokensのAI機能は、侵害した受信箱を解析し、支払いに関する会話や組織内の役割、信頼関係などを把握するためにも使われていました。Microsoftは、詐欺の標的やなりすまし相手を選び、詐欺の進め方を提案する機能を報告しています。AIが、フィッシングメールの作成だけでなく、侵害した受信箱から詐欺に利用できる情報を探すためにも使われた事例です。このため、ビジネスメール詐欺対策では、振込先の変更や通常と異なる送金依頼について、信頼できる別の連絡経路で確認することが欠かせません。Microsoftも別経路での確認を推奨しています。実務では、受信メールに記載された連絡先をそのまま使わず、社内で管理している既知の連絡先で確認する運用が考えられます。

    EvilTokensへの対策

    図2：EvilTokensへの防御と対応

    出典：Microsoft「Disrupting EvilTokens: The AI Chatbot Built for Cybercrime」、Microsoft Learn「Block authentication flows with Conditional Access policy」「Token theft playbook」「Respond to a compromised cloud email account」を基に弊社作成
    ※対策の分類は、Microsoftの公表資料を基に弊社が整理したものです。

    不要なデバイスコード認証を制限する

    予防策の出発点は、自社でデバイスコードフローを使っているかを把握することです。Microsoftは、利用状況を監査して必要性を判断し、可能な限り利用を遮断する方針を推奨しています。業務上必要な用途がある場合は、その理由と保護方法を明確にし、例外を限定します。Microsoft Entra IDの条件付きアクセスでは、認証フローを条件としてデバイスコードフローをブロックできます。変更時は、レポート専用モードで影響を確認してから有効化します。緊急アクセス用アカウントなど必要な除外を設計し、例外が増え続けないよう定期的に点検することも重要です。従業員向けの説明にも、この仕組みを反映することが重要です。「URLを確認する」に加え、「自分が開始していないサインインのコードは入力しない」と具体化すれば、何を判断すべきか伝わりやすくなります。これは、今回の認証手口を踏まえた教育上の対策の一例です。

    認証後の不審な操作を監視する

    監視では、サインインの成否だけで判断を終えないことが重要です。Microsoftのトークン窃取対応資料では、サインインログ、監査ログ、Officeの操作、関連端末の情報などを調べるよう案内しています。新しい認証方法や端末の登録、メール転送ルールの追加なども確認対象となります。これらの情報は、必要に応じてSIEMなどへ集約し、関連付けて確認できるようにします。たとえば、普段と異なるサインインと、その後の転送設定変更を、同じアカウントの時系列として調べる運用が考えられます。ただし、不審な出来事が一つあっただけでEvilTokensによる侵害と断定することはできません。利用者の操作や業務上の変更だったかを確認し、侵害の有無と範囲を絞り込む必要があります。

    侵害が疑われるアカウントを封じ込める

    アカウント侵害が疑われる場合、Microsoftは、侵害が疑われるアカウントを調査中は一時的に無効化することを推奨しています。あわせて、アクティブなセッションと更新トークンを失効させ、登録されたMFAの方法や端末、同意済みアプリ、管理者権限などを点検します。不正なメール転送設定や、通常の画面では見落としやすい受信箱ルールも確認対象です。パスワードを変更して利用者が再びログインできたことだけでは、攻撃者が残した設定まで除去できたとは限りません。どのアクセスを止め、どの変更を戻し、どのログで確認したかを記録し、公式手順に沿って復旧することが必要です。

    送金や支払情報の変更は別経路で確認する

    EvilTokensでは、侵害した受信箱から取引関係や支払いに関する情報が把握され、なりすましや送金詐欺に悪用される可能性があります。振込先の変更や送金依頼など、金銭に関わる重要な依頼については、メールだけで判断せず、既知の電話番号など信頼できる別の連絡手段で確認することが重要です。

    EvilTokensへの対策は、認証管理だけでは完結しません。認証フローの制御、不審な操作を追跡できるログの整備、侵害時の対応、送金依頼の確認までを、自社の担当者と手順に落とし込むことが重要です。正規の認証画面を通った操作であっても、誰のアクセスを許可しようとしているのかを確認する視点が求められます。

    【参考情報】

    編集責任：木下

    アカウント侵害や不正アクセスが疑われる場合は

    BBSecでは、セキュリティインシデント発生時の初動対応から、原因・影響範囲の調査、フォレンジック調査、再発防止まで支援しています。

    平時の対応体制を見直したい場合

    インシデント初動対応準備支援サービスはこちら

    ウェビナー開催のお知らせ

    最新情報はこちら

    Security NEWS TOPに戻る
    バックナンバー TOPに戻る

    投稿日:

    ClosedQuorumとは AIが次の動作を選ぶマルウェアの仕組みと対策

    Share
    ClosedQuorumとはアイキャッチ画像

    生成AIの活用が広がる中、サイバー攻撃でもAIを組み込んだ新たな手法が確認されています。2026年9月、Cisco Talosは、複数のAIモデルに問い合わせながら次の動作を選択するWindows向けマルウェア「ClosedQuorum」の解析結果を公表しました。本記事では、ClosedQuorumの仕組みと現時点で確認されている範囲を整理し、AIを組み込んだマルウェアに対して企業がどのような監視・対策を考えるべきか解説します。

    ClosedQuorumとは

    ClosedQuorumは、実行中に複数のAIモデルへ問い合わせ、その回答を基に次の動作を選択する仕組みを備えたWindows向けマルウェアです。 Cisco Talosが2026年9月22日に解析結果を公表しました。AIが侵入から目的達成までの全工程を自由に考案するわけではなく、あらかじめ実装された複数の動作から、次に実行するものを選択する設計です。ただし、Talosは報告時点で、ClosedQuorumが実際の攻撃に使用されたことを確認していません。公開配布版には仮のAPIキーなどが含まれており、一連の処理が最後まで動作する様子も観測されていません。本稿では、こうした現時点で確認されている範囲を踏まえ、解析で判明した仕組みと、一般的な防御策から考えられる監視のポイントを分けて説明します。

    AIが実行中の判断に加わる仕組み

    ClosedQuorumは最大4系統のAIモデルへ順番に問い合わせ、最多票を得た動作を選びます。応答を集計するのはマルウェア側のプログラムです。認証情報や暗号資産ウォレット情報の収集、別プロセスへのコード注入、継続実行のための設定といった実装済みの処理を選択する設計が確認されています。C2は、マルウェアへの指示や制御を指します。今回の特徴は、この動作選択に商用AIのAPIを利用する点にあります。AIが開発時にコード作成を手伝うことと、動作中のソフトウェアがAIの応答を処理に反映することは、区別して捉える必要があります。

    図1：Talosの静的解析を基にした設計の概略

    出典：Cisco Talos「The Closed Quorum: Inside the first reported autonomous AI C2 implant」（https://blog.talosintelligence.com/the-closed-quorum-inside-the-first-reported-autonomous-ai-c2-implant/）を基に弊社作成
    ※実際の攻撃での使用と、一連の処理が最後まで動作することは確認されていません。公開配布版には仮のAPIキーなどが含まれています。

    AIの痕跡と攻撃の実態を分けて評価する

    Talosが同日に紹介した研究ツールCAIRNは、AI向けの指示文やAPIの接続先などの情報を手掛かりに、AIを組み込んだマルウェアを調べるものです。同社は、AI関連の文字列などの痕跡だけでは、実際にはAIを組み込んでいない検体も候補に含まれるため、最終的な判断にはリバースエンジニアリングによる検証が必要だと説明しています。企業がAIマルウェアの情報を読む際も、「AIとの接点がある」「攻撃機能が実装されている」「実際に被害が発生した」という確認の段階を混同しないことが重要です。これはCAIRNの説明を踏まえた情報評価の観点です。検体の解析結果だけで、被害規模や攻撃の成功率まで判断することはできません。

    ClosedQuorumを理由に、自律型サイバー攻撃がすでに広く成功していると結論づける根拠はありません。一方で、企業が点検できる項目はあります。以下では、MITRE ATT&CKが整理する既知の攻撃手法と防御策を基に、監視体制の確認方法を考えます。これはClosedQuorum固有の検知性能を保証するものではありません。

    正規サービスへの通信は利用の文脈まで確認する

    正規のWebサービスを攻撃の制御に使う手口は、MITRE ATT&CKでも整理されています。通信先が著名なサービスであることだけでは、安全性を判断できません。MITREは、通常と異なるプロセスからの外向き通信や、不自然な状況で行われるWeb API呼び出しを、検知の観点として挙げています。この考え方をAIサービスの通信に当てはめると、確認したいのは、どの端末で、どのプログラムが、何の業務のために通信したかです。承認済みアプリによる通常の利用と、用途不明の実行ファイルによる通信を切り分けられるよう、通信情報と端末上の処理を関連付けて確認することが重要です。

    通信制御も業務上の必要性を踏まえて設計します。MITREは、許可されていない外部サービスの利用をWebプロキシで制限する対策を挙げています。自社で認めるサービスと利用経路を整理しておけば、不明な通信を調べる際の判断材料になります。

    図2：MITRE ATT&CKの一般的な検知観点を基に作成した監視の例

    出典：Cisco TalosおよびMITRE ATT&CK（T1102、T1003.001、T1053.005）を基に当社作成
    ※一般的な検知・監視の考え方を示したものであり、個別の兆候やAIサービスへの通信だけでClosedQuorumへの感染を判断するものではありません。

    認証情報へのアクセスと継続実行の設定を監視する

    端末側では、認証情報を扱う処理への不審なアクセスが重要な確認対象となります。MITRE ATT&CKは、Windowsの認証処理に関わるLSASSへの異常なアクセスと、その後のメモリダンプやファイル作成を、一連の動作として捉える検知方法を示しています。EDRなどで取得した記録を調べる際も、実行ファイルの名前だけでなく、実際に何へアクセスしたかを確認することが重要です。予防策としては、認証情報の保護、特権アカウントの利用制限、LSASSを保護する設定などが挙げられます。ただし、Credential Guardなどの保護機能にも適用条件と守備範囲があります。導入済みという理由だけで、すべての認証情報窃取を防げると判断しないことが必要です。

    継続実行を狙う設定変更にも目を向ける必要があります。たとえば、Windowsのスケジュールタスクは正規の管理用途にも使われますが、攻撃者に悪用されることがあります。MITREは、不審なタスクの作成や変更と、その後の実行を関連付ける検知を示しています。管理作業として説明できるかを確認し、必要以上の権限で動くタスクや不明な実行先を調査することが重要です。

    AIという名称より取得できる証拠を確認する

    自社の監視体制を点検するなら、通信と端末の記録を結び付けられるかを確認するところから始めることが重要です。SOCや外部の監視担当者とも、不明な外向き通信が見つかったときに、その実行元や前後の処理まで調べられるかをすり合わせておきましょう。ClosedQuorumは、AIを動作選択に使う設計を具体的に示した解析事例です。現時点で確認されている事実を踏まえながら、既存のログ、認証情報の保護、権限管理を点検することが重要です。その積み重ねが、AIを組み込んだマルウェアについても、名称や印象に左右されず調査するための土台になります。

    【参考情報】

    編集責任：木下

    継続的な監視・検知体制の見直しを

    サイバー攻撃の手法が変化する中でも、不審な通信や端末上の挙動を継続的に監視し、複数の兆候を関連付けて確認できる体制が重要です。BBSecでは、セキュリティ監視・分析を支援する「G-MDR®」を提供しています。

    G-MDR®について詳しく見る

    ウェビナー開催のお知らせ

    最新情報はこちら

    Security NEWS TOPに戻る
    バックナンバー TOPに戻る

    投稿日:

    AIエージェントを悪用したECサイト攻撃 ―カード情報窃取の報告から考える対策

    Share
    AIエージェントによるECサイト攻撃アイキャッチ画像

    AIエージェントを悪用したECサイトへのサイバー攻撃について、Gambit Securityが2026年9月22日に調査結果を公表しました*6。同社は、2社から60万件を超えるカード記録が窃取されたと報告しています。同報告は暫定的な調査結果に基づくものですが、EC事業者が確認したいのは、自社の決済画面が不正に変更されていないか、攻撃の入口を放置していないかという具体的な問題です。

    Gambit Securityが報告したAIエージェントの役割

    Gambitは攻撃者のステージングサーバーを調べ、脆弱性調査を担うStrix、侵入目標に向けて動くCairn、攻撃全体を調整するHermesの利用を確認したと説明しています。人間も短い指示を出しており、完全な無人攻撃と表現するのは適切ではありません。同社によると、9月10日から15日に105件の攻撃プロジェクトが開始され、少なくとも27社で程度の異なる侵害が発生しました。これらは被害企業による一斉の公式発表ではなく、Gambitの調査結果です。報告には直接確認した証拠のほか、ログやAIの自己報告を組み合わせて評価した情報も含まれ、同社は一部に誤りや不正確さがあり得ると明記しています。

    図1：報告されたAIエージェントの役割

    出典：Gambit Security「Autonomous AI Agents are breaking into hundreds of Online Retailers for $25 a target in an ongoing campaign」（https://gambit.security/blog-posts/autonomous-ai-agents-online-retailers-25-a-company）をもとに弊社作成。
    各ツールの主な役割を簡略化したものであり、すべての対象で同じ順序・攻撃経路が用いられたことを示すものではありません。

    カードスキマーは決済画面に何を仕込むのか

    今回の調査では、カード情報を盗む不正スクリプトの設置も報告されています。ただし、60万件超というカード記録のすべてが、この仕組みだけで窃取されたという意味ではありません。[1]Web上のカードスキマーとは、決済時に入力されるカード情報などを盗み取るための不正なプログラムを指します。こうしたeスキミングでは、決済ページに不正なスクリプトが組み込まれ、利用者のブラウザー上で入力されたカード情報などが窃取されることがあります。

    PCI Security Standards Council（PCI SSC）も、決済ページのスクリプト管理と改ざんの監視を重要な対策として説明しています*2。サイト担当者が決済画面の見た目だけを確認しても、読み込まれるスクリプトの正当性までは判断できません。運用上は、画面の表示確認とは別に、どのスクリプトを、どの目的で、誰の承認に基づいて動かしているのかを把握する必要があります。

    図2： Webスキミングの基本的な仕組みと確認箇所

    出典：PCI Security Standards Council「Payment Page Security and Preventing E-Skimming」（https://blog.pcisecuritystandards.org/new-information-supplement-payment-page-security-and-preventing-e-skimming）をもとに弊社作成。
    一般的なeスキミングの仕組みを簡略化した模式図であり、今回報告されたすべての被害経路を示すものではありません。

    決済ページのスクリプトと変更履歴を確認する

    PCI SSCの解説は、PCI DSSの要件6.4.3と11.6.1について、決済ページのスクリプトの承認、完全性の確認、改ざん監視に焦点を当てています。スクリプトだけでなく、セキュリティに影響するHTTPヘッダーの変更も確認対象となります。個別の適用範囲や検証責任は、決済構成や契約関係を踏まえてアクワイアラーなどに確認する必要があります。

    実務に落とし込むなら、最初に決済ページに関係する変更を誰が把握しているかを確認したいところです。EC担当者、開発会社、決済サービスの担当者が、それぞれ自分の管理部分だけを見ていると、全体の説明ができなくなります。自社で変更できる箇所と、委託先へ確認すべき箇所を整理しておくことが出発点となります。例えば、解析タグの追加を依頼する際に、設置目的と承認者、対象ページを記録します。改ざん検知の通知を受けたら、その時間帯に予定された更新があったかを照合します。通常の変更と不審な変更を確認するための情報を、日常の更新作業から残しておくことが重要です。

    侵入経路を調べる診断と改ざんを見つける監視

    ECサイトの不正アクセス対策を考える際は、「攻撃が入り込む問題はないか」と「すでに不正な変更が起きていないか」を別々に確認する必要があります。脆弱性診断は主に前者、改ざん検知は主に後者を確認するための取り組みです。片方を実施したというだけで、もう片方の確認が済んだことにはなりません。

    診断の対象を相談するときは、商品ページのURLだけを渡すのではなく、ログインや管理機能、APIなど、サイトの機能構成を共有することが重要です。BBSecのSQAT® for Webでは、入出力処理、認証、セッション管理などを診断対象として示し、検出した問題の深刻度と推奨対策を報告しています。監視を導入する際も、通知の受信先を設定するだけで終えず、誰が内容を確認し、誰が開発会社へ連絡するかを決めておく必要があります。営業時間外に通知された場合の連絡先や、決済機能の停止を判断する責任者を定めておけば、発見後の対応を具体化できます。これは今回の個別被害を推測したものではなく、ECサイト運営で準備しておきたい対応体制です。

    BBSecの改ざん検知で日々のサイト変更を監視する

    BBSecの「Webサイトコンテンツ改ざん検知」は、Webサイトの不正な変更やマルウェアの埋め込みを確認するサービスです。クローリング型のCracker Probing-Eyes® Detectが、設定したURLを起点に定期的にサイトを検査します。またWebサーバーにエージェントを導入するCracker Probing-Eyes® Detect Plusは、ファイルの改変をリアルタイムで監視する方式です。導入を検討する際は、自社の決済ページがどのサーバーから配信され、どこにスクリプトが置かれているかを共有し、監視したい範囲に合う方式を相談することが重要です。

    ただし導入しただけですべてのカードスキマーを検知できる、あるいはPCI DSSの関連要件への適合が確定すると判断することはできません。対象環境と監視範囲を確認して設計する必要があります。管理画面のアクセス制御など、基本対策の実施状況から整理したい場合には、「EC加盟店様向け セキュリティ・チェックリスト対応アセスメント」も選択肢となります。対応状況の確認と報告に加え、是正支援を含むコースでは、開発ベンダーとの打ち合わせへの同席などを提供しています。

    異常を見つけた後の対応まで準備しておく

    不審なスクリプトや予期しないファイル変更が見つかったときは、対象ページ、発見時刻、検知内容を整理し、調査担当者に引き継ぎます。BBSecのデジタルフォレンジックを含む緊急対応支援では、状況把握や証拠保全、原因調査、今後の対応方針について相談できます。

    自社サイトを守るために、まずAI攻撃かどうかを判定する必要はありません。公開中の機能に弱点を残していないか、決済ページの変更を把握できているか、異常発見時に動けるかを確かめることが重要です。今回の報告を、自社のECサイトの診断範囲と監視体制を見直す機会にしてはいかがでしょうか。

    【参考情報】

    編集責任：木下

    サイバーインシデント緊急対応

    サイバーセキュリティ緊急対応電話受付ボタン
    SQAT緊急対応バナー

    ウェビナー開催のお知らせ

    最新情報はこちら

    Security NEWS TOPに戻る
    バックナンバー TOPに戻る