「結局、どこから入られたのか」。侵害対応で最も聞かれる質問だが、最も慎重に答えるべき質問でもある。

今回も、確認できた情報だけで侵入経路を一つに断定することはできなかった。ログの保持期間には限りがあり、攻撃者がログを改変・削除している可能性もある。古い認証情報が使われたのか、Webアプリケーションの脆弱性なのか、設定上の問題なのかを、推測だけで公表するべきではない。

「分からない」で止めない

経路を断定できないからといって、調査が無意味になるわけではない。むしろ重要なのは、判明した事実と未確定の可能性を分けることだ。

今回のようなケースでは、少なくとも次の入口を候補として扱う。

  • サーバのログイン情報・SSH鍵の漏えい
  • CMS本体、テーマ、プラグインの脆弱性
  • 管理画面のパスワード漏えいや総当たり攻撃
  • サーバに保存されたAPIキーやメール認証情報の漏えい
  • 過去の開発用設定、不要なアカウント、公開ポート

候補を並べる目的は、犯人当てではない。どの候補であっても再侵入できない状態にするためだ。

ログから確認できること、できないこと

確認するログには、SSHログイン、Webアクセス、Webサーバのエラー、アプリケーションの操作履歴、クラウド基盤の操作履歴などがある。

たとえば、普段使わない国や時間帯からのログイン、不自然な失敗試行の連続、管理画面への異常なPOST、見覚えのない設定変更などは、重要な手掛かりになる。

しかし、ログに異常がないことは安全の証明ではない。ログ保存期間外の出来事かもしれず、正規アカウントが使われていれば通常のログインに見えることもある。

だからこそ、次のように結論を分ける。

  • 確認できた事実：不審な設定・不要なアカウント・異常な挙動があった
  • 未確定の点：最初の侵入時刻と侵入経路
  • 実施する対策：経路が未確定でも、関連する認証情報を失効し、不要な入口を閉じる

影響範囲はサーバの中だけではない

サーバに置かれていた認証情報は、外部サービスにもつながっている。今回も、メール送信用SMTP、アクセス解析、外部APIなどを、影響範囲として扱った。

仮にサーバ上で秘密情報を読み取れた可能性があるなら、その情報は変更前のまま使い続けない。これは「漏えいが証明されたから」ではなく、「漏えいを否定できないから」行う安全策だ。

サービスアカウントの鍵については、古い鍵だけを無効化して終えるのではなく、古いサービスアカウント自体を削除し、新しい用途・最小権限のアカウントを新設するほうが管理しやすい場合がある。大切なのは、何を削除し、何を新設し、どこで利用しているかを記録することだ。

「安全側に倒す」は過剰対応ではない

パスワードや鍵を再発行すると、一時的に連携が止まることがある。その作業を面倒に感じて、経路確定を待ちたくなるかもしれない。

しかし、侵害の可能性がある環境では、再発行の手間より再利用される被害のほうが大きい。特にメール送信権限は、なりすまし、迷惑メール送信、取引先への詐欺連絡につながりうる。

次回は、実際の復旧で行った「削除するもの」「変更するもの」「作り直すもの」を、順番と注意点に分けて紹介する。