top of page
Blog article

Blog article

アスクル ランサムウェア事件に関する包括的調査報告書:サプライチェーンリスクとセキュリティガバナンスの再定義

1. エグゼクティブサマリー


2025年10月、日本の物流およびEコマース(電子商取引)の要衝であるアスクル株式会社(以下、アスクル)を襲った大規模なサイバー攻撃は、国内産業界に深刻な衝撃を与えた。RansomHouse(ランサムハウス)と呼ばれる脅威アクターによるこのランサムウェア攻撃は、アスクルの物流の中枢である自動倉庫システムを麻痺させ、B2B(企業間取引)およびB2C(消費者向け取引)の出荷を長期間にわたり停止に追い込んだ1。本事件において特筆すべきは、約74万件の顧客・従業員情報の漏洩のみならず、物流という物理的なサプライチェーンがデジタル領域からの攻撃によって寸断され、その影響が無印良品(良品計画)などのパートナー企業にまで波及した「サプライチェーン攻撃」の実相である2


本報告書は、アスクルが公表した調査報告書および外部セキュリティ専門機関による分析情報を基に、事件の全容を技術的、組織的、そして経営的な観点から網羅的に分析するものである。調査の結果、攻撃の侵入経路が「多要素認証(MFA)が未設定の委託先管理アカウント」であったこと、そして侵入後のラテラルムーブメント(横展開)においてEDR(Endpoint Detection and Response)の検知回避やバックアップの破壊が行われた事実が明らかとなった1


本報告書の目的は、単なる事件の記録に留まらず、アスクル報告書から見えてきた「強化すべき対策」を、ゼロトラストアーキテクチャ、アイデンティティ管理(IAM)、そしてサイバーレジリエンス(回復力)の観点から具体的に提言することにある。アスクルの事例は、デジタル変革(DX)が進む現代において、一社のセキュリティ不備が社会インフラとしての物流網全体を脅かすリスクを浮き彫りにしており、全産業にとっての警鐘となるものである。



2. 事件の背景とアスクルの事業構造


2.1 アスクルの市場における立ち位置と重要性


アスクルは、オフィス用品の通信販売からスタートし、現在では高度に自動化された物流センター網(ASKUL Logi PARK等)を有する、日本を代表するEコマース・プラットフォーマーである。同社の事業は大きく分けて、中小事業所向けの「ASKUL」、中堅・大企業向けの「ソロエルアリーナ」、そして一般消費者向けの「LOHACO」の3本の柱で構成されている3


特筆すべきは、そのビジネスモデルが「翌日配送(明日来る)」を約束する極めて高効率なロジスティクスに依存している点である。在庫管理、ピッキング、出荷、配送ルートの最適化に至るまで、全てがITシステムによって制御されている。これは、ITシステムが停止すれば、即座に物理的な業務が停止することを意味する。また、アスクルは自社の商品だけでなく、無印良品などの他社ブランドの物流代行も担っており、同社のシステム障害は直ちにパートナー企業の販売機会損失に直結する構造となっていた2


2.2 2025年の日本のサイバー脅威ランドスケープ


アスクルへの攻撃が発生した2025年は、日本の主要企業が相次いでサイバー攻撃の標的となった特異な年として記録されている。アスクル以外にも、アサヒグループホールディングス、ニデック(旧日本電産)の子会社、さらには宇宙航空研究開発機構(JAXA)などが攻撃を受けており、その多くがランサムウェアによる二重恐喝(データの暗号化と漏洩の脅迫)を伴うものであった5


これらの事案に共通するのは、攻撃者が日本の製造業や重要インフラが持つ「サプライチェーンの相互接続性」を悪用している点である。セキュリティ対策が堅牢な本社機能を直接攻撃するのではなく、セキュリティレベルが相対的に低い海外子会社や委託先、あるいはVPN機器の未修正の脆弱性を足掛かりにする手口が常態化していた。アスクルの事件もまた、この文脈の中で発生した「委託先経由」の侵入事例として位置づけられる。



3. 脅威アクター「RansomHouse」のプロファイリング


3.1 組織の概要と特徴


アスクルへの攻撃について犯行声明を出した「RansomHouse」は、2021年頃から活動が確認されているサイバー犯罪グループである。彼らは自らを「ハッカー」ではなく「プロフェッショナルな仲介者(Professional Mediator)」や「監査人」と称し、企業のセキュリティ脆弱性を指摘するという歪んだ正当化を行うことで知られている8


RansomHouseの最大の特徴は、RaaS(Ransomware-as-a-Service)モデルを採用しつつも、単一のランサムウェア株に依存せず、White RabbitやMario(Babukの派生)など、複数のランサムウェア・ファミリーを状況に応じて使い分ける柔軟性にある。彼らは、被害企業のネットワークに侵入後、データを窃取し、その後に暗号化を行う「二重恐喝(Double Extortion)」の手法を常套手段としている9


3.2 アスクル攻撃におけるTTPs(戦術・技術・手順)


セキュリティベンダーや公開情報に基づくRansomHouseの技術的特徴は以下の通りである。

  • 初期侵入(Initial Access):

    既知の脆弱性(CVE)の悪用や、フィッシング、あるいはインフォスティーラー(情報窃取マルウェア)によって流出した正規アカウント情報の悪用を好む。アスクルの事例では、まさに「委託先の正規アカウント」が悪用された1。

  • 仮想化環境への攻撃:

    VMware ESXiなどの仮想化プラットフォームを標的とする傾向が強い。アスクルのような大規模EC事業者は、サーバーリソースを効率化するために仮想化技術を多用しているため、ESXiサーバーが暗号化されると、その上で稼働する数百の仮想マシン(VM)が一瞬にして停止することになる8。

  • バックアップの無力化:

    ランサムウェアを展開する前に、バックアップファイルを探索し、削除または暗号化することで、被害者が身代金を支払わざるを得ない状況を作り出す1。

  • データの暴露:

    交渉が決裂した場合、窃取したデータを専用のリークサイト(ダークウェブ上)で公開する。アスクルのケースでも、10月30日の犯行声明後、11月と12月にデータのリークが行われている2。



4. 攻撃の技術的・法医学的(フォレンジック)分析


アスクルおよびセキュリティパートナー(IIJ等の関与が推察される記述あり10)による調査結果から、攻撃のタイムラインと技術的詳細を再構成する。


4.1 初期侵入:委託先管理アカウントの陥落


攻撃の起点は、アスクルの社内ネットワークへの直接攻撃ではなく、業務委託先が使用していた「管理者権限を持つアカウント」の認証情報窃取であった1


  • 脆弱性の核心:

    この管理者アカウントには、現代のセキュリティ基準では必須とされる「多要素認証(MFA)」が適用されていなかった4。IDとパスワードのみで保護されていたため、攻撃者は正規のユーザーになりすまして容易にネットワーク内部へ侵入することができた。


  • 認証情報の入手経路:

    公式発表では詳細は伏せられているが、一般的にRansomHouseのようなグループは、Initial Access Broker(初期侵入ブローカー)から認証情報を購入するか、委託先の従業員が感染したマルウェア経由で流出したクレデンシャルを悪用するケースが多い。


4.2 偵察とラテラルムーブメント(横展開)


侵入後、攻撃者は即座に攻撃を開始したわけではない。ネットワーク内部での「偵察行動」に時間を費やしている1


  • ネットワーク偵察:

    攻撃者は内部ネットワーク構成、サーバーの役割、データの所在を把握するためのスキャンを行った。特に、物流システムや顧客データベースがどこにあるかを特定するための活動が行われたと見られる。


  • 権限昇格と横展開:

    初期侵入で使用したアカウントの権限を利用し、あるいはさらに高位の権限(ドメイン管理者権限等)を奪取することで、ネットワーク内を自由に移動(ラテラルムーブメント)した。報告によれば、攻撃者は認証データを収集しながら他のサーバーへと感染を広げていった1。


  • EDRの回避:

    極めて深刻な事実として、アスクルが導入していたEDR(エンドポイントでの検知と対応)製品のシグネチャを回避する、複数のランサムウェア亜種が使用されたことが判明している1。これは攻撃者が、事前にアスクルのセキュリティ環境を把握し、検知されないようにカスタマイズされたマルウェアを用意していたか、あるいはEDRの検知ロジックを無効化する手法(「Bring Your Own Vulnerable Driver」攻撃など)を用いた可能性を示唆している。


4.3 実行フェーズ:破壊と窃取


準備が整った段階で、攻撃者は最終的な破壊活動を実行に移した。


  1. バックアップの削除:

    システム復旧を困難にするため、ネットワーク上のバックアップファイルが削除された5。これにより、アスクルは迅速なリストア(復元)を行う手段を失った。

  2. データの外部送信(Exfiltration):

    暗号化の前に、約74万件の個人情報および企業情報が外部のサーバーへ送信された。これには、B2B顧客の担当者情報や配送先情報が含まれていた4。

  3. ランサムウェアの展開(暗号化):

    複数のサーバーに対して一斉にランサムウェアが実行され、ファイルが暗号化された。これにより、WMS(倉庫管理システム)や受注システムが機能不全に陥った3。


4.4 タイムライン詳細


日付 (2025年)

出来事

詳細・対応

10月以前

侵入・潜伏

委託先アカウントを通じた不正アクセス、偵察、権限奪取。

10月19日

発覚・遮断

サーバーの異常(暗号化)を検知。ネットワークの物理的遮断、全システムの停止を決定12

10月20日-22日

業務停止

Web受注、出荷の完全停止。WMSの障害により倉庫業務が不能に。主要クラウドのパスワード変更3

10月24日

初期対応完了

管理アカウントへのMFA適用、EDRシグネチャの更新、全パスワードリセット12

10月30日

犯行声明・公表

RansomHouseが犯行声明。アスクルが情報流出の可能性を公表13

11月上旬

アナログ対応

FAXによる受注と「紙とペン」による倉庫作業で、医療機関など一部顧客への出荷を再開3

11月12日-

段階的復旧

ソロエルアリーナ(B2B)から順次Web注文を再開。しかし配送遅延は継続。

12月中旬

影響継続

完全復旧に至らず、決算発表の延期を決定2


5. オペレーションへの甚大な影響と事業継続性(BCP)の破綻


5.1 物流インフラの完全停止


アスクルの強みである「自動化」は、サイバー攻撃に対して「脆弱性」へと転じた。WMSがダウンしたことで、どの商品が倉庫のどこにあるか、ロボットに指示を出すことが不可能になった。


  • アナログへの回帰:

    NHK等の報道によれば、現場では「紙とペン」を使って注文を処理し、手作業でピッキングを行う事態となった14。通常、数万件のオーダーを自動処理するセンターにおいて、手作業での処理能力は数百分の一以下に低下する。これは、デジタル依存度の高い現代企業において、アナログの代替手段がいかに限定的であるかを如実に示した。

  • 配送遅延の長期化:

    システムが一部復旧した後も、溜まったバックログ(未処理注文)の解消には膨大な時間を要し、12月中旬になっても配送遅延が解消されなかった2。


5.2 サプライチェーン全体への波及(Bullwhip Effect)


アスクルの物流停止は、アスクル一社の問題に留まらなかった。


  • LOHACO・無印良品への影響:

    LOHACOの決済システム自体は無事であったが(外部委託のため)、物流機能がアスクルと統合されていたため、商品の出荷が止まった11。また、物流代行を利用していた無印良品などのパートナー企業も、自社のECサイトでの販売停止や配送遅延を余儀なくされた。これは、サプライチェーンにおける「単一障害点(SPOF)」のリスクを浮き彫りにした。

5.3 情報漏洩の実態とリスク


漏洩した約74万件のデータの内訳は以下の通りである11

データ種別

件数(概算)

リスク詳細

B2B顧客(担当者情報)

590,000件

氏名、部署、連絡先が含まれる。これらは標的型攻撃メール(BEC)やなりすまし詐欺に悪用されるリスクが高い。

B2C顧客(個人)

132,000件

氏名、住所、電話番号。クレジットカード情報は含まれないが、フィッシング詐欺や特殊詐欺のリストとして利用される恐れがある。

取引先・パートナー

15,000件

委託先、代理店情報。サプライチェーン攻撃の新たな足掛かりとなる情報。

役員・従業員

2,700件

内部情報の暴露、ソーシャルエンジニアリングのリスク。

特筆すべきは、クレジットカード情報が「非保持化」されていたため漏洩しなかった点である4。これはPCI DSSなどの基準に準拠していた成果であり、不幸中の幸いであったと言える。



6. 原因分析:なぜ防げなかったのか


アスクルの報告書および状況証拠から、根本的な原因を分析する。


6.1 ガバナンスの欠如:委託先管理の盲点


最大の要因は、「委託先管理アカウントへのMFA未適用」である4


  • なぜMFAがなかったのか:

    多くの日本企業において、社内従業員には厳格なセキュリティポリシー(MFA、VPNなど)を適用する一方で、ベンダーや委託先に対しては「利便性」を優先し、例外的に旧来のID/PW認証を許容してしまうケースが散見される。アスクルにおいても、この「例外」がセキュリティホールとなった。

  • 特権ID管理の不備:

    委託先に対して「管理者権限」という強力な権限を付与していたにも関わらず、そのアクセス制御が脆弱であったことは、特権ID管理(PAM)のプロセスに重大な欠陥があったことを示唆している。

6.2 防御技術の限界:EDRへの過信

「EDRのシグネチャを回避された」という事実は重い教訓を含む1

  • シグネチャベースの限界:

    従来のアンチウイルスや一部のEDR機能は、既知の脅威(シグネチャ)に基づいて検知を行う。RansomHouseのような高度な攻撃者は、マルウェアを再コンパイルしてハッシュ値を変更したり、正規のツール(PowerShell等)を悪用する「Living off the Land(環境寄生型)」攻撃を行うことで、検知をすり抜ける。

  • 監視体制(SOC)の不在または遅れ:

    EDRが自動ブロックできなかったとしても、不審な挙動(深夜の大量アクセス、普段使わないポートの使用など)はログに残っていたはずである。これを24時間365日監視し、即座に異常と判断するSOC(Security Operation Center)の体制が十分であれば、暗号化が始まる前の「偵察フェーズ」で攻撃を検知できた可能性がある。

6.3 レジリエンスの欠如:バックアップ設計の甘さ


バックアップが削除されたことは、システム設計上の敗北である。


  • オンラインバックアップの脆弱性:

    バックアップサーバーがメインネットワークと同じドメイン管理下にあったり、常時接続されていたりした場合、管理者権限を奪った攻撃者は容易にアクセスしてデータを消去できる。ランサムウェア対策における「不変性(Immutability)」や「エアギャップ(ネットワーク分離)」が確保されていなかった可能性が高い。



7. 「強化すべき対策」の包括的提言


アスクルの事例から導き出される、同社および類似のサプライチェーンを持つ企業が即座に実行すべき対策を以下に詳述する。これらはNISTのサイバーセキュリティフレームワーク(CSF 2.0)の機能分類に対応する。


7.1 【特定・防御】アイデンティティ管理(IAM)の厳格化


提言1:例外なき多要素認証(MFA)の強制


  • 内容:

    社内、社外(委託先)、特権ID、一般IDを問わず、すべてのアクセス経路においてMFAを強制する。


  • 具体策:

    SMS認証のような脆弱なMFAではなく、FIDO2準拠のハードウェアキーや生体認証、あるいはスマートフォンアプリを用いた「フィッシング耐性のあるMFA」を採用すべきである。

  • アスクルへの教訓:

    委託先専用のポータルにおいても、自社と同等以上の認証強度を要求するか、あるいはSAML/OIDC連携によって認証基盤を統合し、ポリシーを一元管理する必要がある。

提言2:特権アクセス管理(PAM)の導入

  • 内容:

    管理者権限を持つアカウント(特権ID)を常時利用可能な状態にしない。

  • 具体策:

    必要な時だけ権限を貸し出す「Just-in-Timeアクセス」や、操作内容を全て録画・記録する証跡管理を導入する。これにより、万が一IDが盗まれても、被害を最小限に抑えることができる。

7.2 【防御】ゼロトラスト・ネットワーク・アクセス(ZTNA)への移行

提言3:VPN依存からの脱却とマイクロセグメンテーション

  • 内容:

    一度VPNで接続すれば社内ネットワーク全体が見渡せる「境界型防御」を廃止する。

  • 具体策:

    ZTNA(Zero Trust Network Access)を導入し、委託先ユーザーには「業務に必要な特定のアプリケーション」へのアクセス権のみを付与する。ネットワーク全体へのアクセスは許可しない。

  • アスクルへの教訓:

    もしZTNAが導入されていれば、委託先アカウントが侵害されても、攻撃者は特定のWebアプリにしかアクセスできず、サーバーOS層へのラテラルムーブメントやActive Directoryへの到達は防げた可能性が高い。

7.3 【検知】監視体制の高度化

提言4:振る舞い検知とMDR(Managed Detection and Response)の活用

  • 内容:

    シグネチャ(ファイルの特徴)ではなく、振る舞い(挙動)で攻撃を検知する。

  • 具体策:

    EDRの設定を「検知(Audit)」から「遮断(Block)」へ厳格化するとともに、24時間365日体制で専門のアナリストがアラートを分析するMDRサービスを利用する。

  • アスクルへの教訓:

    「EDRをすり抜けた」という事実は、ツールを入れるだけでは不十分であることを示している。人間の目による監視と、異常発生時に即座にネットワークを隔離できる権限を持った対応チームが必要である。

7.4 【対応・復旧】サイバーレジリエンスの確保

提言5:不変(Immutable)バックアップと復旧訓練

  • 内容:

    攻撃者が管理者権限を持っていても削除・変更できないバックアップを保持する。

  • 具体策:

    Linuxベースの堅牢化リポジトリや、オブジェクトロック機能を持つクラウドストレージ(AWS S3 Object Lock等)を活用し、バックアップデータを「書き換え不能(WORM)」にする。また、ネットワークから物理的に切り離した「オフラインバックアップ(テープ等)」も有効である。

  • アスクルへの教訓:

    バックアップからの復旧手順(リストア)を定期的に訓練し、WMSのような複雑なシステムが実際に何時間で復旧できるか(RTO:目標復旧時間)を検証しておく必要がある。

7.5 【ガバナンス】サプライチェーン・リスク管理(TPRM)

提言6:委託先セキュリティ評価の義務化

  • 内容:

    契約書にセキュリティ条項(SLA)を盛り込み、定期的な監査を行う。

  • 具体策:

    「セキュリティチェックシート」による自己申告だけでなく、BitSightやSecurityScorecardのような外部評価ツールを用いて、委託先のセキュリティポスチャ(姿勢)を客観的にモニタリングする仕組みを構築する。

8. 日本のサイバーセキュリティ環境への示唆と結論


8.1 「能動的サイバー防御」との関連


アスクルの事件は、日本政府が進める「能動的サイバー防御(Active Cyber Defense)」の議論とも密接に関連している16。重要インフラや主要産業に対する攻撃情報は、一企業内で留めるのではなく、国や業界団体(JPCERT/CC、NISC等)と迅速に共有し、国全体での防御態勢を構築する必要がある。アスクルがPIPC(個人情報保護委員会)への報告を行い、情報を公開したことは透明性の観点で評価されるべきだが、攻撃の予兆(脅威インテリジェンス)の共有という点では、日本社会全体での課題が残る。


8.2 結論:信頼の基盤を守るために


アスクルへのランサムウェア攻撃報告書から見えてきた「強化すべき対策」は、単なるITシステムの改修リストではない。それは、デジタル化されたサプライチェーンにおける「信頼(Trust)」の再定義である。

「委託先だから信頼する」「社内ネットワークだから安全だ」という旧来の性善説(暗黙の信頼)は、RansomHouseのような冷徹な攻撃者の前では無力であった。今求められているのは、「決して信頼せず、常に検証する(Never Trust, Always Verify)」というゼロトラストの原則に基づく、厳格かつ動的なアクセス制御である。

アスクルはこの痛ましい経験を経て、セキュリティガバナンスを抜本的に再構築すると表明している17。同社の取り組みは、同様のリスクを抱えるすべての日本企業にとっての試金石となる。経営層は、サイバーセキュリティへの投資を「コスト」ではなく、事業存続のための「必須投資」と捉え直し、特にアイデンティティ管理とバックアップの近代化に即座に着手すべきである。それが、顧客と社会からの信頼を守る唯一の道である。




付録:主な参照データ

  • 被害規模: 個人・企業情報 約74万件流出 1

  • 攻撃手法: 委託先アカウント悪用、MFA未設定、EDR回避、バックアップ削除 1

  • 攻撃者: RansomHouse 18

  • 関連被害: 無印良品等の出荷停止、物流網の長期間麻痺 3

  • 参照ガイドライン: NIST CSF 2.0, IPA ランサムウェア対策特設ページ



引用文献


  1. Ransomware attack against Askul hits nearly 740K - SC Media, 1月 9, 2026にアクセス、 https://www.scworld.com/brief/ransomware-attack-against-askul-hits-nearly-740k

  2. Askul confirms theft of 740000 customer records in October ransomware attack - teiss, 1月 9, 2026にアクセス、 https://www.teiss.co.uk/news/askul-confirms-theft-of-740000-customer-records-in-october-ransomware-attack-16868

  3. E-tailer resumes sales 45 days after ransomware attack - The Register, 1月 9, 2026にアクセス、 https://www.theregister.com/2025/12/03/askul_partial_ransomware_recovery/

  4. Askul Cyberattack: Logistics Operations Begin to Resume - The Cyber Express, 1月 9, 2026にアクセス、 https://thecyberexpress.com/askul-cyberattack-logistics-resume/amp/

  5. 700,000 Records Compromised in Askul Ransomware Attack - SecurityWeek, 1月 9, 2026にアクセス、 https://www.securityweek.com/700000-records-compromised-in-askul-ransomware-attack/

  6. Japanese retailer Askul confirms data leak after cyberattack claimed by Russia-linked group, 1月 9, 2026にアクセス、 https://therecord.media/askul-confirms-data-breach-ransomware-incident

  7. Japanese Firms Suffer Long Tail of Ransomware Damage - Dark Reading, 1月 9, 2026にアクセス、 https://www.darkreading.com/cyberattacks-data-breaches/japanese-firms-suffer-long-tail-ransomware-damage

  8. RansomHouse am See - Trellix, 1月 9, 2026にアクセス、 https://www.trellix.com/blogs/research/ransomhouse-am-see/

  9. From Linear to Complex: An Upgrade in RansomHouse Encryption, 1月 9, 2026にアクセス、 https://unit42.paloaltonetworks.com/ransomhouse-encryption-upgrade/

  10. 弊社が利用するメールセキュリティサービスにおけるお客様情報漏洩の可能性に関する確報 - 【ASKUL】お知らせ詳細 - オフィス用品の通販 アスクル, 1月 9, 2026にアクセス、 https://www.askul.co.jp/shopnews/news_250508_iij_security.html

  11. Askul data breach exposed over 700,000 records after ransomware attack - Security Affairs, 1月 9, 2026にアクセス、 https://securityaffairs.com/185790/security/askul-data-breach-exposed-over-700000-records-after-ransomware-attack.html

  12. アスクルのサイバーセキュリティ | 事業・サービス | アスクル株式 ..., 1月 9, 2026にアクセス、 https://www.askul.co.jp/corp/security/

  13. 【重要】ランサムウェア攻撃による情報流出に関するお詫びとお知らせ - アスクル, 1月 9, 2026にアクセス、 https://www.askul.co.jp/snw/newsDispView/?newsId=18466

  14. Cyberattack: Askul shutdown ripples through Japan economyーNHK WORLD-JAPAN NEWS, 1月 9, 2026にアクセス、 https://www.youtube.com/watch?v=qQ8uhiNvsio

  15. Askul confirms theft of 740k customer records in ransomware attack - Bleeping Computer, 1月 9, 2026にアクセス、 https://www.bleepingcomputer.com/news/security/askul-confirms-theft-of-740k-customer-records-in-ransomhouse-attack/

  16. 1 位「いまや災害級脅威」アサヒ アスクル等のランサム障害 ~ JNSA 2025 セキュリティ十大ニュース (2026年1月7日), 1月 9, 2026にアクセス、 https://www.excite.co.jp/news/article/Scannetsecurity_54359/

  17. Askul corporation restores operations after ransomware attack and data breach - SC Media, 1月 9, 2026にアクセス、 https://www.scworld.com/brief/askul-corporation-restores-operations-after-ransomware-attack-and-data-breach

  18. 700000 Records Compromised in Askul Ransomware Attack - SecurityIT, 1月 9, 2026にアクセス、 https://www.show.it/en/700000-records-compromised-in-askul-ransomware-attack/



All Tags

bottom of page