SESが不正利用された!?その調査と対応

AWSがスパム送信を検知するとSESからのメール送信を停止する恐れがあります。原因や日々のチェック方法などを集めましたので運用の参考にしてください。ビジネスへの重大な影響を防ぎましょう!
2020.10.16

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

はじめに

クレデンシャルを適切に管理してますか?(時候の挨拶
SESが不正利用され、フィッシングを含むスパムメールの踏み台にされている事例を目にしました。これはいかんということで、調査と対応方法をまとめます。

AWSからどんな通知が来るか

SESに関する通知で、タイトルや本文に“vulnerability” “compromised” "phishing"が含まれている場合は要注意です。確認したら早急に対応を実行しましょう。

何がこまるか?

信用の失墜

あなたのドメインを利用してスパムメールが送信されていた場合、受信者はそのドメインのサービスに不安を覚えることになります。信頼感が失われることにより顧客離れが起き、利益損失が発生することが考えられます。また、フィッシング等で大規模な損害が発生した場合に、損害の保障を求められる可能性もありえます。

スパムメール送信によるSESの停止

AWSがスパム送信を検知するとSESからのメール送信を停止する恐れがあり、ビジネスへの多大な影響が懸念されます。

Q: Amazon SES のユーザーがスパムを送信しないよう、どのような方法で防いでいますか?

Amazon SES では、社内のコンテンツフィルタリングテクノロジーを使用して E メールコンテンツをスキャンし、スパムやマルウェアを確認します。 スパムや悪意のあるコンテンツを送信していると判断されたアカウントは、E メールの送信機能が制限または停止されます。

バウンス率・苦情率の増加によるSESの停止

スパムメールの送信先が必ず到達するとは限りません。また、スパムメールを受信したユーザから苦情が報告されることが想定されます。これが一定値に達すると、AWSより警告があり、SESの停止に繋がることになります。自身はルールを守って使っていても、悪意の第三者のせいでSESの停止が発生することは避けたいですよね。

侵害のパターン

まず、以下の図を使って、SESがどういった経路で侵害されるか考えて見ましょう。

様々な経路がありますが、大まかには「SESの操作権限が奪われる」「SESを利用するサイトの脆弱性」のどちらかです。

SESの認証パターンを把握

まずは、ご自身のシステムが、SESに対してどの方法で認証しているか確認してください。
以下に認証方法をまとめます。公式ドキュメントも参考にしてください。

権限名 説明 参考情報
SMTP認証情報 SESへSMTP接続するためのSES専用IDとパスワード。SESコンソールで作成する。 Amazon SES SMTP 認証情報の取得
IAMアクセスキー IAMユーザに紐ついた通常のアクセスキー。SESの操作権限が付与されている場合、SES API経由でメール送信が可能になる
IAMロール SESの操作権限があるIAMロールがEC2やECS等のリソースにアタッチされていた場合、対象リソースからSESの操作が可能になる。

初動対応 スパムメール送信を止める

まず、重要なのはスパムメールの送信を早期に停止することです。停止しない場合、AWSからSESの強制停止が発生する可能性があります。

「SMTP認証情報」「IAMアクセスキー」を利用している場合

キー情報の漏洩を疑います。既存のキーを削除し、再作成してください。手順は以下のドキュメントをご確認ください。このキーを利用しているアプリケーション側でも、近畿作成したキーに入れ替えることを忘れないようにしましょう。

既存の Amazon SES SMTP IAM ユーザーのアクセスキーを更新するにはどうすればよいですか?

IAM アクセスキーの更新

「IAMロール」を使用している場合

IAMロールがアタッチされたリソースが外部から侵害されている可能性があります。IAMロールからSES権限の剥奪および対象リソースの停止または隔離してください。

SESのログについて

SESは送信メール情報・本文を個別で記録する機能を持っていません。そのため、メール送信側でログ記録を行ってください。

パターンごとの対応

IAMユーザのアクセスキーが流出しており、攻撃者が外部からAWS CLIやSDKでメール送信している

チェックポイント

  • メトリクスから想定以上のメールが送信されていないか
  • SESダッシュボードの承認されたアドレスに想定しないアドレスがないか
  • IAMユーザの利用状況レポートから不明なIPがないか(最新の情報反映まで4時間程度かかります)

対策

  • 定期的に認証情報をローテーションする
  • MFAの導入を行う
  • SESへの権限があるIAMユーザにアクセスキーが必要か再検討する
  • git-secretsを導入する。
  • GuardDutyの導入

この場合、影響はSESだけに止まりません。アクセスキーに割り当てられた権限内のサービスを攻撃者は自由に操作できるからです。必ずアカウント内で不正なアクティビティが発生していないか確認しましょう!対策は以下のドキュメントにまとまっています。

AWS アカウントの不正なアクティビティに気付いた場合、どうすればいいですか?

SESのSMTP認証情報が流出し、攻撃者がSES SMTPエンドポイントへ外部からメール送信をしている

チェックポイント

  • メトリクスから想定以上のメールが送信されていないか
  • SESダッシュボードの承認されたアドレスに想定しないアドレスがないか

対策

  • 定期的に認証情報をローテーションする
  • 流出元を特定し対策を行う

SESを利用しているリソース(EC2、ECS等)が侵害され、メール送信されている

チェックポイント

  • アプリケーションやOSのログに不正利用の形跡はないか
  • CloudTrailで対象リソースから予期しないAPIコールが発生していないか
  • 攻撃者により不正なプログラムが配置されていないか
  • 攻撃者によりアプリケーションのコード改ざんされ、不正なメール送信機能が混入していないか

対策

  • OSパッチ適用、アプリケーションの脆弱性修正、定期的なパスワード変更、適切な権限管理等の侵入対策
  • GuardDutyの導入

SESで構成されたメールフォームの脆弱性を利用して、メール送信を行われている

チェックポイント

  • フォーム送信後の自動返信メールを利用してスパムの送信がされているログがないか
  • アプリケーションログからスパムの送信がされていないか
  • Webサーバのログで不審なアクティビティがないか

対策

  • 不正なアクセスのIPアドレス制限
  • アプリケーションレベルでの送信制限
  • アプリケーションの脆弱性対策

セキュリティが心配

セキュリティチェックを実施してみてはいかがでしょうか。

[2020年版]最強のAWS環境セキュリティチェック方法を考えてみた[初心者から上級者まで活用できる]

弊社では脆弱性診断オプションもご用意しております。

脆弱性診断オプション

最後に

アクセスキーの漏洩に対しては対応が浸透してきたと思いますが、SESも気をつけましょう。とは言いつつ、不正利用を発生させなければ本対応は発生しません。クレデンシャルの管理、脆弱性対策をしっかり行いましょう!