AWS DevOps AgentでGuardDutyの検出結果を調査をしてみた

AWS DevOps AgentでGuardDutyの検出結果を調査をしてみた

2025.12.09

AWS DevOps Agent が盛り上がっていますね。
GitHub や Slack など多くの連携先があり、インシデントの調査を包括的に行えるため、ここから多くの調査をすることになりそうです。

そんな DevOps Agent ですが、ここまでいい感じに調査してくれるのであれば、GuardDuty の検知も調査してもらえるんじゃないか? と思いついたのでやってみました。

GuardDutyのイベントは直接参照できない

出オチ感がありますが、GuardDuty の検出結果を確認・調査してと依頼したら権限エラーになります。
devops-agent-gd-permission-error.png

Insufficient GuardDuty Permissions to Retrieve Finding Details
(日本語訳)検出結果の詳細を取得するための GuardDuty 権限が不十分です

スペースで利用される IAM ロールに権限を追加しましたが、同様のエラーとなりました。
おそらく参照できるサービス範囲があるのですが、ドキュメント上記載を見つけられませんでした。もし参照させる方法があれば教えてください。

予想では CloudWatch Investigations と同じサポート範囲なのかなと想定してます。
https://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/monitoring/Investigations-Services.html

諦めようかと思ったのですが、DevOps Agent から直接 GuardDuty を参照できないのであれば、別の場所を参照させればいけるのではと思いつきました。

というわけで GuardDuty のイベントを EventBridge のルールで取得し、CloudWatch Logs に出力して参照させてみます。

guardduty-eventbridge-cloudwatch.png

やってみる

GuardDutyのイベントをCloudWatch Logsへ出力する

まずは GuardDuty の検出結果を CloudWatch Logs へ出力する設定をします。
EventBridge のルールを作成して、ターゲットを CloudWatch Logs にしましょう。
スクリーンショット 2025-12-09 午前11.21.41.png

蛇足ですが、ルールの作成画面すごく使いやすくなっており感動しました。最近のアップデートでビジュアルルールビルダーというのが使えるようになったようです。
https://dev.classmethod.jp/articles/eventbridge-enhanced-visual-rule-builder/

GuardDuty Testerを使って検出結果を発生させる

サンプルイベントでは GuardDuty が参照できなくとも CloudTrail のログだけで調査が完了してしまったので、もう少し複雑な検出結果を調査させます。
こういうテストの時に便利な GuardDuty Tester を使ってみましょう。
https://github.com/awslabs/amazon-guardduty-tester

AWS が提供している CDK で展開できるテスターで、展開された EC2 内からスクリプトを実行すると任意の GuardDuty イベントを発生させることができます。
使い方については上記リポジトリを参照ください。

手順に従って CDK をデプロイし、セッションからスクリプトを実行します。

# リージョン設定REGION=ap-northeast-1

# セッション開始
❯ aws ssm start-session \
  --region $REGION \
  --document-name AWS-StartInteractiveCommand \
  --parameters command="cd /home/ssm-user/py_tester && bash -l" \
  --target $(aws ec2 describe-instances \
    --region $REGION \
    --filters "Name=tag:Name,Values=Driver-GuardDutyTester" \
    --query "Reservations[].Instances[?State.Name=='running'].InstanceId" \
    --output text)
# スクリプト実行
[ssm-user@ip-172-16-0-90 py_tester]$ python3 guardduty_tester.py --ec2 --runtime only --tactics impact
~~~
~~~
***********************************************************************
* restoring account settings:                                         *
Starting Step Function to restore any changes made to GuardDuty
Account Block Public Access settings after allowing time for
findings to first be generated!
* complete!                                                           *
***********************************************************************

これで準備完了です。しばらくするといくつか GuardDuty の検出結果が確認できました。

スクリーンショット 2025-12-09 午前11.35.35.png

この中の 1 つ Impact:EC2/MaliciousDomainRequest.Reputation を調査してみましょう。

DevOps Agentによる調査

GuardDuty の検出結果を出力しているロググループの ARN と、検出結果の ID、発生時刻を渡して調査を開始しました。

Investigation details

The GuardDuty detection results are output to "arn:aws:logs:ap-northeast-1:111111111111:log-group:/aws/events/guardduty-findings:*", so please investigate.

Investigation starting point

Id: 24cd8051f9d9638ffe3ef591b46a7fb6
2025-12-09 10:05:03(JST)

タイムラインではロググループから検出結果の情報を取得してくれています。
スクリーンショット 2025-12-09 午前11.02.04.png

ここから対象インスタンスの特定、設定の確認、デプロイされた方法など詳細に調査が進みます。

最終的には根本原因をしっかり特定してくれました。

スクリーンショット 2025-12-09 午後1.57.24.png

  1. GuardDuty test framework deployment intentionally triggered security findings
    (日本語訳)1. GuardDutyテストフレームワークの導入により、セキュリティ上の問題が意図的に発見された

Python によるスクリプトによって行われた、EICAR の配置なども確認できました。

instance executed a Python-based test script that intentionally made DNS queries to four malicious test domains (abused-rep, suspicious-rep, malicious-rep, crypto-rep.guarddutyc2activityb.com) and placed EICAR test files on the EBS volume.
(日本語訳)インスタンスは、4 つの悪意のあるテスト ドメイン (abused-repsuspicious-repmalicious-repcrypto-rep.guarddutyc2activityb.com) に対して意図的に DNS クエリを実行し、EICAR テスト ファイルを EBS ボリュームに配置する Python ベースのテスト スクリプトを実行しました。

実現したかった GuardDuty イベントからの調査ができて満足です。

まとめ

GuardDuty のイベントを CloudWatch Logs に出力させることで DevOps Agent へ調査をお願いしてみました。

想定されている使い方か少し怪しいですが、DevOps Agent から参照できる情報であれば調査できることがわかりました。

全ての検出タイプに対応できるものではありませんが、セキュリティ関連のインシデント調査にも活用できそうです。

参考

この記事をシェアする

FacebookHatena blogX

関連記事