150以上の組織にまたがり、AWSのルートユーザーアカウントを標的とするパスワードスプレー攻撃キャンペーンが確認されました。この事実は、攻撃者がクラウド環境における最も権限の強いアイデンティティの侵害を継続的に狙っていることを浮き彫りにしています。
このキャンペーンは2026年7月24日から2026年8月23日にかけて実施され、AWSのルートアカウントに対する複数回の認証失敗の試みを伴っていました。被害を受けた組織の多くは中央値で2回の試行を記録していましたが、中には1カ月にわたる活動期間中に最大8回の試行を経験した組織もありました。
Datadogのセキュリティ研究者は、このキャンペーンに関連する不正ログインの成功事例を確認しておらず、攻撃者の最終的な目的は依然として不明です。
セキュリティシステムの導入
しかし、AWSのルートアカウントが侵害されれば、侵入者は組織のクラウドリソース、請求データ、アカウント設定、その他の機密性の高い管理機能に対して無制限にアクセスできるようになる可能性があります。
AWSを狙ったパスワードスプレー攻撃
今回確認された活動では、認証リクエストをトンネリングするために、プロキシを介した広範なインフラが利用されていました。送信元IPアドレスは多数の国やAS(自律システム)にまたがって分散しており、脅威インテリジェンスサービスはこれらをホスティングインフラ、住宅用プロキシ、あるいは類似の匿名化サービスとして分類しています。
このような構成により、IPアドレスベースのブロッキングは効果を発揮しにくくなり、攻撃者の特定も困難になります。さらにDatadogは、被害組織の傾向に明確なパターンを見出せなかったとしています。標的となった組織は業種や地域を問わず多岐にわたっており、特定のセクターを狙ったキャンペーンというよりも、日和見的な標的選定であることがうかがえます。
ログイン試行には、2種類のブラウザのユーザーエージェント文字列が一貫して関連付けられていました。
- Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/85.0.4183.83 Safari/537.36 Edg/85.0.564.41
- Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:120.0) Gecko/20100101 Firefox/120.0
この活動における注目すべき特徴の一つは、ルートユーザーに対するAWS ConsoleLoginイベントの失敗記録には、そのアカウントに紐づくメールアドレスが必要になるという点です。
このことから、脅威アクターはすでにルートアカウントのメールアドレスのリストを保有している可能性が示唆されます。これは過去の情報漏洩、流出した記録、オープンソースインテリジェンス(OSINT)による収集、あるいは認証情報データセットなどから入手したものと考えられます。
あるいは、攻撃者はより広範な企業のメールアドレスのリストをテストし、AWSのルートユーザーとして登録されているアカウントを特定しようとしている可能性もあります。
パスワードスプレー攻撃、すなわち多数のアカウントに対して限られた数のパスワードを試すという手法を用いることで、攻撃者は大量の試行を伴う従来型のブルートフォース攻撃に対して設けられているアカウントロックアウト制御を回避できます。
AWSのルートユーザーは、アカウントに対する完全な権限を保持しているため、特に価値の高い標的となります。AWSはルートユーザーに対して多要素認証(MFA)を義務付け、ルート権限に関するすべての活動を監視するよう推奨していますが、攻撃者はMFAの登録が未完了だったり、アカウント回復のワークフローが脆弱だったり、あるいは過去に認証情報が漏洩していたりするアカウントを依然として狙う可能性があります。
セキュリティチームは、AWS CloudTrailのログを確認し、ルートユーザーによるConsoleLoginイベント(失敗・成功の両方)を精査する必要があります。対象を絞ったクエリでは、userIdentity.type:Root、eventName:ConsoleLogin、認証失敗という結果、そして今回特定されたChrome/Edgeおよび Firefoxのユーザーエージェントをフィルタリング条件として設定する必要があります。
セキュリティシステムの導入
また、組織は以下の項目についてもアラートを設定しておくべきです。
- ルートコンソールへの直接サインインおよびルートAPIの利用
- ルート認証情報、MFA、アカウント回復手段の変更
- 通常とは異なる送信元IP、地域、コンソールの接続先
- 一元管理されたルートアクセスの仕組みを通じて開始された特権セッション
攻撃を受ける可能性を減らすため、企業は可能な限り恒常的なルートユーザーアクセスを排除すべきです。AWS Organizationsのサービスコントロールポリシーを利用すれば、メンバーアカウントにおけるルートユーザーの直接操作を制限できます。
一方で、一元管理されたルートアクセスは、例外的な管理作業のために短期間のAssumeRootセッションをサポートすることが可能です。管理アカウントのルート認証情報については、個別かつ厳格に管理された保護策が必要となります。
調査の遅れによるインシデントを防止しましょう。1万5000のSOCから得た脅威インテリジェンスでTier 1を強化: TI Lookupを自社のSOCに統合する
