SIEM on Amazon OpenSearchでインシデント調査を行う

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

## 概要

- SIEM on Amazon OpenSearchを利用して(仮想の)インシデント調査を行う社内のイベントに参加した。
- その際に勉強したことをメモしておく。


## 原因究明の流れ

1. 調査の目的を決める
2. ログを絞り込む
    
    <img src="https://i.gyazo.com/aaa955064105ab56dccbfe8140b6a32a.png" alt="drawing" width="600"/>
    
    - 画面上部: クエリーバー。ログをフィルターするための条件式を入力
    - 画面左: indexの切り替えとフィールド一覧表示
    - 画面右: 検索結果の時系列表示と、個々のログ。フィールドを指定してテーブル形式で表示することも可能
3. 対象のログの詳細を見て事象を理解する

## インシデント別捜査手順

### 1. IAM認証情報の侵害

- 調査の目的: `インシデントかどうかの判断と侵害の対象を特定する`
- **log-aws-guardduty-***のログに絞る
- フィールドを以下に絞る
    
    
    | @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 | 検出した脅威の説明 |
- GuardDutyの検出結果のうち、IAMUserに関するものに絞る
    
    ```bash
    rule.name:*IAMUser*
    ```
    
- 侵害されたログの詳細のresorce.resourceTypeを見る
    
    <img src="https://i.gyazo.com/7eac4a690ae86caf87cf8ce8ef3b2de8.png" alt="drawing" width="600"/>
    
    - ↑から、**EC2 インスタンス (i-00bbd9925dcbc5bb9) にアタッチされているロール (threat-detection-wksp-compromised-ec2) の認証情報を窃取して攻撃したことがわかる**

### 2. EC2インスタンスの侵害

- 調査の目的: 侵入方法を調査して根本原因を特定する
- 攻撃内容を確認
    - **log-aws-guardduty-***のログに絞る
    - 以下で絞り込む
        
        ```bash
        rule.name:*EC2*
        ```
        
        <img src="https://i.gyazo.com/aaa955064105ab56dccbfe8140b6a32a.png" alt="drawing" width="600"/>
        
        - [rule.name](http://rule.name/) (findins) から SSH Brute Force と 脅威リストとのマッチング (MaliciousIPCaller.Custom) を確認
- SSHに対する脆弱性の有無を確認
    - **log-aws-securityhub-***のログに絞る
    - ↑のうち、event.module(ログの生成元)をinspectorに絞る
    - sshで検索
    - rule.descriptionで、検知されている脆弱性を確認
- SSH Brute Forceの攻撃の成否を確認
    - **log-linux-secure-**のログに絞る
    - sshdに対して外部からアクセスしているログを抽出
        
        ```bash
        process.name:sshd and source.ip:*
        ```
        
    - user.nameの値の集計を見ると、rootが大半(外部からの SSH 接続には一般的には使用されないユーザー名のため、攻撃と思われる)
        
        <img src="https://i.gyazo.com/834f2e80de61f85a19c4ae87f0240566.png" alt="drawing" width="600"/>
        
    - event.outcome(行為が成功したか失敗したか)が成功のログに絞り込む
        
        <img src="https://i.gyazo.com/5f5d659390f330748d42130f014e8967.png" alt="drawing" width="600"/>
        
    - ↑から、**SSH Brute Forceを行い、ユーザーID alice を使ってログインが成功したことがわかる**

### 3. S3バケットの侵害

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

## 感想

- GuardDutyがなければ調査の取っ掛かりすらつかめなかったはず。GuardDutyは絶対有効にしておこうと思った。

## 参考

- [SIEM on Amazon OpenSearch Service Workshop](https://catalog.us-east-1.prod.workshops.aws/workshops/60a6ee4e-e32d-42f5-bd9b-4a2f7c135a72/ja-JP/03-log-analysis-basics)
- [OpenSearch Dashboardsのクエリ(KQL)の書式](https://www.elastic.co/guide/en/kibana/current/kuery-query.html)
- [GuardDutyの検出結果の形式](https://docs.aws.amazon.com/ja_jp/guardduty/latest/ug/guardduty_finding-format.html)
- [GuardDutyの検出結果タイプ](https://docs.aws.amazon.com/ja_jp/guardduty/latest/ug/guardduty_finding-types-active.html)