エムオーテックス株式会社が運営するテックブログです。

最新DFIRツール「Suzaku」使ってみた

最新DFIRツール「Suzaku」使ってみた

はじめに

セキュリティソリューションの堀田です。 普段の業務ではフォレンジックなどを行っております。

近年、クラウドコンピューティングの普及に伴い、クラウド環境におけるセキュリティの重要性が高まっていると感じています。少し前にはなりますが、2025年3月17日にデジタルフォレンジック研究会が公開した「証拠保全ガイドライン 第10版」*1に、クラウドサービスの章が追加されるなど、クラウド環境における証拠保全や調査手法に注目が集まっています。

そのような状況の中、2025年4月20日にYamato Securityがクラウドログのためのイベント解析ツール、「Suzaku」をリリースしました。現在はα版開発中のツールですが、AWSのCloudTrailに対応しています。

今回はSuzakuを実際に利用し、使用感や簡単な利用例などを備忘録として以下に記載します。

Suzakuとは

Yamato Securityが開発・リリースしたクラウド用のDFIR(デジタルフォレンジックおよびインシデントレスポンス)ツールです。Suzakuについて、GitHubのreadmeでは以下の通り紹介されています。

Suzakuは、クラウドログのための脅威ハンティングおよび高速フォレンジックタイムライン生成ツールです。 ・・・(中略)・・・ クラウドログには、数千もの異なるAPI呼び出しがあり、手動で確認するには膨大なイベントが存在します。 Suzakuは、ノイズの中から攻撃を見つけるだけでなく、迅速なフォレンジック調査を行うために必要なイベントとデータのみを含むDFIRタイムラインを提供するよう設計されています。

(引用)https://github.com/Yamato-Security/suzaku/blob/main/README-Japanese.md

Suzakuのダウンロード

SuzakuはGitHubからダウンロード可能です。以下のリンクから、お使いの環境に合わせてダウンロードしてください。 github.com

読み込むCloudTrailログが手元にない場合にはサンプルデータも配布されております。 github.com

Suzakuの実行

今回はWindows環境での実行例を記載します。

インシデントタイムラインの生成

展開したSuzakuのディレクトリ配下で以下実行してください。

Suzakuは.jsonおよび.json.gzに対応しています。

以下は配布されていたサンプルデータでの実行例となります。

suzaku-0.1.1-win-x86.exe aws-ct-timeline --directory "<解析対象のパス>"

Suzakuの実行は非常に高速で、サンプルデータ (3.5MB程度) の実行では数秒で完了しました。

実行後には以下のように出力され、検知内容が時間順に並べられます。

Suzaku実行後の画面

検出例

検知回数のタイムライン

Suzaku実行結果のサマリー

上記結果をコマンドライン上で確認してもよいのですが、-o オプションをつけることでファイルへの出力も可能です。

suzaku-0.1.1-win-x86.exe aws-ct-timeline --directory "<サンプルデータのパス>" -o "<出力ファイル名>"

上記を実行することで <出力ファイル名>.csv でファイル出力されます。

sigmaルールについて

sigmaルールは各種ログにおける異常等を検知するための統一されたルールフォーマットです。 Suzakuはあらかじめ定義されたsigmaルールに従って検出を行っています。

Suzakuで利用されている各ルールについて、ある程度名前から内容を推測できますが、詳細を確認したい場合にはダウンロードしたSuzakuのrules ディレクトリ配下の各ymlファイルもしくは、以下のsuzaku-rulesのリポジトリから確認可能です。 github.com

各ルールの説明の他に関連資料や、該当ルールのMITREテクニックのタグもファイル中に記載されています。

以下ではSuzakuで利用されているルールを例に中身を説明します。

CloudTrail Logging Stopped

サンプルの実行結果でも出力されていた High相当の検出内容になります。

タイトルからもわかる通り、CloudTrailのログが停止したという内容のルールになっています。 こちらのルールは以下のように記述されています。

title: CloudTrail Logging Stopped
id: da90c11e-e3d4-411e-aaf7-06d02e0c5c23
status: test
description: |
    A user successfully disabled CloudTrail logging.
    Sample command line: aws cloudtrail stop-logging --name TrailName
references:
    - https://securitylabs.datadoghq.com/cloud-security-atlas/attacks/stopping-cloudtrail-trail/
    - https://research.splunk.com/cloud/8a2f3ca2-4eb5-4389-a549-14063882e537/
    - https://logrhythm.com/blog/aws-defense-evasion-and-centralized-multi-account-logging/
    - https://medium.com/daniel-grzelak/disrupting-aws-logging-a42e437d6594
    - https://pages.awscloud.com/rs/112-TZM-766/images/Visibility_detect_respond_AWS_SANS_whitepaper.pdf
    - https://traildiscover.cloud/#CloudTrail-StopLogging
author: Zach Mathis (@yamatosecurity)
date: 2025-04-23
modified: 2025-04-23
tags:
    - attack.defense-evasion
    - attack.t1562.008 # Impair Defenses: Disable or Modify Cloud Logs
logsource:
    product: aws
    service: cloudtrail
detection:
    selection:
        eventSource: 'cloudtrail.amazonaws.com'
        eventName: 'StopLogging'
    filter:
        errorCode: 'AccessDenied'
    condition: selection and not filter
falsepositives:
    - Admins turning off unneeded logging
level: high

出展:suzaku-rules/suzaku/aws_cloudtrail_logging_stopped.yml at 14f60b90181ab3124a563a5fcd105d0be9e00cf2 · Yamato-Security/suzaku-rules · GitHub

ライセンス:https://github.com/Yamato-Security/suzaku-rules/tree/46c21eca20dcafb0640a874caa07a81fb42ccaa4?tab=License-1-ov-file

descriptionにてルールの概要が記載されており、タイトルだけで内容が分からない場合にはこちらを確認してください。

sigmaルール中では referencesやtags (MITREタグ) が記述されており、検知の内容やどの段階の攻撃であるかわかりやすくなっています。

その他 detectionでは検知を行うソースを指定しています。  logging stopのイベントではCloudTrail上にStopLoggingのAPI呼び出しのログが記録されている場合に検知が行われる仕組みになっていることがわかります。

フォレンジックでの利用

Suzakuを利用することで、クラウド環境でのインシデント発生の事実確認や全体像の把握を高速に行えそうです。

また、専門の調査環境やgrep等のコマンドに関する知識がなくても、出力したCSVファイルをExcel等で読みこむことで誰でも簡単に調査を行えます。

以下では利用例を記載します。

Levelベースのフィルタリング

調査の初期の段階で、全く手がかりが存在しないような状況であれば、CriticalやHighでフィルターを実行し残ったものから確認していくのが良いと考えます。

Levelの高いルールでの検出は直接的な侵害を示唆する場合があり、検出した時刻周辺に侵害関連の情報が存在する可能性が高いと考えられます。 しかしながら通常の操作により発生する可能性も0ではありません。詳細については周辺時刻のログ精査をする必要が有ります。

そのため実際の利用例としては

Suzaku出力 -> 検出内容をフィルタリング -> 調査対象を絞り詳細調査 (接続元IP、ユーザー情報、イベント名等の確認)

といった流れになると思われます。

なお、現時点ではSuzakuのルールにCriticalのものが設定されていないため、Highで検出されているものを確認していくことになります。

rulesベースのフィルタリング

Levelのフィルターと考え方は似ていますが、一般的な運用ではあまり見かけず、悪意のある操作時に頻繁に検出されるようなルールがいくつかあります。 ある程度の慣れが必要ですが、ルール毎にフィルターをかけることで効果的な調査が行えます。

一般的な操作で発生しにくいルールの例としてCloudTrailのログ設定操作や、AWS RDS DBのマスターパスワード変更の操作等が考えられます。

その他にもAWSでの作業記録取得や利用時のルールを定めている場合には、以下の不審な操作特定が容易になります。

  • パスワード変更

  • ユーザー追加

  • AWSルートアカウントの利用 等

その他

ルール別に調査を進めるのが簡単ですが、上記以外にも有用な項目が多数あります。

  • EventName

  • SrcIP

  • UserAgent

  • UserName

  • UserARN 等

さいごに

今回はテストデータに対しての実行のみとなりましたが、Suzakuを調査の初期段階に実行することで迅速にフォレンジックを行えると感じました。

今回利用したSuzakuはα版ですが、AWSの調査においては現時点でも利用できる場面があると思います。今後はGCPとAzureにも対応予定とのことで、今後の発展にも期待しています。

時間があればStratus Red TeamやGrimoireで攻撃した後の結果などを検証してみたいですね。

以上、Suzakuの紹介でした。

今後MOTEXテックブログではセキュリティ技術に関連する記事も投稿していきます。 次回投稿をお楽しみに。