アスクル 2025年 委託先の管理者アカウントからのランサムウェア
多要素認証を例外的に外していた委託先の管理者アカウントで、2025年6月に社外から入られた。気付いたのは4か月半後の10月19日、ランサムウェアが一斉に起動した時で、物流システムと同じデータセンターの控えも暗号化され、物流センターの出荷が全面に止まった。
要点
- 入口は、業務委託先に渡していた管理者アカウント。多要素認証の適用から例外的に外れていた。
- 初期侵入は2025年6月5日。偵察と侵入の拡大が10月19日まで続き、その間に検知されなかった。データセンターのサーバーにはEDRが無く、24時間の監視も無かった。
- 攻撃者は脆弱性対策ソフトを止めてからサーバーを渡り、暗号化と同時に控えのファイルも消した。控えは同じデータセンターにあり、ランサムウェアを想定した作りではなかった。
- 流出が確かめられたのは4区分で、合わせて約74万件。ログの一部が失われ、閲覧された範囲は特定しきれていない。
- 根本の直しは、例外の無い多要素認証と、委託先の管理者権限の絞り込み。検知と、本番から消せない控えは、それが破れたときの網。
何が起きたか
| 日付 | 発表の内容 |
|---|---|
| 2025年6月5日 | 業務委託先用のアカウントを使い、社外から初期侵入[1] |
| 2025年6月から10月9日 | 管理者権限などの取得を狙ったログイン試行。すべて失敗[1] |
| 2025年7月9日から10月19日 | 脆弱性対策ソフトを無効にし、物流システム、社内システム、端末へ侵入を広げ、ランサムウェアを置いた[1] |
| 2025年10月19日 | 事前に設定された時刻にランサムウェアが起動し、サーバーの暗号化とファイルの削除が始まる。午前に検知し、感染の疑いのあるシステムの切り離しと網の遮断、全パスワードの変更に着手。16時半に ASKUL、ソロエルアリーナ、LOHACO の受注と出荷を停止[1][2] |
| 2025年10月19日、21日、27日 | メールで脅迫文が届く[1] |
| 2025年10月20日 | 外部の専門機関に支援を要請し、ログの解析を始める[1] |
| 2025年10月22日 | 外部のクラウドサービスへの不正アクセスが起きる[1] |
| 2025年10月23日、24日 | 主要な外部のクラウドサービスのパスワードの変更を終える。以後、新たな侵入は確認されていない。24日に認証情報のリセット、管理アカウントへの多要素認証の適用、ランサムウェアの検体の抽出とEDRのシグネチャの更新[1][2] |
| 2025年10月30日、11月10日、12月2日 | リークサイトにデータが公開される。それぞれの翌日以降に、公開された情報の確認を終える[1] |
| 2025年11月12日 | 残った脅威の調査を踏まえて安全と判断し、ソロエルアリーナからWebの注文を再開[2] |
| 2025年12月12日 | 第13報で調査結果と再発防止策を公表し、個人情報保護委員会へ確報を出す[1] |
| 流出が確かめられた情報 2025年12月12日時点 | 件数 |
|---|---|
| 事業所向けサービスのお客様情報の一部 | 約59万件 |
| 個人向けサービスのお客様情報の一部 | 約13万2,000件 |
| 取引先の情報の一部。業務委託先、エージェント、商品の仕入先など | 約1万5,000件 |
| 役員と社員などの情報の一部。グループ会社を含む | 約2,700件 |
- 件数は第13報の表による[1]。約74万件はこの4区分の和で、発表の文には合計の数が無い。
- LOHACO の決済では同社がカードの情報を受け取らない作りで、個人のお客様のカードの情報は持っていないとされた[1]。
- 一部の通信ログとアクセスログが失われ、攻撃者が閲覧した可能性のある範囲を完全に特定するのは難しいと判断された[1]。
- 基幹業務システムと、お客様とパートナー向けのフロントのシステムには侵害の痕跡が無かったとされた[1]。
通った道筋
第13報の言葉では、例外的に多要素認証を適用していなかった業務委託先に付与していた管理者アカウントのIDとパスワードが、何らかの方法で漏れて不正に使われた[1]。入った後は偵察で認証情報を集め、EDRなどの脆弱性対策ソフトを無効にしてサーバーを渡り、必要な権限を得て網全体に届くようになった。使われたランサムウェアは複数種で、当時のEDRのシグネチャでは検知が難しいものも含まれていた[1]。
暗号化と同時に控えのファイルも消された。物流センターを動かす複数の物流システムが暗号化され、同じデータセンターの中の控えのファイルも暗号化されたため、復旧に時間がかかった[1]。物流センターは自動倉庫やピッキングを物流システムが動かす作りで、システムが止まると出荷が全面に止まった[1]。
第13報は、VPN機器のベンダーが2025年9月末頃に脆弱性を公表していたが、その脆弱性を悪用した侵入の痕跡は確認されなかったと書く[1]。初期侵入は6月で、その公表より前である。入口は委託先の管理者アカウントのIDとパスワードとされ、機器の弱点ではない。社員のPCにも不正侵入や情報窃取の痕跡は無かった。委託先が管理するノートPCは、OSの更新の過程で侵入の時点のログが消えており、確かめられなかった[1]。
例外の形を、架空の作りで示す。方針そのものは多要素認証を求めていても、外した群が1つあれば、その群のアカウントでは知識の情報だけで通る。
悪い例。架空のリモート接続の認証の方針
# remote-access-policy.yaml 架空の例
policy: remote-access
require_mfa: true
exclude_groups:
- vendor-admins # 委託先の管理者。端末の都合で一時的に外した
- break-glass # 非常用。棚卸しの対象外直した例。例外を置かず、委託先の権限は時間と対象で絞る
policy: remote-access
require_mfa: true
exclude_groups: []
# 非常用は別の方針。使うと即時に警告し、使った後に資格情報を替える
vendor_access:
grant: on-request # 作業の承認ごとに有効にする
expires_after: 8h
allowed_hosts: [198.51.100.10, 198.51.100.11]どこで止められたか
| 段 | この件で発表されたこと | 止める仕組み |
|---|---|---|
| 1 入る | 例外的に多要素認証を外した委託先の管理者アカウントのIDとパスワードが漏れ、社外から使われた[1] | すべてのリモート接続に例外なく多要素認証を掛ける。委託先の権限は役割の範囲の機器だけにする[3] |
| 2 居座る | 4か月余り、管理者権限を狙うログイン試行が続いたが、すべて失敗した[1]。データセンターのサーバーにEDRが無く、24時間の監視も無く、即時に検知できなかった[1] | 失敗したログインの連続と、普段と違う時間と場所からの管理者のログインを、人が見る警告にする[5] |
| 3 広げる | 脆弱性対策ソフトを無効にしてサーバー間を移動した[1] | EDRを全部のサーバーに置き、止められたこと自体を警告にする[3] |
| 4 壊す | オンラインの控えはあったが、ランサムウェアを想定した作りではなく、同じデータセンターの控えも暗号化され、控えのファイルの削除もされた[1] | 本番の管理者の権限で消せない、切り離した暗号化の控えを持ち、戻せるかを定期に試す[3] |
| 5 跡が消える | 当時のログが消え、原因の完全な究明は難しいとされた。委託先のノートPCはOSの更新で侵入時のログが消えていた[1] | ログを機器の外へ送り、保管の期間を決め、消されたか止められたかを定期に確かめる[3] |
1 入る。例外の無い多要素認証
同社の再発防止策の1つ目は、自社と業務委託先における、すべてのリモートアクセスへの多要素認証の徹底である[1]。例外は、方針の表には1行でも、攻撃者から見れば、知識の情報だけで通れる唯一の入口になる。例外を置いた理由がある場合は、その例外の一覧を誰が持ち、いつ見直すかを決める。それが無ければ例外は残り続ける。CISA は、VPNと重要なシステムに届くアカウントにフィッシングに強い多要素認証を求め、委託先には最小の権限と職務の分離で、役割の範囲の機器とサーバーだけに届く権限を渡すよう書く[3]。認証の強さの決まりは A07 認証の不備 にある。
委託先に管理者の権限を常に持たせる形も見直す。作業の承認ごとに期限を付けて有効にすれば、IDとパスワードが漏れても、使える時間と届く先が限られる。同社の再発防止策の2つ目も、管理者権限の厳格な運用である[1]。同じ委託先の入口から入られた国内の例に 大阪急性期・総合医療センター 2022年 と 半田病院 2021年 がある。
2と3 居座る、広げる。4か月の間に見えていたもの
偵察の段の管理者権限を狙うログイン試行は、すべて失敗していた[1]。OWASP は、認証の失敗を必ず記録し、同じアカウントへの失敗の繰り返しや短時間の連続を見張るよう書く[5]。失敗の連続は、警告にしていれば、暗号化の4か月前に気付ける信号である。何を記録し、どう警告まで繋ぐかは A09 セキュリティログとアラートの不備 にある。
同社は、侵入の検知が遅れた原因を、データセンターのサーバーにEDRが無く、24時間の監視が無かったことに置き、24時間365日の監視と、EDRを含む多層の検知を再発防止策に挙げた[1]。対策ソフトは止められる前提で置く。止まったこと、外されたことを、それ自体の警告にする。
4 壊す。本番から消せない控え
同社は、侵害されたサーバーではオンラインの控えを取っていたが、ランサムウェアを想定した控えの環境を作っていなかったため、一部の控えも暗号化され、早い復旧が難しくなったとした[1]。網全体に届く管理者の権限を取られた後では、その権限で書ける控えは控えにならない。CISA は、多くのランサムウェアが届く控えを探して消すか暗号化するとして、切り離した暗号化の控えを持ち、使えるかを定期に試すよう書く。クラウドでは、狙われやすい保管先に削除の保護かオブジェクトロックを掛けるよう勧める[3]。
同社は、汚染の疑いのある環境を部分的に直さず、安全を確かめた新しい環境を一から作る方式を取った[1]。控えから戻す場合も、戻す先を作り直す場合も、汚染の前の時点を知るには侵入の始まりが分かっている必要がある。この件では初期侵入から4か月半あった。控えの世代が短いと、汚染の前まで戻れない。控えの汚染で復旧が延びた例に 名古屋港 2023年 がある。
5 跡が消える。ログの置き場所
この件では、委託先のノートPCのログはOSの更新で消え、一部の通信ログとアクセスログも失われた[1]。そのため、IDとパスワードがどこで漏れたかも、攻撃者が何を閲覧したかも絞りきれていない。ログが攻撃を受けた機器の中にだけあると、その機器と一緒に失われる。CISA は、網の機器、端末、クラウドのログを保管して守り、重要なシステムのログは可能なら1年以上残し、ログが消されたり止められたりしていないかを定期に確かめるよう書く[3]。委託先が管理する端末のログも、契約で保管の期間と提出を決めておく。
JPCERT/CC は、侵害が確かめられたシステムを、調査と保全のためにも網から切り離すよう書き、調査に要るログが暗号化で使えなくなる例があると注意する。切り離したシステムを戻す前には、残されたマルウェアや裏口、不正な設定が除かれたことを確かめるよう求める[4]。
守り方
- EDRを全部のサーバーと端末に置き、止められたことを警告にし、24時間見る体制を持つ[1][3]。
- 失敗したログインの連続と、普段と違う管理者のログインを警告にする。A09 セキュリティログとアラートの不備
- ログを機器の外へ送って期間を決めて残す。委託先の端末のログも契約で残させる[3]。
- 控えから戻す練習を定期にし、物流のような止まると事業が止まるシステムから順に、戻すまでの時間を測る[3]。
- クラウドのサービスのアカウントも、社内網が取られた前提で多要素認証と接続元の制限を掛ける。この件では検知の3日後にクラウドのアカウントが侵害された[1]。
- 個人データが漏れたら、個人情報保護委員会への報告と本人への通知を行う[6]。
参照
- ランサムウェア攻撃の影響調査結果および安全性強化に向けた取り組みのご報告 ランサムウェア攻撃によるシステム障害関連・第13報 アスクル、2025年12月12日。PR TIMES での同社の発表
- アスクルのサイバーセキュリティ アスクル、2026年8月4日更新
- #StopRansomware Guide CISA
- 侵入型ランサムウェア攻撃を受けたら読むFAQ JPCERT/CC、2026年6月18日更新
- Logging Cheat Sheet OWASP Cheat Sheet Series
- 漏えい等の対応とお役立ち資料 個人情報保護委員会