盗まれたパスワードでメール大量送信の「踏み台」にされないために|中小企業が今日からできる防御策

想定読者

本記事は、情報システム部門を持たない中小企業で、メールサーバーやメールアカウントの管理を任されている総務・情報システム担当者の方を想定しています。

SPF・DKIM・DMARCという言葉は聞いたことがあっても、仕組みの細部までは詳しくない方に向けて解説します。

要点

  • 盗んだID・パスワードで正規のSMTP認証(メールを送信するときに行う本人確認の仕組み)を通過されてしまうと、SPF・DKIM・DMARCを正しく設定していても、自社ドメインを使った迷惑メール大量送信の「踏み台」被害は防げません
  • 攻撃は「フィッシングによる認証情報の窃取」→「クレデンシャルスタッフィング(他サービスで使い回したパスワードの悪用)」→「正規ログインとしての大量送信」という段階を踏みます。多くの中小企業のメールサーバーは送信量の上限やログ監視がなく、この流れを途中で止められない構成になっています
  • 完全に防ぐことは難しい前提で、「人為的ミスをなくす対策」と「システムで検知・制限する対策」を組み合わせる二段構えが現実的です

迷惑メールの「踏み台」にされる事件が増えている背景

迷惑メール(フィッシングメールを含む、受信者の意図しない大量メール)が原因でサーバーに侵入され、そこを「踏み台」として別の迷惑メールが大量送信される被害が増えています。

踏み台とは、攻撃者が自社のメールサーバーを乗っ取り、自社の正規のメール送信機能を使って第三者に迷惑メールを送りつける状態を指します。

送信元が自社名義になることで生じるブランドダメージ

踏み台にされた場合、送信されるメールの送信元は自社のメールアドレスやドメインになります。受信した側からは「この会社から迷惑メールが届いた」という事実だけが見え、実際には自社も被害者であるという経緯は伝わりません。

結果として、取引先や顧客からの信頼が損なわれたり、自社ドメインが大手メールサービスの受信拒否リストに登録され、正常な業務メールまで届きにくくなったりする二次被害が起こり得ます。

情報漏洩のような直接的な損害がなくても、ブランドイメージへの影響は小さくありません。

SPF・DKIM・DMARCが正しくても防げない理由

なりすましメールはSPF・DKIM・DMARCで防げるが、盗まれた認証情報による正規ログインはこの仕組みでは防げないことを示す比較図

SPF・DKIM・DMARCは、受信側のメールサーバーが「このメールは本当にそのドメインの管理者が送ったものか」を検証するための仕組みです。

これらを正しく設定していれば、第三者が自社ドメインを「かたって」送った偽のメール(なりすましメール)は見破られやすくなります。

ところが、今回取り上げる被害はこの仕組みの対象外です。攻撃者は自社ドメインを「かたる」のではなく、盗んだ正規のID・パスワードを使って自社のメールサーバーに本物のユーザーとしてログインし、正規のSMTP認証を通過してメールを送信します。

送信元の情報も認証も本物であるため、SPF・DKIM・DMARCの検証はすべて正常に通過してしまいます。

つまり、受信側のなりすまし対策がどれだけ整っていても、送信側のアカウントそのものが乗っ取られている以上、この種の被害を防ぐことはできません。

ここが、一般的に知られている「なりすましメール対策」と本記事のテーマの大きな違いです。

攻撃の典型的な手口を図解で理解する

アカウントを乗っ取られて踏み台にされるまでには、いくつかの段階があります。手口を単純化すると、次のような流れになります。

  1. フィッシングでID・パスワードを窃取する:攻撃者は、取引先や社内システムを装った偽のメールやログインページを使い、担当者からメールアカウントのID・パスワードをだまし取ります
  2. 別サービスで使い回されたパスワードを悪用する(クレデンシャルスタッフィング):窃取した、あるいは別の漏洩事件で流出したID・パスワードの組み合わせを、メールサーバーのログイン画面に次々と試します。複数のサービスで同じパスワードを使い回していると、ここで突破される可能性が高くなります
  3. 正規のSMTP認証を通過する:正しいID・パスワードが当たれば、メールサーバー側からは「本人による正常なログイン」としか見えません。多要素認証(パスワードに加えてスマートフォンなどでもう一段階の確認を行う仕組み)が設定されていなければ、この時点で突破は完了します
  4. 大量送信を行う:乗っ取ったアカウントを使い、自社のメールサーバーを経由して不特定多数の宛先に迷惑メールやフィッシングメールを送信します

パスワード窃取からSMTP認証突破までの流れ

フィッシングでの情報窃取からパスワード使い回しの悪用、SMTP認証の突破、大量送信までの4段階の攻撃の流れを示すフローチャート

この流れで重要なのは、1と2の段階、つまりパスワードが盗まれる、あるいは推測される瞬間が被害の始まりだという点です。

フィッシングメールに気づかず情報を入力してしまう、業務用のパスワードをプライベートのサービスでも使っている、といった人の行動が起点になっています。

技術的な脆弱性を突くよりも、人を狙う手口の方が成功率が高いため、攻撃者はこの経路を好んで使います。

攻撃者が狙う「認証さえ通れば送れる」設定

攻撃者にとって都合がよいのは、「正しいID・パスワードでログインできれば、あとは制限なくメールを送れる」サーバー設定です。

送信件数に上限がなく、短時間に数百件、数千件のメールを送っても誰も気づかない、ログインした時間帯や場所(IPアドレス)を誰もチェックしていない、といった構成がそのまま突破口になります。

これは特別な脆弱性ではなく、多くの中小企業で導入時のまま変更されていない標準的な設定であることが少なくありません。

一般的な中小企業のメールサーバー構成に潜むリスク

送信件数の上限やログ監視、海外ログインの制限がない中小企業の一般的なメールサーバー構成の弱点を示す図

情報システム部門を専任で持たない中小企業では、メールサーバーの設定を導入時のまま運用し続けているケースが多く見られます。

ここに、踏み台被害を拡大させやすいリスクが潜んでいます。

送信件数の上限やログ監視がないケース

一般的に、メールサーバーには1アカウントあたりの送信件数に上限(レート制限)を設ける機能が用意されていますが、初期設定では無効、あるいは非常に緩い値になっている場合があります。

上限がないと、乗っ取られたアカウントから短時間に大量のメールが送られても、サーバーはそれを異常として扱いません。

また、ログイン履行や送信履歴のログを定期的に確認する運用がなければ、被害が発生してから数時間、場合によっては数日経ってから、取引先からの指摘で初めて気づくということも起こります。

海外IPや深夜帯のログインを制限していないケース

社員が海外出張する予定がない、深夜にメールを送る業務がない、といった会社であっても、ログイン可能な場所や時間帯を制限していないケースは珍しくありません。

攻撃者は多くの場合、業務時間外や、普段その会社の社員がアクセスしない国・地域からログインを試みます。

アクセス元の国やIPアドレス、ログインの時間帯に明らかな異常があっても、それを検知する仕組みがなければ、正規のログインとして素通りしてしまいます。

今日からできる防御策|人的対策とシステム対策の二段構え

人的対策とシステム対策を組み合わせた二段構えの防御策の全体像を示す図

ここまで見てきたように、盗んだ認証情報による踏み台被害は、技術的な脆弱性というより「正規の仕組みを正規の手順で悪用される」ことで起こります。

そのため、どれほど対策を重ねても被害の可能性を完全にゼロにすることは難しいという前提に立ち、被害が起きにくくする対策と、起きた際に早く気づいて被害を小さくする対策を組み合わせることが現実的な進め方になります。

対策の種類代表的な取り組み
人的対策教育・MFA・パスワード運用
システム対策送信制限・ログ監視・外部リレー

人為的ミスをなくす対策(教育・多要素認証・パスワード運用)

まず取り組みやすいのが、パスワードが盗まれる機会そのものを減らす対策です。

  • フィッシング訓練を行う:疑似的なフィッシングメールを定期的に送り、社員が不審なメールやログインページを見分けられるようにします。一度の訓練で終わらせず、定期的に継続して実施することが望まれます
  • パスワードの使い回しを禁止する:業務用のメールアカウントのパスワードを、他のサービスや個人のアカウントと共用しないルールを徹底します。パスワード管理ツールの利用を案内するのも有効です
  • 多要素認証(MFA)を導入する:パスワードに加えて、スマートフォンへの通知確認やワンタイムコードなど、もう一段階の確認を必須にします。ID・パスワードが盗まれても、この段階で不正ログインを止められる可能性が高くなります
  • 退職者・休職者のアカウントを速やかに無効化する:使われていないアカウントは、監視の目が届きにくく悪用されやすいため、利用状況を定期的に点検します

システムで防ぐ対策(送信量制限・ログ監視・外部フィルタリングサービス)

人的対策で突破を防ぎきれない場合に備えて、システム側で異常を検知・制限する仕組みを用意します。

  • 送信件数のレート制限を設定する:1アカウントあたり、1時間あたり・1日あたりに送信できるメール数の上限を設定します。上限を超えた場合は自動的に送信を一時停止する設定にしておくと、被害の拡大を早期に食い止められます
  • ログイン・送信ログを監視する:通常とは異なる国・地域からのログイン、深夜帯の大量送信、短時間での連続ログイン失敗などを検知する仕組みを導入します。既存のメールサーバーに監視機能がない場合は、ログを定期的に目視確認するだけでも、被害の早期発見につながります
  • 送信専用の外部リレーサービスを活用する:自社でメールサーバーを運用する代わりに、送信専用の外部サービス(メールリレーサービス)を経由させる方法です。サービスによっては送信量の監視や異常検知の機能が備わっていることがあり、自社で監視体制を整えにくい場合の選択肢になります
  • 不要な認証方式を無効化する:古いメールプロトコルの中には多要素認証を回避できてしまうものがあります。業務で使っていない認証方式やプロトコルは無効にしておくことで、攻撃者が突破口として使える経路を減らせます

いずれの対策も、導入すればそれだけで安心というものではなく、設定後も定期的に見直すことが前提になります。

自社運用が難しい場合は信頼できるWEBサーバーサービスを利用する

ここまで紹介した人的対策・システム対策は、専任の情報システム担当者がいない中小企業にとって、すべてを自社だけで整えるのは負担が大きいことも事実です。

そうした場合に有効な選択肢となるのが、送信量の制限やログ監視、不正アクセス検知といったセキュリティ対策があらかじめ標準機能として備わっている、信頼できるレンタルサーバーやメールサーバーのサービスを利用する方法です。

例えば、Xserverのようなレンタルサーバーサービスや、Zenlogicのような企業向けWEBサーバーサービスでは、送信件数の上限設定やアクセスログの監視、不正アクセスの検知といった機能が標準で提供されています。

サービス例標準的なセキュリティ機能
Xserver送信数制限・ログ監視
Zenlogic不正アクセス検知

自社でこうした仕組みを一から構築・運用するには、専門知識を持つ人材と継続的な監視体制が必要になります。

しかし、これらを標準装備したサービスを利用すれば、専任の情報システム担当者がいない企業でも、一定水準のセキュリティ対策を確保しやすくなります。

自社運用か、サービス利用かは、社内のリソースや体制に応じて検討する必要がありますが、「人手が足りないから対策を諦める」のではなく、「信頼できるサービスに任せる」という選択肢があることを知っておくことは、中小企業にとって現実的な防御策の一つになります。

IPA(情報処理推進機構)の相談窓口にも、迷惑メールに関連した相談が寄せられており、被害に気づいた際の対応や相談先についての案内が公開されています(出典:安心相談窓口だより:迷惑メールへの対応について(IPA))。

自社だけで判断に迷う場合は、こうした公的な相談窓口の情報も参考にすることができます。

まとめ:完璧な防御はなくても、被害を小さくする備えはできる

盗まれた正規の認証情報でメールサーバーに正規のログインをされてしまうと、SPF・DKIM・DMARCをどれだけ正しく設定していても、踏み台にされる被害そのものを防ぐことはできません。

この種の被害は、フィッシングによる認証情報の窃取から始まり、使い回されたパスワードの悪用、正規のSMTP認証の通過、大量送信という段階を踏んで進みます。

完全に防ぎきることは難しいという前提に立ち、パスワードが盗まれる機会を減らす人的対策と、盗まれた後の被害を早期に検知・制限するシステム対策を両方用意しておくことが、現実的な備えになります。

まずは自社のメールサーバーに送信件数の上限があるか、ログインの異常を検知できる仕組みがあるかを確認するところから始めてみてください。

▼略歴

  • 東京都世田谷区生まれ
  • 経営・財務の分野を学び、建設・不動産業界にて経理部に在席。
  • 家電メーカーにて直営店舗の運営やマーチャンダイザーを経験。PCのBTOビジネス推進やホームネットワークの普及推進、デジタル家電活用のセミナー講師、直営の免税店を経験。
    同時に、グループ企業のWEBマスターとして、ポータルサイト、eコマースサイトの制作・運営、情報セキュリティマネジメント、ナレッジマネジメントを推進。
  • 家電量販店にて情報部門リーダー、都心店舗の店長を経験。
    その後、店舗開発部で新店舗出店時のレイアウト設計やスタッフの育成、出店準備、VMDの企画・制作などを歴任。
  • システムインテグレーターとして、手術室及び血管造影室の画像・映像配信システムの開発・設計、エンジニアリングを担当。さらに、遠隔手術支援システムの企画・開発を担当し、専門誌へ医師の偏在問題に関する論文を寄稿。
    また、医療向けシステムやフェリーの設備を安全にリモートメンテナンスするソリューションを開発・運用。
    その後、会社のリブランディングプロジェクトへの参画、デジタルマーケティング組織の立ち上げ、メディカル組織のマネジメントを経験。
  • 論文 医師偏在の課題と向き合う遠隔手術支援ソリューション(CiNiiで検索)
  • 論文 手術室の生産性向上に貢献する医療映像ソリューション(CiNiiで検索)
  • 現在、企業向けにIT技術者育成セミナー(ネットワーク/ウェブデザイン等)を主催しております。