SJ blog
Security-JAWS #41（10周年記念 Day1） #3

EC2侵害調査の実践 — SSHブルートフォースの裏に潜んでいた本当の脅威

GuardDutyアラートをきっかけに調査を開始したら、ブルートフォースとは別経路でのマルウェア感染が判明した実際のインシデント対応事例

🎤 Webセキュリティ企業 セキュリティエンジニア（新卒2年目）

#EC2 #GuardDuty #フォレンジック #マルウェア #SSH #インシデントレスポンス #CloudTrail

キーテイクアウェイ

SSHブルートフォースのアラートを調査したら、実際の侵害はブルートフォースではなく公開鍵認証経由のルートログイン+マルウェア設置だった。アラートの表面だけ見ず、関連アラートまで含めた調査が必須

登壇者・企業の背景

  • Webセキュリティ・クラウドセキュリティ特化の上場企業（2020年グロース市場上場）
  • 主要サービス6つ（Webセキュリティ3、脆弱性関連2、クラウドセキュリティ運用1）
  • 登壇者は大学院で情報系専攻 → 2025年4月入社（社会人2年目）のセキュリティエンジニア
  • Security-JAWS初参加

インシデント概要

最初の相談内容

EC2に対して外部からSSHポートへの多数のログイン試行が確認された（GuardDutyアラート）

初期ヒアリングで判明した状況

  • ブルートフォースアラートは初回ではなく継続検知
  • セキュリティグループのインバウンドが0.0.0.0/0で全世界公開
  • マルチアカウント環境を運用中
  • 対象EC2で過去に「通常と異なる外部IPへの通信」アラートも検知済み
  • 顧客情報等の重要データは当該アカウントには存在していない

調査プロセス

ステップ1: データ保全

AWS推奨のEC2フォレンジック収集手順（優先順位順）:

  1. インスタンスメタデータの取得
  2. インスタンス終了保護の有効化
  3. ディスクの取得（EBSスナップショット）
  4. メモリの取得（揮発性データ）

揮発性の高いデータを優先し、作業による影響を最小化する原則。

ステップ2: スナップショット解析

フォレンジック環境（簡単に作成・削除可能な解析環境）でスナップショットをマウントし調査。

認証ログ調査

  • ブルートフォース元IPからのログイン成功: 確認されず ✓
  • ユーザや定期実行の不審な内容: 確認されず ✓

→ ここで安心してはいけない

プロセス調査 — 重大発見

  • EC2のrootユーザーのホームディレクトリから、root権限で実行中の不審なプロセスを発見
  • ファイル作成日が「外部IPへの通信異常アラート」の発生日と同一日

認証ログ深堀り — 侵害の痕跡

  • 外部IPアドレスからrootユーザーへの公開鍵認証によるSSHログイン成跡を発見
  • このログインも過去アラートと同日に発生
  • SSH設定でrootの公開鍵認証ログインが許可された状態だった

ステップ3: マルウェア解析

静的解析結果

  • 2024年作成のマルウェアと判明
  • 機能: 暗号化通信、自己削除
  • C2サーバーのIPアドレス = 過去アラートの外部IPアドレス（一致）

動的解析（サンドボックス）

  • Anyrun（エンタープライズ版）で実行を試行
  • 結果: マルウェアの自己削除機能が発動し、サンドボックス環境を検知して自らを消去
  • 詳細な動的解析は不可能に

判明したタイムライン

T1: セキュリティグループが0.0.0.0/0で設定される（時期不明）
     ↓
T2: 攻撃者がrootユーザーに公開鍵認証でSSHログイン
     ↓ 同日
T2: マルウェアを設置（root権限で実行開始）
     ↓ 同日
T2: マルウェアがC2サーバーに通信 → GuardDutyが外部通信異常を検知
     ↓ 後日
T3: SSHブルートフォースアラート発生（これは別の攻撃者による無関係な攻撃）

重要な発見: 相談のきっかけになったブルートフォースと、実際の侵害は別々のイベントだった。

調査結論

  1. SSHブルートフォースによるログイン成功: なし（不正ログイン成功の可能性は低い）
  2. しかしEC2は別経路で既に侵害されていた
  3. 侵入経路の特定: ログ保持期間の関係で不可能（数ヶ月分しか残っていなかった）

推定される侵入経路（確定不能）

  • 脆弱性を突いてEC2内に公開鍵を設置した可能性
  • 正規の秘密鍵が何らかの理由で漏洩した可能性

推奨対応フロー

1. アラート確認

  • 発生日、対象EC2を「5W」で整理
  • 時間軸での継続確認
  • 関連する他のアラートも必ずチェック（今回の教訓）

2. データ保全

  • EC2終了保護の有効化
  • EBSスナップショット作成
  • メモリダンプ取得（可能な場合）
  • 自動化の活用で迅速に保全

3. 設定確認

  • セキュリティグループの確認（外部からのアクセス難易度）
  • SSH設定の確認（root公開鍵認証の許可状態）
  • 過去・現在のアラートを両方確認

4. OS内部調査

  • 認証ログ確認（ディストリビューションとRsyslog有無で確認ファイルが異なる）
  • コマンド実行履歴
  • 不審なプロセス・ファイルの特定
  • VPCフローログ（有効化されていれば追加視点で調査可能）

Q&Aハイライト

Q: GuardDutyのEC2ランタイムモニタリングは有効だった？ A: 有効化されていなかった。有効化されていればマルウェアの悪意ある活動を早期検知できた可能性が高い。

Q: ログの保持期間の推奨は？ A: 半年〜1年が目安。ただし内部保存だけでなく外部へのアウトプット（S3等）が重要。今回はログが容量上限で古いものから削除されていた。

Q: 顧客への報告方法は？ A: 一次報告と最終報告の2段階。事実と推測を明確に区分して報告する。

初心者向け補足

GuardDutyアラートの読み方

GuardDutyのアラートは「何が起きたか」の事実を示すが、それが本当の問題の全体像とは限らない。

  • ブルートフォースアラート: 「攻撃を受けている」ことを示すが、「侵害された」ことは示さない
  • 外部通信異常アラート: 内部から不審な外部への通信 → こちらの方が侵害を示す可能性が高い

C2（Command and Control）サーバーとは

マルウェアが攻撃者の指示を受け取るための外部サーバー。マルウェアに感染したマシンは定期的にC2に接続し、次の命令を待つ。

フォレンジックの原則

  • 証拠を壊さない（元のディスクは直接触らない）
  • スナップショットから別環境で解析する
  • 揮発性の高いデータ（メモリ）を優先的に保全する

なぜセキュリティグループの全世界公開が危険か

0.0.0.0/0 = インターネット上の全IPアドレスからアクセス可能。これは「世界中の攻撃者に対してドアを開けっぱなしにしている」状態。今回のインシデントの根本原因。