AI-Assisted Hackers Compromise AWS Cloud in 72 Hours Using Stolen Credentials
2026/07/10 gbhackers — AI を悪用する脅威アクターたちが、有効な認証情報/弱いアイデンティティ制御/露出したシークレットに接触するとき、現代的な AWS 環境であっても、きわめて迅速に侵害されることが実証された。既知の手法が用いた、約 72 時間という前例のない速度で、広範なクラウドの制御が奪われた。クラウド・セキュリティ・チームにより調査された、このインシデントが示すのは、もはや攻撃者たちが、ゼロデイ脆弱性やカスタム・マルウェアを必要としていないことである。その代わりに AI を悪用することで、偵察/スクリプト作成/ラテラル・ムーブメントを、緊密に調整された攻撃の波へと圧縮している。

72 時間で AWS クラウドを侵害
この侵入は、インターネットに公開されたアプリケーションの脆弱性から始まった。この脆弱性により AWS アクセス・キーが露出し、ユーザー組織のクラウド・アカウント内に、攻撃者は初期の足場を獲得した。この出発点から、攻撃者は AI 支援型ツールを悪用し、サービス/アイデンティティ/権限/デプロイメント・ワークフローを迅速に列挙していった。
これにより、攻撃者が特定したのは、深層へのアクセスを得るために悪用できる、ミスコンフィグや過剰に許可されたロールである。新たに発見された複数の認証情報とトークンが、さらなる悪用のためのピボット・ポイントとなった。それぞれを検証した攻撃者は、有効な権限をマッピングしていった。そして、拡大された攻撃領域で、探索/発見/シークレット収集/永続化の手順を繰り返した。

Sygnia によると、このキャンペーンは、ECS と EC2 ワークロード/S3 ストレージ/RDS データベース/CI/CD ランナー/GitHub や Bitbucket などのソース管理プラットフォームを含む、AWS 環境の複数レイヤーにまたがって展開された。
環境変数/S3 内の平文データ/アプリケーション・データベース/AWS Secrets Manager/Systems Manager Parameter Store から、各種のシークレットが体系的に収集された。この収集により、アカウントとロールに対する継続的なホッピングに必要な接続が得られた。
それと同時に攻撃者は、永続的なアクセスのためのバックドアおよび仕組みを作成した。それには、新しい IAM ユーザーとアクセスキーの追加/コンピュート・インスタンスおよびコンテナへのリバースシェルの展開/通常運用中でのアクセスを繰り返して確保するためのデプロイメント・ファイルの微妙な変更が含まれる。
攻撃の速度は、きわめて素早いものであったが、すべての観測された挙動は、以下の MITRE ATT&CK 手法と一致していた。
- 認証情報アクセス (T1552/T1528)
- クラウドアカウントの悪用 (T1078)
- 発見 (T1087/T1580)
- コマンド実行 (T1059)
- CI/CD パイプライン侵害 (T1677)
データ・アクセスと恐喝のための準備が、攻撃者の目的のコアである。攻撃者は複数の RDS データベースに対して、数百件のカスタマイズされた SQL クエリを実行し、ユーザーレコード/取引データなどの機密性の高いビジネス情報を抽出した。これらの情報は、収益化と交渉の材料として悪用できるものだった。
従来のランサムウェア型の暗号化ではなく、このキャンペーンは、インフラに対する制御を示すことに重点が置かれていた。
- S3 アクセスの無効化
- ECS サービスのゼロへのスケールダウン
- ACL によるネットワークアクセスのブロック
- メッセージキューの消去
これらのアクションの大半は、元に戻せるものであるが、攻撃者が運用を妨害できる能力を示しており、恐喝交渉における立場を強化するものだった。
複数のアーティファクトが示していたのは、LLM が侵入を直接支援していたことである。調査担当者が観測したのは、異なるアカウントの複数の AWS アクセスキーが、単一の IP アドレスおよびユーザー・エージェントから同時に使用されるという、きわめて並列性の高いアクティビティである。
このパターンが一致するのは、単独のオペレーターが手動でタスクを実行するものではなく、自動化され調整されたセンタライズド・ワークフローである。
スクリプトおよびペイロードには、AI 生成コードの特徴を示すマーカーが含まれていた。それらが示すのは、事前構築されたツールだけに依存するのではなく、発見のためのカスタム・スクリプトやデータ抽出ユーティリティといった、新たな攻撃対象に対応するタスク固有のツールを、攻撃者がオンデマンドで生成できていたことである。
攻撃者が作成した、ブランチ/コミット/HTML ファイルは、そのアクティビティを Red Team や Pentest として装うことが多かった。この言葉遣いは、防御側を誤誘導するものであり、そのアクティビティを承認済みのセキュリティテストとして、AI ツールに思い込ませることを狙ったものとされる。
このインシデントにおいて、特に注目すべきものは、攻撃側と防御側における AI 利用の不均衡である。攻撃者は AI を悪用して、多数のアイデンティティにまたがる運用上の記憶を維持し、どの認証情報がどのリソースを解放するのかを追跡し、発見/悪用/永続化の重なり合う波をマシンスピードで調整していた。
それに対して防御側は、断片化した可視性/部分的な制御の展開/手動の承認プロセスに苦しんだ。そのような手法では、自動化された認証情報窃取/権限分析/攻撃パスマッピングの速度に追いつけない。
この事例は、クラウド・セキュリティ・チームに対して、厳しい現実を突きつけるものだ。マシン スピードで実行される AI が、盗み出した認証情報を、数日あるいは数分で完全なクラウド侵害へ転換できるケースを想定する必要がある。その際のレジリエンスは、新規のポイント・ソリューションよりも、堅牢なアイデンティティ・セキュリティ/シークレット管理/CI/CD の強化などを、マシンスピードで実行できる、自動的な封じ込めの戦略になるはずだ。
訳者後書:クラウド運用の自動化が進み利便性が高まる中で、攻撃側も機械学習モデルなどの自動化技術を駆使し、驚異的な速度で認証情報を悪用するケースが確認されています。 今回の Amazon Web Services ( AWS ) の環境における事例では、ゼロデイのような特殊な欠陥ではなく、設定ミスや露出したアクセスキーが起点となり、わずか数日でシステム全体の制御を掌握される大きな影響が生じました。防御において必要なことは、過剰な権限を見直して最小権限の原則を徹底し、各種シークレット情報を安全に集中管理して、不審な挙動を自動で検知/遮断できる仕組みを整えることです。よろしければ、関連情報として 2026/03/11 の「AWS Admin アクセスを npm パッケージを介して 72 時間で奪取:UNC6426 の手口とは?」も、ご参照ください。

You must be logged in to post a comment.