新たに明らかになったサイバー犯罪キャンペーンによって、AmazonのSimple Email Service（SES）が大規模なフィッシング攻撃の武器に変えられ、1日5万通を超える悪意あるメールが送信されている。
「ブランド毀損にとどまらず、これはあなたから送られたように見えるフィッシングを可能にし、スピアフィッシングや詐欺、データ窃取、業務プロセス内でのなりすましに利用される可能性がある」と、Wizの研究者はこのSES攻撃について説明した。
この活動は、クラウドサービスの悪用が大幅にエスカレートしていることを示すとともに、攻撃者が正規のインフラを金銭詐欺や認証情報の窃取に転用している実態を浮き彫りにしている。
SES攻撃の仕組み
このSESの悪用キャンペーンは、クラウド環境ではあまりにも一般的な、侵害されたアクセスキーから始まる、周到かつ高度に自動化された一連の手順を踏んでいた。攻撃者は、公開コードの漏えい、設定ミスのあるクラウド資産、または開発者の端末の窃取を通じて認証情報を入手し、それを使って被害者のAWSアカウントにアクセスしたとみられる。
ハッカーはまずGetCallerIdentityを使って窃取したキーの権限を確認し、メール悪用の可能性を示すSES関連の命名を見つけた。続いてGetSendQuotaとGetAccountを使い、そのアカウントがSESの1日200通というサンドボックス制限の対象かどうかを確認した。
攻撃者は、すべてのAWSリージョンに同時にPutAccountDetailsリクエストを発行することでSESのサンドボックス制限を回避した。これは前例のない手法で、アカウントを5万通の送信枠を持つ本番モードへ昇格させるものだった。このマルチリージョン自動化により、送信枠を最大限に活用し、制御を回避するとともに、リージョンごとの制限に備えた冗長性を確保していた。
フィッシング基盤の構築と運用
本番モードに移行した後、攻撃者はCreateEmailIdentityを使って、managed7.comのような攻撃者所有サイトや、DMARCの設定が弱い正規ドメインを検証し、信頼されたIDの大規模な偽装を可能にした。
検証済みドメインにadmin@やnoreply@のようなアドレスを作成し、「2024年の納税フォームを閲覧・印刷できます」といった税務関連の誘い文句を組み合わせて、スパムフィルターを回避し、受信者を誘導した。
5万通の送信枠では不十分になると、攻撃者はCreateCaseを使ってAWSサポートチケットを開き、カスタムの「ses-support-policy」IAMポリシーを追加して権限の昇格を試みた。これは成功しなかったものの、デフォルトの送信枠でも大規模なフィッシングは可能だった。
攻撃者は、窃取した認証情報、自動化、ドメイン設定、送信枠の悪用を組み合わせ、SESを大規模なフィッシング基盤へと変えた。その活動は通常のAWS利用を模倣しており、従来の検知を回避していた。
このSES悪用が特に危険な理由
SESの悪用キャンペーンは、クラウドサービスの悪用が拡大しているリスクを浮き彫りにしている。攻撃者はカスタムマルウェアを持ち込む必要はなく、企業がすでに信頼している正規のプラットフォームを武器にできる。
フィッシングメールはAmazonのインフラから送信されるため、AWSの評判がもたらす信頼性を受け継ぎ、セキュリティツールやエンドユーザーが悪意あるメールだと見抜くことが難しくなる。
攻撃者は、1本の窃取したアクセスキーだけで、ブランドのドメインを偽装しながら毎日数万通のフィッシングメールを送信できるため、組織は侵害と評判への損害の両方にさらされる。侵害されたAWSアカウントからのフィッシングによって顧客データが露出すれば、SESの悪用は不正利用の報告、クラウドサービスの停止、規制当局による調査につながる可能性がある。
ビジネスメール詐欺（BEC）につながる可能性があり、窃取されたクラウド認証情報が被害者の環境内にある追加サービスへのアクセスに転用されるおそれもある。
セキュリティチームは、休眠キー、リージョンをまたぐ活動、大量のAPI利用といったクラウドネイティブの脅威にも監視を広げなければ、被害が発生した後に初めて悪用を検知することになりかねない。クラウドの導入が進む中、アクセスキーの保護とリージョンをまたぐ活動の監視は、パッチ適用と同じくらい重要だ。正規サービスでさえ武器に変えられるからだ。
セキュリティチームがリスクを低減するために取れる対策
セキュリティチームは、SESの悪用をクラウド認証情報が侵害された兆候として扱うべきだ。Wizの研究者は、次のような緩和策を推奨している。
- 未使用アカウントでSESをブロックすることを、AWS Service Control Policiesで実施する。
- IAMキーを定期的にローテーションすることに加え、休眠状態のキーを監視して異常な活動を検知する。
- 最小権限を徹底することで、送信者の検証や本番アクセスのリクエストを承認済みのロールだけが行えるようにする。
- CloudTrailとCloudWatchを使って異常を検知すること。PutAccountDetailsの集中発生、CreateCase API呼び出し、メール送信数の急増などを検知対象とする。
より広範な防御戦略として、組織は多要素認証の導入とゼロトラストセキュリティによって、クラウドセキュリティ体制を強化できる。
クラウドプラットフォームは効率性と拡張性を高める一方で、悪意ある目的にも悪用され得ることを今回の事例は示している。
強固なクラウドセキュリティのベストプラクティスで防御を強化すべきだ。