正当なインフラの悪用:メール認証を迂回するフィッシング手口

by

最終更新日:
8 読了時間:約8分
正当なインフラの悪用:メール認証を迂回するフィッシング手口

主なポイント

  • 「正当なインフラの悪用」とは、攻撃者が信頼されているクラウドメール配信プラットフォームを経由して悪意のあるメールを送信し、そのプラットフォームの良好な送信者レピュテーションを悪用するフィッシングの手法である。
  • 使用されているインフラは技術的に正当なものであるため、こうした高度なフィッシング攻撃は、SPF、DKIM、DMARCのチェックを常に問題なく通過しています。
  • 従来のセキュアメールゲートウェイでは、正当なトラフィックに対して甚大な誤検知率を引き起こすことなく、主要なクラウドのIPアドレスをブロックすることができないため、こうした脅威を見逃してしまいます。
  • 攻撃者は、サイバー犯罪フォーラムで盗まれたクラウドプラットフォームのAPIキーをわずか15ドルで購入することで、この種の攻撃を助長している。
  • DMARCの適用によってこれらの攻撃が完全に阻止されるわけではありませんが、DMARCを継続的に監視することで、予期せぬ送信量の異常を検知し、早期警告システムとしての役割を果たします。

次のような状況を想像してみてください。フィッシングメールが企業の受信箱に直接届きます。セキュリティゲートウェイがそれをスキャンし、問題なしとの判定を下します。Sender Policy Framework(SPF):合格。DomainKeys Identified Mail(DKIM):合格。Domain-based Message Authentication, Reporting, and Conformance(DMARC):合格。 このメールは極めて悪質なものであるにもかかわらず、あらゆる防御層を難なく突破してしまいました。なぜでしょうか?それは、このメールが、御社のメールセキュリティツールがすでに盲目的に信頼している、評判の良いクラウドインフラを通じて送信されたからです。

この手口は、インフラの悪用、あるいはメールフィッシングにおいては「リビング・オフ・ザ・ランド」として知られています。攻撃者は、怪しげで短命なドメインを設定する代わりに、定評のある信頼性の高いクラウドメール配信プラットフォームを経由してキャンペーンを展開しています。

これは大きなトレンドとなっています。『Cloudflare 2026年脅威レポート』では、クラウドメールプラットフォームが、高度なフィッシングやマルウェアの拡散において多用される攻撃経路となっていることを指摘し、国家レベルの攻撃主体がこの手法を自らの戦術に積極的に取り入れていると述べています。また、カスペルスキーのセキュリティ研究者らは、2026年1月から、主要なクラウドインフラを経由して送信されるフィッシング攻撃が持続的かつ大幅に増加していることを確認しました

「正当なインフラの悪用」とは何か?

「正規インフラの悪用」とは、攻撃者が専用のインフラではなく、確立された信頼性の高いクラウドメール配信プラットフォームを通じてフィッシング攻撃を展開する手法を指します。エンドポイントセキュリティの分野において、「リビング・オフ・ザ・ランド(Living off the Land)」とは、ハッカーが明らかなマルウェアをインストールするのではなく、PowerShellのようなシステムに標準搭載され、信頼されているツールを使用して攻撃を実行することを意味します。ツール自体が本来その場所に存在すべきものであるため、検知が極めて困難になります。「正規インフラの悪用」は、まさにこの同じ論理をメール配信に応用したものです。

詐欺師たちは、タイポスクワットされたドメインを購入したり、悪意のある専用メールサーバーを立ち上げる代わりに、既存のクラウド型トランザクションメールプラットフォームを乗っ取ったり、そのスペースを借りたりしています。Amazon SES、SendGrid、Mailjet といったプラットフォームが頻繁に標的とされるのは、それらの内部セキュリティが脆弱だからではなく、その非の打ちどころのない送信者レピュテーションが、攻撃者にとって究極の資産となるからです。

攻撃者は通常、主に以下の2つの方法でアクセス権を取得します:

  • 認証情報およびAPIキーの盗難:攻撃者は、既存のクラウドメールアカウントの正規のAPIキーやアカウント認証情報を盗んだり購入したりします。Abnormal AIによると、これらはサイバー犯罪フォーラムで、わずか15ドルという安値で日常的に取引されているとのことです。
  • 乗っ取られた送信ドメイン:攻撃者は、既存の企業ドメインを乗っ取ります。このドメインには、クラウド型メールサービスプロバイダー(ESP)が認証済み送信者として設定されており、長年にわたって築き上げられた送信者レピュテーションをそのまま引き継いでいます。

「インフラの不正利用とは何か」-

なぜメール認証ではこれを防げないのか

認証のギャップ

SPF、DKIM、DMARCといったプロトコルは、ある根本的な疑問に答えるために構築されました。それは、「このメールは、このドメインの正規の送信者から送られてきたものなのか?」という疑問です。攻撃者が正当なクラウドアカウントを乗っ取ったり、ドメインの正規のESP設定を悪用したりした場合、技術的な答えは間違いなく「はい」となります。

このメールは、クラウドプロバイダーのIPアドレスがドメインのSPFレコードに明示的に記載されているため、SPFの検証に合格します。また、プラットフォームがドメインの正しい暗号鍵を使用してメッセージに署名しているため、DKIMの検証にも合格します。最後に、両プロトコルの結果が完全に一致しているため、DMARCの検証にも合格します。

これはDMARCのバグや欠陥ではありません。プロトコルは、設計通りに正確に動作しています。問題は、送信者が認証されているかどうかを確認することと、そのアカウントが依然として実際のドメイン所有者の管理下にあるかどうかを確認することとは、まったく別物であるという点です。

IPレピュテーションによるブロックが失敗する理由

従来のセキュリティツールは、IPレピュテーションスコアに大きく依存しています。あるIPアドレスからスパムが送信されると、そのIPアドレスはブロックされます。しかし、インフラの悪用に対しては、このアプローチは完全に機能しなくなります。

送信元のIPアドレスは、毎日数十億通もの正当な企業メールを処理している大規模なクラウドプロバイダーに属しています。もしセキュアメールゲートウェイ(SEG)がフィッシング攻撃を阻止するためにこれらのIP範囲をブロックした場合、甚大な誤検知率を引き起こし、何千もの無関係な企業にわたって重要なビジネスメールがブロックされてしまうことになります。攻撃者は、この巨大で信頼されている集団の中に身を潜めているのです。

セキュアメールゲートウェイが見落としている理由

ほとんどのSEGは、ドメインの運用期間、既知の悪意のあるリンク、および添付ファイルのシグネチャに基づいて受信メールを評価します。こうした攻撃では、送信元のドメインに不審な点はなく、レピュテーションも申し分なく、認証スコアは100%という完璧な数値を示しています。

さらに、攻撃者は、ESP自体に組み込まれている「オープンリダイレクト」フィッシングの手法を利用して、リンクスキャナーを無力化します。彼らは、メールゲートウェイによって一律にホワイトリスト登録されている、プラットフォーム独自のクリック追跡URLを利用します。ゲートウェイは、信頼性の高い追跡リンクをスキャンしてメッセージを通過させますが、悪意のあるリンク先への転送は、ユーザーがリンクをクリックしたまさにその瞬間にリダイレクトによってのみ実行されます。

その他の手口では、詐欺師たちはリンクを一切含まないビジネスメール詐欺(BEC)の誘引メールを送信することで、URLスキャンを完全に回避しています。彼らは、単純な支払い詳細が記載された無害なPDFファイルを添付したり、請求書の変更に関する偽造されたメールのやり取りを挿入したりし、認証済みのメールにソーシャルエンジニアリングの手法を組み込むことで、被害者を騙そうとします。

実際に「正当なインフラの悪用」とはどのようなものか

実社会では、こうしたキャンペーンは、極めて緊急性が高く、信頼性が高いように見える手口に依存しています。一般的な手口としては、DocuSignなどのプラットフォームを装った偽の電子署名通知、緊急のアカウントセキュリティ警告、経理部門を標的とした請求書詐欺などが挙げられます。

こうした攻撃の温床となっているのは、まさに不適切な認証情報の管理です。ハッカーたちは、公開されたGitHubリポジトリ内のAWS Identity and Access Management(IAM)設定や、誤ってコミットされてしまった.envファイルから、APIキーを日常的に収集しています。

あらゆる要素がうまくかみ合うと、その結果は驚くべきものになります。2026年4月にIRONSCALESが記録した実例では、マイクロソフトの複合認証スコアで100点満点中100点という完璧なスコアを記録したフィッシングメールが注目されました。このメールは、広く利用されているプロジェクト管理ツールを装っており、侵害されたドメインの正規のクラウドESP設定を通じて送信されたため、SPF、DKIM、DMARCの検証を完璧に通過しました。

受信メッセージ:認証結果

認証チェック/メトリックステータス/スコア結果・評決
SPF (Sender Policy Framework)PASS承認済み
DKIM (DomainKeys Identified Mail)PASS承認済み
DMARC(ドメインベースのメッセージ認証)PASS整合済みかつ承認済み
Microsoft 複合認証スコア100 / 100「パーフェクト・トラスト・スコア」

主な調査結果: 認証はされたが、正当なものではない。(IRONSCALESが記録した2026年4月のインシデントに基づく)。

実際に役立つこと:現実的な防御策

率直に言えば、この種の攻撃を完全に阻止できるツールは一つもありません。DMARCだけでインフラの悪用を自動的に阻止できると主張する人は、過大な期待を抱かせていると言えます。しかし、多層的で現実的なアプローチを採用すれば、リスクを大幅に低減することができます。

1. DMARCモニタリング:早期警告システム

認証済みのフィッシングメールは検証を通過してしまいますが、DMARCの集計レポート(RUA)を利用すれば、送信環境の全体像を把握することができます。もし攻撃者がAPIキーを盗み出し、貴社のドメインを使用してクラウドプラットフォーム経由でスパムを送信し始めた場合、その送信量の急激な増加は即座にレポートに反映されます。

DMARCレポート(RUA)を定期的に確認することで、評判への広範な損害が生じる前に、不正なインフラの利用を早期に発見することができます。自動検出を希望するチーム向けに、PowerDMARC DMARC Analyzerは継続的な監視とリアルタイムの異常アラートを提供し、予期せぬ送信元が出現した瞬間にそれを検知します。

2. DMARCの適用:ドメインからの送信メールを保護する

DMARCポリシーを「p=reject」に設定することで、攻撃者が承認済みのクラウドインフラストラクチャ以外の不正な経路を通じてドメインをなりすまそうとした場合、そのメッセージが即座にブロックされるようになります。さらに、厳格な適用を行うことで、ドメインははるかに攻撃されにくい標的となります。インフラストラクチャの悪用が容易な標的を探している詐欺師たちは、緩い「p=none」ポリシーを採用している、防御が脆弱な標的を好んで狙う傾向があります。

3. ESP 認証情報のセキュリティ:エントリポイントを閉じる

認証情報フィッシングを防ぐ最も直接的な対策は、送信インフラの鍵を保護することです。

  • すべてのESP管理者アカウントに対して、多要素認証(MFA)適用してください。
  • 必要な権限を最小限に制限した、適用範囲が厳格に限定されたAPIキーを使用してください。
  • APIキーは定期的に更新してください。
  • 自動コードスキャンを導入し、機密情報がパブリックリポジトリにコミットされることがないよう徹底する。
  • ESPの利用状況ダッシュボードを毎週確認し、異常なトラフィックの急増や、不明な送信者設定がないかを確認してください。

4. 行動分析型メールセキュリティ

従来のゲートウェイは信頼できるインフラに対しては効果が限定的であるため、統合型クラウドメールセキュリティ(ICES)レイヤーが必要です。AIを活用した行動分析型セキュリティツールは、単なるレピュテーション情報だけでなく、コンテキストを分析します。これらのツールは、通信履歴、通常の送信量、言語パターンを精査します。完全に認証済みのアカウントから、普段とは異なる受信者に対して突如として異常な請求書の送付依頼が行われた場合、行動分析型ツールはそれを検知して隔離することができます。

5. 対象を絞ったユーザー意識向上研修

フィッシングメールがすべての技術的な検証チェックを通過した場合、最終的には人間の防御力にかかってきます。従業員は、ブランドイメージが完璧で、送信者アドレスに不審な点がなく、技術的な警告も一切表示されないメールであっても、そのアカウントが乗っ取られている場合は罠である可能性があることを認識できるよう、適切な研修を受ける必要があります。

チームメンバーには、突如として届いた支払指示や口座情報の変更については、別の通信経路(例えば、簡単な電話など)を通じて独自に確認するよう指導してください。また、最初のメールのリンクがどれほど安全に見えたとしても、認証情報を入力する前に、ブラウザの最終的な表示ページを注意深く確認する必要があります。

最後に、従業員は「フィッシングメールチェッカー」を利用するだけで、即座に脅威分析を行うことができます。必要なのは、ヘッダーを含むメール本文全体を貼り付けるだけで、認証記録、送信者の特徴、不審なリンク、緊急性を煽る文面などを確認できます。

フィッシングメールチェッカー

まとめ

企業の脅威モデルは根本的に変化しました。現代の高度なフィッシング攻撃は、もはや不審なランダムなドメインから送信される、形式の乱れたメールに依存するものではありません。攻撃者は、正当なインフラを悪用し、私たちが日々利用し、信頼しているクラウドサービスの便乗を積極的に図り、送信者の認証と真の身元管理との間のギャップを悪用しています。

防御戦略は、この現実に合わせて調整する必要があります。認証プロトコルだけでは問題を解決できませんが、環境を厳重に監視することで、状況は一変します。

今すぐメール環境のセキュリティを確保しましょう:自社ブランドの名義でメールを送信しているのが具体的に誰なのか、正確に把握したいとお考えですか?PowerDMARCのDMARCアナライザーを活用して、セキュリティ境界を管理し、予期せぬ送信行動に関するリアルタイムのアラートを受け取りましょう。

よくあるご質問

メールがSPF、DKIM、DMARCの検証を通過しているのに、なぜセキュリティゲートウェイはそれを通過させてしまうのでしょうか?

セキュリティゲートウェイは、まさにそれらのプロトコルを信頼するように設定されているからです。メールがこれら3つの条件すべてを完全に満たすと、ゲートウェイは、そのメールがドメイン所有者からの正当かつ承認された通信であると判断します。ゲートウェイが確認するのは、そのインフラストラクチャがメールを送信する権限を持っているかどうかであり、キーボードを操作してメールを作成しているのが誰かではありません。

これは、DMARCが機能していない、あるいは役に立たないということなのでしょうか?

とんでもありません。DMARCは、私たちが意図したとおりに機能しています。つまり、悪意のある第三者が何の前触れもなくあなたのドメイン名をなりすますのを防いでいるのです。ただし、攻撃者が盗まれたAPIキーを購入したのか、それともあなたの実際のクラウドアカウントを乗っ取ったのかまでは判別できません。DMARCをハイテクなデッドボルトのようなものだと考えてみてください。泥棒があなたの家の鍵そのものを盗まない限り、完璧に機能するのです。

なぜ、こうしたフィッシングメールを送信しているIPアドレスを単にブロックできないのでしょうか?

なぜなら、それらのIPアドレスは、Amazon SESやSendGridといった大規模で正当なサービスに属しているからです。毎日、何百万通もの通常の安全なビジネスメール(領収書、フライトの予約確認、パスワードのリセット通知など)が、まさにそれらのIPアドレスを経由して送信されています。IP範囲をブロックしてしまうと、悪意のあるトラフィックだけでなく、正当なトラフィックもブロックすることになってしまいます。

ハッカーは、こうしたクラウドメールプラットフォームの認証情報をどのように入手しているのでしょうか?

たいていの場合、原因は単純な人的ミスにあります。開発者がうっかり、GitHubの公開リポジトリにAPIキーを放置してしまったり、ログイン情報がそのまま記載された.envなどのファイルをコミットしてしまったりすることがあります。また、サイバー犯罪フォーラムで、漏洩した有効な認証情報を、わずか15ドルといった安価な金額で購入するケースもあります。

技術的なフィルタが機能しなくなった場合、ユーザー向け啓発研修は実際に役立つのでしょうか?

はい、しかし、従業員の研修方法を変える必要があります。従来の研修では、不審なメールアドレスや認証指標の異常といった「警告サイン」に注意するようユーザーに指導してきました。しかし、インフラの悪用においては、そうした警告サインは見当たりません。研修では、たとえメールがどれほど正常に見えても、突如として通常の手順外で行われる金銭の要求や機密性の高いアカウント情報の更新については、電話をかけて確認するといった「行動上のチェックポイント」に焦点を当てる必要があります。