2026年9月セキュリティ勧告

Brevoは2026年9月に、顧客プラットフォームおよびインフラストラクチャに関する2つの別個のセキュリティインシデントを開示しました。

最初のインシデントは、138のBrevo顧客アカウントへの不正アクセスに関するもので、複数のアカウントが正規のBrevoインフラストラクチャを通じてフィッシングメールを配信するために使用されました。

数日後、BrevoのCloudflare環境に関する別の侵害により、Brevoが管理するウェブサイトおよび顧客が埋め込んだアセットを通じて悪意のあるJavaScriptが配信されました。

独立したセキュリティ研究者の推定では、2番目のインシデントはBrevoコンポーネントを使用する10万以上のウェブサイトに到達する可能性がありました。

これらのインシデントは、サードパーティのメールおよびマーケティングプラットフォームに依存する組織にとって、ますます重要な現実を浮き彫りにしています:

信頼されたインフラストラクチャは、それを制御するシステムやアカウントが侵害された場合、攻撃チャネルになり得ます。

また、DMARCをp=noneに設定したままのドメインを持つ組織にとって、重要な疑問を提起しています:

あなたのドメインは実際に不正使用に対する保護を強制していますか、それとも単にモニタリングしているだけですか?

I. Brevoで何が起きたのか?

2026年9月に発生したBrevoの2件のセキュリティインシデントを示すタイムライン：9月10日のSAML侵害と9月14日のCloudflare攻撃。

Brevoは2026年9月に2つの異なるセキュリティインシデントを開示しました。

インシデント1:SAML SSOアカウント侵害

2026年9月10日、BrevoはSAMLシングルサインオンの実装に関するセキュリティ問題を特定しました。

Brevoの公式インシデントレポートによると、攻撃者は認可境界の問題を悪用して以下へのアクセスを取得しました:

138のBrevo顧客アカウント

Brevoの報告によると:

  • 6つのアカウントがフィッシングメールの送信に使用されました。
  • 43のアカウントから連絡先がエクスポートされました。
  • 93のアカウントでは攻撃者による意味のある活動は見られませんでした。

Brevoは9月10日UTC 06:30頃に問題を特定し、アクセス経路はUTC 08:30頃までに閉鎖されたと述べています。

同社はまた、プラットフォーム全体のすべてのアクティブユーザーをサインアウトさせました。

Brevoによると、攻撃者はBrevoアカウントを作成し、SSOを設定し、正規のBrevoユーザーをその環境に招待しました。

問題は、ある組織のSSO設定を通じた認証が、その組織に適切に制限されていなかったことで発生しました。

代わりに、攻撃者は招待されたユーザーがアクセスできる他の組織へのアクセスを取得できました。

Brevoは根本原因を、正しく強制されていなかった認可境界と説明しています。

II. フィッシングは正規のBrevoインフラストラクチャを通じて送信された

SAML侵害によりBrevoの顧客アカウント138件が侵害：6件からフィッシングメールが送信され、43件では連絡先がエクスポートされ、93件ではアクティビティが確認されませんでした。

Brevoの開示で最も重要な側面の1つは、フィッシングメッセージが単に無関係なインフラストラクチャから送信されたなりすましメッセージではなかったということです。

それらは正規のBrevoインフラストラクチャを通じて送信されました。

Brevoは明確に次のように述べています:

メッセージは正規のインフラストラクチャから送信されたため、通常のメール認証チェックに合格しました。

この区別は重要です。

SPF、DKIM、DMARCは、メールが技術的に認証されているかどうかを判断できます。

それらは次のような質問に答えます:

  • このサーバーは送信を許可されていましたか?
  • メッセージは暗号署名されていましたか?
  • 認証された送信ドメインは、表示されているFromドメインと一致していますか?

しかし、次の質問には答えられません:

認可されたアカウント自体が攻撃者によって制御されていましたか?

攻撃者が認可されたプラットフォーム上の正規アカウントを侵害し、正しく構成されたインフラストラクチャを通じてメッセージを送信した場合、結果として生成されるメッセージはSPF、DKIM、DMARCに合格する可能性があります。

これが、メール認証をより広範なメールセキュリティアーキテクチャの1つの層として見るべき理由です。

III. 4日後に2番目のBrevoインシデントが発生

2026年9月14日、Brevoは2番目の技術的に異なるセキュリティインシデントを経験しました。

Brevoは、攻撃者が完全なアカウント権限を持つ長期間有効なCloudflare APIキーを取得したことを確認しました。

Brevoによると、その認証情報はアプリケーションのソースコードに保存されていました。

攻撃者は侵害されたAPIキーを使用して、Brevoの環境内に悪意のあるCloudflare Workerをデプロイしました。

そのWorkerは、BrevoのCDNインフラストラクチャを通過するトラフィックを変更できました。

約5時間半の間、悪意のあるJavaScriptが以下に注入されました:

  • brevo.com
  • sendinblue.com
  • Brevoのログイン、アカウント、オンボーディングページ
  • sibforms.com
  • Brevoフォーム
  • Brevo Conversationsウィジェット
  • Brevo SDKローダー
  • Brevo顧客が自社ウェブサイトに埋め込んだJavaScriptファイル

Brevoは、主な影響期間が以下の時間帯であったと報告しています:

9月14日UTC 15:01から20:30まで

ClickFix攻撃

悪意のあるJavaScriptの影響を受けた訪問者は、偽のCloudflare検証ページを見る可能性がありました。

このページはWindowsユーザーに以下を含む操作を指示しました:

  1. Win + Rを押す
  2. コマンドを貼り付ける
  3. そのコマンドを実行する

これらの手順に従うと、被害者のコンピュータにマルウェアがダウンロードされました。

この技術は一般的にClickFixと呼ばれています。

Brevoはまた、影響を受けたBrevoコンポーネントを埋め込んだWordPressウェブサイトで、悪意のあるスクリプトがログインしているWordPress管理者がサイトを訪問した際にプラグインのインストールとアクティベーションを試みたと報告しています。

Brevoは悪意のあるCloudflare Workerを削除し、侵害された認証情報を無効化し、攻撃者が制御するホスト名を削除し、影響を受けたエッジキャッシュをパージしました。

同社は、侵害されたスクリプトは現在安全に使用できると述べています。

IV. 10万以上のウェブサイトが潜在的に露出

Brevoは、影響を受けたJavaScriptを読み込んだ顧客ウェブサイトの正確な数を公開していません。

しかし、Sansecによる独立したセキュリティ調査では、Brevoの埋め込みコンポーネントが10万以上のウェブサイトに存在すると推定されています。

これは、10万のウェブサイトが必ずしも侵害されたことや、すべての訪問者がマルウェアを受け取ったことを意味するわけではありません。

悪意のあるコンテンツは選択的に配信されました。

しかし、潜在的な配信範囲は、信頼されたサードパーティJavaScriptインフラストラクチャが侵害された場合に生じる増幅効果を示しています。

これは典型的なサプライチェーンリスクです。

個別の組織を1つずつ侵害する代わりに、攻撃者は何千もの組織がすでに信頼しているインフラストラクチャを侵害できます。

V. 2つのインシデント、2つの異なるセキュリティ問題

2つのインシデントを技術的に混同しないことが重要です。

それらは異なる攻撃経路を含んでいました。

9月10日

攻撃ベクトル: SAML SSO認可の欠陥

影響: 138の顧客アカウントへの不正アクセス

結果: 正規のBrevo顧客アカウントを通じたフィッシングメールの送信と、一部のアカウントからの連絡先データのエクスポート

9月14日

攻撃ベクトル: 侵害されたCloudflare API認証情報

影響: Brevoウェブサイトおよび顧客が埋め込んだリソースへの悪意のあるJavaScriptの注入

潜在的到達範囲: 独立したセキュリティ調査によると10万以上のウェブサイト

結果: ClickFixマルウェア配信とWordPress永続化の試み

VI. これはDMARCと何の関係があるのか?

どちらのインシデントもDMARCが原因ではありません。

また、どちらのインシデントもDMARC単独で防げたものとして表現されるべきではありません。

しかし、これらのインシデントは、組織がサードパーティサービスが自社ドメインをどのように使用することを許可しているかを正確に理解すべき理由を浮き彫りにしています。

Brevoの現在のドキュメントは、顧客に次のDMARC設定を提供しています:

v=DMARC1; p=none; rua=mailto:[email protected]

p=noneのDMARCポリシーは有効です。

しかし、それが何を意味するかを理解することが重要です。

p=noneはモニタリングを意味する

現在のDMARC標準では、次のように設定されたドメイン:

p=none

はモニタリングモードで動作しています。

受信メールシステムはDMARCを評価してレポートデータを生成できますが、ドメイン所有者はDMARC失敗に基づいた制限的な処理を特に要求していません。

これにより、p=noneは初期のDMARCデプロイメント中に非常に有用になります。

組織は以下を発見できます:

  • どのシステムがドメインを使用してメールを送信しているか
  • SPFが一致しているか
  • DKIMが一致しているか
  • どのサードパーティプラットフォームが許可されているか
  • どの未知のインフラストラクチャがドメインになりすましている可能性があるか

しかし、p=noneはDMARC強制ではありません。

VII. DMARCモニタリング vs 強制

DMARCポリシーの比較：p=noneは監視のみ、p=quarantineは不審なメールを識別し、p=rejectは未承認メールの配信をブロックします。

主要なDMARCポリシー状態は3つあります。

p=none

モニタリング

認証と一致に関する可視性を提供します。

DMARC失敗に基づく制限的な処理の優先設定は要求されません。

p=quarantine

強制

DMARCに失敗したメッセージをより制限的に扱うことを受信者に要求します。

受信プロバイダーによっては、これにはスパム配置、隔離、またはその他の処理が含まれる場合があります。

p=reject

より強力な強制

DMARC検証に失敗したメッセージに対して最も強力なDMARCポリシー設定を表明します。

受信プロバイダーは最終的にメッセージの最終処分に対する制御を保持します。

実用的な違いは:

p=noneはモニタリングします。

p=quarantineとp=rejectはポリシーを強制します。

p=noneがBrevoインシデントを引き起こしたのか?

いいえ。

この点は重要です。

9月10日のインシデントでは、攻撃者が正規のBrevoアカウントへのアクセスを取得しました。

侵害されたBrevoアカウントが適切に認証されたBrevoインフラストラクチャを通じてメールを送信する場合、それらのメッセージはDMARCに合格する可能性があります。

ドメインを次のように変更しても:

p=none

から:

p=reject

へ

侵害された認可アカウントから発信された認証済みの悪意のあるメッセージを必ずしもブロックできるわけではありません。

DMARCはメールの意図や内容を分析しません。

DMARCは異なる質問に答えます:

このメッセージは、それが表明するドメインで認証され、一致していますか?

その区別は根本的です。

VIII. では、なぜDMARC強制が重要なのか?

別の攻撃者を考えてみましょう。

この攻撃者はBrevoを侵害していません。

Microsoft 365へのアクセス権もありません。

Google Workspaceへのアクセス権もありません。

組織の代理でメールを送信することを正当に許可されているプラットフォームを制御していません。

代わりに、攻撃者は単純に次のように送信しようとします:

From: [email protected]

攻撃者が制御するインフラストラクチャを使用して。

そのインフラストラクチャがcompany.comと一致するSPFまたはDKIM認証を提供できない場合、メッセージはDMARCに失敗します。

次の設定では:

p=none

ドメイン所有者は主に失敗をモニタリングしています。

次のような強制ポリシーでは:

p=quarantine

または:

p=reject

組織はその失敗したメッセージに対する制限的な処理ポリシーを表明します。

これがDMARCの最も重要なセキュリティ機能の1つです。

攻撃者が未承認のインフラストラクチャを使用して保護されたドメインを直接なりすます能力を低減します。

p=noneは多くの場合、正しい出発点です

組織はすべてのドメインを直ちにp=rejectに移行すべきではありません。

組織の送信環境を理解せずにそうすると、正規のメールが中断される可能性があります。

現代の組織は、次のようなシステムを通じてメールを送信する可能性があります:

  • Microsoft 365
  • Google Workspace
  • Salesforce
  • HubSpot
  • Brevo
  • Zendesk
  • マーケティングプラットフォーム
  • 請求システム
  • CRMシステム
  • HRプラットフォーム
  • トランザクションメールプロバイダー
  • チケットシステム
  • セキュリティプラットフォーム
  • 内部アプリケーション

強制の前に、これらのシステムを発見し、正しく認証する必要があります。

これがp=noneが多くの場合、適切なデプロイメント段階である理由です。

問題は、それが恒久的なセキュリティ態勢のままであるべきかどうかです。

IX. デプロイされたDMARCは必ずしも強制されたDMARCを意味しない

この区別はしばしば見落とされます。

ドメインは、完全にモニタリングモードで動作しながら、有効なDMARCレコードを持つことができます。

例えば:

v=DMARC1; p=none;

はDMARCが存在することを意味します。

しかし、ドメインは強制に移行していません。

これが、組織が以下を区別すべき理由です:

DMARCデプロイメント

と:

DMARC強制

それらは同義ではありません。

X. 最低限のコンプライアンスは最大限の保護ではない

主要なメールボックスプロバイダーは、バルク送信者に対して認証をますます要求しています。

これらの要件は、エコシステム全体のメールセキュリティを大幅に改善しました。

しかし、多くの送信者要件は次のように受け入れます:

p=none

を最低限のDMARCポリシーとして。

重要な言葉は:

最低限

したがって、企業は、ドメインをモニタリングモードで運用しながら、バルク送信者要件を満たす可能性があります。

エンタープライズ、金融機関、規制対象企業、高価値ブランドにとって、規制またはプラットフォームのコンプライアンスは、最大限のドメイン保護と自動的に同じものと見なされるべきではありません。

XI. Brevo顧客は現在のDMARC設定を確認すべき

Brevoは現在、顧客に次のDMARCポリシーを提供しています:

v=DMARC1; p=none; rua=mailto:[email protected]

Brevoを使用する組織は、これが組織のより広範なDMARCセキュリティポリシーでもあるかどうかを確認すべきです。

ドメインごとに有効なDMARCレコードは1つだけであるべきです。

したがって、組織は、複数のメールプラットフォームが認証を要求するという理由だけで、競合するDMARCレコードを公開することを避けるべきです。

代わりに、サードパーティ送信者は組織の既存の認証アーキテクチャに組み込まれるべきです。

XII. 組織はBrevoを削除すべきか?

これらのインシデントだけを理由に削除すべきではありません。

Brevoが組織が積極的に使用している正規のビジネスシステムのままである場合、認証レコードを突然削除すると、正規のメールが中断される可能性があります。

代わりに、組織は信頼関係を再評価すべきです。

1. Brevoがまだ必要であることを確認する

企業ドメインを使用することを許可されているすべての外部プラットフォームには、正当な現在のビジネス目的があるべきです。

未使用のプラットフォームは無期限に承認されたままであるべきではありません。

2. Brevoアカウントのセキュリティを確認する

組織は以下を確認すべきです:

  • 管理者アカウント
  • SSO設定
  • 特権ユーザー
  • API認証情報
  • SMTP認証情報
  • MFA設定
  • アカウントアクセスログ

3. DMARCポリシーを確認する

組織のドメインが現在次のどれで動作しているかを判断します:

p=none
p=quarantine

または:

p=reject

DMARCレコードの存在がドメインがDMARCを強制していることを意味すると仮定しないでください。

4. すべての承認された送信者を特定する

組織は、現在ドメインを使用してメールを送信しているすべてのプラットフォームを理解すべきです。

未知の送信インフラストラクチャは調査されるべきです。

5. SPFとDKIMの一致を検証する

正規の送信サービスは、正しく一致したSPFおよび/またはDKIMを通じてDMARCを満たすべきです。

これにより、未承認のインフラストラクチャが特定される間、正規のメールが継続できます。

6. 適切な場合は強制に向けて移行する

正規の送信者が発見され認証されたら、組織はモニタリングモードで無期限に継続することが望ましいセキュリティ態勢を反映しているかどうかを評価すべきです。

7. 複数のDMARCレコードを公開しない

ドメインには1つの一貫したDMARCポリシーがあるべきです。

追加の独立したDMARCレコードを追加すると、無効な設定が作成される可能性があります。

9月14日のインシデント後の追加措置

Brevoウェブサイトコンポーネントを使用している組織は、Brevoの修復ガイダンスも確認すべきです。

Brevoは特に、ユーザーが9月14日に悪意のあるコンテンツと対話した場合の措置を推奨しています。

ClickFixコマンドが実行された場合

影響を受けたコンピュータを潜在的に侵害されたものとして扱います。

Brevoは以下を推奨しています:

  • システムを切断する
  • 完全なセキュリティスキャンを実行する
  • デバイスで使用したパスワードを変更する
  • Brevoアカウント認証情報を優先する

WordPress管理者が影響を受けたサイトを訪問した場合

WordPressでBrevoスクリプトを使用している組織は、9月14日にインストールまたはアクティベーションされたプラグインを確認すべきです。

Brevoは疑わしいプラグインを削除し、管理者認証情報を変更することを推奨しています。

ユーザーが9月14日にBrevoにログインした場合

Brevoは予防措置として、アカウントパスワードを変更し、API認証情報を確認することを推奨しています。

XIII. Skysnag顧客がすべきこと

Brevoを使用しているSkysnag顧客にとって、Brevoを承認された送信者として削除する自動的な要件はありません。

Brevoは、Skysnagがより広範なドメイン認証とDMARCポリシーを管理し続ける間、正規の送信プラットフォームとして統合されたままにできます。

既存のSkysnagが管理するDMARC設定は、Brevoがドメイン認証を要求するという理由だけで、一般的なp=noneレコードに置き換えられるべきではありません。

目的は正規のインフラストラクチャをブロックすることではありません。

目的は以下を確実にすることです:

  • 正規のサービスが認証されたままである
  • 未承認のソースがドメインを簡単になりすますことができない
  • DMARCの一致が正しいままである
  • ドメインの強制ポリシーが制御されたままである
  • 送信環境の変更が可視化されたままである

XIV. より大きなセキュリティ教訓

2つのBrevoインシデントは、2つの異なる形式のサードパーティリスクを示しています。

1つ目は以下を示しました:

アカウント承認が失敗すると、正規のメールアカウントがフィッシングチャネルになり得る。

2つ目は以下を示しました:

インフラストラクチャ認証情報が侵害されると、信頼されたWebインフラストラクチャがマルウェア配信チャネルになり得る。

組織は以下の相互接続されたネットワークにますます依存しています:

  • SaaSプロバイダー
  • メールプラットフォーム
  • マーケティングシステム
  • CRM
  • CDNインフラストラクチャ
  • JavaScriptライブラリ
  • クラウドプロバイダー
  • トランザクションメールシステム

信頼された統合はそれぞれ、組織の運用能力を拡大します。

それはまた、信頼境界も拡大します。

つまり、現代のドメインセキュリティは層状でなければなりません。

アカウントセキュリティは、承認されたプラットフォームへのアクセスを保護します。

SPFは送信インフラストラクチャを認証します。

DKIMはメッセージを認証します。

DMARCはドメインの一致を検証します。

DMARCレポートは可視性を提供します。

DMARC強制は、未承認の直接ドメインなりすましに対する保護を強化します。

単一の制御ですべてのクラスの攻撃を解決することはできません。

目的は、これらの制御を連携させることです。

XV. モニタリングはセキュリティ決定につながるべき

DMARC p=noneには重要な目的があります。

強制を導入する前に、組織が送信環境を理解するために必要なインテリジェンスを提供します。

しかし、モニタリングは最終的にセキュリティ決定を通知する場合に最も価値があります。

承認された送信者が特定され適切に認証されたら、組織はp=noneで無期限に留まることが実際に必要とする保護レベルを反映しているかどうかを判断すべきです。

なぜなら、以下の間には重要な違いがあるからです:

誰かがあなたのドメインになりすましていることを知ること

と:

未承認のインフラストラクチャがそれをなりすますことを防ぐことを意図したポリシーを公開すること。

モニタリングは可視性を提供します。

強制はその可視性をポリシーに変えます。

XVI. ドメインを確認する

組織がBrevoを使用していて、ドメインが現在p=none、p=quarantine、またはp=rejectのどれで動作しているか不明な場合、Skysnagは現在のメール認証態勢を評価し、承認された送信インフラストラクチャを特定し、正規のメールを不必要に中断することなく、強制への適切な道筋を決定できます。

Skysnagでドメインを確認してください。