皆さま、こんにちは。 Weekly AWSでは、毎週 AWS プロダクトのアップデート情報をお届けしています。 それでは、先週 (10月5日～11日) の主な AWS アップデート情報を紹介します。 今週の注目アップデート Amazon Bedrock で TwelveLabs Pegasus 1.5 の提供を開始 Amazon Bedrock で TwelveLabs Pegasus 1.5 が利用可能になりました。これは、動画から構造化されたタイムコード付きのメタデータを生成する video-to-text モデルです。 Pegasus 1.5 は動画全体を読み取り、何がい

本ブログは 2026 年 10 月 12 日に公開された AWS Blog “ GuardDuty Extended Threat Detection has added five new indicators to surface attack sequences ” を翻訳したものです。 Amazon GuardDuty 拡張脅威検出 は、弱い GuardDuty シグナルの組み合わせが信頼性のしきい値を超えると、それらを相関付けて、重要度が Critical の単一の攻撃シーケンスの検出結果にまとめます。2026 年 5 月 20 日から、攻撃シーケンスに 5 種類の新しいインジケーター ( MALICIOUS_PACKAGE 、 MISCONFIGURATION 、 REACHABILITY 、 SENSITIVE_DATA 、 VULNERABILITY ) が付与されるようになりました。詳細については、「 Document history for Amazon GuardDuty 」および「 Attack sequence finding details 」を参照してください。 これらのインジケーターの情報源は、 Amazon Inspector 、 Amazon Virtual Private Cloud (Amazon VPC) Reachability Analyzer 、 Amazon Macie 、そして AWS Security Hub を通じて提供されるポスチャデータです。これらのサービスを既に別の目的で利用しているお客様もいるでしょう。今回のアップデートにより、拡張脅威検出はこれらのサービスのシグナルを攻撃シーケンスの検出結果に取り込むようになりました。この記事は、前提条件となるサービスを既に利用しているチーム向けの運用ガイドです。新しいインジケーターが検出結果にどのように表示されるか、リリース後のデータから何がわかるか、そしてインシデント対応ワークフローにどう組み込むかについて説明します。これらのインジケーターにより、拡張脅威検出はアカウント内で最も優先すべきシグナルを判断しやすくなります。その結果、 Amazon Elastic Compute Cloud (Amazon EC2) 、 Amazon Elastic Container Service (Amazon ECS) 、 Amazon Elastic Kubernetes Service (Amazon EKS) のランタイムアクティビティをモニタリングするアクティブディフェンス戦略の一環として、ワークロード領域でより信頼度の高い検出結果が得られます。 新しいインジケーターの概要 GuardDuty におけるシグナルとは、GuardDuty が不審なアクティビティを探す際に評価するあらゆるイベントを指します。弱いシグナルとは、それ単体では脅威を明確に示さないシグナルのことで、5 つの新しいインジケーターはこれに該当します。例えば、ホスト上で Common Vulnerabilities and Exposures (CVE) が 1 件検出されたとしても、それは脆弱性が存在することを示すだけで、攻撃者がその脆弱性を悪用していることを示すわけではありません。次の表に示すように、これらの検出結果は、GuardDuty が既に追跡している不審なアクティビティのシグナルと相関付けられることで、初めて価値を発揮します。 インジケーター ソース 示される内容 VULNERABILITY Amazon Inspector Common Vulnerability Scoring System (CVSS) の重要度と Exploit Prediction Scoring System (EPSS) の悪用可能性スコアを含む CVE のリスト。 MALICIOUS_PACKAGE Amazon Inspector Amazon Inspector の MAL-* パッケージインジケーター。Amazon Inspector による脆弱性のスコアリング方法の詳細については、「 Amazon Inspector Security Research 」を参照してください。 REACHABILITY Amazon VPC Reachability Analyzer ホストまたはクラスターがインターネットから到達可能かどうか MISCONFIGURATION AWS Security Hub のコントロール (ポスチャ管理) リソースの設定が、AWS または 業界のベストプラクティス に沿っていないこと。例えば、IMDSv1 が有効なままになっている、管理者ポリシーの権限が過剰である、パブリックにアクセス可能な Amazon Simple Storage Service (Amazon S3) バケットがある、などです。 SENSITIVE_DATA Amazon Macie リソース内で機密データと思われる情報が検出されたこと。 これら 5 つの値は、GuardDuty の AWS マネジメントコンソールで攻撃シーケンスの検出結果を開いたときの [インジケーター] タブと、 GetFindings の JSON ファイルに表示されます。 図 1: 攻撃シーケンスの検出結果の [インジケーター] セクション VULNERABILITY インジケーターには EPSS が含まれるため、ここで EPSS について補足しておきます。「 FIRST EPSS overview 」によると、EPSS スコアは、公開済みの CVE が今後 30 日以内に実際の環境で悪用される確率を 0～1 の範囲で表したものです。EPSS は CVSS を置き換えるものではありません。CVSS が脆弱性本来の重要度を表すのに対し、EPSS は近いうちに悪用される可能性の高さを表すため、インシデント対応ではより役立つ数値となります。 前提条件 インジケーターにデータを反映させるには、次の AWS サービスを有効にしておく必要があります。 Amazon Inspector (Amazon EC2 および Amazon EKS で有効化): VULNERABILITY と MALICIOUS_PACKAGE に対応します。 AWS Security Hub : AWS Foundational Security Best Practices に基づいて MISCONFIGURATION を提供します。 Amazon VPC Reachability Analyzer (本番環境の VPC で有効化): REACHABILITY に対応します。 GuardDuty Runtime Monitoring (Amazon EC2、Amazon ECS、Amazon EKS で有効化): 生成されるすべてのシグナルが、相関付けの起点 (アンカー) になり得ます。 Amazon Macie : SENSITIVE_DATA を提供します。 弱いランタイムシグナルの強化 プロセスの呼び出し、ポッドでの exec、システムコールのパターンなどのランタイムシグナルは、ノイズが多くなることがあります。既知の攻撃ツールのパスに一致しないランタイムシグナルは単体では重要な意味を持たず、リソース状態のコンテキストがなければ、通常は重要度が Critical の攻撃シーケンスとなるしきい値に達しません。 新しいインジケーターは、この欠けていたコンテキストを補います。弱いランタイムシグナルが観測されたホストに、優先度の高いパッチ未適用の CVE、既知の悪意のあるパッケージ、IMDS の設定ミス、インターネットからの到達可能性が併存する場合、拡張脅威検出はそれらをまとめて、高い信頼度で重要度が CRITICAL の単一の攻撃シーケンスに昇格させます。個々の GuardDuty ランタイム検出結果については、ノイズの多さが大きな課題であるというフィードバックをお客様から一貫していただいてきました。このリソース状態のコンテキストを加えることで、弱いシグナルが対応可能なアラートへと変わります。 実際に、ランタイムプロセス領域では新規の攻撃シーケンスの検出結果が大幅に増加し、優先順位付けされたランタイムプロセスの攻撃シーケンスのおよそ 4 件に 1 件を占めるまでになりました。一方、ネットワークベースの侵害の痕跡 (IOC) 領域ではほとんど変化はありませんでした。リリース後 1 週間で、このパターンは多くのお客様のアカウントで確認されています。従来は弱く相互に関連のない複数の検出結果としてばらばらに表示されていた攻撃シーケンスが、重要度が CRITICAL の単一の検出結果として表示されるようになったのです。 例: Amazon EKS で新規に検出された攻撃シーケンス 追加のインジケーターによって拡張脅威検出がどのように改善されたかを説明したところで、これらのインジケーターがどのような価値をもたらすかを具体的な例で見ていきましょう。ここでは、Amazon EKS クラスターで実際に観測されたシナリオを分析します。このアクティビティは 8 日間にわたって発生し、11 件の異なる GuardDuty の検出結果が生成されました。 図 2: 拡張脅威検出がシグナルを相関付ける前の EKS クラスターのアクティビティの概要 図 2 に示すように、GuardDuty が 8 日間にアクティビティ領域で観測したのは、55 件の EKS_AUDIT_LOGS シグナル (ポッドでの exec、ロールの引き受け、 AssumeRoleWithWebIdentity の呼び出し) と、18 件の検出結果レベルのシグナルでした。これらはすべて、198.51.100.69 という単一の外部 IP アドレスから発生していました。この IP アドレスから、同じ EKS クラスターに対して 4 つの異なる AWS Identity and Access Management (IAM) アイデンティティによる認証が行われていました。ワーカーノード上のランタイムアクティビティは、既知の攻撃ツールのパスに一致するプロセスがなく、実行プロファイルのフラグも立たなかったため、ありふれたものに見えました。リリース前の相関ロジックでは、このシーケンスを検出するには EKS_MALICIOUS_PROCESS ルールが発動する必要がありました。このルールの発動には、悪意のある exec パスか、異常で疑わしいツールのプロファイルのいずれかが必要です。今回のアクティビティにはどちらも該当しなかったため、相関付けられた攻撃シーケンスの検出結果は生成されませんでした。 新しい GuardDuty 拡張脅威検出のインジケーターによって、この EKS の例に追加された情報は次のとおりです。 MALICIOUS_PACKAGE (クラスター上): Amazon Inspector の識別子 MAL-2022-4933 が検出されています。 VULNERABILITY (Amazon Inspector の全出力、クラスター上): 合計 42 件の CVE があり、そのうち 33 件が CVSS で CRITICAL と評価されています。 クラスター上: CVE-2022-1471 (SnakeYAML のデシリアライゼーション、EPSS 0.94)、CVE-2024-4577 (PHP-CGI の引数インジェクション、EPSS 0.97)、CVE-2024-34351 (Next.js の SSRF)、CVE-2025-29927 (Next.js の認証バイパス)、CVE-2023-44487 (HTTP/2 Rapid Reset)、CVE-2022-37434 (zlib のヒープオーバーフロー、EPSS 0.92) を含む 12 件の CVE があります。 5 つのワーカーノード全体: 合計 379 件の CVE があり、そのうち 68 件が Amazon Inspector によって CRITICAL と判定されています。 REACHABILITY : クラスターの API エンドポイントがインターネットから到達可能で、5 つのワーカーノードのうち 3 つもインターネットから到達可能です。 MISCONFIGURATION (EC2 IMDS): 5 つのワーカーノードすべてで、引き続き IMDSv1 にアクセスできる状態になっています。 これらの追加インジケーターを考慮すると、この一連のアクティビティは単一の AttackSequence:EKS/CompromisedCluster の検出結果として表示されます。重要度は CRITICAL で、データが反映された 4 つのインジケーターすべてが [インジケーター] タブに表示されます。また、 MITRE ATT&CK® の Initial Access (External Remote Services)、Discovery、Persistence へのマッピングも示されます。 図 3: 攻撃シーケンス内の新しい脆弱性インジケーター この検出結果には、ワーカーノードレベルで 100 件を超える Amazon EC2 の CVE が記載されています。CVSS が CRITICAL のものが 1 件、 HIGH のものも多数ありますが、EPSS スコアが低いため、ほとんどは脆弱性の優先度が LOW です。GuardDuty が優先度の高いものを強調表示するため、100 件を超える検出結果を精査してどれから対処すべきかを判断する必要はなく、最も効果の高い箇所に対応作業を集中できます。 例: 暗号資産マイニングと脆弱なホスト 2 つ目の例では、EC2 インスタンスグループのケースを取り上げます。このケースでは、GuardDuty は暗号資産マイニングを示す有力なネットワークベースの検出結果を既に得ていましたが、新しいインジケーターが修復に役立つ追加のコンテキストを提供したことで、インシデント対応を迅速化できました。 図 4: EC2 インスタンスに対する暗号資産マイニング攻撃 複数の EC2 インスタンスが既知の暗号資産マイニングの宛先と通信しており、この宛先は脅威インテリジェンスによって mining/misc としてフラグ付けされていました。ネットワーク IOC の証拠は、それ単体でも十分に強力なものでした。 新しいインジケーターによって追加された観測内容 : VULNERABILITY により、関与した 3 つのインスタンスのうち 2 つで、EPSS が約 0.9 の CVE-2007-4559 (Python tarfile) が示されました。 結果 : AttackSequence:EC2/CompromisedInstanceGroup の検出結果を基に、「 宛先 IP のブロック 」にとどまらない対応が可能になりました。暗号資産マイニングツールが侵入に悪用したと考えられる脆弱性と、それを修復するパッチが示されるため、アウトバウンド接続を遮断するだけでなく、根本的な侵入経路に対処できます。 GuardDuty は EC2 インスタンスグループで暗号資産マイニングが行われている強力な証拠を得ていたため、この攻撃シーケンス自体は脆弱性のコンテキストがなくても生成されていたはずです。ただし、コンテキストが増えることで、トリアージを迅速に行えます。 リリース後 1 週間のサンプルで観測された侵害の痕跡 次の CVE (EPSS スコアは観測当時の値) は、リリース後の最初の 1 週間に新しい拡張脅威検出のインジケーターが付与されたお客様のアカウントのホストで、各インジケーターの検出結果が生成された時点で観測されたものです。EPSS スコアは特定時点の値であるため、今後の検出結果に表示される CVE の優先度は、ここに示す値ではなく、その時点の EPSS に基づきます。 CVE-2024-4577 – Windows 上の PHP-CGI の引数インジェクション。EPSS 0.97 以上。 CVE-2022-1471 – SnakeYAML のデシリアライゼーション。EPSS 0.94。CVSS は Critical。 CVE-2022-37434 – zlib のヒープバッファオーバーフロー。EPSS 0.92。 CVE-2007-4559 – Python tarfile のパストラバーサル。2026 年時点でも EPSS は 0.9 以上。 CVE-2025-29927 – Next.js の認証バイパス。Node ベースのウェブ層で頻繁に検出。 CVE-2024-34351 – Next.js の SSRF。 CVE-2023-44487 – HTTP/2 Rapid Reset。 ランタイムモニタリングでは、侵害されたホストから回収されたマルウェアやツールのアーティファクトに関連する弱いシグナルが検出されました。 HackTool ファミリーの Linux/frp : Fast Reverse Proxy の亜種で、コマンドアンドコントロールトンネルとして使用されていました。Amazon EKS ワーカーノード上では、多くの場合 kuboard-agent や kuboard-agent-server というバイナリに偽装されていました。また、 /var/lib/containerd/io.containerd.snapshotter.v1.overlayfs/snapshots/.../usr/bin/ 配下で、コンテナスナップショットのパスとの一致も観測されました。frp バイナリはコンテナイメージ内とノード上の両方に存在するため、パッチが適用されていない AMI からノードを再構築するだけでは修復として不十分です。 Burp Collaborator のアウトオブバンドのコールバックホスト名が *[.]oastify[.]com 配下で見つかり、パターン <35-char base32>[.]oastify[.]com に一致していました。これらは同じ EKS シーケンス上で frp と同時に観測されており、共有インフラストラクチャ上で 2 つ目のツールまたは別のアクターが活動していた可能性が高いと考えられます。 Amazon Inspector の悪意のあるパッケージインジケーター MAL-2022-4933 が、Amazon EC2 と Amazon EKS の両方のコンテキストで検出されました。 上記のツール関連のシグナルと相関していたアイデンティティとアクセスのパターンは次のとおりです。 単一の外部送信元 IP から、短期間のうちに Amazon EKS、Amazon ECS、Amazon EC2 の別々の領域にまたがって、人間が使用する複数の異なる IAM アイデンティティによる認証が行われていました。これは、新規に検出されるようになった Amazon EKS プロセス関連のクラスで最も多く見られたアイデンティティのシグネチャです。 これらのインジケーターを活用した攻撃シーケンスへの対応 新しいインジケーターによって、既に発生した攻撃シーケンスに対するインシデント対応のランブックが変わるわけではありません。新しいインジケーターが意味を持つのは新規の検出結果であり、それらの検出結果は、ランタイムモニタリング関連のシグナルが強化された領域に集中しています。新規の検出結果には、次のように対応してください。 シーケンスに緊急に対応してください 。 MALICIOUS_PACKAGE と優先度の高い VULNERABILITY が示されている場合、そのホストは侵害されるリスクにさらされてきただけでなく、現在もさらされています。露出しているリソースを封じ込め、脆弱性を修復してください。また、攻撃者にさらされた可能性があるすべての IAM 認証情報、 インスタンスプロファイル 、 IAM Roles for Service Accounts (IRSA) にバインドされたロール をローテーションしてください。 EPSS で重み付けした優先度に基づいてパッチを適用してください 。CVSS の値だけで判断しないでください。検出結果に含まれる優先度の高い VULNERABILITY リストは、既に EPSS の高い CVE に絞り込まれています。 パブリックなリソースを隔離してください 。 REACHABILITY インジケーターで示されたリソースが対象です。悪用可能な脆弱性があり、インターネットから到達可能なホストは、修復のために隔離する必要があります。 さらに詳しい対応方法については、「 Remediating detected GuardDuty security findings 」の修復手順と、GuardDuty の検出結果とアカウントを AI で分析するセキュリティ分析機能である GuardDuty Investigation を参照してください。 まとめ GuardDuty 拡張脅威検出は、セキュリティチームが特に支援を必要とすることが多いランタイムワークロード領域 (Amazon EC2、Amazon ECS、Amazon EKS) で、信頼度の高い攻撃シーケンスの検出結果をより多く提供できます。これは、GuardDuty のアクティビティシグナルと、他の AWS サービスから得られるリソース状態のコンテキストを組み合わせることで実現しています。個々の GuardDuty ランタイム検出結果については、ノイズの多さが大きな課題であるというフィードバックをお客様から一貫していただいてきました。拡張脅威検出は、こうした弱いシグナルを脆弱性、パッケージリスク、到達可能性、設定ミス、機密データの各インジケーターと相関付けることで、ノイズを、重要度が CRITICAL の対応可能な検出結果に変えます。AWS Security Hub、Amazon Inspector、Amazon VPC Reachability Analyzer、Macie、GuardDuty Runtime Monitoring を既に有効にしている場合、新しいインジケーターは攻撃シーケンスの検出結果に自動的に表示されます。これらのサービスをまだ使用していない場合は、新しい GuardDuty 拡張脅威検出のインジケーターと、各サービス自体が提供する価値を活用するために、ぜひ有効化をご検討ください。 この記事に関する質問がある場合は、 AWS re:Post で新しいスレッドを開始するか、 AWS サポートにお問い合わせください 。 Aman Khare Aman は Amazon GuardDuty のシニアソフトウェア開発者です。 拡張脅威検出 の開発に携わり、AWS インフラストラクチャで検出された悪意のある攻撃チェーンをお客様が正確に特定できるよう支援しています。以前は Amazon OpenSearch のパフォーマンスとレジリエンシーに関する取り組みを主導し、クラスターマネージャーのメモリ使用量の 10 分の 1 への削減や、1,000 ノード規模のクラスターの実現などを達成しました。仕事以外では、旅行、アドベンチャーアクティビティ、読書、ボードゲームを楽しんでいます。 Kyle Koeller Kyle は Amazon GuardDuty チームのセキュリティエンジニアで、脅威検出を専門としています。クラウドの脅威検出とオフェンシブセキュリティに情熱を注いでおり、CompTIA Security+、PenTest+、CompTIA Network Vulnerability Assessment Professional、SecurityX の資格を保有しています。仕事以外では、ジムで過ごしたり、ニューヨーク市を散策したりすることを楽しんでいます。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

はじめに 先日、社内で AI Coding Agent Hackathon というイベントを開催いたしました。本記事では、そのイベントの様子を紹介します。 目的 RevComm には「AI活用推進室 (AI Promotion Office)」という組織があります。AI活用推進室における活動の一環として、「AI Coding Agents Optimization Guide」というガイドラインを策定しています。このガイドラインは、AI コーディングエージェントの価値を最大化するために、各チームが段階的に AI コーディングエージェントの活用を進めていけるような指針を定めています。具体的には、まず AGENTS.md の導入などから始め、最終的にはサブエージェントやスキル、MCP などの活用やコスト削減のための方法論などの応用的な活用法を段階的に取り入れていくためのプラクティスを整備しています。 この AI Coding Agents Optimization Guide を実践を通じて組織的に学ぶ場として、ハッカソンを開催しました。 実施したこと 概要 開催時間: 3 時間 使用した AI コーディングエージェント: Claude Code または Codex 題材 今回のハッカソンではタイピングゲームの開発を題材としました。普段、フロントエンド開発に携わっているメンバーも参加しやすいよう、ランタイムとしては Node.js を選定しました。 当日の進行をスムーズにするために、あらかじめテンプレートリポジトリを整備しました。各参加者はこのテンプレートをベースにリポジトリを作成することで、すぐに開発に取り掛かることができます。 メトリクスの収集・可視化 各種メトリクスを収集・可視化することでトークン使用量などのコストを意識して課題に取り組めるようにするために、ダッシュボードを作成しました。このダッシュボードは Claude Code や Codex などのコーディングエージェントを OpenTelemetry を介して Datadog と連携させることによって実現されています。テンプレートリポジトリの Markdown ドキュメントに Datadog と各種コーディングエージェントの連携方法を記載しておき、スムーズにセットアップできるようにしました。 Datadog によるメトリクスの可視化 課題の着手 テンプレートリポジトリには、取り組むべきタスクを詳細に記載した Markdown ドキュメントが含まれています。 タスクの一覧 各タスクには priority が設定されており、それに応じて最終的な採点結果が加算されます。 タスクの例 成果発表 最後に成果発表を実施しました。各自で取り組んだ内容や工夫したことに加えて、普段の開発環境やコーディングエージェントの活用方法についての共有も実施しました。 成果発表の様子 スコアと分析結果の共有 各メンバーのスコアの採点と全体的な分析結果の共有を実施しました。スコアは runn と Playwright を活用して、自動で採点できる仕組みを構築しました。また、ハッカソンに参加いただいた各メンバーが今後、より効果的に AI コーディングエージェントを活用できるようにするため、Datadog で収集したコスト情報とスコアのプロットや、Datadog で収集した情報から判明した良い活用法などについても全体で共有しました。 フィードバック まとめ 成果発表の場を通して、参加者の方々がさまざまな工夫や活用法などを実践されていることがわかりました。 Git worktree や herdr / cmux などを活用してセッションを並列実行することで、タスクをより効率的にこなす。 claude-code-orchestra を活用したマルチエージェントのオーケストレーション /grill-me スキルの活用 自分自身、まだ試したことのないコーディングエージェントの活用法などを知ることもできたため、今後、実践していきたいです。 今回のように、普段の業務と異なる題材で気軽に試せる場を設けることで、組織全体として AI コーディングエージェントの知見を共有する機会になったと感じています。今後もこのような取り組みを通じて、より実践的な AI 活用を進めていきます。