インシデント公表文の読み方フレームワーク-【題材】ニチレイの不正アクセス事案（公式リリース全5報）

セキュリティインシテントが起きるたびに、被害企業の公表文（プレスリリース）を読む機会があると思います。でも公表文は情報が驚くほど少ない。「不正アクセスによるシステム障害が発生しました」「詳細は差し控えます」一一これだけ読んで、技術者として何を判断すればいいのか。

この記事では、インシデント公表文から最大限の情報を引き出し、かつ誤読・過剰解釈をしないための読み方フレームワークを整理します。題材として、2026年7月13日に発生したニチレイグループの不正アクセスによるシステム障害（公式リリース第1報～第5報）を使います。

この記事でわかること

・インジデント公表文を読むときの4つの点（表現の変遷／非公表項目／攻撃者主張との分離／ソースの区別）
・ ニチレイ事案（2026/7）で公式に「わかっていること」と「わかっていないこと」の正確な境界線
・「業務が止まったーランサムウェアで暗号化された」と断定してはいけない技術的理由
・ コピペで使える「公表文読解チェックリスト」
・警察庁統計（令和7年）を踏まえた、自組織のVPN・RDP露出を棚卸しする具体的手順（コマンド付き）

この記事で扱わないこと

・ニチレイ事案の侵入経路・攻撃手法の特定（公式に非公表であり、現時点で誰にも書けません）
・ 特定ベンダ製品の推奨・比較

なお、本記事は個人の学習・技術的展開を目的としたものです。事実はすべて未尾の出典（公式リリース・公的機関・報道を区別）に基づき、考察には「考察」ラベル（考察と明記）を付けています。

1.なぜ「公表文の読み方」が技術者のスキルなのか

インシデント公表文は、法務・広報・経営が関与して一語一語慎重に選ばれた文です。書いてあることは（基本的に）事実ですが、書いていないことのほうが圧倒的に多い。そして技術者がこれを読む場面は意外と実務に直結しています。

・ 自社への影響判断：取引先・委託先が被害を受けたとき、自社システムとの接続を切るか、様子を見るかの初動判断材料になる

・社内報告：「〇〇社がランサムウェアにやられたらしいです」と未確認情報のまま上に報告すると、後で訂正するはめになる（そして公表文を正確に読んでいれば防げる）

・自社が当事者になったときの逆引き：他社の公表文の構造を知っていると、自社で公表文を書く側に回ったときに何を出し何を出さないかの相場観が持てる

一方で、公表文の少ない情報を推測で埋めたくなる誘惑は強く、SNSでは「これは絶対●●」という断定が飛び交います。少ない情報から読み取れることを最大化しつつ、読み取れないことは「読み取れない」と言い切る。このバランスを取るのが、以下の4観点です。

2.フレームワーク：公表文を読む4つの観点

観点1：原因表現の変遷を追う（リリース間のdiffを取る）

第1報と続報とで、原因や被害の表現がどう変わったかに注目します。公表文の語の選択は意図的です。表現が変わった箇所は「調査で確定した情報が増えた」ことを、変わらない箇所（特に続報でも曖昧なままの箇所）は「まだ確定していないor 意図的に出していない」ことを示唆します。

実務的には、各報の原因記述を抜き出して並べる（＝diffを取る）だけです。

観点2：非公表項目を列挙する（「書いてないことリスト」を作る）

公表文を読んだら、書いてあることの要約と同時に、書いていないことのリストを作ります。定番の確認項目は次のとおりです。

確認項目	よくある状態
侵入経路・悪用された脆弱性	非公表が多い（調査中・再攻撃防止）
攻撃種別（ランサムウェアか、暗号化被害の有無）	明言しない例が多い
攻撃者の身元	公式が言及する例は少ない
身代金要求の有無	ほぼ非公表
影害を受けたシステムの具体的範囲	「業務」単位で書かれ、システム単位では書かれないことが多い
個人情報の件数・種類	「可能性」段階では非公表が多い
発生・検知の正確な時刻	公表文には書かれず報道にだけ出ることがある

このリストの価値は、「不明」を「不明」として扱う根拠になることです。「公表文に記載がない」と「事実として存在しない」は別物で、逆に「報道には書いてあるが公表文にない」情報は出どころの確認が必要になります（観点4）。

観点3：攻撃者の主張と公式発表を分離する
ランサムウェア攻撃グループはリークサイトで犯行声明を出しますが、これは攻撃者の主張であって事実確認された情報ではありません。攻撃者には誇張の動機があり（脅迫の効果を高めるため）、無関係の便乗の可能性もゼロではありません。報道が「〇〇グループが犯行声明」と伝えても、それは「声明が出たこと」の報道であって「そのグループが攻撃したこと」の確認ではない、と区別して読みます。

書き分けの基準はこうなります。

NG:〇〇社は××グループのランサムウェア攻撃を受けた
OK：〇〇社への攻撃について××グループが犯行を主張していると報じられている
（〇〇社は攻撃者・攻撃種別を公表していない）

観点4：一次ソースと二次ソースを区別する

・一次ソース：被害企業の公式リリース、公的機関（警察庁・IPA・JPCERT/CC・個人情報保護委員会等）の発表、CVE/NVD、ベンダアドバイザリ

・ 二次ソース：報道、専門家の解説、まとめブログ（本記事もここに入ります）

二次ソースにしかない情報（例：発生時刻、被害規模の推定）は「～と報じられている」として扱い、一次ソースの情報と混ぜないようにします。また、二次ソース同士で記述が食い違うことは珍しくなく、食い違い自体が「確定していない」ことのシグナルになります。

3.適用例：ニチレイ事案（2026年7月）を4観点で読む

3-0.事案の概要（公式発表ベース・最小限）

2026年7月13日、ニチレイは不正アクセスによるシステム障害の発生を公表しました。影響業務はニチレイロジグループ各社の冷蔵倉庫入出庫業務とニチレイフーズの冷凍食品出荷業務で、障害範囲は日本国内に限定 [1]。同社は発生当日に緊急対策本部を設置してシステム遮断を実施し[2]、7月17日から部分稼働[3]、そして7月24日、受発注制限を解除し「全拠点で平常時の通常稼働に移行しました」と公表しました（第5報）[8]。発生から全面復旧の公表まで11日です。攻撃の詳細・原因・攻撃者は第5報でも公表されていません[8]。

日付	出来事	区分
7/13	障害発生・第1報公表。当日中に緊急対策本部設置・システム遮断（第2報で公表）	公式[1][2]
7/15	第2報。「サイバー攻撃を受けたことを確認」。個人情報保護委員会へ報告	公式[2]
7/17	第3報。冷蔵倉庫・食品工場の部分稼働を開始	公式[3]
7/22	第4報。警察と連携、攻撃詳細は非開示、対象者へ個別通知、「今週中に全拠点通常稼働へ移行予定」	公式[4]
7/22	「RansomHouse」がリークサイトで犯行を主張したと報道（真未確認）	報道[9][10][11]
7/24	第5報。受発注制限を解除し、全拠点で平常時の通常稼働に移行（発生から11日）	公式[17]

3-1.観点1の適用：全5報の原因表現をdiffする

公式リリース5報から原因に関する表現を抜き出して並べます。

 第1報（7/13）：「不正アクセスによるシステム障害」が発生
+第2報（7/15）：当社のサーバが「サイバー攻撃を受けたことを確認」
 第3報（7/17）：（原因表現の更新なし。復旧状況が中心）
 第4報（7/22）：「サイバー攻撃の詳細は、情報開示を差し控えさせていただきます」
 第5報（7/24）：（原因表現の更新なし。受発注制限の解除、全拠点通常稼働への移行を公表）

読み取れることは3つあります。

1.第1報→第2報で「不正アクセス」から「サイバー攻撃を受けたことを確認」へ明確化された[1][2]。初報時点では攻撃の確証が持てていなかった（または表現を慎重にしていた）ものが、2日間の調査で「攻撃を受けた」ことは確定情報に昇格した、と読めます。

2.全5報を通じて「ランサムウェア」という語は一度も使われていない[1][2][3][4][17]。攻撃種別-暗号化被害の有無は、復旧完了を公表した第5報の時点でも公式には一切不明です。

3．第2報・第4報で「詳細は差し控える」と2回明言している[2][4]。単に書き忘れたのではなく、開示しないという判断が意図的に維持されていることがわかります。

3-2.観点2の適用：非公表項目リスト

執筆時点（2026-07-29）で、公式リリース全5報に記載がない項目です。

項目	状況
侵入経路・悪用された脆弱性	非公表。「被害の拡大を防ぐため」開示を差し控えると明言[2][4]
攻撃種別（ランサムウェアか否か・暗号化被の有無）	非公表。「ランサムウェア」の語は公式に未使用[1][2][3][4][17]
攻撃者の身元	非公表（犯行声明報道は観点3で扱う）
身代金要求の有無・交渉状況	非公表
個人情報の件数・種類・対象範囲	非公表（「被害サーバの一部に個人情報が保管」「対象者へ個別通知を実施」まで）[2][4]
被害サーバーシステムの具体的範囲	非公表（影響「業務」のみ公表）[1]
障害発生・確認の正確な時刻	公式には非公表。「7/13午前6時50分ごろ確認」は日クロステック報道のみ[8]

ちなみに「全拠点通常稼働の完了」は、第4報（7/22）時点ではこの表に載る「予定」段階の項目でしたが、第5報（7/24）で確定事実に昇格しました[4][17]。非公表項目リストは続報のたびに変化する一ーだからこそ観点1（表現の変遷）とセットで使う、というフレームワークの動きがそのまま観察できた例です。

逆に、公式に書いてあることも整理しておくと、初動対応（当日の対策本部設置とシステム遮断[2]）、外部セキュリティ専門会社との協力・警察との連携[2][4]、個人情報保護委員会への「漏えいの可能性がある事案」としての報告[2]、対象者への個別通知[4]、といった対応プロセスはかなり具体的に公表されています。「攻撃の詳細は出さないが、対応のプロセスは出す」という開示方針が読み取れます。

3-3.観点3の適用：RansomHouse報道をどう扱うか

7月22日、ランサムウェア攻撃グループ「RansomHouse」がリークサイトにニチレイを掲載し犯行を主張した。と複数メディアが報じました[9][10][11]）。攻撃者は財務資料・顧客関連文書等の窃取を主張していると報じられています[10]。

観点3に従って分離すると、こうなります。

・事実（確認済み）：「RansomHouseが犯行を主張したという報道が存在する」こと
・未確認：RansomHouseが実際の攻撃者か／窃取を主張するデータが本物か／本件が「ランサムウェア攻撃」だったか

さらにこの事案では、観点3の応用問題として面白い（≒危うい）ポイントが2つあります。

その1：専門家の間でもグループの手口の記述が食い違っている。RansomHouseについて「データを暗号化せず、窃取データによる恐喝のみを行う」とする分析がある一方[12]、「システムの暗号化と暴露をあわせた多重恐喝を行う」とする解説もあります[11]。つまり仮に同グループの関与が事実だとしても、「暗号化被害があった」ことにはならない。二次ソース間の食い違いは「確定していない」ことのシグナル、という観点4の実例でもあります。

その2：「業務が長期間止まった＝暗号化された」は成立しない。ニチレイは発生当日に自らシステムを適断しています[2]。攻撃者に暗号化されていなくても、防御側が封じ込めのために自らネットワークを切れば、外から見える「止まり方」は同じです。業務停止の長さから攻撃種別を逆算することはできません。

3-4.観点4の適用：この事案の一次／二次ソースの境界

・障害確認時刻「7/13午前6時50分ごろ」は日経クロステックの報道のみが情報源で、公式リリースに時刻の記載はありません[8]

・取引先の日本KFC-くら寿司はそれぞれ欠品・配送遅延等のお詫びを公表していますが、両社ともニチレイの社名を明示していません（「物流会社」「お取引先様」と表現）[6][7]。両社の障害をニチレイ起因と結びつけているのは報道です

・RansomHouseがアスクル事案（2025年10月）と同一グループとする情報も報道ペースです[11][13]

「取引先が〇〇社を名指ししていないのに、まとめ記事では名指しになっている」バターンは頻出です。引用時にどの主体がどこまで言ったかを保持するのは、地味ですが公表文読解の基本動作です。

4.技術者として読み取れること（※ここからは考察）

以下は公開情報に基づく一般論としての考察であり、本件の確定情報ではありません。

4-1.「発生当日にシステム遮断」の重み

発生当日に緊急対策本部設置とシステム遮断まで到達している[2]のは、検知→エスカレーション→意思決定の手順が機能した可能性を示唆します。適断そのものは技術的には数分で終わる操作ですが、意思決定としては「全業務を止めるルベルの経営判断です。判断者・発動条件・遮断対象の優先順位がランブック（対応手順書）と権限設計に落ちていない組織では、承認を取り回しているうちに当日が終わります。他社の公表文で「当日遮断」の記述を見かけたら、そこは事前準備の痕跡として読める箇所です。
これは、同社が日頃から訓練及び対応手順書の整備を怠っていなかったという見方も可能だと考えます。

一方で、適断が早くても、全拠点の通常稼働までは11日を要しています[1][17]。封じ込めの速さ（インシデントレスポンスの守備範囲）と、止まった業務をどう回し・どう戻すか（事業継続計画の守備範囲）は別レイヤーの問題で、前者の成功は後者を保証しません。

4-2.止まったのが「WMS等の業務系」であることの意味

停止したのは情報系（メール・会計等）ではなく、冷蔵倉庫の入出庫・出荷指示という物理的なモノの動きを直接制する業務システムです[1]。物流システムの階層を単純化すると、

[経営層] ERP・受発注・止まっても数日は帳票・電話で代替しうる
[実行層] WMS（倉庫管理）・TMS（輸配送管理）___★今回止まった層
[制御層] WCS・マテハン制御・自動車クレーン___WMSからの指示がないと動けない
[物理層] パレット・フォークリフト・トラック

実行層（WMS）が止まると、在庫は物理的に存在していても「どのパレットをどこへ出すか」の指示が出せず、制御層以下が総倒れになります。冷凍倉庫は常温倉庫と違い「とりあえず全部外に出して手作業で仕分け」もできません（温度管理の制約）。物流・製造業では実行層の障害が即、操業停止になる構造です。ニチレイロジグループの顧客は年間約5,000社・売上の約92%がクループ外と報じられており[8]、この層の停止がサプライチェーン全体へ波及した規感の背景になっています。

復旧が「部分稼働（7/17）→全拠点通常稼働（7/24完了・受発注制限の解除）」[3][17]と段階的なのも、この階層構造と整合的です。安全性を確認した拠点・システムから順に再接続していく手順は、全システム一斉復旧よりも再感染リスク管理の観点で標準的なアプローチです（※考察。実際の復旧手順は非公表）。

4-3.攻撃詳細を公表しない一般的理由

「詳細は差し控える」を隠蔽と短絡するのは早計で、一般論として合理的な理由がいくつもあります。

1.捜査上の制約：警察と連携している場合[4]、何をいつ開示できるかは捜査側の都合にも縛られる

2.再攻撃・模倣の防止：フォレンジックが完了する前に侵入経路を明かすことは、攻撃者側に「その経路がまだ生きているか」の答え合わせをさせるのに等しい

3.交渉・二次被害への影響：攻撃者と接触があるケースでは、接触状況を開示すること自体が相手に交渉材料を与えうる

調査完了後の確報で侵入経路・時系列が詳細に公表される事例も多く、現時点は「続報を待って評価すべき段階」です。逆に言えば、確報が出たときにこそ観点1（表現の変遷）が最も効きます。

5.コピペで使える：インシデント公表文 読解チェックリスト

上記フレームワークをチェックリスト化したものです。他社事案を読むとき、社内報告を書くとき、そのままコピーして使えます（Markdown）

## インシデント公表文読解チェックリスト
対象事案:__________／確認日：___________

### A.ソースの確認（観点4）
- [ ] 被害企業の公式リリース原文を読んだ（まとめ記事・SNS経由の孫引きでない）
- [ ] 公式リリースの「一覧ページ」を確認し、最新の報を特定した（第N報まで）
- [ ] 上場企業の場合、適時開示（TDnet）の有無を確認した
- [ ] 報道にしかない情報（発生時刻・被害規模等）をマークし「報道による」と区別した
- [ ] 取引先・関係企業の発表は、誰が誰を名指ししているかを保持して引用した

### B.表現の変速（観点1）
- [ ] 各報の原因表現を抜き出して並べた（例：不正アクセス → サイバー攻撃を確認）
- [ ] 続報で明確化された点/暖味なまま維持されている点を区別した
- [ ] 「詳細は差し控える」等、意図的な非開示の明言があるか確認した

### C.非公表項目の列挙（観点2）
- [ ] 侵入経路・脆弱性：公表／非公表
- [ ] 攻撃種別（暗号化被害の有無）：公表／非公表
- [ ] 攻撃者：公表／非公表
- [ ] 身代金要求：公表/非公表
- [ ] 影響システムの具体的範囲：公表／非公表
- [ ] 個人情報の件数・種類：公表／非公表「可能性」段が「確定」かも区別）
- [ ] 復旧状況：完了報告あり／「予定」段階

### D.攻撃者主張の分離（観点3）
- [ ] 犯行声明の有無を確認した（あれば「主張」「真偽未確認」と明記）
- [ ] 「業務停止の長さ」から攻撃種別を推定していないか自己チェックした（自主遮断でも長期停止は起こる）
- [ ] 攻撃グループの手口説明を単一ソースに依存していないか確認した

### E.発信前の最終チェック
- [ ] 断定形で書いた文はすべて一次ソースに対応しているか
- [ ] 「らしい」「possibly」を落とした要約になっていないか（タイトル・見出しも）
- [ ] 公開前に公式サイトを再確認し、続報が出ていないか確認したか

6.おまけの実務編：警察庁統計を踏まえたVPN/RDP露出の棚卸し

本件の侵入経路は非公表です。ここからは本件を離れた一般論として、国内の統計上もっとも「ありがち」な侵入口を自組織で棚卸しする手順を載せておきます。

警察庁「令和7年におけるサイバー空間をめぐる脅威の情勢等について」によると、令和7年（2025年）に警察へ報告された企業・団体等のランサムウェア被害は226件。
感染経路として判明したもののうち、VPN機器からの侵入が6割以上で最多、次いでリモートデスクトップからの侵入と報告されており、被害組織の約6割は中小企業です[14]。つまり統計上は、高度な攻撃よりも「インターネットに露出したVPN/RDPの管理不備」が主戦場です。

手順1：外部に露出しているものを把握する

まず「自組織のクローバルIPで何が待ち受けているか」を確認します。
スキャンは自組織が管理権限を持つIPアドレスに限定してください（他者のシステムへのスキャンは不正アクセス禁止法等に抵触するおそれがあります）。また、実施する際は個人の勝手な対応とせずに必ず組織上の承認をとってから行うべきです。特に攻撃検知の仕組みを持っている組織・団体であると、即座に実施したことが攻撃だと誤認されてしまう可能性があります。

# 自組織の管理するグローバルIPに対して、VPN/RDPでよく使われるポートを確認
# （nmapは無料。実行は必す自組織言理のエのみ。
# TCP:SSL-VPN・RDP・管理画面などでよく使われるポート
nmap -Pn -p 443,1194,3389,8443,10443 <自組織のグローバルIP>

# UDP:IPsec （IKE/NAT-T）・OpenVPN のホートはUDPなので別途3で確認
# （UDPスキャンは管理者権限が必要で、時間がかかり結果もopen|filteredと暖味になりやすい）
nmap -sU -Pn -p 500,4500,1194 <自組織のグローバルIP>

「開いているつもりのないポートが開いていた」「退役したはずのVPN装置が応答した」が棚卸しの典型的な発見です。

手順2:Windows側でRDPの状態を確認する

＃ RDPが有効になっているか（0＝有効、1=無効）
Get-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server' -Name fDenyTSConnections

＃ 3389で待ち受けているか
Get-NetTCPConnection -LocalPort 3389 -State Listen -ErrorAction SilentlyContinue

# 有効なローカルアカウントの棚卸し（使っていないアカウントは無効化候補）
Get-LocalUser | Where-Object { $_.Enabled } | Select-Object Name, LastLogon, PasswordLastSet

RDPをインターネットに直接公開しない・使うなら必ず多要素認証と接続元制限を挟む、が原則です。

手順3：VPN機器の管理台帳を作る

特定製品名には触れませんが、確認項目は共通です。

確認項目	見るところ
ファームウェアが最新か	各ベンダのアドバイザリ、JVN [15]、IPA重要セキュリティ情報[16]
サポート期限（EOL）を過きていないか	ベンダのEOL告知ページ（台帳に期日を記録）
不要アカウントが残っていないか	VPN装置のローカルユーザー覧（退職者・保守業者の残置アカウント）
多要素認証が有効か	装置/連携するID基盤の設定
管理画面がWAN側に出していないか	手順1のスキャン結果と装置の設定

いずれも標準機能と無料の情報源だけで実施でき、統計上の主要経路[14]を直接つぶしにいく作業です。四半期に1回、手順1～3を回すだけでも露出の劣化（設定変更・EOL到来・アカウント残置）を検出できます。

7.まとめ

・公表文は「書いてあること」より「書いていないこと」「表現が変わったこと」に情報がある。4観点（表現の変遷/非公表項目/攻撃者主張の分離／ソースの区別）で読む

・ニチレイ事案は、復旧完了を公表した第5報まで含めて公式5報のどこにも「ランサムウェア」の話がなく、攻撃種別・侵入経路・暗号化被害の有無はすべて非公表。RansomHouseの犯行声明は報道ペースの未確認情報[1][2][3][4][17][9][10]

・「業務が長く止まった＝暗号化された」は成立しない。自主遮断でも同じ止まり方をする

・攻撃の詳細より先に「対応プロセス」（当日遮断・対策本部・届出・個別通知・11日での全面復旧公表）が具体的に公表されており[2][4][17]、公表文からはむしろインシデント対応体制のほうがよく見える

・統計上の最多侵入経路（VPN機器・RDP[14]）の棚卸しは、標準機能と無料ソールで今日から始められる

本件は第5報で全拠点通常稼働への移行が公表されましたが[17]、攻撃の詳細は依然として非公表です。調査完了後の確報が出たら、観点1の「表現の変遷」を使って読み直すのが、このフレームワークの一番おいしい使い方です。

姉妹記事（対象読者が異なります）

姉妹記事は、時間のない経営者・ビジネスマン、または技術者向けの図解・考察編です。同じ事案について、経営層向けに1分で把握できる図解3枚版と、中小企業向けの低予算対策チェックリスト版（バックアップの3-2-1化、手作業運用手順、届出先の事前備など）を、対象読者が異なるためnoteで公開しています - http://note.com/cikano/

こちらもご興味ありましたらぜひ読んでみてください！

参考文献

公式（被害企業・取引先）
・[1]ニチレイ「当社グループでのシステム障害発生について（第1報）」2026/7/13-https://www.nichirei.co.jp/news/2026/512.html

・[2]ニチレイ「当社グループでのシステム障害発生について（第2報）」2026/7/15-https://www.nichirei.co.jp/news/2026/513.html

・[3]ニチレイ「当社グループでのシステム障害発生について（第3報）」2026/7/17ーhttps://www.nichirei.co.jp/news/2026/514.htm！

・[4]ニチレイ「当社グループでのシステム障害発生について（第4報）」2026/7/22-https://www.nichirei.co.jp/news/2026/515.html

・[17]ニチレイ「当社グループでのシステム障害生について（第5報）」2026/7/24-https://www.nichirei.co.jp/news/2026/517.html

・[5]ニチレイニュースリリース一覧（2026/7/24問、本件リリースは第1～5報の掲載を確認）-https://www.nichirei.co.jp/news/

・[6]日本KFC「通常営業再開のお知らせ」2026/7/22-https://apan.kfc.co.jp/news_release/8160

・[7]くら寿司「一部店舗での商品の欠品・配送遅延に関するお詫びとお知らせ」2026/7/15-https://www.kurasushi.co.jp/uplcad/260715release.pdf

公的機関
・[14]警察庁サイバー警察局「令和7年におけるサイバー空間をめぐる春威の情勢等について」2026年3月公表一
https://www.npa.go.jp/publications/statistics/cybersecurity/data/R7/R07_cyber_jousei.pdf

・[15] JVN (Japan Vulnerability Notes) - https://jvn.jp/

・[16] IPA重要なセキュリティ情報-https://www.ipa.go.jp/security/security-alert/

報道
・[8] 日経クロステック「ニチレイに不正アクセス、冷凍食品の生産や入出庫に関する業務に影響」2026/7/14ー
https://xtech.nikkei.com/atcl/nxt/news/24/03305/※一部有料

・[9] ITmedia NEWS「ニチレイへの攻、ランサム集団『RansomHouse』が犯行声明アスタルを攻撃したグループか」2020/7/22ー
https://www.itmedia.co.jp/news/articles/2607/22/news064.html

・[10] 日本経済新聞「ニチレイへのサイバー攻撃、ランサムウェアかハッカー集団が声明」2026/7/22ー
https://www.nikkei.com/article/DGXZQOUC220C30S6A720C2000000/ ※一部有料

・[11] ビジネス+IT「ニチレイのサイバー攻撃、ロシア系ランサムハウスが犯行声明、アスクル害と同一集団」2026/7/22ー
https://www.sbbit.jp/article/cont1/186206

解説（考察の参考）
・[12] サイバートラストブログ「アスクル社（ASKUL）を襲ったランサムウェア攻撃」ーhttps://www.cybertrust.co.jp/blog/linux-oss/system-
monitoring/vulnerability/security-threat-trends2511-01.html

・[13] 日経クロステック「アスクルへのランサムウエア攻撃で犯行声明、「RansomHouse』グループの正体」一https://xtech.nikkei.com/atcl/nxt/column/18/00001/11224/

---

QiitaでCikaは、現場感のあるホワイトハッカーとしてセキュリティニュースや事故を題材に技術者・エンジニアの方が参考になる情報を発信していきたいと思いますので、よかったら❤️＆フォローをお願いできたらと思います。
読んでいただいてありがとうございます！