オープンソースツールでAWSインシデント対応プレイブックを構築する

AWSインシデント対応のためのオープンソースMCPサーバー

以下の調査手順を通じて、AWS-IReveal-MCPを含む、インシデント対応向けの複数のオープンソースツールに言及します。これはSysdig Threat Research Teamが開発したMCPサーバーで、前述のAWSサービスと統合します。不審なアクティビティの分析中に支援してくれるアシスタントだと考えるとよいでしょう。また、調査で得られた発見に基づいて是正策も提案します。

‍

AWS CloudTrail

AWSアカウントに問題があったのではないかと懸念している場合、何が起きたのかの見当をつけるために最初に確認する場所は、おそらくAWS CloudTrailでしょう。

トレイルを作成すると、デフォルトでは管理イベントのみのログが有効になり、データイベント、ネットワークアクティビティイベント、Insightsは有効になりません。これらは追加コストで有効化できます。

• データイベントは、リソースレベルで発生するデータプレーン操作です。たとえば、S3バケット内のファイルに対するアップロード、ダウンロード、削除などの操作はデータイベントです。AWSサービスごとのデータイベントの一覧はこちらです。データイベントが有効化されていないサービスがインシデントの影響を受けた場合、適切に調査するのが難しくなる可能性があります。
• ネットワークアクティビティイベントは、VPC内で実行される管理プレーンおよびデータプレーン操作の可視性を提供します。これらのイベントは特定のサービスでサポートされています。高度なイベントセレクターを設定することで、有効化するサービスを選択できます。eventName、errorCode、vpcEndpointIdの任意のイベントセレクターを指定し、特定のシナリオのみをログに記録することも可能です。たとえばVPCエンドポイントを使用している場合、VPCエンドポイントポリシー違反によりエラーVpceAccessDeniedとなったネットワークアクティビティをログに残したいことがあります。サポート対象サービスの一覧と、高度なイベントセレクター設定例はこちらです。
• Insightsは、APIコール量やエラー率に基づく異常な挙動の指標です。Insightsは、アカウントの通常の利用パターンと比べて大きな差異を強調してくれるため有用です。

メンバーアカウントごとに1本のトレイルを作るのではなく、組織トレイルを設定するのが良いプラクティスです。どのリージョンのイベントも取りこぼしたくないため、トレイルはマルチリージョンにすべきです。また、S3バケットに保存されるトレイルログはObject Lockを設定して保護してください。 

CloudTrailは、LookupEvents APIを呼び出すイベント履歴（Event history）によって基本的なフィルタリングを提供します。これは不審なアクティビティを調査するための良い出発点です。次のスクリーンショットは、サンプルプロンプトを用いたAWS-IReveal-MCPの動作を示しています。

‍

Clineで動作するMCPサーバー

以下に示すように、特定の命名パターンを持つロール、またはロールの集合によって実行された操作をたどるよう依頼することもできます。

‍

Claude Codeで動作するMCPサーバー

ここでは敵対者エミュレーションテストを実施するためにStratus Red Teamを利用しました。LLMはそれを正しく指摘しました。

‍

‍

CloudTrailログを調査する際に留意すべき重要ポイントをいくつか挙げます。

• sessionCredentialFromConsoleフィールドが存在する場合、そのイベントはWebコンソールから生成されています。
• ec2RoleDeliveryフィールドが存在する場合、そのイベントはEC2インスタンスのIMDSから認証情報を取得したプリンシパルによって生成されています。値は、そのインスタンスがIMDSv1を使用していたかIMDSv2を使用していたかを示します。
• ログにinvokedBy:AWS Internal（通常はsourceIPAddress:AWS InternalおよびuserAgent:AWS Internalを伴う）が含まれる場合、そのイベントはAWSによって生成されています。これは必ずしも、そのイベントを悪意あるものとして扱うべきではないという意味ではありません。たとえば、攻撃者が侵害されたアカウントから組織内の別アカウントへSwitchRoleを行うと、invokedBy:AWS Internalを伴うAssumeRoleが発生します。
• userAgentの値は、リクエスト時に任意に設定できます。 
• クロスアカウントでリソースへアクセスするリクエストでは、recipientAccountIdの値はリソース所有者のアカウントIDであり、userIdentity.accountIdはリクエストを行ったアカウントのIDです。
• vpcEndpointIdフィールドが存在する場合、そのリクエストはVPCから生成されています。この場合、sourceIPAddressはVPCのIPアドレスであり、プライベートである可能性があります。攻撃者は、VPCを使用してIPアドレスを偽装するためにここで説明されている手法を用いることがあります。  

CloudTrailログは、CloudTrail LakeまたはAmazon Athenaを用いてSQLでクエリし、より粒度の細かい検索が可能です。両サービスの主な違いは次のとおりです。

• CloudTrail Lakeはイベントを不変（immutable）なデータストアに取り込みます。一方Athenaは、S3上の生のJSON（または圧縮）ログファイルを直接クエリするため、ユーザーがSQLテーブルを構築する必要があります。
• CloudTrail Lakeには2つの保持オプションがあります。1つは最大10年間データストアにイベントを保持し、もう1つは最大7年間保持します。対してAthenaは、保持にS3ライフサイクルポリシーを利用します。
• CloudTrail LakeのSQL構文はAthenaより制限があります。
• CloudTrail LakeとAthenaはいずれも、クエリでスキャンされたバイト数に対して課金されます。ただし、パーティション化によりスキャン量を劇的に削減でき、大きなコストメリットが得られます。Athenaはパーティション化を完全に制御できますが、CloudTrail Lakeはデータストア内でイベントがどのように整理されるかを内部的に管理します。

本記事の目的では、Athenaを使用します。

‍

Amazon Athena

パーティション投影（Partition projection）は、運用オーバーヘッドを削減する優れた方法です。AWS-IReveal-MCP 

実装では、ドキュメントに示されたクエリを用いて、指定日以降の単一AWSリージョンのCloudTrailログに対してパーティション投影を使用するテーブルを作成します。これで、Athenaを使って不審なアクティビティの調査を始める準備が整いました。クエリの効果的なテンプレートの1つは次のとおりです。

WITH flat_logs AS (
    SELECT
        eventTime,
        eventName,
        userIdentity.principalId,
        userIdentity.arn,
        userIdentity.userName,
        userIdentity.sessionContext.sessionIssuer.userName as sessionUserName,
        sourceIPAddress,
        eventSource,
        json_extract_scalar(requestParameters, '$.bucketName') as bucketName,
        json_extract_scalar(requestParameters, '$.key') as object
    FROM <TABLE_NAME>   
)
SELECT *
FROM  flat_logs
WHERE date(from_iso8601_timestamp(eventTime)) BETWEEN timestamp '<yyyy-mm-dd hh:mm:ss>' AND timestamp '<yyyy-mm-dd hh:mm:ss>'--AND eventname IN (GetObject, 'PutObject', 'DeleteObject')
--AND userName = 'adminXX'--AND sessionUserName = '<ROLE_NAME>'--AND principalId LIKE 'AROA<xxxxx>:%'--AND arn LIKE '%user/admin%'--AND eventSource = '<SERVICE>.amazonaws.com'--AND sourceIPAddress LIKE '<x.x.x.x>'--AND bucketName = '<BUCKET_NAME>'--ORDER BY eventTime DESC
LIMIT 50;

このテンプレートではクエリ条件がコメントアウトされているため、実施したい検索に応じて必要なものをアンコメントできます。

以下は、AthenaツールとともにAWS-IReveal-MCPを使用する例です。

プロンプト: 

Has any S3 data event occurred on buckets with name containing 'customers'in eu-central-1in the last 24 hours?
for Athena queries use s3://pallas-athenas/ in us-east-1 as output bucket

‍

‍

ここから、すでに重要な情報が得られています。

• 2つの重要バケットが影響を受けました：「customers-keys」と「private-customers」。
• 多数のファイルがダウンロードされ削除されており、ランサムウェア攻撃に典型的なパターンです。
• これらのAPIコールの発信元IPアドレスが分かるため、同じIPからの他のアクティビティも調査できます。AWS-IReveal-MCPに実装されたAthenaクエリテンプレートでそれが可能です。
• このアクティビティの実行主体はロール「sysadmin」で、攻撃者はセッション名「cleanup」でそれを引き受けています。ここから調査は次の問いに進むべきです。
  • そのロールにAWSDenyAllポリシーをアタッチした後も、攻撃者はそのロールから永続化できたでしょうか。たとえば別ロールを引き受けたり、一時的認証情報を生成できたでしょうか。
  • そのロールの権限は何でしょうか。攻撃者はその権限で他のサービスやIDを狙ったでしょうか。
  • 誰がこのロールを引き受けられるのでしょうか（つまり、信頼ポリシーにおける信頼されたIDは何か）。
  • このロールは何に使われているのでしょうか。EC2インスタンスプロファイルのロールでしょうか。この場合、攻撃者はIMDS経由で制御を奪った可能性があり、AssumeRoleは不要です。そうでない場合、攻撃者が呼び出したAssumeRoleのログを取得することが極めて重要です。攻撃中に生成されたAPIコールのログにあるPrincipal IDは、AssumeRoleログにあるresponseElements.responseElements.assumedRoleIdの値と一致しなければなりません。今回のケースでは「AROATICXVRRGB3TJTEQXJ:cleanup」です。

さまざまな攻撃シナリオをカバーする追加のAmazon Athenaクエリについては、オープンソースリポジトリaws-incident-responseを参照してください。

‍

Amazon CloudWatch

多くのAWSサービスは、ログをAmazon CloudWatchへ送信するよう設定できます。サービス設定によっては、これらのログが非常に大量になる可能性があります。有効化することで、インシデント中に何が起きたのかを理解するうえで大きな違いが生まれます。 

‍

{
"Version": "2012-10-17",
"Statement": {
"Sid": "DenyInferenceForAnthropicModels",
"Effect": "Deny",
"Action": [
"bedrock:InvokeModel",
"bedrock:InvokeModelWithResponseStream",
"bedrock:Converse",
"bedrock:ConverseWithResponseStream"    ],
"Resource": [
"arn:aws:bedrock:*::foundation-model/anthropic.*"    ]
  }
}

侵害されたEC2インスタンスの調査

AWSアカウントへの初期アクセス獲得の一般的な方法は、EC2インスタンス上でホストされている脆弱または設定ミスのあるWebアプリケーションを悪用することです。AWSは、EC2インスタンスのフォレンジック分析を自動化するためにAutomated Incident Response and Forensics Framework、およびAutomated Forensics Orchestratorを提供しています。

これらには、分析をセットアップするために必要な次の重要ステップが含まれます。

• 侵害されたインスタンスがAuto Scalingグループの一部である場合、そのグループから外す。
• インスタンスにアタッチされたすべてのEBSボリュームのスナップショットを取得する。
• すべてのインスタンスメタデータ（パブリック/プライベートIPアドレス、AMI詳細、サブネットなど）を記録する。
• アタッチされているセキュリティグループをすべて外し、すべてのインバウンド/アウトバウンド接続を拒否する隔離用セキュリティグループに置き換える。
• すべてのAPIアクセスを禁止するIAMロールをアタッチする。

マシンを隔離した後、そのボリュームスナップショットはフォレンジックアカウントと共有する必要があります。その後、それらのスナップショットから新しいEBSボリュームを作成し、調査用にVPC内のプライベートサブネットで稼働するEC2インスタンスへアタッチします。

これでマシンの分析を進められます。マシンのOSに応じて、いくつかのオープンソースツールを使用できます。

• LiME（Linux Memory Extractor）。
• Volatility（メモリフォレンジックに使用）。 
• The Sleuth Kit（ディスクイメージ解析のためのツールセット）。多くの機能の中でも、現在のマシンのファイルシステムと元のAMIのファイルシステムの「差分（diff）」を作成できます。これは、攻撃者がマシンに加えたごくわずかな変更であっても検出するのに非常に役立ちます。
• ssm-acquire（Mozillaが開発。SSM（Systems Manager）を使用してEC2インスタンスのメモリを取得・分析）。
• cloud-forensics-utils（Googleが開発。EC2インスタンスのフォレンジック分析をセットアップ）。仮想マシンの隔離、EBSスナップショット作成、外部フォレンジックインスタンスへのアタッチ、またはdc3dd（ディスクバックアップツールddのパッチ版）を利用するスクリプトでS3バケットへコピーする機能を実装しています。また、分析に使用するインスタンスにThe Sleuth Kitを含む複数のフォレンジックツールをインストールします。

多数のEC2インスタンスを運用している場合、脅威検知と対応の自動化は非常に有用です。GuardDutyの検出結果により、AWSが提供するフレームワークをトリガーして影響を受けたマシンを分析し、アカウント所有者へ通知し、分析レポートを送付できます。さらに詳細な分析のために追加ツールで拡張することも可能です。 

調査したいEC2インスタンスを考えてみましょう。cloud-forensics-utilsをインストールした後、次のコマンドを実行して、インスタンスがあるアカウントから別のフォレンジックアカウントへボリュームをコピーします。

cloudforensics aws 'us-east-1c' copydisk --volume_id='vol-0f1af2a470d420440' --src_profile='hp2-adminB' --dst_profile='default'

次に、以下のコマンドで、指定したAMI、4CPU、50GBボリューム、そして侵害されたインスタンスからコピーしたボリュームを備えた新しいEC2インスタンスをフォレンジックアカウントで起動します。

cloudforensics aws 'us-east-1c' startvm 'vm-forensics' --boot_volume_size=50 --cpu_cores=4 --ami='ami-020cba7c55df1f615' --attach_volumes='vol-0db527dfcd85612f8' --dst_profile='default'

これで、新しいEC2インスタンスに接続して侵害されたボリュームを分析できます。 

まずはThe Sleuth Kitの一部であるflsから始め、指定デバイス上のすべてのファイルとディレクトリエントリを列挙します。

sudo fls -r -m / /dev/xvdf1 > full.body

出力ファイルをmactimeに入力し、時系列の「MACタイムライン」（Modify, Access, Change）をCSVファイルとして構築します。

sudo mactime -z UTC -d full.body > timeline.csv

よりリッチなイベントベースのタイムラインとして、インスタンスに自動インストールされるフォレンジックツールに含まれるPlasoも活用できます。次のコマンドは、数百のアーティファクトソース（ファイルシステムのタイムスタンプ、Windowsイベントログ、macOSログ、ブラウザ履歴など）をスキャンし、イベントを/mnt/plaso.dumpに書き込みます。

sudo log2timeline.py /mnt/plaso.dump /dev/xvdf1

最後に、次を実行してタイムラインをHTMLまたはCSVファイルとして作成できます。

sudo psort.py -o dynamic -w plaso_timeline.html /mnt/plaso.dump

この手順により、ファイルシステムの変更を分析し、疑わしいボリューム上のアクティビティの完全なタイムラインを再構築できます。生のファイルシステムメタデータを「body file」に取り込み、SleuthKitのflsとmactimeでタイムスタンプ順に並べ替えることで、各ファイルの作成/変更/アクセス/変更（change）時刻を1つのCSVで確認できます。さらに、同じ生デバイスをPlaso（log2timelineとpsort）に取り込むことで、他の数百のアーティファクトソースを単一のタイムラインに重ね合わせられます。

次のスクリーンショットはpsortの出力の抜粋で、誰かがマシンのSSHログインをブルートフォースしようとしている証拠を示しています。

この情報がpsortによって取得されるのは、/mnt/target/var/log/auth.log.1ファイルがログイン試行のたびに更新されているためです。

関連するアイデアとして、現在のファイルシステムと元のAMIのファイルシステムを比較し、不審な変更を探すことも有用です。

‍

悪意あるアクティビティのためのネットワークトラフィック分析

VPC Flow Logsは、VPC内のネットワークインターフェイスとの間で送受信されるネットワークトラフィックを捕捉し、悪意あるアクティビティ検知の重要なリソースとなります。これらのログはCloudWatch、S3バケット、またはAmazon Data Firehose（同一または別アカウント）へ配信するよう選択できます。CloudWatchでは、送信元/宛先ポート、送信元/宛先アドレス、プロトコルなど、さまざまなメトリクスフィルターに基づいてアラームを設定できます。1時間以内にEC2インスタンスへの拒否されたSSH接続試行が10回以上発生した場合のアラーム作成方法の例はこちらです。  

その後、Amazon Athenaを使ってSQLクエリでネットワークトラフィックを分析できます。見慣れないIPアドレスへの接続、外部への大量データ転送、通常使用しないポートでのトラフィック、確立されたベースラインから大きく逸脱する通信パターンなど、異常なパターンを探してください。これらの所見をCloudTrailなど他のセキュリティログと相関させ、不審なネットワークアクティビティの発生源と文脈を特定します。拒否された接続は、脆弱性探索の試みを示す可能性があるため特に注意してください。Flow Logsを定期的にレビュー・分析し、通常のネットワーク挙動を強く理解することが重要です。組織のベースライン挙動を把握していれば、悪意を示す可能性のある逸脱を効果的に特定できます。

‍

一般的な永続化手法の緩和

フェデレーション認証情報

IAMユーザーのキーが侵害されたことを検知した際の最初の対応は、多くの場合それらのキーを無効化または削除することです。しかし、キーが無効化される前に攻撃者がGetFederationTokenで一時的認証情報を作成できていた場合、これだけではそのユーザーの悪用を防げません。 

このAPIは最大36時間（ユーザーがルートユーザーの場合は1時間）有効な一時的認証情報を作成します。呼び出し時にセッションポリシー（管理ポリシーまたはインライン）を渡せます。結果として得られるセッション権限は、IAMユーザーポリシーと提供されたセッションポリシーの共通部分（intersection）になります。

‍

{
"Version": "2012-10-17",
"Statement": {
"Effect": "Deny",
"Action": "*",
"Resource": "*",
"Condition": {
"DateLessThan": {"aws:TokenIssueTime": "2014-05-07T23:47:00Z"}
    }
  }
}

バックドアロール

攻撃者がAWSアカウントへのアクセスを維持する一般的な方法は、IAMロールにバックドアを仕込むことです。これは、ロールの信頼ポリシーを変更し、攻撃者のAWSアカウントに属するIDがそのロールを引き受けられるよう指定することで実現されます。 

{
"Version": "2012-10-17",
"Statement": [
        {
"Effect": "Allow",
"Principal": {
"AWS": [
"arn:aws:iam::<ATTACKER_ACCOUNT_ID>:user/evil_user
                ]
            },
            "Action": "sts:AssumeRole"
        }
    ]
}

ロールの信頼ポリシーを監視し、外部アカウントIDが引き受け可能なロールを検知してアラートするセキュリティ機構を用意すべきです。

別の永続的脅威として、互いに引き受け可能なロールの集合が挙げられます。攻撃者がそのうちの1つを侵害すると、別ロールを引き受けて認証情報を更新し、同様の操作を繰り返してアクセスを維持できます。ロールチェーンのドキュメントによれば、これらの認証情報の有効期間は最大1時間に設定できます。この手法はrole chain jugglingとして知られています。 

‍

EC2インスタンス

EC2インスタンスは、権限管理のためにインスタンスプロファイル（IAMロールのコンテナ）を使用します。これらの権限は、インスタンスがAWSサービスへアクセスするために必要です。インスタンスプロファイルのセッション認証情報を取得するには、インスタンスで設定されているIMDSv1またはIMDSv2が提供するエンドポイントを呼び出す必要があります。

EC2インスタンス上で動作するWebアプリケーションにRCEまたはSSRFの脆弱性を見つけた攻撃者は、それを悪用して認証情報を盗むことができます。これにより攻撃者はインスタンスプロファイルの権限を使用でき、被害者のAWSアカウントへのアクセスを維持できます。

IMDS経由で認証情報を盗む行為を迅速に検知するには、マシン上での適切なランタイム検知が必要です。この操作はAssumeRoleイベントを生成しないため、そのAPIの不審な呼び出し監視に頼ることはできません。代わりに、前述のとおりCloudTrailログのec2RoleDeliveryフィールドに頼れます。このフィールドは、API呼び出しに使用された認証情報がIMDSv1またはIMDSv2で生成されたかを示します。

EC2インスタンスロールからの不審イベントを検知した後の最初の対応は、やはりそのロールにdenyポリシーをアタッチし、過去のセッションを失効させることです。その後、DisassociateIamInstanceProfileを呼び出して、侵害されたインスタンスプロファイルをインスタンスから関連付け解除することを検討してください。攻撃の根本原因（Webアプリの脆弱性または設定ミス）を是正した後、そのEC2インスタンスに関連付けるための新しいインスタンスプロファイル（新しいキーセット）を作成すべきです。

‍

リソースベースの手法

前述の永続化手法は運用上のものとみなせます。攻撃者がIAMロールや実行中のインスタンスにバックドアを仕込み、サービスやリソースの集合に対する制御を維持するケースです。別の種類の永続化は、RDSデータベースなどのリソースに紐づきます。

S3バケット、Lambda関数、SQSキューなどです。これらのリソースにバックドアを仕込むことで、攻撃者は被害者のAWSアカウント内のいかなるIDにもアクセスできなくても、それらを通過するデータへのアクセスを維持できます。緩和策と対応戦略は、影響を受けたリソースに応じて異なる場合があります。

• Amazon RDS: 手動スナップショットを取得し、パラメータグループ設定をエクスポートする。
• Amazon S3: ポリシーJSONとオブジェクトACLをコピーする。
• AWS Lambda: デプロイ済みコードパッケージをダウンロードする。
• Amazon SQS: キュー属性とポリシーをエクスポートする。

その後、次を実施してください。

• リソースのスナップショットまたは状態を、最後に既知の良好なInfrastructure as Code（IaC）定義と比較し、不正な変更を特定する。
• パブリックエンドポイントを切り離す、またはネットワークを制限する（例：RDSのセキュリティグループを厳格化する）。
• リソースポリシーから外部プリンシパルを直ちに削除する。

‍

結論

インシデント対応は静的なプロセスではありません。変化し続ける脅威環境に対して有効性を保つため、絶えず洗練が求められる動的で進化する分野です。各インシデントから得られる教訓は、現在のインシデント対応計画に統合すべき貴重な洞察を提供します。この継続的なフィードバックループにより、組織の防御は常に適応し改善されます。継続的改善を促進するうえで、次の領域は特に重要です。

• 可能な限りインシデント対応アクションを自動化する：インシデント対応ワークフロー内の反復タスクやプロセスを特定し自動化することで、効率と一貫性を大幅に高められます。適切な脅威検知手段を実装し、ほぼリアルタイムのアラートを上げるべきです。これは自動対応アクションと組み合わせられます。たとえばEC2インスタンスに対するアラートが、インスタンスを隔離しフォレンジック分析用のスナップショットを作成する自動化をトリガーできます。
• 定期的なセキュリティ監査とペネトレーションテスト：攻撃者に悪用される前に脆弱性や弱点を特定するため、予防的なセキュリティ評価は不可欠です。内部・外部の定期監査により、設定、ポリシー、手順を業界ベストプラクティスやコンプライアンス要件に照らしてレビューできます。一方ペネトレーションテストは、現実世界の攻撃を模擬して、システム、アプリケーション、ネットワーク設定における悪用可能な脆弱性を特定します。現実世界の攻撃をシミュレートする非常に効果的なツールの1つがStratus Red Teamです。検知のテストは、潜在的な問題を特定して解決するうえで重要です。
• インシデント対応チームの訓練と意識向上：最先端のツールや技術も、それを使う人の能力次第です。インシデント対応チームが幅広いセキュリティインシデントに対処できるようにするため、継続的な訓練と意識向上プログラムが極めて重要です。組織全体で強いセキュリティ文化を育むことは、より強靭な全体セキュリティ態勢に寄与します。

継続的改善にコミットし、利用可能なリソースを活用することで、組織はAWSにおける非常に効果的なインシデント対応能力を構築でき、セキュリティインシデントの影響を最小化し、クラウド上の重要資産を保護できます。

‍