Eストアー（BASE子会社）の情報漏洩は、 2026年5月21日〜8月1日までの約72日間、 攻撃者がサーバー内部で不正プログラムを実行し続けていた。
つまり、 2ヶ月以上も攻撃を検知できなかったということになる。
この「長期間気づけなかった」という事実は、 脆弱性そのものよりも深刻で、 企業の監視体制・ログ管理・セキュリティ運用の問題を浮き彫りにしている。
本章では、 なぜ攻撃を検知できなかったのか、 その構造的な原因を専門的に解説する。
1．ログ監視の不備：異常通信を検知できなかった可能性
✔ 外部へのデータ送信が“少量・断続的”だった
攻撃者は大量データを一気に送るのではなく、 小分けで長期間にわたり送信する方式を取っていた可能性が高い。
この方式は、
- 通信量が急増しない
- アラートが発火しにくい
- 正常通信に紛れやすい
という特徴があり、 監視体制が弱い企業ほど見逃しやすい。
✔ ログ監視の粒度が粗かった可能性
- アプリケーションログ
- DBアクセスログ
- 外部通信ログ
これらが十分に連携していなければ、 不正プログラムの動作を検知するのは難しい。
2．脆弱性診断の不足：攻撃前に気づけなかった構造的問題
✔ 脆弱性は“攻撃前に発見できた可能性が高い”
今回の侵入経路はアプリケーション脆弱性。 これは本来、
- 定期的な脆弱性診断
- ライブラリ更新
- コードレビュー で発見できる種類の問題。
つまり、 脆弱性が長期間放置されていた可能性が高い。
✔ 診断頻度が低かった可能性
一般的に、 ECプラットフォームは月次〜四半期で診断を行うべきだが、 今回の長期侵害を見る限り、 診断頻度が十分ではなかった可能性がある。
3．アプリケーション層の監視が弱い：不正プログラムの実行を検知できなかった
攻撃者はサーバー内部で不正プログラムを実行していた。
通常であれば、
- 不審なプロセス
- 異常なDBアクセス
- 想定外のスクリプト実行 などが検知されるはず。
しかし今回は、 不正プログラムが“正規プロセスに偽装”されていた可能性が高い。
✔ 想定される偽装方法
- 正規アプリケーションと同じユーザー権限で動作
- 正規プロセス名に近い名前を使用
- ログ出力を抑制
- 外部送信を低頻度に調整
こうした偽装は、 監視体制が弱い企業ほど見抜けない。
4．アラート設定の甘さ：異常検知が機能していなかった可能性
✔ アラート閾値が高すぎた可能性
- 通信量が一定以上
- DBアクセスが急増
- CPU負荷が急上昇
こうした閾値が高すぎると、 攻撃者の“静かな攻撃”は検知できない。
✔ アラートの種類が不足していた可能性
- 不正なスクリプト実行
- 想定外のDBクエリ
- 外部送信の異常 などのアラートが設定されていなかった可能性がある。
5．セキュリティ運用の人員不足：監視体制が機能していなかった可能性
中小ECプラットフォームでは、 セキュリティ担当者が少ないケースが多い。
✔ 想定される運用上の問題
- ログを“蓄積するだけ”で分析していない
- アラートが来ても対応が遅れる
- 監視が平日昼間に偏っている
- 夜間・休日の監視が弱い
攻撃者はこうした“運用の隙”を狙う。
6．攻撃者の巧妙さ：検知されないように設計された攻撃
今回の攻撃は、 検知されないように設計された高度な情報収集型攻撃だった。
特徴：
- 長期間
- 少量送信
- 正規プロセス偽装
- バックドアなし（痕跡を残さない）
つまり、攻撃者は 「静かに、長く、確実に情報を吸い出す」 ことを目的としていた。
まとめ
Eストアーが2ヶ月以上攻撃を検知できなかった理由は、 単なるミスではなく、 監視体制・脆弱性管理・ログ分析・アラート設定など複数の構造的な問題が重なった結果だ。
特に以下の点が深刻：
- 脆弱性が長期間放置されていた可能性
- アプリケーション層の監視が弱かった
- 不正プログラムの実行を検知できなかった
- 外部送信の異常を見逃した
- セキュリティ運用の人員不足
- 攻撃者が“静かな攻撃”を設計していた
この事件は、 「気づけなかったこと自体が最大の問題」 であり、 ECプラットフォームの監視体制の脆弱さを象徴する事例となった。
コメント