メール送信サービスのキー悪用、11万通の踏み台に

メール送信サービスのキー悪用、11万通の踏み台に インシデント対応

衣料品・寝具メーカーのTENTIALが利用していたメール送信サービスのアクセスキーが第三者に不正利用され、同社の正規メールアドレスから約11万通のフィッシングメールが送信されました。攻撃者は正規の鍵で正規の送信基盤を使ったため、送信元は本物のドメインです。受信側のなりすまし対策（SPF・DKIM・DMARC）はすべて「正当」と判定します。

情シスにとっての要点は「自社が知らないうちに同じ構造を抱えていないか」です。メール送信サービスの鍵は開発チームやマーケティング部門が発行し、情シスの資産台帳に載らないまま何年も生き続けます。

この記事でわかること

  • 正規の送信基盤が乗っ取られると、なぜドメイン認証で止まらないのか
  • 自社ドメインがどのメール送信サービスに送信を委任しているかを調べる方法
  • 被害の本体は「顧客情報の漏えい」ではなく「ドメインの評判の毀損」であること
  • アクセスキーの棚卸しが現場で進まない理由と、現実的な優先順位

メール送信サービスとは何か（「うちは使っていない」は疑ってよい）

メール送信サービスとは、アプリケーションから大量のメールを確実に届けるための外部送信基盤です。注文確認、パスワードリセット、会員登録通知といった自動送信メールを、自社メールサーバではなく専用事業者の設備から送り出します。代表的なものにAmazon SES、SendGrid、Mailgunなどがあり、アプリ側は発行されたアクセスキー（APIキー）を使ってAPIやSMTPで送信を依頼します。

問題は導入した記憶がなくても使っていることが多い点です。ECサイト構築サービス、会員管理SaaS、マーケティングオートメーションツール、問い合わせフォームのプラグイン——これらは内部でメール送信サービスを利用していることがあり、送信元はあくまで自社ドメインの noreply@ です。情シスが管理するメールサーバのログには一切残りません。自社がどの送信サービスを使っているかは推測ではなく、後述するSPFレコードの確認で事実として洗い出せます。

何が起きたのか

TENTIALの公表（2026年7月28日）によると、事実関係は次のとおりです。

項目 内容
発生日時 2026年7月25日20時ごろ〜7月26日5時ごろ（約9時間）
送信件数 概算で約11万通
悪用された送信元 noreply@tential.jp、info@tential.jp、noreply@kencoco.com（いずれも自動送信用アドレス）
メールの件名例 「Abonnement PrimeVideo」など複数
侵害された資格情報 メール送信サービスのアクセスキー。メール送信に特化しており、顧客情報の閲覧権限は持たない
顧客情報への影響 顧客データベースへの不正アクセス・個人情報の漏えいは確認されていない（公表時点）
対応 該当アクセスキーの無効化、不正送信経路の遮断。以後の不正送信は停止
原因 キーの流出経路は公表されていない（調査継続中とされる）

件名の「Abonnement PrimeVideo」はフランス語で「Prime Videoの定期購読」を意味します。日本の消費者向けとは考えにくく、悪用されたキーに顧客情報の閲覧権限がなかったという説明とあわせると、宛先リストは攻撃者側が用意したものである可能性が高いと見られます。ただし宛先の出所は公表されていないため、断定はできません。

なお、原因が特定できていない段階でも「自社ドメインから不審メールが出ている」という事実を発生から3日で先に告知した判断は、受信者保護の観点から妥当だったと言えます。

なぜ「なりすまし対策」では止まらないのか

答えは単純で、これはなりすましではないからです。攻撃者は正規のアクセスキーを使い、正規の送信サービスから、正規のドメインで送信しました。

SPFは「そのIPアドレスがそのドメインの送信を許可されているか」を、DKIMは「署名鍵が正当か」を検証します。今回はどちらも本物です。したがってDMARCも当然パスします。送信ドメイン認証は「他人が自社を騙る」ことは防げても、「他人が自社の鍵を握る」ことは防げません。ここを混同すると、「DMARCをp=rejectにしているから大丈夫」という誤った安心につながります。

受信側から見れば、本物のドメインから来て、認証もすべて通り、日頃から注文確認メールを受け取っている送信元です。フィッシングとしての成功率は、無関係なドメインから送るものと比べものになりません。手口そのものについてはフィッシングとは？仕組み・手口・情シスが取るべき対策もあわせてご覧ください。

では何で気づけるのか

内容ではなく量とパターンの異常でしか気づけません。現実的な検知点は次の3つです。

  • 送信サービス側の送信量アラート：多くのサービスに送信数の閾値通知やダッシュボードがあります。深夜帯に平常時を大きく超える送信が9時間続いた形なので、閾値アラートが設定されていれば早期に止められた可能性があります。
  • DMARC集約レポート（rua）：自ドメインを送信元とするメールの発生源と件数が日次で届きます。受信設定をしていない組織が多いのですが、こうした事象では最も分かりやすい証跡になります。
  • バウンス・苦情率の急増：存在しない宛先への大量送信はバウンス率を跳ね上げます。送信サービス側が自動で送信停止をかけることもあります。

いずれも「誰かが見ていれば」機能する仕組みです。深夜に発報しても翌朝まで誰も見ない、という運用では意味がない点は正直に申し上げておきます。

本当の被害は「ドメインの評判」に出る

今回は顧客情報の漏えいが確認されていません。しかし情シスに直撃するのはむしろ二次被害のほうです。

自社ドメインから11万通のフィッシングメールが出れば、大手メールプロバイダからの評価は下がります。その結果、本来届くべき正規のメール——パスワードリセット、注文確認、請求書、採用連絡——が迷惑メールフォルダに入る、あるいは拒否される状態が起こり得ます。回復には時間がかかり、その間の問い合わせ対応はすべて現場に降ってきます。

過去にも、アカウントを乗っ取られて外部へのスパム送信の踏み台にされた事例があります（アカウント乗っ取りでスパム踏み台に 日中経済協会の事例）。構造は違っても、「自組織の正当性が攻撃の武器として使われる」という点は共通しています。

自社は大丈夫か：まず30分でできる確認

資産台帳の整備を待たずに、いま調べられることがあります。

1. SPFレコードで「送信を委任している先」を洗い出す

自社ドメインのSPFレコードには、送信を許可した外部サービスが include: の形で並んでいます。ここに見覚えのないサービスがあれば、それが「誰かが使っている送信基盤」です。

Windowsのコマンドプロンプトなら次のとおりです。

nslookup -type=txt example.jp

返ってきた v=spf1 で始まる行の include: を数えてください。3つも4つも並んでいて、それぞれが何のためか即答できないなら、そこが管理の空白です。DKIM用のCNAMEレコード（セレクタ名にサービス名が入ることが多い）も同様の手がかりになります。

2. 洗い出したサービスごとに「鍵の一覧」を出す

管理コンソールで発行済みのアクセスキーを一覧し、発行日・最終使用日・用途・発行者を確認します。最終使用日が何年も前のキーは、まず無効化の候補です。発行者が既に退職しているキーが出てくることも珍しくありません。

3. 権限とIP制限を見直す

今回、被害が送信だけで止まった直接の理由はキーの権限が送信に限定されていたことです。もし同じキーで顧客情報が読めていれば、事案の性質はまったく別のものになっていました。これは最小権限の原則が実際に効いた事例として評価すべき点です。あわせて、送信元IPの制限、送信可能なFromアドレス・ドメインの制限、用途ごとのキー分離が設定できるかを確認してください。

現場目線の課題：鍵の棚卸しはなぜ進まないのか

正論としては「アクセスキーを台帳化し、定期的にローテーションする」で終わりです。しかし現場で進まない理由ははっきりしています。

  • 止めていいか誰にも分からない：あるキーがどのバッチ処理から使われているかを追える人が社内にいない。無効化して深夜の配信が止まれば責任は情シスが負う。だから触らない、という判断が積み重なります。
  • そもそも情シスが発行していない：事業部門がSaaSを契約し、開発委託先が設定し、鍵は納品物のどこかに書かれている。契約が終わってもキーは生き続けます。
  • ローテーションに手が回らない：鍵の差し替えには参照元の全システムの設定変更が要ります。事故が起きていない対象への計画的作業は、常に後回しになります。

現実的な落としどころは、全数棚卸しを目指さないことだと考えています。まず「外部に大量送信できる権限を持つキー」と「顧客データを読めるキー」の2種類に絞って所在を確認する。この2つは事故時の影響が桁違いに大きく、数もそれほど多くないはずです。ここだけなら着手できます。

情シスはどうすべきか（公的指針の活用）

自組織のドメインが踏み台にされた場合、技術的な封じ込めと同時に、受信者への注意喚起という対外対応が発生します。手順を自前で組み立てる前に、公的なガイドラインを土台にしてください。

  • フィッシング対策協議会「フィッシング対策ガイドライン 2026年度版」（事業者向け）：自社を騙るフィッシングが発生した際の事業者の要件と対応が体系的にまとまっています。https://www.antiphishing.jp/report/guideline/
  • 総務省「迷惑メール対策」：送信ドメイン認証技術（SPF・DKIM・DMARC）の解説と国内の普及状況。経営層への説明資料としても使えます。https://www.soumu.go.jp/main_sosiki/joho_tsusin/d_syohi/m_mail.html
  • IPA「中小企業の情報セキュリティ対策ガイドライン」：クラウドサービスの利用管理を含め、体制づくりの基礎から確認できます。https://www.ipa.go.jp/security/guide/sme/about.html
  • IPA「対策のしおり」：従業員向けの啓発資料。正規ドメインから届くフィッシングが現実にある以上、「送信元アドレスが本物なら安全」という思い込みを崩す教育が要ります。https://www.ipa.go.jp/security/guide/shiori.html

特に最後の点は軽視できません。「送信元ドメインを確認しましょう」と教えてきた組織ほど、正規ドメイン発のフィッシングには弱くなります。伝えるべきは「差出人が本物でも、リンク先と入力を求められる情報で判断する」という一段深い基準です（スピアフィッシングとは？フィッシングとの違いと情シスの実態）。

まとめ

  • 正規の鍵を握られた送信はSPF・DKIM・DMARCをすべてパスする。送信ドメイン認証は「騙り」を防ぐ仕組みであり、鍵の不正利用は止められない。検知は送信量の異常・DMARC集約レポート・バウンス率で行うしかない。
  • 自社ドメインのSPFレコードの include: を確認すれば、どの外部送信サービスに送信を委任しているかがその場で分かる。台帳に載っていない送信基盤の洗い出しはここから始められる。
  • 被害の本体は顧客情報ではなくドメインの評判である。正規メールが届かなくなる二次被害は長引き、対応は情シスに集中する。優先すべきは「大量送信できる鍵」と「顧客データを読める鍵」の権限限定と所在把握。

出典

タイトルとURLをコピーしました