【2025年10月】アスクル ランサムウェア攻撃 ― MFA例外の委託先管理者アカウントから侵入、約4か月の潜伏を経て物流基盤とバックアップを暗号化

2025年10月19日、法人向け通販「ASKUL」と個人向け「LOHACO」を運営するアスクルで、ランサムウェアによるシステム障害が発生し、受注・出荷が全面的に停止しました。アスクルが物流を受託していた無印良品やロフトなどのEC出荷にも影響が及び、Web受注の本格再開は12月3日まで約1.5か月かかりました。

12月12日に公表された調査報告(第13報)では、初期侵入が障害発生の 4か月以上前(6月5日) で、入口は 業務委託先に付与していた管理者アカウント、しかもそのアカウントは 多要素認証(MFA)を例外的に適用していなかった ことが明らかにされています。本記事では、公表された範囲の事実に沿って、侵入・拡大・影響の各段階で何が起きたのかを整理します。

■ この記事のまとめ

  • 初期侵入:MFA適用の例外になっていた委託先の管理者アカウントのID/パスワードを悪用(入手経路は未特定)
  • 拡大:約4か月の潜伏中に偵察・認証情報の収集・権限昇格を進め、EDRを無効化して複数サーバーへ横展開。データセンターの一部サーバーにはEDRが導入されていなかった
  • 影響:10月19日に複数種類のランサムウェアを実行し、物流・社内システムを暗号化。ランサムウェアを想定していないバックアップも暗号化・削除され、OSから作り直す復旧に
  • 情報窃取:約74万件の個人情報などが窃取・公開された二重恐喝型。窃取したアカウントで外部クラウドの問い合わせ管理システムにも不正アクセスされた
  • 分類:人手によるランサムウェア攻撃(human-operated ransomware)、有効なアカウントの悪用、委託先を経由したサプライチェーン型の侵入
目次

概要

項目内容
被害組織アスクル(ASKUL、LOHACO、物流受託先の通販を含む)
初期侵入2025年6月5日
ランサムウェア実行2025年10月19日
侵入経路業務委託先に付与していた管理者アカウント(ID/パスワード)の不正利用。当該アカウントは例外的にMFAが未適用
拡大手法偵察、認証情報の収集、権限昇格、EDRなどセキュリティ製品の無効化、複数サーバーへの横展開(具体的なツール名は未公表)
影響物流システム・社内システムの暗号化、バックアップの暗号化・削除、受注・出荷の停止
情報流出約74万件(事業所向けサービス顧客 約59万件、個人向け 約13.2万件、取引先 約1.5万件、役員・社員 約2,700件など)
攻撃者RansomHouse(2025年10月30日に犯行声明。約1.1TBの窃取を主張)
攻撃の分類人手によるランサムウェア攻撃/二重恐喝/有効なアカウントの悪用/委託先経由の侵入

事件の時系列

日付出来事
2025年6月5日業務委託先に付与していた管理者アカウントの認証情報で、社内ネットワークへの不正アクセスに成功(初期侵入)
6月〜10月攻撃者がネットワーク内で偵察、認証情報の収集、権限昇格を継続。EDRなどのセキュリティソリューションを無効化し、複数サーバーへ横展開
10月19日複数のサーバーでランサムウェアが実行され、ファイルを暗号化。バックアップも暗号化・削除される。システム障害を公表し、受注・出荷を停止
10月下旬一部で手作業による出荷を開始(出荷能力は従来の1〜2割程度)
10月22日〜23日窃取された認証情報により、外部クラウドサービス上の問い合わせ管理システムへ不正アクセス。23日のパスワード変更で侵入を停止(報道による)
10月30日RansomHouse がリークサイトで犯行声明
12月3日Web受注を本格再開
12月12日調査結果と再発防止策を公表(第13報)
攻撃経路
公表された範囲での攻撃経路。①〜⑤は本文の各段階に対応
侵入から公表・復旧までの時間軸
初期侵入から暗号化まで約4か月。暗号化後にもクラウド側への侵害が続いた

① 初期侵入:MFA例外の委託先管理者アカウント

入口になったのは、業務委託先がアスクルの環境を運用・保守するために付与されていた 管理者権限のアカウント です。アスクルは社内アカウントにMFAを導入していましたが、このアカウントは MFA適用の例外 とされ、ID/パスワードだけで認証が通る状態でした。

攻撃者がこの認証情報をどこで入手したかは特定されていません。一般に、委託先端末へのインフォスティーラー感染、他サービスで漏えいしたパスワードの使い回し、委託先へのフィッシングなどが考えられますが、本件で確認された事実ではありません。重要なのは、正規のアカウントで正規の経路から入られた ため、境界の防御機器から見ると通常の保守接続と区別がつかなかった点です(MITRE ATT&CK の T1078 Valid Accounts、T1133 External Remote Services)。

MFAの「例外」は、パスワードの強度や定期変更では埋め合わせられません。認証情報が1回でも漏れれば、そのまま管理者として入れるからです。しかも例外アカウントは、通常のアカウントと違って利用状況の監視や棚卸しから漏れやすい傾向があります。

② 潜伏・偵察・権限昇格:約4か月の「準備期間」

初期侵入から暗号化まで、攻撃者は約4か月をかけて内部の調査を進めました。報告書によれば、この間に偵察、認証情報の収集、権限昇格の試行が繰り返されています。

侵入の痕跡は6月5日までさかのぼった
フォレンジック調査の結果、初期侵入は暗号化の4か月以上前と判明した

これは近年の「人手によるランサムウェア攻撃」に典型的なパターンです。攻撃者はマルウェアを即座にばらまくのではなく、

  • ネットワーク構成、ドメイン構成、重要サーバー(物流・基幹系・バックアップ)の所在を把握する
  • 追加の認証情報(より強い権限のアカウント)を収集する
  • 暗号化の直前に、検知・復旧の手段(EDR、バックアップ)を潰す

という手順を踏み、一斉に暗号化したときの被害が最大になる状態 を作ってから実行に移ります。具体的に使われたツールや手法(認証情報のダンプ方法など)は公表されていません。

③ 防御回避と横展開:EDRの無効化と「監視の空白」

攻撃者はEDRなどのセキュリティソリューションを無効化し(T1562.001 Impair Defenses: Disable or Modify Tools)、複数のサーバーへ横展開しました(TA0008 Lateral Movement)。

報告書では、侵害されたデータセンターの 一部サーバーにEDRが導入されていなかった ことも明らかにされています。EDRが導入されている端末で停止操作が行われれば、本来は「エージェントの停止」「改ざん防止機能への操作」が管理コンソールに通知されるはずですが、そもそもEDRがないサーバーでは攻撃者の操作を記録・検知する手段がありません。加えて、検知が難しいものを含む 複数種類のランサムウェア が使われたと報じられています。

④ 影響:物流システムとバックアップの暗号化

10月19日、攻撃者は複数のサーバー上でランサムウェアを実行し、物流・社内システムのファイルを暗号化しました(T1486 Data Encrypted for Impact)。アスクルの出荷は、受注データから倉庫内の作業指示・出荷指示までをシステムで連携して行う仕組みのため、これらのシステムが止まった時点で、在庫があっても出荷できない状態になりました。

さらに深刻だったのがバックアップです。報告書は ランサムウェア攻撃を想定したバックアップ環境を構築していなかった ため一部のバックアップも暗号化されたとしており、バックアップデータの削除も行われていました(T1490 Inhibit System Recovery)。本番環境と同じ認証基盤・同じ権限で操作できるバックアップは、管理者権限を奪った攻撃者にとって「本番の一部」にすぎません。結果としてアスクルは、既存環境の修復ではなくOSのインストールからやり直すクリーンな再構築を選び、復旧が長期化しました。

手作業での出荷
手作業での出荷を再開したものの、出荷能力は従来の1〜2割程度にとどまった

⑤ 情報窃取と二重恐喝、クラウドへの二次侵害

暗号化に先立ち、攻撃者は社内システムから顧客情報などを窃取していました。RansomHouse は10月30日に犯行声明を出し、約1.1TBのデータを盗んだと主張、データの一部を公開しています。暗号化による業務停止と、窃取データの公開をちらつかせる脅迫を組み合わせた 二重恐喝型 の攻撃です。持ち出しに使われた手段(通信先、ツール)は公表されていません。

また、社内で窃取されたアカウントを使い、外部クラウドサービス上の 問い合わせ管理システム にも不正アクセスされ、情報が窃取されました(T1078.004 Cloud Accounts)。報道によればこのアクセスは暗号化後の10月22日に行われ、23日のパスワード変更で止まっています。インシデント対応では、オンプレミスの封じ込めだけでなく、侵害された可能性のあるすべての認証情報(SaaSを含む)を直ちに無効化・変更すること が重要であることを示しています。

MITRE ATT&CK との対応

公表された事実をATT&CKの戦術・技術に対応づけると次のようになります(具体的な手法が公表されていない段階は「詳細未公表」としています)。

段階(戦術)技術本件での事実
初期アクセスT1078 Valid Accounts/T1133 External Remote Services委託先に付与した管理者アカウント(MFA例外)で侵入
探索・認証情報アクセス・権限昇格(詳細未公表)約4か月にわたり偵察、認証情報の収集、権限昇格を実施
防御回避T1562.001 Disable or Modify ToolsEDRなどのセキュリティソリューションを無効化
横展開TA0008 Lateral Movement(手法は詳細未公表)複数サーバーへ展開。一部サーバーはEDR未導入
収集・持ち出し(詳細未公表)約74万件の個人情報などを窃取。RansomHouseは約1.1TBと主張
影響T1486 Data Encrypted for Impact/T1490 Inhibit System Recovery物流・社内システムを暗号化、バックアップも暗号化・削除
(クラウド)T1078.004 Cloud Accounts窃取したアカウントで問い合わせ管理システムへ不正アクセス

本事件を未然に防ぐために必要な予防策

初期侵入を防ぐ

  • MFAの例外を作らない:委託先・保守用・サービス用のアカウントほど権限が強く、監視が手薄になりがちです。技術的にMFAを適用できない場合は、接続元IPの限定、利用時間帯の制限、申請ベースで一時的に有効化する運用(Just-In-Time)、セッションの録画・監視などの補償統制を組み合わせ、例外を台帳で管理して定期的に見直します。
  • 委託先アカウントのライフサイクル管理:アカウントごとに利用者・用途・権限・有効期限を明確にし、共用を禁止します。常時有効な管理者アカウントを委託先に渡さず、特権ID管理(PAM)経由で払い出す方式が望ましいといえます。
  • リモート接続の異常検知:普段と異なる時間帯・接続元からのログイン、初めて見る端末からの接続を検知して確認する仕組みを持ちます。

侵入後の拡大を食い止める

  • EDRのカバレッジを100%に近づける:データセンターのサーバーを含め導入漏れを棚卸しし、エージェントの停止・アンインストールの検知と改ざん防止(tamper protection)を有効にします。EDRの停止は、それ自体が最優先のアラートです。
  • 24時間の監視体制:潜伏期間中の偵察・権限昇格の兆候(大量のアカウント探索、異常な認証、管理ツールの実行)を拾うには、平日日中だけの監視では足りません。自社で難しければ MDR/SOC サービスの利用を検討します。
  • 特権アカウントの分離:ドメイン管理者などの特権アカウントを日常の運用端末で使わない、ティアモデルで管理系を分離する、ローカル管理者パスワードを端末ごとに変える(LAPS など)ことで、1台の侵害が全体に広がるのを防ぎます。

影響を小さくする

  • ランサムウェアを前提としたバックアップ:本番と別の認証基盤・権限で管理し、変更・削除ができない(イミュータブル)領域やオフラインにも保管します。「取れていること」だけでなく、隔離環境で実際に復元できることを定期的に確認します。
  • インシデント時の認証情報の全面リセット:オンプレミスだけでなく、SaaS・クラウドのアカウントやAPIキーも含めて、侵害の可能性があるものを迅速に無効化します。本件では暗号化の3日後にクラウド側への不正アクセスが発生しています。
  • 事業継続の手順:システム停止時の手作業での受注・出荷手順、取引先・物流受託先への連絡手順をあらかじめ決めておきます。

まとめ

アスクルの事件は、「MFAを導入している組織」でも、例外として残したアカウントが1つあれば、そこから管理者として侵入され得ることを示しました。そして侵入後の約4か月間、EDRの空白と監視の不足によって攻撃者の準備が見過ごされ、バックアップまで含めて暗号化される最悪の結果につながりました。入口の例外をなくすこと、侵入後の兆候を見逃さないこと、バックアップを攻撃者の手の届かない場所に置くこと――いずれも基本的な対策ですが、それぞれに穴があると、その組み合わせが大規模な業務停止を招きます。

■ メモ

本記事は、アスクルの公表資料(第13報)と報道をもとに、公表された範囲の事実を整理したものです。攻撃に使われた具体的なツールや、委託先の認証情報が漏えいした経路などは公表されていません。

参考資料

画像出典

  • 写真「Automatisches Kleinteilelager.jpg」(Photo: Andreas Praefcke, CC BY 3.0、Wikimedia Commons)※吹き出し等を加工
  • 写真「CSIRO ScienceImage 435 Scientist using microscope.jpg」(Mark Fergus, CSIRO, CC BY 3.0、Wikimedia Commons)※吹き出し等を加工
  • 写真「An aid warehouse (7554223204).jpg」(Oxfam East Africa, CC BY 2.0、Wikimedia Commons.jpg))※吹き出し等を加工
  • 図中のアイコン:Tabler Icons(MIT License)

ほかの事件の解説は「日本のサイバーセキュリティ事件まとめ」から読めます。

よかったらシェアしてね!
  • URLをコピーしました!
  • URLをコピーしました!

この記事を書いた人

目次