【AWS中級へのステップ】 慌てないで！GuardDutyで検出結果が発生した際の調査ステップ
はじめに
猫とアポロチョコが好きな m.hayakawaです。
本記事は、AWS サービスの基本設計や運用方法には慣れてきたものの、「この構成で問題ないのか」「より良い設計方法はないのか」「問題が発生したときの対処方法は何か」といった実務的な課題に直面している方向けの内容となります。
AWS 初学者が中級者へとステップアップするために押さえておきたい実践的な知識や TIPS のひとつを紹介し、初学者の方が知識をより深めるため、またベテランの方が知識を再確認するための一助となることを目指しています。
そもそもGuardDutyって何してるの？
Amazon GuardDuty は、AWS 環境における脅威検出サービスです。
以下のデータソースを継続的に監視・分析しています。
- AWS CloudTrail 管理イベント
- VPC フローログ
- DNS ログ
これらのデータソースに対して、脅威インテリジェンスフィード（悪意のある IP アドレスやドメインのリストなど）や機械学習（ML）モデルを使用して、不審なアクティビティを検出します。
GuardDuty を有効化するだけで、上記のデータソースの分析が自動的に開始されます。
検出結果って何？
GuardDuty が不審なアクティビティを検出すると、「検出結果（Finding）」が生成されます。検出結果は、潜在的なセキュリティ上の問題を通知するものです。
検出結果タイプは、以下のフォーマットで命名されています。
ThreatPurpose:ResourceTypeAffected/ThreatFamilyName.DetectionMechanism!Artifact
| 要素 | 説明 |
|---|---|
| ThreatPurpose | 脅威の目的や攻撃のステージ（例: Backdoor, Exfiltration, UnauthorizedAccess） |
| ResourceTypeAffected | 対象となる AWS リソースタイプ（例: EC2, S3, IAMUser） |
| ThreatFamilyName | 検出された脅威の種類（例: C&CActivity, AnomalousBehavior） |
| DetectionMechanism | 検出メカニズム（例: .Custom, .Reputation）※省略される場合あり |
| Artifact | 使用されたツールに関連するリソース（例: !DNS）※省略される場合あり |
例えば Backdoor:EC2/C&CActivity.B!DNS であれば、「EC2 インスタンスが、既知の C&C サーバーに関連するドメインに DNS クエリを送信している」ということが、タイプ名から読み取れます。
検出結果には重大度（Severity）が設定されており、Critical / High / Medium / Low の4段階があります。重大度が高いほど、緊急性の高い対応が求められます。
検出結果の詳細調査方法の例
まず、検出された時はタイトルをクリックして、結果の詳細を確認しましょう。
また、下記のスクリーンショットの赤枠をクリックすると JSON が出ます。
これらの情報を元に、各検出結果で何が起こっているかを調査、判断できます。
検出結果タイプによって調査方法に違いがあります。いくつか例示をします。
※以降は英語版のコンソールの表記を例とします。
DefenseEvasion:EC2/UnusualDNSResolver
この検出結果は、EC2 インスタンスが、通常使用される Amazon 提供の DNS リゾルバーではなく、外部のパブリック DNS リゾルバーと通信している場合に検出されます。重大度は Medium です。
攻撃者が DNS トラフィックの監視を回避するために、外部の DNS リゾルバーを使用するケースがあります。一方で、Cisco Umbrella（OpenDNS）や Google Public DNS などを意図的に使用している場合もあるため、調査によって正当性を判断する必要があります。
では、この検出結果が出た場合の調査ステップを見ていきましょう。
ステップ 1: 対象の EC2 インスタンスを特定する
検出結果の Overview セクションから、対象の EC2 インスタンス ID を確認します。
ステップ 2: 通信先の IP アドレスを確認する
検出結果の Target セクションにある IP address V4 を確認します。これが、EC2 インスタンスが通信しているパブリック DNS リゾルバーの IP アドレスです。
ステップ 3: whois コマンドで通信先を調査する
確認した IP アドレスの所有者を whois コマンドで調べます。
例えば、IP address V4 に 208.67.220.220 が記録されていた場合、以下のように調査します。
$ whois 208.67.220.220
実行結果の OrgName や NetName を確認します。この例では以下の情報が得られます。
NetName: OPENDNS-NET-1
OrgName: Cisco OpenDNS, LLC
これにより、Cisco が提供しているパブリック DNS サーバー（OpenDNS）であることが分かります。
代表的なパブリック DNS リゾルバーの IP アドレスは以下の通りです。
| サービス名 | IP アドレス |
|---|---|
| Google Public DNS | 8.8.8.8, 8.8.4.4 |
| Cloudflare DNS | 1.1.1.1, 1.0.0.1 |
| Cisco OpenDNS | 208.67.222.222, 208.67.220.220 |
ステップ 4: EC2 インスタンスの DNS 設定を確認する
対象の EC2 インスタンスにログインし、DNS の設定を確認します。
$ cat /etc/resolv.conf
VPC の DHCP オプションセットで DNS サーバーがカスタム設定されている場合もあるため、マネジメントコンソールから VPC の DHCP オプションセットも確認します。
ステップ 5: 対応を判断する
調査の結果、意図的に外部 DNS リゾルバーを使用している場合は問題ありません。抑制ルールを設定して、同様の検出結果を非表示にすることもできます。
意図しない設定であった場合は、以下の対応を検討します。
- EC2 インスタンスの
/etc/resolv.confや DHCP オプションセットの設定を修正し、Amazon 提供の DNS リゾルバーを使用するように戻す - EC2 インスタンスが侵害されていないか調査する（不審なプロセス、不正な設定変更の痕跡など）
Exfiltration:S3/AnomalousBehavior
この検出結果は、IAM エンティティが S3 バケットに対して、通常とは異なる方法で API を呼び出した場合に検出されます。データの持ち出し（Exfiltration）に関連する API 呼び出しが、確立されたベースラインから逸脱していることを示しています。重大度は High です。
GuardDuty の機械学習モデルが、リクエストを行ったユーザー、リクエスト元の場所、リクエストされた API、対象のバケット、API 呼び出しの回数などを追跡し、異常と判断した場合に生成されます。
では、この検出結果が出た場合の調査ステップを見ていきましょう。
ステップ 1: 対象の S3 バケットを特定する
検出結果の Overview セクションから、対象の S3 バケット名と ARN を確認します。
ステップ 2: 誰が操作したかを特定する
以下の情報を確認します。
Principal ID（IAM ユーザーまたはロール）API（呼び出された API 名。例:GetObject,CopyObjectなど）Caller typeやIP addresses（リクエスト元の IP アドレス）
Access key ID が AKIA で始まる場合は IAM ユーザーの長期認証情報、ASIA で始まる場合は STS による一時認証情報です。
ステップ 3: 異常な API 呼び出しの内容を確認する
検出結果の Additional information セクションにある Anomalous APIs を確認します。ここに、通常とは異なると判断された API 呼び出しの一覧が記載されています。
例えば、普段 GetObject を呼び出していない IAM ユーザーが大量に GetObject を実行していた場合、データの持ち出しが疑われます。
ステップ 4: CloudTrail で詳細を調査する
CloudTrail のイベント履歴で、該当の IAM エンティティが実行した S3 関連の API 呼び出しを確認します。
- 対象のバケットに対してどのような操作が行われたか
- リクエスト元の IP アドレスは既知のものか
なお、CloudTrail コンソールではデータイベントの確認はできません。もし、データイベントを取得している場合はそれも調査対象に含めます。
ステップ 5: 対応を判断する
調査の結果、意図した操作であれば問題ありません。後述の抑制ルールを検討しましょう。
意図しない操作であった場合は、以下の対応を検討します。
- 該当 IAM エンティティの認証情報をローテーション（または無効化）する
- S3 バケットのアクセス許可を見直す
UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration.OutsideAWS
この検出結果は、EC2 インスタンスのインスタンスメタデータから取得された一時認証情報が、AWS 外部の IP アドレスから使用された場合に検出されます。重大度は High です。
EC2 インスタンスに付与された IAM ロールの一時認証情報が外部に持ち出され、AWS 外から API 呼び出しに使用されている可能性を示しています。
では、この検出結果が出た場合の調査ステップを見ていきましょう。
ステップ 1: 対象の EC2 インスタンスを特定する
検出結果の Overview セクションから、認証情報の発行元となった EC2 インスタンス ID を確認します。
ステップ 2: 外部 IP アドレスを確認する
検出結果の Actor セクションにある IP address V4 を確認します。この IP アドレスが、AWS 外部から認証情報を使用したリクエスト元です。
ステップ 3: 正当なアクセスかどうかを判断する
以下のケースでは、意図的なアクセスである可能性があります。
- AWS Outposts を使用している場合
- VPN 接続を経由してインターネットトラフィックがオンプレミスのゲートウェイから出ている場合
これらの構成では、EC2 インスタンスの認証情報を使用した API 呼び出しが、AWS 外部の IP アドレスから行われているように見えることがあります。
ステップ 4: 対応を判断する
正当なアクセスであった場合、また、今後同様の事象が発生しうる場合は、後述の抑制ルールを検討しましょう。
不正なアクセスが疑われる場合は、以下の対応を検討します。
- 該当 EC2 インスタンスの IAM ロールに付与されている権限を確認し、最小権限の原則に従っているか見直す
- 該当 EC2 インスタンスが侵害されていないか調査する（不審なプロセス、不正なソフトウェアのインストールなど）
- 必要に応じて、該当 IAM ロールの一時認証情報を無効化する（ロールのアクセス許可ポリシーに条件を追加して、特定の時刻以前に発行されたセッションを拒否する）
Backdoor:EC2/C&CActivity.B!DNS
この検出結果は、EC2 インスタンスが、既知のコマンド＆コントロール（C&C）サーバーに関連するドメインに DNS クエリを送信している場合に検出されます。重大度は High です。
C&C サーバーとは、ボットネットのメンバーにコマンドを発行するコンピューターです。EC2 インスタンスが C&C サーバーと通信しているということは、マルウェアに感染し、外部から制御されている可能性を示しています。
では、この検出結果が出た場合の調査ステップを見ていきましょう。
ステップ 1: 対象の EC2 インスタンスを特定する
検出結果の Overview セクションから、対象の EC2 インスタンス ID を確認します。
ステップ 2: クエリ先のドメインを確認する
検出結果の Actor セクションにある Domain の Domain name を確認します。これが、C&C サーバーに関連すると判断されたドメインです。
ステップ 3: ドメインの情報を調査する
確認したドメインについて、以下の方法で調査します。
$ nslookup <ドメイン名>
$ whois <解決された IP アドレス>
ドメインの所有者や、関連する組織の情報を確認します。
また、VirusTotalなどの脅威インテリジェンスサービスでドメインを検索し、悪意のあるドメインとして報告されているかを確認することも有効です。
ステップ 4: EC2 インスタンスの状態を確認する
対象の EC2 インスタンスにログインし、以下を確認します。
- 不審なプロセスが実行されていないか（
ps auxやtopコマンドで確認） - 不審なネットワーク接続が確立されていないか（
netstat -tlnpやss -tlnpコマンドで確認） - 不審な cron ジョブが登録されていないか
- 不審なファイルが作成されていないか
ステップ 5: VPC フローログを確認する
VPC フローログを取得している場合は、対象の EC2 インスタンスから C&C サーバーの IP アドレスへの通信が継続的に行われているかを確認します。
ステップ 6: 対応を判断する
C&C サーバーとの通信が確認された場合、EC2 インスタンスが侵害されている可能性が高いです。以下の対応を検討します。
- 該当 EC2 インスタンスをネットワークから隔離する（セキュリティグループのインバウンド・アウトバウンドルールを制限する）
- フォレンジック調査のために、EBS ボリュームのスナップショットを取得する
- 侵害の原因を特定した上で、クリーンな AMI から新しいインスタンスを起動する
下記のドキュメントも参考となると考えられます。
誤検知や意図通りであった場合の抑制方法
各検出結果を調査の上、誤検知と判断、または、意図通りと判断できる場合は、検出結果の抑制を検討します。
マネジメントコンソールから抑制ルールの作成の際は、下記のステップを実施します。
検出結果画面でフィルタリングする
今回は例として、UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration.OutsideAWS を抑制ルールとして追加します。
まずは、Filter findings の欄で Finding type を選択、Equals(=) を選択し、UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration.OutsideAWSを入力します。
IP address V4 の部分が既知の IP アドレス（例：VPN 接続を経由してインターネットトラフィックがオンプレミスのゲートウェイから出ている場合における既知のパブリック IP）であった場合、この条件を抑制するため、虫眼鏡マーク（＋）を押下します。
その後、Create suppression ruleボタンを押下します。
抑制ルールを調整する
抑制ルールの作成画面に遷移します。ここでは抑制ルールの条件をさらに追加することができます。すべての設定が完了したらCreate suppression ruleボタンを押下します。
作成後の編集は、左ペインからSuppression rulesを選択し、抑制ルールのリストから抑制ルールを選択し、Action -> Update supression ruleを押下することで、編集できます。
テストってできる？
マネジメントコンソールから、検出結果のサンプルを出力することができます。
ただし、コンソール上から検出結果のサンプルを生成すると大量の検出結果が出てしまうので、特定の検出結果だけ出したいときは、AWS CLI を使用すると良いでしょう。
最後に
セキュリティに関する警告を受けることで、焦ってしまう気持ちはあると思いますが、まずは冷静になって状況を把握して、緊急性があるかどうかを判断できるようになることが肝要です。
彼を知り己を知れば百戦殆からず
調査ステップを把握することで、GuardDuty とうまく付き合っていきましょう。
参考資料
ぎりぎり20分で話しきる Amazon GuardDuty による脅威検知 - ISV Dive Deep セミナー
クラスメソッドオペレーションズ株式会社について
クラスメソッドグループのオペレーション企業です。
運用・保守開発・サポート・情シス・バックオフィスの専門チームが、IT・AI をフル活用した「しくみ」を通じて、お客様の業務代行から課題解決や高付加価値サービスまでを提供するエキスパート集団です。
当社は様々な職種でメンバーを募集しています。
「オペレーション・エクセレンス」と「らしく働く、らしく生きる」を共に実現するカルチャー・しくみ・働き方にご興味がある方は、クラスメソッドオペレーションズ株式会社 コーポレートサイト をぜひご覧ください。※2026 年 1 月 アノテーション㈱から社名変更しました
