re:Invent 2025: GuardDuty Runtime Monitoringの実践的な脅威検出テスト手法
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
re:Invent 2025 の書き起こし記事については、こちらの Spreadsheet に情報をまとめています。合わせてご確認ください
📖 re:Invent 2025: AWS re:Invent 2025 -Testing GuardDuty’s Runtime Detections:Hands-on with real world attack scenarios
この動画では、Amazon GuardDutyのリードセキュリティエンジニアであるMohammad Wasiqが、GuardDuty Runtime Monitoringの脅威検出機能について解説しています。AWS CIRTの実際のインシデントデータから、AWS顧客への攻撃で最も多い初期アクセス手法が認証情報の侵害とパブリック公開アプリケーションの侵害であることを明らかにし、GuardDutyがこれらに対する検出を優先している理由を説明します。単純なテストではなく、webshellを通じたマルウェアダウンロードやcronジョブ作成など、実際の攻撃パターンを反映した現実的なシナリオでテストする重要性を強調し、Amazon GuardDuty TesterのGitHubリポジトリを使用した具体的なテスト手順をデモンストレーションしています。EKSクラスタ上の脆弱なPHPアプリケーションへの攻撃シミュレーションを通じて、GuardDutyが生成する複数の検出結果と攻撃シーケンスファインディングの有効性を実証しています。
※ こちらは既存の講演の内容を最大限維持しつつ自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますのでご留意下さい。
本編
GuardDutyが実世界の脅威情報を収集し、検出を優先順位付けする方法
こんにちは、皆さん。このトークに来ていただきありがとうございます。AWS re:Invent で楽しい時間を過ごされていることを願っています。私の名前は Mohammad Wasiq で、Amazon GuardDuty のリード セキュリティ エンジニアの一人です。GuardDuty での私の主な仕事は、脅威検出機能を研究、開発し、継続的に改善することです。過去 3 年間、私は GuardDuty ランタイム モニタリングに焦点を当ててきました。このトークでは、GuardDuty が実世界の脅威に関する情報をどのように収集するのか、その情報を使用して脅威検出をどのように優先順位付けして実装するのか、そして現実的な攻撃シナリオを使用して GuardDuty ランタイム モニタリングをテストする方法について学びます。
GuardDuty が何かご存じない方のために説明すると、GuardDuty は CloudTrail ログや VPC フロー ログなど、AWS アカウント内のさまざまなログ ソースを監視し、機械学習と検出ルールを適用してリアルタイムで脅威を検出する脅威検出サービスです。GuardDuty Runtime Monitoring は、GuardDuty が提供するオプションのランタイム モニタリング ソリューションです。これには、EC2 インスタンスなどの AWS コンピュート ワークロードに eBPF エージェントをデプロイすることが含まれます。eBPF エージェントはさまざまなオペレーティング システム レベルのイベントを収集し、それらを GuardDuty に送り返してモニタリングと脅威検出を行います。
重要な質問は、ランタイム モニタリング ソリューションをテストする必要がある理由です。明らかな理由は、ランタイム モニタリング サービスが要件を満たしていることを確認するために評価したいということです。もう一つの重要な理由は、インシデント対応機能をテストしたいということです。なぜなら、ランタイム モニタリングの検出結果に対応するための堅牢なインシデント対応手順を持つことが本当に重要だからです。
多くのお客様がランタイム モニタリングをテストする際に単純なテストを使用していることに気付きました。これらの単純なテストは、多くの場合、単一の MITRE テクニックにマップされます。 例えば、お客様は永続性アクティビティの検出をテストするために cron ジョブを作成します。これらの単純なテストには 2 つの主な問題があります。 まず第一に、それらは現実的ではありません。第二に、ランタイム モニタリング ソリューションのノイズ削減またはノイズ管理機能に関する情報を提供しません。これらのアクションはすべて、良性のアクティビティでも非常に一般的なアクションです。例えば、cron ジョブの作成は非常に一般的な良性アクティビティです。ですから、これらの単純なテストを使用すると、ランタイム モニタリング ソリューションが実際の脅威アクティビティから良性アクティビティをフィルタリングするのにどの程度優れているかについての洞察は得られません。
より効果的なテストのためには、より現実的な攻撃シナリオが必要です。これが今日このトークで学ぶことです。 まず、GuardDuty が実世界の攻撃に関する情報をどのように収集するかを見てみましょう。最初の、そして最も重要な情報源の一つは実際のお客様のインシデントです。AWS CIRT、つまり Customer Incident Response Team と呼ばれるチームがあり、セキュリティ インシデントへの対応でお客様をサポートしています。これらのお客様とのエンゲージメントから、AWS のお客様に対する実際の攻撃で使用されるタクティクスとテクニックに関する貴重な情報を収集します。また、AWS のお客様に対して使用される最も一般的な、または上位のテクニックについても学びます。
AWS CIRT のデータによると、AWS の顧客に対する攻撃で使用される初期アクセス手法の上位 2 つは、認証情報の侵害とパブリックに公開されているアプリケーションの侵害です。認証情報の侵害というのは、攻撃者が AWS の認証情報または IAM 認証情報を入手して、それを使用して AWS アカウントにアクセスすることを意味します。そこから、彼らはデータを流出させたり、スパムメールを送信したり、リソースハイジャッキングのためのコンピュートワークロードを作成したりすることができます。パブリックに公開されているアプリケーションの侵害というのは、脆弱性のあるパブリックに公開されているアプリケーションを持っていることを意味します。攻撃者はその脆弱性を悪用して、EC2 インスタンスなどの基盤となるコンピュートリソースにアクセスすることができ、そこから暗号マイニングやインターネット上の他のターゲットに対する DDoS 攻撃など、様々な活動を実行することができます。
AWS のデータによると、AWS の顧客に対する攻撃の大多数がこれら 2 つの初期アクセス手法を展開しています。これが GuardDuty が CloudTrail モニタリングなどの他の GuardDuty 機能だけでなく、GuardDuty ランタイムモニタリングにおいても、これらの手法に対する検出の開発を優先している理由です。さらに、このトークで学ぶことになる実際の攻撃シナリオは、これら 2 つの初期アクセス手法に基づいています。
実際の攻撃に関する情報のもう 1 つのソースは、GuardDuty が消費する脅威インテリジェンスです。GuardDuty は様々な社内および第三者の脅威インテリジェンスソースを使用しており、これらのソースから学ぶことは以下の通りです。 まず、実際の攻撃で使用される IP アドレス、ドメイン名、ファイルハッシュである侵害の指標について学びます。また、実際の攻撃で使用される戦術とテクニック、および実際の攻撃で使用される様々なアクティビティパターンについても学びます。最後になりますが、実際の攻撃または実際の脅威を取り巻く背景についても学びます。この背景は非常に重要です。なぜなら、それは GuardDuty に特定の脅威がターゲットとするアプリケーションと環境の種類、および彼らが展開する戦術とテクニックのシーケンスについて知らせるからです。
シンプルな実際の攻撃シナリオを使用して、これらすべてを可視化して理解しましょう。Web アプリケーションの侵害は、私たちのハニーポットによって日常的にキャプチャされる最も一般的な攻撃ベクトルの 1 つです。これが典型的な Web アプリケーション侵害の仕組みです。 攻撃者は Web アプリケーションの脆弱性を悪用して webshell をデプロイします。webshell をデプロイしたら、基盤となるオペレーティングシステム上で任意のコマンドを実行できます。通常、彼らが最初に行うステップは、スクリプト、つまりスクリプトマルウェアをダウンロードして実行することです。その後、スクリプトマルウェアは暗号マイナーや DDoS マルウェアなど、セカンドステージマルウェアをダウンロードするために使用されます。その後、chmod コマンドを使用してセカンドステージマルウェアを実行可能にします。最後に、セカンドステージマルウェアを実行します。通常、攻撃者はスケジュール済みタスクまたは cron ジョブを作成することで、セカンドステージマルウェアの実行を永続化させます。これらのすべてのアクションとアクティビティが特定の MITRE 戦術とテクニックにマップされていることがわかります。また、これらのテクニックで使用される特定のパターンについても学んでいることがわかります。
例えば、この場合、攻撃者は curl コマンドを使用して IP アドレスベースの URL からスクリプトマルウェアをダウンロードし、それをシェルプロセスにパイプします。もう 1 つの興味深いパターンは cron ジョブの作成です。ここで、攻撃者は cron ジョブの指示を一時ファイルに書き込み、crontab コマンドを使用してその一時ファイルをロードします。 また、これらのすべてのアクションとステップを取り巻く背景についても学びます。例えば、これらのすべてのアクションは Web アプリケーションまたはネットワークに公開されているアプリケーションから発生し、非常に特定のシーケンスに従います。この例は、GuardDuty が実際の攻撃または実際の脅威で使用される戦術とテクニック、およびアクティビティパターンについてどのように学ぶのか、そしてこの情報を使用して脅威検出を優先化および開発する方法を示しています。
Amazon GuardDuty Testerを使用した現実的な攻撃シナリオの実践テスト
では、GuardDuty のランタイムモニタリングを使用して、現実的な攻撃シナリオでこれらの脅威をどのように検出できるかを見てみましょう。Amazon GuardDuty Tester に複数の現実的なシナリオを追加しました。 Amazon GuardDuty Tester が何かを見てみましょう。 Amazon GuardDuty Tester は公開されている GitHub リポジトリで、様々な GuardDuty の検出結果をテストすることができます。 Google で検索することができます。GitHub リポジトリのメインページを開くと、簡単に使用できる手順が見つかります。 AWS アカウント内にセキュアでロックダウンされたテスト環境をセットアップするための手順です。
これらの手順に従って実行すると、 AWS アカウント内にロックダウン VPC がセットアップされ、EC2 インスタンスなどの様々なリソースが含まれます。 ECS クラスタと EKS クラスタも含まれます。テスト環境をセットアップしたら、次の重要なステップは GuardDuty ランタイムモニタリングが有効になっていることを確認することです。GuardDuty コンソールを開いて、 左側のランタイムモニタリングリンクをクリックします。 これでランタイムモニタリングの有効化メインページに移動します。 ランタイムモニタリングが有効になっていることを確認してください。この場合は有効になっていますが、AWS Fargate のエージェント管理は有効になっていません。これを有効にしましょう。また、Amazon EC2 のエージェント管理も有効になっていません。これも有効にしましょう。
テスト環境がセットアップできたので、テストを実行しましょう。 テストを 2 つのステップで実行します。最初のステップでは、EKS クラスタに脆弱な PHP アプリケーションをデプロイします。2 番目のステップでは、その PHP アプリケーションに対して攻撃を実行します。 Amazon GuardDuty Tester を使用してテスト環境を作成すると、AWS アカウント内に複数の EC2 インスタンスが作成されます。そのうちの 1 つは driver GuardDuty Tester インスタンスです。 このインスタンスに SSM start session を使用して接続し、ターミナルセッションを開始します。そこから攻撃シナリオを実行します。
Amazon GuardDuty Tester リポジトリをもう一度開きましょう。 driver インスタンスに接続するための SSM start session コマンドが提供されています。そのコマンドをコピーしてください。次に、クライアント側のホストでターミナルウィンドウを開きます。AWS CLI がセットアップされており、SSM start session を実行するための権限があることを確認してください。 まず、Amazon GuardDuty Tester を使用してテスト環境をインストールまたは作成したリージョンを設定します。次に、コマンドを貼り付けて実行します。 これで driver インスタンスにログインしました。
driver インスタンス内には、様々なファイルとディレクトリがあります。そのうちの 1 つは runtime scenarios ディレクトリです。 このディレクトリを見てみましょう。 ここに様々な現実的なシナリオが見つかります。そのうちの 1 つが php-webshell で、これが今日実行するものです。php-webshell の中を見てみましょう。 このディレクトリには 2 つの異なるスクリプトがあります。1 つは deploy_php.sh で、もう 1 つは attack.py です。deploy_php.sh は EKS クラスタに PHP ウェブアプリケーションをデプロイします。PHP ウェブアプリケーションをデプロイしましょう。
deploy_php.sh を実行すると、ECR リポジトリが作成され、PHP Apache コンテナイメージがそこにロードされます。その後、そのイメージを使用して EKS クラスター上に EKS ポッドが作成されます。今、ポッドが作成されている途中です。少し待ちましょう。ポッドが作成されました。こちらがポッドの名前で、こちらが Web アプリケーションにアクセスできる IP アドレスです。ポッドの作成後、スクリプトはポッド上で様々なセットアップステップを実行します。より興味深いセットアップステップの一つは、シナリオのコマンド・アンド・コントロール通信をシミュレートするために、コマンド・アンド・コントロールサーバーをセットアップすることです。
PHP アプリケーションがデプロイされたので、攻撃を実行してみましょう。攻撃スクリプトを最初に開始すると、アカウント内で必要な GuardDuty のパーミッション設定を変更または作成するための許可を求められます。それを許可してください。攻撃の最初のステップとして、スクリプトは PHP Web アプリケーションの IP アドレスを取得します。その後、index.php にアクセスし、脆弱性を悪用して webshell をデプロイします。webshell をデプロイした後、様々な検出コマンドを実行し、マルウェアをダウンロードして実行します。
これで攻撃シナリオの実行が完了しました。次に、GuardDuty が生成した検出結果を見てみましょう。GuardDuty コンソールを開き、トップメニューの findings リンクをクリックします。これにより、生成されたすべての検出結果が表示されます。このシナリオは複数の検出結果を生成しているはずです。
例えば、webshell を通じて複数のコマンドが実行されたとき、GuardDuty は高い重大度の疑わしいコマンド検出結果を生成しました。この検出結果が PHP Web アプリケーションから発生したことを確認するために、このプロセスの系統を見てみましょう。ここで、親が Apache2 であることが分かります。これは、PHP を実行するために Apache を使用しているため、実際に PHP アプリケーションから発生したことを意味しています。
攻撃シナリオはまた、ネットワーク偵察のために nmap を実行しました。そのため、GuardDuty は疑わしいツール検出結果を生成しました。スクロールダウンしてみましょう。プロセスの名前が nmap であることが分かります。攻撃シナリオはまた、暗号マイナーをダウンロードして実行したため、GuardDuty は暗号マイナー実行検出結果を生成しました。この検出結果を詳しく見てみましょう。
このファインディングが PHP ウェブアプリケーションからも発生していることを確認するために、このファインディングのプロセス系統図も見てみましょう。ここで確認できるように、祖父プロセスは Apache2 であり、つまりこれが実際に PHP アプリケーションから発生していたということです。最後に、GuardDuty は攻撃シーケンスのファインディングも生成しました。これは集約型またはコンポジットのファインディングで、攻撃シナリオ中に検出されたすべての戦術、技法、シグナルの包括的なビューを提供します。
このトークの重要なポイントをまとめます。このトークでは、GuardDuty がどのように実世界の攻撃に関する情報を収集し、それを使用して検出を優先順位付けし、脅威検出を実装するのか、そして現実的な攻撃シナリオを使用して GuardDuty のランタイムモニタリングをテストする方法について学びました。Amazon GuardDuty Findings Tester の GitHub リポジトリに複数の現実的なシナリオを追加しました。このリポジトリには、この QR コードからアクセスできます。今後も引き続きシナリオを追加していく予定です。このトークにご参加いただき、ありがとうございました。
※ こちらの記事は Amazon Bedrock を利用し、元動画の情報をできる限り維持しつつ自動で作成しています。
Discussion