ハクソク

世界を動かす技術を、日本語で。

HNに聞く: AWSアカウントが障害後に侵害されました

2025年10月22日

概要

  • AWSで600インスタンス が3時間以内に起動
  • SESクォータ増加リクエスト や複数ドメイン認証の痕跡
  • AWSからのヘルスイベント通知
  • 脆弱性調査中 で2つの主な疑い
  • APIキー漏洩 または MFA未設定のコンソールアクセス が焦点

AWSインスタンス急増とSESクォータ増加の関連性

  • 600インスタンスの急増 と SESクォータ増加リクエスト、および 複数ドメインの認証 が同時期に発生

  • AWSからのヘルスイベント通知 による異常検知

  • これらのイベント間に関連性 がある可能性が高いと判断

    • 攻撃者によるAPIキー または MFA未設定のコンソールアクセス からの侵害疑い
    • SESクォータ増加 は スパムメール送信 や フィッシング攻撃 の準備行動としてよく見られるパターン
    • 複数インスタンスの短時間大量作成 も 悪用目的 でよく利用される手法

  • 初動対応 としては、 該当APIキーの無効化 や 全アカウントへのMFA導入 が急務

  • CloudTrailやIAMログ の詳細調査によるアクセス経路の特定が必要

  • SESやEC2リソース利用状況の監視 強化

疑われる侵害経路と推奨対応

  • APIキー漏洩

    • GitHub等の公開リポジトリ や 第三者サービス 経由での流出リスク
    • IAMユーザーの権限見直し と 不要キーの削除 が必須

  • MFA未設定のコンソールアクセス

    • パスワードリスト型攻撃 や フィッシング によるアクセスリスク
    • 全ユーザーへのMFA必須化 と パスワードリセット の実施

  • 今後の対策

    • AWS GuardDutyやSecurity Hub の有効化による自動監視
    • 異常検知ルール の設定と 定期的なセキュリティレビュー の実施
    • インシデント発生時の即時対応フロー 整備

まとめ

  • インスタンス大量作成とSES操作 は 同一攻撃者による連動した行動 の可能性
  • APIキー管理 と MFA運用徹底 が最重要課題
  • 継続的な監査と運用改善 による再発防止策の確立

Hackerたちの意見

おそらく偶然だと思う。一般的には、露出したアクセスキーだね。MFA保護されてないコンソールアクセスのパスワードが露出することはあるけど、あんまり一般的じゃない。

CloudTrailのイベントで、EC2を作成したのが何かを示せるはずだよ。思い出す限りでは、runInstanceイベントだと思う。

└

RunInstances

└

俺は正式にAWSを離れたから、チェックするコンソールがないんだけど、ノートパソコンに戻ったよ。ドキュメントや他の人に起こったことへの懸念を考えると、まずは以下のことをやるかな。

  1. コンソールを使って、誰が/何がそのEC2を作ったのか確認する: eventSource:ec2.amazonaws.com eventName:RunInstances
  2. userIdentityフィールドに基づいて、次のアクションを調べる。
  3. 誰かが手動でコンソールにログインしたか確認する（アイデンティティによる）: eventSource:signin.amazonaws.com userIdentity.type:[Root/IAMUser/AssumedRole/FederatedUser/AWSLambda] eventName:ConsoleLogin
  4. 誰かがセキュリティトークンサービス（STS）に対して認証したか確認する: eventSource:sts.amazonaws.com eventName:GetSessionToken
  5. 誰かが有効なSTSセッションを使ってAssumeRoleを実行したか確認する: eventSource:sts.amazonaws.com eventName:AssumeRole userIdentity.arn（または他の識別子）
  6. 永続性のために新しいIAMロール/アカウントが作成されたか確認する: eventSource:iam.amazonaws.com (eventName:CreateUser OR eventName:DeleteUser)
  7. すでに脆弱なIAMロール/アカウントがより許可的に変更されたか確認する: eventSource:iam.amazonaws.com (eventName:CreateRole OR eventName:DeleteRole OR eventName:AttachRolePolicy OR eventName:DetachRolePolicy)
  8. アクセスキーが作成されたか確認する: eventSource:iam.amazonaws.com (eventName:CreateAccessKey OR eventName:DeleteAccessKey)
  9. もし本番環境のEC2がIAMインスタンスプロファイルを変更されていたら、ウェブシェルやバックドアを使ってEC2の権限を利用するための裏口が作られているかもしれない。 などなど。もし初期調査で侵害があったなら、環境を徹底的に監査するためにプロのサポートを受ける価値はあると思うよ。
└

これは役に立ちそうですね。ログを探してみます。それと、以下の観察もあります：1) 私たちのルート内に20の組織が作成されていて、すべて同じドメイン（co.jp）のメールアドレスを持っていました。2) 攻撃者は複数のFargateテンプレートを作成しました。3) 16〜17のAWSリージョンでリソースを作成しました。4) SES、WS Fargateリソースのレートクォータ変更を要求してきました。SageMakerノートブックのメンテナンスもありましたが、これらのインスタンスを使う必要はありません（これについてAWSからメールが来ました）。5) いくつかのメールで新しい名前が追加されているのを見かけました（ランダムな名前 @outlook.com）。

Redditで何人かが言ってたけど、障害中にリフレッシュしてたら、全然違うユーザーとして一時的にログインしてたらしいよ。

└

参考文献ある？これはちょっとクレイジーだね。

└

もしかしたらDynamoDBが一時的に不安定で、その影響でIAMの認証情報が混乱したのかな？これに関する参考文献ある？もし本当なら、マジでヤバいよ。

└

Redditの数人が言ってたけど、障害中にリフレッシュしてたら、全然違うユーザーとして一時的にログインしてたって。ChatGPTも最近似たような問題があったよね？すごく似てる気がする。

└

友達の友達が、Netflixのルートアカウントにログインした友達を知ってる。ソース: 信じてくれ、兄弟。

└

数年前、俺が働いてた会社で、顧客が他の顧客のデータを見始めたことがあった。原因は、悪い雇用者が本番環境でライブデバッグセッションをやろうとしたことだった。（悪い雇用者って言うのは、俺が面接した後のフィードバックが「彼を雇うべきじゃない」だったから。）それを追跡して片付けるのはかなり面倒だったよ。

関係ないと思うけど、もし関係があるなら、これを読んでるBloomberg Newsとか他のメディアの人たち、こんにちはって感じだね。顧客の信頼を壊すような大惨事になるから、完全には戻らないだろうね。

Hacker Newsで議論の続きを見る