Amazon SES悪用フィッシング・BEC攻撃急増2026｜SPF/DKIM突破の手口とIAM最小権限防御

2026年5月、Kaspersky のセキュリティチーム Securelist が、Amazon Simple Email Service（SES）を悪用したフィッシング・BEC（Business Email Compromise）攻撃が急増しているとする調査レポートを公開した。攻撃者は流出した AWS の IAM アクセスキーで他社の SES を踏み台にし、正規の AWS インフラ経由でフィッシングメールを送る。受信側では SPF・DKIM・DMARC すべてが pass となるため、認証ベースのフィルタリングは機能しない。本記事では、Kaspersky のレポートと公開されている関連事例をもとに、攻撃の流れ・検知が難しい理由・送信側（AWS 利用者）と受信側それぞれの防御策を整理する。

この記事ではAmazon SES悪用によるフィッシング・BEC攻撃の最新動向を解説します。OSS開発・クラウド運用全体を貫くサプライチェーン視点でのリスク像と対策の俯瞰はサプライチェーンセキュリティ2026｜攻撃手法・防御ツール・実践チェックリストをご覧ください。

なぜAmazon SESがフィッシング・BEC攻撃の踏み台に選ばれるのか

Amazon SES は AWS が提供するマネージド型のメール送信サービスで、トランザクションメールやマーケティングメールの大量配信を SMTP / API 経由で実行できる。送信側からみたメリット――到達率の高さ、SPF / DKIM の自動セットアップ、AWS の IP レピュテーション――は、そのまま攻撃者が悪用したい要件と一致する。

Kaspersky のレポートによれば、攻撃者は侵害した AWS アカウントの SES から直接送るため、フィッシング検知用の IP ブラックリスト・送信元レピュテーションといった伝統的な指標がほぼ機能しない。受信側で異常を検出する起点は、メール本文の文言・添付PDF・リンク先 URL の内容解析だけになる。

攻撃の全体像 — フィッシングとBECの2系統に分かれる

Kaspersky の観測では、SES を踏み台にする攻撃は大きくふたつの系統に分かれる。ひとつは不特定多数を狙うフィッシングキャンペーン、もうひとつは特定の企業を狙う BEC（経理担当者を狙う請求書差し替え型）である。両者は技術的な前段（SES へのアクセス取得）は共通で、後段の本文と着地ページが異なる。

フィッシング系 — DocuSign / Adobe Sign偽装が最多

Kaspersky の観測ではフィッシング系のうち最も多いテーマは電子署名サービスの偽通知だった。DocuSign や Adobe Sign の正規通知メールを模した HTML テンプレートが SES のカスタムテンプレート機能で配信され、「契約書を確認してください」「電子署名が必要です」といった本文でリンククリックを誘導する。

リンクの着地先は攻撃者が AWS 上に立てたページ（*.amazonaws.com または *.s3.amazonaws.com）で、ブラウザのアドレスバーに amazonaws.com が表示されるため、ユーザーが「AWS の正規サービス」と誤認しやすい。最終的に Microsoft 365 / Google Workspace / 銀行のログイン画面を模した偽フォームへ遷移し、認証情報を窃取する。

BEC系 — 偽メールスレッドと請求書PDFのコンボ

BEC は明確に標的を絞った攻撃で、ターゲット企業の経理担当者・財務部門に向けて送られる。本文には実在しそうな上司・取引先名と、偽造された過去のメールスレッド（”昨日の件、添付の請求書ご確認ください” のような書き出し）が組み合わされる。添付の PDF 請求書は本物に近い体裁で作られているが、振込先の口座番号だけが攻撃者の口座に差し替わっている。

伝統的な BEC は社内ドメインの偽装（lookalike domain、From ヘッダ詐称）が多かったが、SES 悪用型は「正規の SES 送信」である点が決定的に違う。受信側のメールクライアントで From を見ても DMARC 整合エラーは出ない。メールの送信元ドメインが取引先と微妙に違うことに人間が気付けるかどうかが最後の砦になる。

流出したIAMキーがSES送信権限に変わるまで — 攻撃の起点を解剖する

SES 悪用攻撃の起点は AWS そのものへの侵害ではなく、利用者側の IAM アクセスキー流出である。Kaspersky・Mimecast の双方が、攻撃者が大規模に IAM キーを収集し、そのうち SES 権限を持つキーだけを抽出して使っていると指摘する。

流出経路の典型パターン

攻撃者は数千〜数万件の AWS キーを TruffleHog などの OSS スキャナーで自動的に集め、各キーで sts:GetCallerIdentity iam:ListAttachedUserPolicies ses:GetSendQuota を順に叩いて、SES 送信が可能なキーだけを抽出する。

攻撃者の最小コマンド例

侵害後、攻撃者が SES の送信可否を確認する流れはおおむね以下のようになる。再現用ではなく、防御側が CloudTrail で何を検知すべきかを把握する目的で示す。

# 1. キーが有効かと所属アカウントを確認
aws sts get-caller-identity

# 2. 現在のリージョンでSES送信枠の確認
aws ses get-send-quota --region us-east-1

# 3. 既に検証済みのIdentity（送信ドメイン/メール）を列挙
aws ses list-identities --identity-type Domain --region us-east-1

# 4. 各Identityの送信ステータスを確認
aws ses get-identity-verification-attributes \
  --identities example.com --region us-east-1

このシーケンスが侵害判定のシグネチャになる。日常運用では get-send-quota を頻繁に叩くことはなく、list-identities をスクリプトで連続呼び出しするのも珍しい。CloudTrail で eventName を絞り込めば、人間オペレーション以外のパターンが浮かび上がる。

検知が困難な理由 — 認証・IP・ドメインすべてが正規

受信側でこの攻撃が止められない最大の理由は、技術的な「正規性」が三重に揃っているからだ。Kaspersky のレポートはこの点を「認証ベースの検知パイプラインが空振りする」と表現している。

認証チェックがすべてpassする

Authentication-Results: mx.example.com;
  spf=pass (sender IP is 23.249.215.x) smtp.mailfrom=amazonses.com;
  dkim=pass header.d=amazonses.com;
  dmarc=pass action=none header.from=victim-tenant.com;

このような Authentication-Results ヘッダは Amazon SES の正規メールと完全に同一である。フィッシング判定で dmarc=fail を起点にしているフィルタは反応しない。多くの企業向けセキュアメールゲートウェイは、認証 pass の場合は本文スコアリングの閾値を引き下げる仕様のため、攻撃者にとってはむしろ追い風になる。

IPベースのブロックは副作用が大きすぎる

実際、AWS 公式の SES 送信IPレンジは AWS GovCloud などを除いても膨大で、ここを丸ごと拒否すると業務メールの相当数が落ちる。Mimecast や Proofpoint といった商用ゲートウェイも、SES 経由は「conditional trust」として個別判断する設計を取っている。

Message-IDが正規メールと区別不能

SES 経由メールの Message-ID ヘッダは <[email protected]> のような形式になる。この形式は SaaS のトランザクションメールで日常的に観測されるため、ヘッダ単独では正規・不正の判別が付かない。

2026年3月のAmazon偽装コールバック・フィッシング事例

Mimecast が2026年3月に発見・報告した派生キャンペーンは、SES 悪用の応用例として注目に値する。Amazon の正規パスワードリカバリ通知システムを利用しつつ、注文確認の「ユーザー名」フィールドにコールバック先の電話番号を埋め込むという手口だった。

攻撃者は標的のメールアドレスで Amazon にアカウント登録（または既存のアカウント情報変更）を試み、ユーザー名・氏名フィールドに「未承認の注文を確認するには 1-XXX-XXX-XXXX に電話してください」のような文字列を入れる。Amazon が送る正規の確認メールにそのフィールドが反映され、結果として [email protected] の正規アドレスから「未承認の注文がある」「電話してください」といった内容のメールが標的に届く。

Hello,

We've received a request to update your Amazon account.
Username: 未承認の注文 #A-7281: 至急 +1-555-0142 へお電話ください
Date: ...

被害者がそのコールバック番号に電話すると、Amazon カスタマーサポートを名乗る攻撃者が出て、リモート支援ソフトのインストールやクレジットカード情報の口頭聴取に誘導する。SES 経由ではないが、同じ「正規の AWS / Amazon インフラを利用して認証チェックを通すフィッシング」という設計思想を共有しており、コンテンツ解析以外に検知する手段がない点も同様である。

AWS利用者側の防御策 — IAM最小権限とSES監視で踏み台化を防ぐ

最も効果のある対策は「自社のSESを攻撃者に使わせない」ことである。受信側のフィルタは限界があり、踏み台になり得る AWS アカウントすべてが防御を強化することがエコシステム全体の前提条件になる。Kaspersky のレポートも防御策の主軸を AWS 利用者側の IAM・監視に置いている。

IAMアクセスキーを発行しない / 短命化する

長期発行型の IAM ユーザーアクセスキーが流出経路の大半を占める。新規発行を最小化し、既存キーは IAM Identity Center（旧 AWS SSO）または IAM Roles for Service Accounts（IRSA / Pod Identity）に置き換える。CI/CD は OIDC フェデレーションでロール引き受けに切り替えれば、長期キーをリポジトリに置く必要が消える。

# GitHub Actions で AWS にアクセスする際のOIDC設定例
permissions:
  id-token: write
  contents: read

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: aws-actions/configure-aws-credentials@v4
        with:
          role-to-assume: arn:aws:iam::123456789012:role/github-deploy
          aws-region: ap-northeast-1
          # access_key_id / secret_access_key を直接書かない

SES送信ロールの最小権限ポリシー

SES の SendEmail SendRawEmail SendBulkTemplatedEmail をフルに付ける必要があるアプリケーションは多くない。送信元 Identity を絞り、送信先ドメインも条件で制限する。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "RestrictSesSendingToOwnDomain",
      "Effect": "Allow",
      "Action": [
        "ses:SendEmail",
        "ses:SendRawEmail"
      ],
      "Resource": "arn:aws:ses:ap-northeast-1:123456789012:identity/example.com",
      "Condition": {
        "StringEquals": {
          "ses:FromAddress": "[email protected]"
        },
        "ForAllValues:StringLike": {
          "ses:Recipients": ["*@example.com", "*@partner.example.jp"]
        },
        "IpAddress": {
          "aws:SourceIp": ["203.0.113.0/24"]
        }
      }
    }
  ]
}

ses:FromAddress 条件で送信元アドレスを固定し、ses:Recipients で配信先を許可ドメインに限定、aws:SourceIp で社内 / 自社サーバーレンジに縛る。攻撃者が侵害した IAM キーを持っていても、自分のラップトップから叩けば IP 条件で拒否される。

CloudTrailとCloudWatchで送信異常を検知する

SES の送信状況は CloudTrail（API操作）と CloudWatch Metrics（送信実績）の両方を組み合わせて監視する。CloudTrail だけでは「キーが盗まれた」検知が遅れ、Metrics だけでは「どのキーが叩いたか」が分からない。

# Bounce率が3%を超えたらアラート（SESアカウント停止のしきい値が5%/10%なので前段で気付く）
aws cloudwatch put-metric-alarm \
  --alarm-name ses-bounce-rate-alert \
  --metric-name Reputation.BounceRate \
  --namespace AWS/SES \
  --statistic Average \
  --period 300 \
  --threshold 0.03 \
  --comparison-operator GreaterThanThreshold \
  --evaluation-periods 1 \
  --alarm-actions arn:aws:sns:ap-northeast-1:123456789012:security-alerts

# 送信レートが普段の3倍を超えたらアラート
aws cloudwatch put-metric-alarm \
  --alarm-name ses-send-spike-alert \
  --metric-name Send \
  --namespace AWS/SES \
  --statistic Sum \
  --period 900 \
  --threshold 1500 \
  --comparison-operator GreaterThanThreshold \
  --evaluation-periods 1 \
  --alarm-actions arn:aws:sns:ap-northeast-1:123456789012:security-alerts

加えて、CloudTrail で eventName=SendEmail のイベントログを Athena で検索可能にし、sourceIPAddress が普段使わないリージョンや国から発生していないか週次でレビューする運用が望ましい。

.envファイルの誤公開を防ぐ最小ルール

最後に、IAM キーを GitHub に置かないという基本動作を機械的に強制する。.gitignore だけでは不十分で、Pre-commit フックと CI のシークレットスキャンが必要になる。

# .gitignore に最低限入れるべき行
.env
.env.*
!.env.example
*.pem
*.key
credentials
.aws/
secrets/

# pre-commit フックで gitleaks を走らせる
cat <<'EOF' > .pre-commit-config.yaml
repos:
  - repo: https://github.com/gitleaks/gitleaks
    rev: v8.18.0
    hooks:
      - id: gitleaks
EOF

pre-commit install

GitHub Advanced Security のシークレットスキャンも併用すれば、誤って公開された AWS キーを Push 直後に GitHub 側が検出し AWS に通知する。AWS は通知を受けて自動的に該当キーに AWSCompromisedKeyQuarantineV2 ポリシーを当てて使用を制限するが、攻撃者の自動スキャナーが速いと数分で悪用されるケースがあるため、検出されたキーは即時失効・新規発行が必要になる。

受信側の防御策 — 認証pass前提の検知ポリシーへ移行する

完全な遮断はできないにせよ、受信側で取れる対策はゼロではない。前提として「Amazon SES 経由メール = 怪しい」では運用が成立しないため、コンテンツ・送信パターン・リンク先解析を組み合わせる。

コンテンツベースの検知ルール例

• 件名に「電子署名」「契約書」「DocuSign」「Adobe Sign」を含み、かつ送信元ドメインが過去6ヶ月で初めての場合は隔離
• 本文中のリンクが s3.amazonaws.com s3-*.amazonaws.com cloudfront.net のサブドメインで終わる場合は警告
• 添付PDF内の口座番号を OCR で抽出し、過去の取引履歴にない口座への振込指示は人間レビューを必須化
• 「過去のスレッドへの返信」を装う場合、In-Reply-To References ヘッダの Message-ID が自社受信履歴に存在するかを確認

受信側ポリシー比較

ユーザー教育で残せる最後の砦

技術的な検知が抜けた場合、最後に止められるのはエンドユーザーである。Kaspersky のレポートも「認証ヘッダが正規でも、経理担当者が振込前に必ず電話で確認する運用」が最も効果的だと結論づけている。具体的な研修テーマとしては以下が挙げられる。

• 振込先口座変更を伴う依頼は、必ず登録済みの電話番号で発信側に折り返し確認する
• 電子署名サービスからの通知は、メール内リンクではなくブックマーク経由でアクセスする
• リンク先 URL のホスト部を確認する習慣（amzonaws.com と amazonaws.com の違いに気付ける）
• AWS / Amazon の「カスタマーサポート」名乗りからの電話は折り返さず、公式サイトの番号にかけ直す

参照ソース

• Securelist: Amazon SES Phishing Campaigns — Kaspersky GReATの2026年5月レポート
• BleepingComputer: Phishing campaign abuses Amazon SES — 2026年5月の関連報道
• GBHackers: Threat Actors Abuse Amazon SES — SES悪用キャンペーンの解説記事
• Mimecast: Callback Phishing via Amazon Notification — 2026年3月のAmazon正規通知悪用事例
• AWS公式: Amazon SES Sending authorization — 送信権限の最小化に関する公式ドキュメント
• AWS公式: SES Sending Quotas and Throttling — 送信枠とレピュテーションメトリクスの監視
• AWS公式: AWSCompromisedKeyQuarantineV2 Policy — 流出キー自動隔離ポリシー
• TruffleHog GitHub — シークレットスキャンOSS、攻撃者と防御者の双方が利用