Eストアー（BASE子会社）の「ショップサーブ」情報漏洩事件は、 単なる設定ミスや内部不正ではなく、 アプリケーションの脆弱性を悪用した外部攻撃によって発生した。
攻撃者は約2ヶ月以上にわたり、 サーバー上で不正プログラムを実行し続け、 データベースに格納された情報を外部へ送信していた。
本章では、公式最終報と一般的な攻撃手法を踏まえ、 「攻撃者は何をしたのか」「なぜ長期間気づけなかったのか」 を専門的に解説する。
1．攻撃の入口：アプリケーション脆弱性の悪用
✔ 侵入経路は“アプリケーションの脆弱性”
Eストアーのサーバー上で稼働するアプリケーションに 脆弱性（セキュリティホール）が存在していた。
攻撃者はこの脆弱性を利用し、 サーバー内部で不正なコードを実行できる状態を作り出した。
✔ 想定される脆弱性の種類（一般論）
公式発表では具体的な脆弱性名は伏せられているが、 この規模の漏洩でよく見られるのは以下のタイプ：
- RCE（リモートコード実行）
- SQLインジェクション
- 認証回避（Broken Authentication）
- アクセス制御の不備（IDOR）
- 古いライブラリの脆弱性
今回の特徴（不正プログラム実行 → DB送信）から、 RCE系の脆弱性が濃厚と考えられる。
2．攻撃者が行ったこと：不正プログラムの実行
攻撃者は脆弱性を利用して、 サーバー内部で 不正プログラム（スクリプト） を実行した。
✔ 不正プログラムの役割
- データベースにアクセス
- 顧客情報・会員情報・店舗情報を抽出
- 外部の攻撃者サーバーへ送信
- 継続的に情報を吸い出す仕組みを維持
つまり、攻撃者は「一度侵入して終わり」ではなく、 長期間にわたって情報を収集し続ける仕組みを構築していた。
3．攻撃期間が長期化した理由：検知できなかった構造的問題
✔ 攻撃期間：2026年5月21日〜8月1日（約72日間）
なぜこれほど長期間、攻撃を検知できなかったのか？
想定される要因（一般論）
- ログ監視が不十分
- 外部送信の通信量が少量で気づきにくい
- 不正プログラムが正規プロセスに偽装されていた
- アプリケーション層の異常検知が弱い
- 脆弱性診断が定期的に行われていなかった
特に「外部送信の通信量が少量」という点は重要で、 攻撃者は大量データを一気に送るのではなく、 小分けにして長期間吸い出すことで検知を回避した可能性が高い。
4．バックドアがなかった理由：侵入経路が限定されていた
フォレンジック調査の結果：
- 侵入経路は1つに限定
- バックドア（恒久的な侵入口）は設置されていない
これは攻撃者が「脆弱性を利用した一時的な侵入」を繰り返し、 その都度データを吸い出していた可能性を示す。
バックドアがないということは、 攻撃者は脆弱性が修正されれば侵入できなくなるため、 脆弱性修正が最重要の対策となる。
5．データベース吸い出しの仕組み：攻撃者の動き
攻撃者が行ったことを時系列で整理するとこうなる：
① 脆弱性を悪用してサーバー内部に侵入
↓
② 不正プログラムを実行
↓
③ データベースに格納された情報を抽出
↓
④ 外部の攻撃者サーバーへ送信
↓
⑤ 数日〜数週間単位で繰り返し実行
↓
⑥ 8月1日に通信遮断されるまで継続
この仕組みは、 標的型攻撃（APT）に近い性質を持つ。
6．攻撃者の目的：情報収集型のサイバー攻撃
今回の攻撃は、 金銭目的の「即時不正決済」ではなく、 長期的な情報収集を目的とした攻撃と考えられる。
理由：
- クレカ情報は“部分的”で即悪用できない
- 購入者・店舗・アフィリエイターなど多層の情報が狙われている
- 長期間の継続的な吸い出し
- バックドアを設置していない（情報収集に特化）
つまり、攻撃者は 「大量の個人情報を収集し、後から転売・詐欺に利用する」 という典型的な情報収集型のサイバー攻撃を行った可能性が高い。
まとめ
Eストアーの情報漏洩事件は、 アプリケーション脆弱性を悪用した外部攻撃によって発生した。
攻撃者は脆弱性を利用してサーバー内部で不正プログラムを実行し、 約2ヶ月以上にわたり、 購入者・会員・店舗・アフィリエイターの情報を吸い出し続けた。
侵入経路は1つに限定され、バックドアは設置されていなかったが、 長期間検知できなかったことから、 アプリケーション層の監視体制や脆弱性診断の不足が浮き彫りになった。
この攻撃は、 即時の金銭目的ではなく、長期的な情報収集を目的とした高度な攻撃であり、 ECプラットフォームの脆弱性が中小事業者に与える影響の大きさを示す事例となった。
コメント