ハクソク

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

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

216日前

概要

  • 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とか他のメディアの人たち、こんにちはって感じだね。顧客の信頼を壊すような大惨事になるから、完全には戻らないだろうね。

└

そう言うけど、AzureやOktaでは何件かこういうことがあったけど、あっちの生活はまあまあ続いてるよね。慣性ってほんとすごい薬だわ。

普通なら「それは偶然だろう」と言うけど、実はクライアントのアカウントが侵害されたことがあったんだ。すごく変だったよ。クライアントは小さな組織で、すごく古いIAMアカウントが突然、最近（昨日）コンソールにログインしたり、パスワード変更があったりしたんだ。侵害の程度を調査中だけど、今のところ、彼らがやったのはSESのプロダクションアクセスをオンにして、1日のメール制限を5万に増やすためのチケットを開いたことだけみたい。これらは5年以上前からほとんど使われてなかったIAMユーザーで、特にこの日に突然動き出すのは確かに変なタイミングだよね。

└

フィッシング攻撃の匂いがする。AWSが障害を経験しているっていうメールを受け取って、ステータスを確認するためにコンソールにログインして、悪意のあるラッパーを通じて認証して、アカウントのセキュリティが侵害されるって感じ。

└

ほぼ同じことが1年前に私にも起こりました。非常に古いアカウントのログインで、SESのアクセスがあり、メールの制限を引き上げるリクエストがありました。制限を引き上げるためにチケットを開かなければならなかったので、すぐに気づくことができました。新しく作成されたロールも確認してみてください。私たちは侵害されたユーザーをかなり早く排除しました（私自身も含めて、起源を特定しましたが）、ちょっと運が良かったのは、ロールを見て、1ヶ月未満のものや管理者アクセスのあるものを削除していったからです。ちょっと悪魔の弁護をすると、私たちの場合、実際に私のキーが侵害されたのは確かですが、どうやってそうなったのかは正確にはわかりません（多分、私がバカだったのと、組織がバカだったのと、誰かが二つの事実を結びつけたから）。最初に作成されたユーザーは、実際のSESリクエストのほぼ1ヶ月前にさかのぼることができました。あなたのケースでも、誰かが一時的にあなたを侵害していた可能性があり、AWSがダウンした時が攻撃する絶好のタイミングだと判断したのかもしれません。あなたが「またAWSの何かが起きている」と気づかない時に。

すでにアクセスを得た人たちが、AWSのインフラに何か問題が起こるのを待って、混乱の中に隠れている可能性はあるかな？だから、アクセス・トークンは数週間前や数ヶ月前に漏れたかもしれないけど、直接行動するのではなく、大きなことが起こるまでじっと待ってたのかも。もし俺がその側にいたら、確かにその戦略を探ると思う。

└

同じチームの者ですが、あなたの言ってることには同意します。2年前に、今日の攻撃に使われたのと同じキーについて、ランダムな人からのメールで警告を見たことがあります。でも、昨日まで実際の攻撃はなかったですね。

└

確かにそうですね。私はデュリジェンスを担当していて、攻撃者が会社の売上を待ちながら下準備をしているという話を聞いています。洗練された攻撃者は、こういう状況を利用するのが得意で、事前に準備してチャンスを待っていると思います。

└

みんながAWSにログインしているから、今が最悪のタイミングじゃないですか？もし私の会社がAWSを使っていたら、今何が起きているのかすごく気を使うと思います。

もし俺が泥棒で、家の盗まれた鍵を持ってて、いい日を待ってるとしたら、全市的な停電はいい日だろうな。

└

それは泥棒にとってはあまり良い日ではないでしょうね。多分、みんな家にいるでしょうし。ゴミの日を待って、ゴミを出してない人を見てみるといいかも。

us-east-1は想像を超えるほど大きいですね。私が見た最後の公表情報では、159のデータセンターがあると言っていました。多くのアカウントがそこに集中しているのも不思議ではないです。ダウンタイムに関係している可能性もありますが、これは単なる偶然の不運なケースだと思います。

パニックの時こそ、人々はフィッシング攻撃に最も脆弱になります。パスワードを全てリセットして、AWSの担当者に知らせてください。通常、彼らは善意で対応してくれます。