(※2022-12-07に書いた個人ブログの転記です。)

概要

原因究明の流れ

調査の目的を決める
ログを絞り込む
- 画面上部: クエリーバー。ログをフィルターするための条件式を入力
- 画面左: indexの切り替えとフィールド一覧表示
- 画面右: 検索結果の時系列表示と、個々のログ。フィールドを指定してテーブル形式で表示することも可能
対象のログの詳細を見て事象を理解する

フィールドを以下に絞る

@log_type	ログタイプまたはログを送信したサービス
rule.name	IDS 等の検出名。GuardDuty では Inspector や Macie の検出結果名
source.ip	送信元 IP アドレス
user.id	ユーザ固有の ID。AWS リソースの場合はアクセスキー
user.name	ユーザ名。AWS リソースの場合は IAM のユーザー名やロール名。SH ログでは OS のユーザー名
cloud.instance.id	EC2 インスタンス ID
rule.description	検出した脅威の説明

調査の目的: 被害状況を確認する
成功した攻撃を確認する
- **log-aws-cloudtrail-***に絞る
- 1で検出した攻撃者のuseridとipアドレスで絞り込む
- event.outcomeで成功した攻撃に絞り込む
- ログのrequestParameters.keyを見ると、config.pyを取得していることがわかる
  - requestParameters.keyを表示フィールドに追加すると、すべての攻撃でconfig.pyをGetしていることがわかる
- S3への驚異を検出するためMacieのログに絞り込む
  - **log-aws-securityhub-***を選んで、クエリーバーに event.module:macie
    と入力
  - ↑から、バケットに読み込み権限が付与されたことがわかる
- PutBucketAclのログを探す
以下がわかる
- • 10:21:19 - S3 バケットに ACL を変更して読み込み権限を付与
- • 10:24:03 - EC2 インスタンスの認証情報でS3 バケットから config.py を窃取