Terrance DeJesus

脅威検出用AWS S3 SSE-C Ransomのエミュレーション

AWS S3' SSE-Cサービスを使用したRansomの理解と検出

21分で読めますセキュリティ調査
脅威検出のためのAWS S3 SSE-C身代金のエミュレーション

前文

ElasticによるAWS検出エンジニアリングの新しい記事へようこそ。STS AssumeRootに関する前回の記事はこちらでお読みいただけます。

この記事では、脅威アクターがAmazon S3のServer-Side Encryption with Customer-Provided Keys (SSE-C)を活用して身代金/恐喝の作戦を行う方法について探ります。この現代的な悪用戦術は、攻撃者がクラウドネイティブサービスを利用して金銭的目標を達成するための創造的な方法を示しています。

読者は、S3、SSE-Cワークフロー、バケツ構成の内部の仕組みについての洞察を得ることができます。また、この手法の手順を順を追って説明し、S3バケツを保護するためのベストプラクティスについて議論し、環境内のSSE-Cの用を特定するために検出ロジックを作成するための実用的なガイダンスを提供します。

この研究は、初めて公然になったランサムウェア動作を目的としたSSE-Cのin-the-wild（ItW）悪用を文書化したHalcyon研究チームによる最近の発表に基づいています。ここでは、この新たな脅威を深く掘り下げ、敵に先んじる方法をご紹介します。

私たちは、このブログで参照されているTerraformコードとエミュレーションスクリプトを含むgistを公開しました。このコンテンツは、教育と研究目的でのみ提供されています。適用される法律やガイドラインに従って、責任を持ってご利用ください。Elasticは、予期しない結果や誤用について一切の責任を負いません。

ぜひご活用ください！

AWS S3の理解: 主要なセキュリティ概念と機能

エミュレーションとこれらの戦術、技術、手順 (TTP) に直接入る前に、AWS S3に含まれる内容を簡単に確認しましょう。

S3は、ユーザーが非構造化データまたは構造化データを「バケツ」に格納するのを可能にする共通ストレージサービスです。これらのバケツは、コンピュータシステムでローカルに見つかるフォルダに似ています。これらのバケツに格納されているデータはオブジェクト」呼ばれ、各オブジェクトはファイル名のように機能するオブジェクトキーによって一意に識別されます。S3は、JSONからメディアファイルまで、多様なデータ形式をサポートし、さまざまな組織のユースケースに最適です。

バケツは、さまざまなAWS S3サービスのオブジェクトを格納するように設定できますが、ユースケースに応じて手動またはプログラムでオブジェクトを追加することもできます。さらに、バケツはバージョニングを活用してオブジェクトの複数のバージョンを保守し、誤って削除または上書きされた場合でも回復力を提供します。ただし、バージョン管理はデフォルトで常に有効になっておらず、ランサムウェアや一括削除などに関連する特定の攻撃に対して、データが脆弱な状態になります。バケツは、さまざまなAWS S3サービスのオブジェクトを格納するように設定できますが、ユースケースに応じて手動またはプログラムでオブジェクトを追加することもできます。さらに、バケツはバージョニングを活用してオブジェクトの複数のバージョンを保守し、誤って削除または上書きされた場合でも回復力を提供します。ただし、バージョン管理はデフォルトで常に有効になっておらず、ランサムウェアや一括削除などに関連する特定の攻撃に対して、データが脆弱な状態になります。

これらのバケツへのアクセスは、通常作成時に定義されるアクセスポリシーに大きく依存しています。これらのポリシーには、バケツの内容が意図せず露出しないようにパブリックアクセスを無効にする設定が含まれています。構成はそれだけではありません。バケツには独自のAmazon Resource Name（ARN）があり、アイデンティティアクセス管理（IAM）のロールまたはポリシーを使用して、さらにきめ詳細なアクセスポリシーを定義することもできます。たとえば、ユーザー「Alice」がバケツとそのオブジェクトにアクセスする必要がある場合、s3:GetObjectなどの特定の権限をIAMロールに割り当てる必要があります。その役割は、アクセス許可ポリシーとしてAliceに直接適用することも、Aliceが所属する関連グループに適用することもできます。

これらのメカニズムは万全に見えますが、アクセス制御の構成ミス（例：過度に寛容なバケツポリシーやアクセス制御リスト）は、セキュリティインシデントの一般的な原因です。たとえば、この記事の執筆時点では、buckets.grayhatwarfare.comによると、約325.8kのバケツが公開されています。Elastic Security Labsは、2024年版Elasticグローバル脅威レポートで、失敗したAWSポスチャチェックの30%がS3に関連していることを観察しました。

S3におけるサーバーサイド暗号化
S3は、保存データを保護するための複数の暗号化オプションを提供しています。これには以下が含まれます。

  • SSE-S3：暗号化キーはAWSによって完全に管理されます。
  • SSE-KMS: キーはAWS Key Management Service (KMS)を通じて管理され、より多くのカスタムキーポリシーとアクセス制御が可能になります。これらがElasticで実装される方法をご覧ください。
  • SSE-C：お客様は制御を強化するために独自の暗号化キーを提供します。このオプションは、コンプライアンスや特定のセキュリティ要件のためによく使用されますが、キーの安全な管理や格納など、追加の運用上の負担を伴います。重要なのは、AWSがSSE-Cキーを格納せず、代わりにキーのHMAC（ハッシュベースのメッセージ認証コード）が検証目的でログに記録されることです。

SSE-C の場合、暗号化キーの管理ミスや意図的な悪用（例：ランサムウェア）によって、データが永久にアクセス不能になる可能性があります。

ライフサイクルポリシー

S3バケツはライフサイクルポリシーを活用することもでき、オブジェクトをより安価なストレージクラス（例：Glacier）に移行したり、指定された時間が経過した後にオブジェクトを削除したりするアクションが自動化されます。これらのポリシーは通常、コスト最適化用に使用されますが、攻撃者がこれを悪用して重要なデータの削除をスケジュールし、ランサムウェアインシデント時のプレッシャーを増大させる可能性があります。

ストレージクラス

Amazon S3は、異なるアクセスパターンや頻度のニーズに応じて設計された複数のストレージクラスを提供します。ストレージクラスは通常、コスト最適化用に選択されますが、暗号化とセキュリティがデータストレージと相互作用する方法を考慮するには、ストレージクラスを理解することが重要です。

たとえば、S3 StandardとIntelligent-Tieringは、最小限のレイテンシーで頻繁なアクセスを保証するため、ライブアプリケーションに適しています。一方、Glacier Flexible RetrievalやDeep Archiveなどのアーカイブクラスは、データにアクセスするまでに遅延が発生し、セキュリティシナリオにおけるインシデント対応を複雑にする可能性があります。

暗号化が導入されると、これは特に重要になります。サーバーサイド暗号化 (SSE) はすべてのストレージクラスで機能しますが、SSE-C (顧客提供キー) はキー管理の責任をユーザーまたは攻撃者に移します。AWS 管理の暗号化 (SSE-S3、SSE-KMS) とは異なり、SSE-C では、すべての取得操作で元の暗号化キーを提供する必要があります。そのキーが失われたり、敵対者によって提供されなかった場合、データは永久に回復不能になります。

これを理解することで、in-the-wildで観察されたSSE-Cの悪用の影響について重要な疑問が生じます。攻撃者が公開されている、または誤って構成されたS3バケツにアクセスし、ストレージポリシーと暗号化キーの両方を制御できるようになると、何が起こるのでしょうか。

こうして、身代金要求のためのSSE-Cの悪用が始まる

次のセクションでは、以下を完了することで、サンドボックスAWS環境でのこの動作をエミュレートするための実践的なアプローチを説明します。

  1. Infrastructure-as-Code (IaC) プロバイダーTerraformを介して脆弱なインフラをデプロイする
  2. PythonでSSE-Cリクエストを作成する方法を探求する
  3. Halcyonブログで説明されているランサムウェアの動作をエミュレートするカスタムスクリプトを実行する

前提条件

これは、検出エンジニアリングの特定のシナリオの再現に関する記事です。これがあなたの目標である場合、まず次のことを確立する必要があります。

  • Terraformをローカルにインストールする
  • 仮想環境で使用し、エミュレーションスクリプトを実行するために、Python 3.9+もローカルにインストールする
  • インフラの導入中に、Terraformが使用できる管理者権限を持つAWS CLIプロフィールを設定する

脆弱なインフラのデプロイ

ホワイトボックスエミュレーションでは、実世界のシナリオで組織が持つ可能性のあるS3構成を複製することが重要です。以下はデプロイされたインフラの概要です。

  • リージョン: us-east-1 (デフォルトの導入リージョン)
  • S3バケツ: 機密データを含み、攻撃者が制御する暗号化を可能にする、一意の名前の給与計算データバケツ
  • バケツ所有権の制御:「BucketOwnerEnforced」を適用して、ACLベースの権限を防御します。
  • 公共アクセス制限: 偶発的な露出を防御するため、公共アクセスは完全にブロックされます。
  • IAMユーザー: 過剰なS3権限を持つ、敵対者が管理する侵害されたIAMユーザーです。アクセスキーの認証情報は、自動タスク向けに他の場所でプログラム的に使用されるため、ログインプロフィールは割り当てられていません。
  • IAMポリシー: バケツレベルとオブジェクトレベルの両方で、攻撃者は次への権限を持っています。
    • s3:GetObject
    • s3:PutObject
    • s3:DeleteObject
    • s3:PutLifecycleConfiguration
    • s3:ListObjects
    • s3:ListBucket
  • バケットレベルとオブジェクトレベルの両方に適用されます
  • IAMアクセスキー: アクセスキーは敵対的なユーザーのために生成され、プログラムによるアクセスを可能にします。
  • ダミーデータ: シミュレートされた機密データ（customer_data.csv）がバケツにアップロードされます

この種の攻撃が展開する方法を評価するためには、インフラを理解することが重要です。Halcyonのブログは攻撃手法を説明していますが、影響を受けた組織の具体的なAWS構成についてはほとんど詳細を提供していません。これらの詳細は、そのような攻撃の実現可能性を判断し、実行を成功させるために必要な手順を決定するのに不可欠です。

バケットへのアクセシビリティと露出

このような性質の攻撃が発生するには、攻撃者は次の2つの主要な方法のいずれかを使用してS3バケットにアクセスする必要があります。

パブリックアクセスバケット: バケットが公開アクセスポリシーで誤って構成されている場合、攻撃者はそれを直接操作できるようになり、提供されたバケットの許可ポリシーはs3:PutObject、s3:DeleteObject、またはs3:PutLifecycleConfigurationのようなアクションを許可します。これらの権限は、ワイルドカード（*）プリンシパルを使用して誤って割り当てられることが多く、誰でもこれらの操作を実行できるようになります。

侵害された認証情報: 攻撃者がAWS認証情報を（認証情報の漏洩、フィッシング、またはマルウェアを通じて）入手した場合、正規のIAMユーザーとして認証され、意図されたアカウント所有者であるかのようにS3とやり取りすることができます。

当社のエミュレーションでは、バケットは公開されておらず、攻撃は侵害された認証情報に依存していると想定しています。これには、敵対者が有効なAWSアクセスキーを取得し、クラウドインフラストラクチャーの探索を行ってアクセス可能なS3バケットを特定する必要があります。これは通常、s3:ListAllMyBuckets、s3:ListBuckets、s3:ListObjects などのAWS API呼び出しを使用して行われ、特定のリージョンのバケットとそのコンテンツが公開されます。

攻撃の実行に必要なIAM権限: SSE-Cを使用してファイルを暗号化し、削除ポリシーを確実に実施するには、適切なIAM権限が攻撃者に必要です。当社のエミュレーションでは、侵害されたIAMユーザーに明示的な権限を構成しましたが、実際のシナリオでは、複数の権限モデルがこの攻撃を可能にする可能性があります。

  • 過度に寛容なカスタムポリシー：組織は、厳密な制約なしに、知らず知らずのうちにS3の広範な権限を付与している可能性があります。
  • AWS管理ポリシー：攻撃者は AmazonS3FullAccess または AdministratorAccess を持つユーザーまたはロールに関連する資格情報を入手した可能性があります。
  • 部分的なオブジェクトレベルのアクセス許可: IAMユーザーが AllObjectActionsを持っていた場合、オブジェクトレベルのアクションのみが許可されますが、オブジェクトを取得し、それらを反復して暗号化および上書きするために必要なライフサイクルポリシーの変更やバケットのリスト化は許可されません。

Halcyonブログはどの権限が悪用されたかを明示していませんが、当社のホワイトボックスエミュレーションは、説明された通りに攻撃が機能するために必要な最小限の権限を確保します。

侵害されたIAMユーザーの役割
もう1つの重要な要素は、認証情報が侵害されたIAMユーザーの種類です。AWSでは、攻撃者は必ずしもインタラクティブなログインプロファイルを持つユーザーの認証情報を必要としません。多くのIAMユーザーはプログラム専用のアクセスのために作成されており、追加のセキュリティブロッカーとして機能する可能性があるAWS Management Consoleのパスワードや多要素認証 (MFA) は、必要ありません。

これは、IAMユーザーに属する盗難された認証情報が自動化やサービス統合に使用される場合、攻撃者は追加の認証チャレンジなしでAPIリクエストを簡単に実行できることを意味します。

Halcyonブログは、この攻撃で使用された手法を効果的に文書化していますが、被害者の基盤となるAWSの構成に関する詳細は含まれていません。攻撃の背後にあるインフラストラクチャー（バケットアクセス、IAM権限、ユーザーロールなど）を理解することは、これらのランサムウェア操作が実際に展開される方法を評価するために不可欠です。これらの詳細が提供されていないため、攻撃が成功した条件をよりよく理解するために情報に基づいた仮定を立てる必要があります。

当社のエミュレーションは、この種の攻撃に必要な最小限の条件を再現するように設計されており、防御戦略と脅威検出能力の現実的な評価を保証します。インフラストラクチャーの技術的側面を探ることで、潜在的な緩和策や、組織が同様の脅威に対して積極的に防御する方法について、より深い洞察を提供できます。

インフラストラクチャーの設定

当社では、インフラストラクチャーの導入にIaCフレームワークとしてTerraformを活用しています。この記事を簡潔に保つために、Terraform構成とアトミックエミュレーションスクリプトに簡単にアクセスできるよう、両方がダウンロード可能なgistに保存されています。以下は、これらのファイルがダウンロードされた後に予想されるローカルファイル構造です。

必要なファイルをローカルに設定した後、このシナリオ用のPython仮想環境を作成し、必要な依存関係をインストールできます。環境が設定されたら、次のコマンドでTerraformを初期化し、インフラをデプロイします。

Command: python3 s3\_sse\_c\_ransom.py deploy

導入が完了すると、攻撃のエミュレーションと実行を進めるために必要なAWSインフラストラクチャーが準備されます。パブリックアクセスはブロックされており、IAMポリシーはセキュリティ上の理由から動的に生成されたIAMユーザーにのみ適用されることに留意してください。ただし、テストが完了した後や必要なデータを取得した後は、インフラストラクチャーを解体することを強く推奨します。

AWSコンソールにログインするか、CLIを使用する場合、us-east-1 リージョンにバケットが存在し、ダウンロードするとプレーンテキストになる customer_data.csv, が含まれていることを確認できます。また、「ransom.note」が存在しないことにも気づくでしょう。

PythonでS3 SSE-Cリクエストを作成する方法を探求する

アトミックエミュレーションを実行する前に、攻撃者がこの攻撃を成功させるための基礎となるトレードクラフトを調査することが重要です。

AWSに精通していれば、バケットへのアクセス、オブジェクトの一覧表示、データの暗号化などのS3操作は、通常AWS SDKまたはAWS CLIを使用すると簡単に行えます。これらのツールは多くの複雑さを抽象化し、ユーザーが基礎となるAPIのメカニズムを深く理解することなく操作を実行できるようになります。また、これらの機能を悪用しようとする攻撃者に必要な知識の壁も低くなります。

しかし、Halcyonブログでは、攻撃の実行に関する重要な技術的詳細が指摘されています。

攻撃者は、x-amz-server-side-encryption-customer-algorithmヘッダーを呼び出し、ローカルで生成して格納したAES-256暗号化キーを使用して暗号化プロセスを開始します。

ここでの重要な違いは、この攻撃の暗号化操作に必要なx-amz-server-side-encryption-customer-algorithmヘッダーの使用です。AWSドキュメントによると、このSSE-Cヘッダーは通常、事前署名付きURLを作成し、S3でSSE-Cを活用するときに指定されます。これは、攻撃者が被害者のデータを暗号化するだけでなく、AWS自体が暗号化キーを格納しない方法で暗号化するため、攻撃者の協力なしには回復が不可能になることを意味します。

事前署名付きURLとSSE-Cの不正使用における役割

事前署名付きURLとは何ですか？
事前署名付きURLは、ユーザーが限られた時間内に特定のS3操作を実行できるようにする署名付きAPIリクエストです。これらのURLは、AWS の認証情報を公開せずにオブジェクトを安全に共有するために一般的に使用されます。事前署名されたURLは、S3オブジェクトへの一時的なアクセスを許可し、ブラウザを通じてアクセスしたり、APIリクエストでプログラム的に使用したりできます。

一般的な AWS 環境では、ユーザーは事前署名付きURLに対してSDKやCLIラッパーを利用します。しかし、SSE-C を使用する際、AWS は暗号化または復号化のために追加のヘッダーを要求します。

SSE-Cと必須のHTTPヘッダー
AWS SDK経由またはS3 REST APIの直接な呼び出しを介して SSE-Cリクエストを行う場合、次のヘッダーを含める必要があります。

  • x-amz-server-side-encryption-customer-algorithm: 暗号化アルゴリズムを指定しますが、AES256である必要があります（Halcyonのレポートに記載されています）
  • x-amz-server-side-encryption-customer-key: S3がデータを暗号化または復号化するために使用する256ビット、base64エンコードされた暗号化キーを提供します
  • x-amz-server-side-encryption-customer-key-MD5: 暗号化キーのBase64でエンコードされた128ビットのMD5ダイジェストを提供します。S3はこのヘッダーを使用してメッセージの整合性をチェックし、暗号化キーがエラーや改ざんされずに送信されたことを確認します

これらの詳細は、検出の機会を探す場合に非常に重要です。

AWS Signature Version 4 (SigV4) とその役割

S3へのリクエストは、認証されているか匿名のいずれかです。事前署名付きURLを使用したSSE-C暗号化には認証が必要であり、すべてのリクエストは正当性を証明するために暗号で署名される必要があります。ここで、AWS Signature Version 4 (SigV4) が登場します。

AWS SigV4は、API リクエストがAWSサービスに対して署名および検証されることを保証する認証メカニズムです。S3でオブジェクトを変更するには認証済みのAPI呼出しが必要であるため、これはSSE-C操作にとって特に重要です。

この攻撃では、以下によって各暗号化リクエストに署名される必要があります。

  1. AWS SigV4を使用して暗号署名を生成する
  2. リクエストヘッダーに署名を含める
  3. 必要なSSE-C暗号化ヘッダーをアタッチする
  4. S3にリクエストを送信し、オブジェクトを暗号化されたバージョンで上書きする

適切なSigV4署名がない場合、AWSはこれらのリクエストを拒否します。Halcyonが記述した攻撃は、侵害された認証情報に依存しています。これは、当社のテストでリクエストが拒否されなかったことで確認されています。また、これは攻撃者が不適切な署名要件などのAWS S3の誤った構成を悪用できること、バケットの複雑さや関連するオブジェクトのアクセス制御を理解していることを示唆しています。これは攻撃が公開されているS3バケットではなく、侵害されたAWS認証情報に依存しており、攻撃者がS3バケットやオブジェクトだけでなく、AWSの認証と暗号化のニュアンスも理解できるほど熟練していたという仮説を補強しています。

アトミックエミュレーションの発動

当社のアトミックエミュレーションは、ログインプロファイルを持たないIAMユーザーの「侵害された」認証情報を使用し、ターゲットバケットに対する複数のS3アクションを許可する権限ポリシーがアタッチされています。念のためにお知らせしますが、当社がこれを実施するインフラと環境は、共有のgistを参照した「インフラスの設定」セクションからデプロイされたものです。

以下は、エミュレーションの手順を示したワークフローです。

  1. 盗まれたAWS認証情報を読み込む（環境変数から取得）
  2. 侵害された認証情報でS3クライアントを設定する
  3. S3エンドポイントURLを生成する（バケットのURLを構築）
  4. S3 オブジェクトを列挙する → s3:ListObjectsV2 (オブジェクトリストを取得)
  5. AES-256暗号化キーを生成する（ローカルで生成）
  6. ループを開始する（バケット内の各オブジェクトに対して）
    1. GETリクエストを生成し、AWS SigV4で署名する（リクエストを認証）
    2. S3からオブジェクトを取得する → s3:GetObject (暗号化されていないデータを取得)
    3. PUTリクエストを生成し、AWS SigV4で署名する（SSE-Cヘッダーをアタッチ）
    4. S3のオブジェクトを暗号化して上書きする → s3:PutObject (SSE-Cで暗号化)
  7. エンドループ
  8. 7日間の削除ポリシーを適用 → s3:PutLifecycleConfiguration（時間制限付きデータ破壊）
  9. 身代金要求メモを S3 にアップロード → s3:PutObject (被害者に残された恐喝メッセージ)

以下は、このエミュレーションワークフローの視覚的表現です。

私たちのPythonスクリプトには、このスクリプトを悪用しないことに同意したことを確認するために、ユーザーの操作を必要とするプロンプトを意図的に追加しました。デトネーション中に生成される別のプロンプトが、必要に応じてAWSの調査に時間を与えるために、S3オブジェクトを削除する前にユーザーの実行を停止します。SSE-C が使用されているため、オブジェクトは Terraform がアクセスできないキーで暗号化され、そのため失敗します。

Command: python s3\_sse\_c\_ransom.py detonate

発動後、S3バケット内のオブジェクトはSSE-Cで暗号化され、身代金要求メモがアップロードされ、有効期限のライフサイクルが追加されます。

customer_data.csvオブジェクトにアクセスしようとすると、サーバー側の暗号化を使用して格納されているため、AWSはリクエストを拒否します。オブジェクトを取得するには、正しいAES-256暗号化キーを含む署名済みリクエストが必要です。

クリーンアップ

このエミュレーションのクリーンアップは比較的簡単です。S3 オブジェクトを保持することを選択した場合は、手順 1 から開始してください。それ以外の場合は、手順 5 に直接進んでください。

  1. us-east-1リージョンにアクセスする
  2. S3に移動する
  3. 次を見つける: s3-sse-c-ransomware-payroll-XX bucket
  4. すべてのオブジェクトを削除する
  5. Command: python s3\_sse\_c\_ransom.py cleanup

完了したら、最初にデプロイされたものはすべて削除されます。

検出とハンティングの戦略

アトミックエミュレーションを行った後、AWSのCloudTrailが提供するAPIイベントログに基づいて、このランサム行為を効果的に検出する方法を共有することが重要です。当社は、データの取り込みと初期クエリの開発にElastic Stackを活用しますが、クエリのロジックとコンテキストは選択したSIEMに翻訳可能である必要があります。また、CloudTrailの設定でS3のデータイベントを「すべてのイベントをログに記録する」に設定することが重要であることにもご留意ください。

SSE-Cを使用した異常なAWS S3オブジェクトの暗号化

この検出戦略の目的は、SSE-Cを利用するPutObjectリクエストを特定することです。顧客提供の暗号化キーは、特に組織が主にKMS (SSE-KMS) またはS3のネイティブ暗号化 (SSE-S3) を通じてAWS管理の暗号化を使用している場合、異常な活動に対する強力な指標となる可能性があります。

当社のエミュレーションでは、PutObject件のリクエストがx-amz-server-side-encryption-customer-algorithmヘッダーをAES256に設定して構成され、顧客提供のキーが暗号化 (SSE-C) に使用されたことをAWSに通知しました。

幸いなことに、AWS CloudTrailはこれらの暗号化の詳細をリクエストパラメータ内に記録しているため、セキュリティチームは異常なSSE-Cの使用を検出することができます。監視すべき主なCloudTrail属性は次のとおりです。

  • SignatureVersion: SigV4 → このリクエストが署名されたことを示します
  • SSEApplied: SSE_C→ サーバー側の顧客キー暗号化が使用されたことを示します
  • bucketName: s3-sse-c-ransomware-payroll-96 → これが発生したバケットを示します
  • x-amz-server-side-encryption-customer-algorithm: AES256→ 顧客の暗号化キーに使用されたアルゴリズムを示します
  • key: customer_data.csv → これが適用されたオブジェクトの名前を示します

これらの詳細を用いて、これらのイベントに一致し、最終的には元のHalcyonブログで報告された脅威に対応する脅威検出クエリを作成することができます。

event.dataset: "aws.cloudtrail" (aws.cloudtrail)および event.provider:"s3.amazonaws.com" と event.action:"PutObject" と event.outcome:"success" と aws.cloudtrail.flattened.request_parameters.x-amz-server-side-encryption-customer-algorithm: "AES256" と aws.cloudtrail.flattened.additional_eventdata.SSE適用:「SSE_C」

これは広範囲の検出ですが、組織は次のような質問をして、自社の環境に合わせて調整する必要があります。

  • S3バケットまたはオブジェクト操作に対して、SigV4を使用した事前署名付きURLを期待しているか
  • SSE-CがS3またはこの特定のバケットでのPutObject操作に使用されると期待しているか

新しい用語ルールタイプで誤検知を削減
誤検知（FP）を最小限に抑えるために、Elasticの新用語ルールタイプを活用して、疑わしいアクティビティの初回発生を検出できます。すべての一致に対してアラートを発するのではなく、IAMユーザーと影響を受けるS3バケットの一意の組み合わせを追跡し、設定された期間内にこの動作が初めて観察された場合にのみアラートを生成します。以下は、当社が観察するいくつかの一意の組み合わせです。

  • S3でSSE-C暗号化を実行する一意のIAMユーザー（ARNs）。
  • SSE-Cが適用される特定のバケット。

これらのアラートは、このアクティビティが過去 14 日間に初めて観察された場合にのみトリガーされます。

この適応型アプローチは、正当なユースケースが経時的に学習されるのを確実にし、期待される操作に対する反復的なアラートの発生を防ぎます。同時に、S3におけるSSE-Cの初めて発生する異常を検出することで、脅威の早期発見に役立ちます。必要に応じて、特定のユーザーID ARN、バケット、オブジェクト、さらにはソースIPに対してルールの例外を追加し、検出ロジックを洗練させることができます。この手法は、歴史的なコンテキストと行動のベースラインを組み込むことで、信号の忠実度を向上させ、検出の効果とアラートの実用性を高めます。

ルールの参照

SSE-Cを使用した異常なAWS S3オブジェクトの暗号化
SSE-Cを使用した過剰なAWS S3オブジェクトの暗号化

まとめ

この出版物をお読みいただき、また、エミュレーションをお試しいただいたことに心より感謝申し上げます。ホワイトボックステストはクラウドセキュリティにおいて重要な役割を果たし、現実世界の脅威を再現し、その行動パターンを分析し、効果的な検出戦略を策定することを可能にします。クラウドベースの攻撃が増加する中、攻撃者の戦術の背後にあるツールを理解し、研究結果を広範なセキュリティコミュニティと共有することが重要です。

当社のAWS検出ルールセットにご興味がある場合は、Elastic AWS Detection Rulesをご覧ください。また、当社のルールセットを向上させるための寄稿もお寄せください。皆様の努力は集団防御の強化に役立ち、私たちは心から感謝しております！

ご興味があれば、Halcyonの出版物を読むことをお勧めします。また、当社は同社が研究を共有してくれたことに感謝します。

それでは、また次回まで。

重要な参考資料:

Halcyon ResearchのSSE-C ItWに関するブログ
AWSにおけるSSE-CのためのElasticエミュレーションコード
Elastic事前構築済みAWS脅威検出ルールセット
Elasticの事前構築済み検出ルールリポジトリ
ルール: SSE-Cを使用した異常なAWS S3 オブジェクトの暗号化
ルール: SSE-Cによる過剰なAWS S3オブジェクトの暗号化

この記事を共有する

TwitterFacebookLinkedInRedditの