Cloudflareは2021年のバースデーウィーク中に、Email Routingサービスを発表しました。これは、受信者のアドレスや部署などの基準に基づいて、マーケティング、トランザクション、管理などの異なるタイプのメールメッセージを、別々のアカウントに分けられるようにするものです。その機能とルーティングメッセージの量は、リリース以来大幅に増加しています。
その数か月後の2022年2月23日、当社はメール、Web、ネットワークといった環境におけるフィッシング攻撃からユーザーを保護するために、Area 1 Securityを買収する意向を発表しました。2022年4月1日に買収が完了して以来、Area 1のメールセキュリティ機能は、Cloudflareのセキュアアクセスサービスエッジ（SASE）ソリューションポートフォリオに統合され、現在では毎日数千万のメッセージを処理しています。
当社はお客様に代わり毎日数百万の電子メールメッセージを処理することで、悪意のあるメールがもたらす脅威、スパムの量、SPF、DMARC、DKIMなどのメール認証方法の採用、メールサーバーによるIPv4/IPv6およびTLSの使用によってもたらされる独自の視点を得ることができます。本日、Cloudflare Radarに新しいメールセキュリティセクションを立ち上げ、これらの視点を皆さんと共有します。この新しいセクションで得られるインサイトは、さまざまな指標を見ながらメールセキュリティの現状をよりよく理解し、メールを媒介とする脅威のリアルタイムの傾向を理解するのに役立ちます。（たとえば、組織内で観測された悪意のあるリンクを含むメッセージの増加と、Cloudflareで観測された同様の増加との相関など。）以下では、Radarで利用可能になった新しい指標についてレビューします。
悪意のあるメールの追跡
Cloudflareのメールセキュリティサービスは、お客様に代わってメールメッセージを処理するため、問題のあるメッセージを悪意のあるメッセージとして識別し、分類することができます。例えば、悪意のあるメールは、受信者を騙してログイン情報などの個人情報を共有させようとするものや、メッセージの埋め込み画像、リンク、添付ファイルなどによってマルウェアを拡散しようとするものもあります。Cloudflare Radarに搭載された新しいメールセキュリティセクションでは、選択した時間枠内で悪意があると分類した処理済みメッセージの総割合について、グローバルレベルでのインサイトが提供されるようになりました。2024年2月中に、下図に示すように、平均2.1%のメッセージが悪意のあるものとして分類されたことがわかりました。2月10日と11日に悪意のある電子メールの急増が見られ、メッセージ全体の29%にも上ります。こうしたスパイクは、スーパーボウルの直前に発生し、試合前の1週間に悪意のある電子メールが増加したという過去の観測と一致しています。ほかに、顕著ですが低いスパイクが、2月13日、15日、17日、24日、25日に見られました。悪意のあるメール共有の概要と時系列データは、Radar APIを通じて利用することができます。
脅威の分類
Cloudflare Radar 2023 Year in Reviewでは、悪意のあるメールメッセージを使用して攻撃を行う際に、攻撃者が使用する手口をいくつか取り上げました。前述のように、これにはマルウェアにつながるリンクや添付ファイルが含まれるほか、メッセージが信頼できる相手から送信されているように見えるID詐称や、メッセージが信頼できるブランドから送信されているように見えるブランド偽装などのアプローチも含まれます。Cloudflareのメールセキュリティサービスは、悪意のあるメールメッセージを分析し、これらのメッセージに含まれる脅威を分類しています。（1つのメッセージに複数のタイプの脅威が含まれている可能性があることに注意してください。送信者が信頼できる相手になりすましている一方で、メールの本文には偽のログインページに誘導するリンクが含まれているといったこともあります。）
その評価に基づいて、Cloudflare Radarは現在、「添付ファイル」、「リンク」、「なりすまし」、「その他」を含む脅威タイプの複数の異なるグループについて、観察された傾向に関する洞察を提供しています。「添付ファイル」は、攻撃者がメールメッセージにファイルを添付した個々の脅威タイプをグループ化、「リンク」は攻撃者がユーザーに何かをクリックさせようとする個々の脅威タイプをグループ化、「なりすまし」は攻撃者が信頼されるブランドや連絡先になりすましている個々の脅威タイプをグループ化します。「その他」のグループ化には、前の3つの脅威タイプに含まれない他の脅威タイプが含まれます。
2024年2月中、「リンク」のグループでは、下図が示すように、当然ながらリンクベースの脅威が最も多く、悪意のあるメールの58%に入っていました。HTMLのリンク（いわゆるハイパーテキスト）のテキスト表示は任意設定が可能なため、攻撃者は、実際は悪意のあるURLをあたかも無害なサイトにリンクしているかのように見せかけることができます。悪意のあるメールの約3分の1は、ユーザーの資格情報を収集するように設計されたものにリンクしていました。これらの脅威カテゴリーの要約および時系列データは、Radar APIを通じて利用できます。
「添付ファイル」のグループについては、2024年2月中にメッセージの約13%に悪意のある添付ファイルがあり、攻撃のコンテキスト内で開かれたり実行されたりすると、行動喚起（ターゲットにリンクをクリックするように仕向けるなど）したり、攻撃者が設定した一連のアクションを実行したりします。月間にわたりこの割合は急増し、最大で70%に達しました。メッセージの6%近くの添付ファイルは、開くとすぐに追加のソフトウェア（おそらくマルウェア）をダウンロードしようとしました。
メールメッセージが信頼できるブランドからのものだと思われれば、ユーザーはそれを開封して、荷物の出荷状況の確認や金融取引の検討などの行動を起こす可能性が高いかもしれません。2024年2月、平均して4分の1以上の悪意のあるメールが、有名ブランドになりすました攻撃者から送信されました。他の脅威カテゴリと同様に、このカテゴリでもかなりの急増が見られ、2月17日の時点で88%に達しています。メッセージの18%強が、何らかの方法でユーザーを脅迫しようとしていたことが判明しました。このようなキャンペーンは、バレンタインデー（2月14日）前の週から非常に活発だったようですが、ピークは2月15日で、メッセージの95%以上に達しました。
ID詐欺は、類似するドメインや表示名の操作を使用して、攻撃者または悪意のある人が別の人物を装うメールを送信するときに発生します。これは、2024年2月中に36%以上の悪質メールで見られた「その他」のグループの脅威カテゴリーのトップでした。下の図は、この手法の使用による3つの明らかな「波」を示しています。1つ目は月初旬、2つ目は2月9日頃、3つ目は2月20日頃から始まっています。メッセージの11%以上が、送信元のネットワーク（自律システム）のレピュテーションにより、悪意のあるものに分類されました。一部のネットワークプロバイダーは、悪意のある迷惑メールの送信元としてよく知られています。
危険なドメイン
トップレベルドメインは、TLDとも呼ばれ、ホスト名の一番右側部分にあります。例えばradar.cloudflare.comは、.com汎用トップレベルドメイン（gTLD）で、bbc.co.ukは、.uk国コードトップレベルドメイン（ccTLD）です。2024年2月現在、IANAルートゾーンデータベースには1,600近くのトップレベルドメインが掲載されています。過去15年ほどの間に、「最も危険なTLD」つまり、脅威アクターが最も好むTLDに関するレポートが複数発表されました。こうしたレポートの「トップ」TLDは、通常、小さな国のccTLDと新しいgTLDが混在しているものです。Radarでは、これらの危険なTLDに関するCloudflare独自の視点を共有し、悪意のあるメールやスパムメールの割合が最も高いTLDを強調しています。分析は、メールメッセージのFrom:ヘッダーにある送信ドメインのTLDに基づいて行われます。たとえば、メッセージが[email protected]から来た場合、example.comが送信ドメイン、.comが関連するTLDになります。
Radarでは、スパムと悪意のあるメールの割合を表示することができます。また、時間枠ごと、TLDの「タイプ」ごとにフィルタリングでき、オプションで、すべて（完全なリスト）、ccTLD（国コード）、「従来の」TLD（RFC 1591で指定されるgTLDのオリジナルセットなど）を表示することもできます。ここに示されたスパムの割合は、他の業界の分析で報告された値よりも低い可能性があることに注意してください。Cloudflareのクラウドメールセキュリティをご利用のお客様は、メッセージが処理のためにCloudflareに到着する前に、初回のスパムフィルタリングを実行する場合があります。その結果、Cloudflareがスパムとして特徴付けられるメッセージの割合が低くなります。
2024年2月全体で振り返ると、新しいgTLDアソシエイトとccTLD zw（ジンバブエ）が、それぞれ85%以上で、悪質メールの発信元ドメインで最大の割合となるTLDであることがわかりました。新しいTLDである、academy、directory、barは、関連するドメインから送信されたメールの中でスパムの割合が最大であり、95%以上を占めました。
2024年2月に悪意のあるメールの割合が最も高かったTLD
2024年2月にスパムメールの割合が最も高かったTLD
下図はccTLDを分析するもので、zw(ジンバブエ、85%）とbd（バングラデシュ、50%）のドメインから送られているメッセージの少なくとも半分が悪意のあるものに分類されることがわかりました。zwドメインでは、悪意のあるメールの割合がスパムメールの割合をはるかに上回っている一方、bdとpw（パラオ）ではよりバランスがとれていました。2024年2月に悪意のあるメールに分類されたメッセージは、合計80のccTLDで1%未満でした。
2024年2月に悪質メールの割合が最も高かったccTLD
「古典的な」TLDの中では、悪意のあるメールとスパムの両方の割合が比較的低いことがわかります。当然のことかもしれませんが、最大のTLDであるcomは、2024年2月に両者で最大のシェアを占めています。intドメインとgovドメインの登録に関する制限を考えると、関連するドメインからのメッセージの2%でも悪意のあるものとして分類されているのは興味深いことでしょう。
2024年2月に悪質メールの割合が最も高かった従来のTLD。
一部のTLDが悪意のあるメールやスパムメールの割合を大きくしている理由はさまざまです。登録要件が緩かったり存在しなかったりするものもあれば、いわゆる「ドメインテイスティング」に都合の良いものや、ドメイン登録料が特に安いものもあります。TLDごとの悪質メールとスパムメールの割合についての概要は、Radar APIを通じて利用できます。
メール認証方式の採用
SPF、DKIM、DMARCは3つのメール認証方式であり、これらを併用することで、スパマーやフィッシャーなどの不正な第三者が、自分が所有していないドメインの代わりにメールを送信することを防ぐことができます。
送信者ポリシーフレームワーク（SPF）は、ドメインがメールを送信するすべてのサーバーをリストアップする方法です。DNSのSPFレコードは、ドメインからのメール送信を許可されているすべてのサーバーのIPアドレスをリストアップします。メールを受信したメールサーバーは、受信者の受信箱に渡す前にSPFレコードと照合することができます。DomainKeys Identified Mail（DKIM）を使用すると、ドメイン所有者が、自身のドメインからメールが来たことを数学的に検証するために暗号を使用するデジタル「署名」によって、自動的にそのメールに「署名」することができます。Domain-based Message Authentication Reporting and Conformance（DMARC）は、SPFとDKIMをチェックした結果、受信側のメールサーバーがどのような処理を行うべきかを指示するものです。DMARCレコードに保存されるドメインのDMARCポリシーはさまざまな方法で設定することができ、SPFやDKIM、またはその両方に失敗したメールを隔離する、拒否する、配信するなどの指示をメールサーバーに出すことができます。
これらの認証方法は最近、重要性を増しています。これは、GoogleとYahoo!の両社が2024年第1四半期中にスパムを削減するためのより積極的な取り組みの一環として、一括送信者に、SPF、DKIM、DMARCなどの規格を使用したより強力な電子メール認証の実装を含むベストプラクティスに従うよう求めることを発表したためです。これら3つの方法に対して任意のメールメッセージを評価した場合、潜在的な結果は「成功」、「失敗」、「なし」となります。最初の2つは一目瞭然ですが、「なし」はメッセージの送信ドメインに関連するSPF/DKIM/DMARCポリシーが存在しなかったことを意味します。
2024年2月全体の平均シェアを確認すると、メッセージの93%以上がSPF認証に成功し、失敗したのはわずか2.7%でした。この指標を考慮すると、SPFはDKIMよりもなりすましが容易であり、また、企業のマーケティング部門が、その企業に代わってサードパーティを使用して電子メールを送信するにもかかわらず、そのサードパーティを関連付けられたSPFレコードに追加していない場合など、「シャドーIT」状況によって失敗する可能性があるため、「失敗」という結果に大きな関心が集まっています。2月のDKIM評価では、平均88.5%のメッセージが認証に成功し、失敗となったメッセージはわずか2.1%でした。DKIMの場合、悪意のない理由から特定の署名が検証できていない可能性があるため、検証の「成功」に焦点を当てる必要があります。DMARCでは、メッセージの86.5%が認証に成功し、4.2%が失敗しました。成功と失敗の組み合わせに関心が寄せられますが、これは、関連付けられたポリシーの存在がこの指標にとっての最たる関心事であり、メッセージ認証が成功したか失敗したかということはさほど重要ではないためです。このセクションの3つの方法すべてにおいて、「なし」とは関連するポリシーがないことを示しています。SPF（概要、時系列）、DKIM（概要、時系列）、DMARC（概要、時系列）データはRadar APIを通じて利用できます。
プロトコルの使用状況
Cloudflareは長い間、IPv6の採用を提唱してきましたが、主にこのプロトコルのそれほど新しくないバージョンを介して、Webリソースを利用できるようにすることに重点を置いてきました。ただし、他のインターネットサービスがIPv6のサポートと使用を始めることも重要です。これは、当社の最近の調査においてプロバイダーが不足している可能性があると示されている領域です。
送信者のメールサーバーからCloudflareのメールサーバーへのインバウンド接続を分析することで、IPv4およびIPv6におけるこれらの接続の分布に関する洞察を得ることができます。2024年2月の分布を見ると、接続の95%がIPv4経由であったのに対し、IPv6を使用した接続はわずか5%であることがわかります。この分布は、IPv6対応（デュアルスタック）WebコンテンツへのIPv6リクエストの割合が、同期間に37%であったこととは全く対照的です。IPv4/v6分布の概要および時系列データは、Radar APIで利用できます。
Cloudflareは長年、安全な接続も提唱してきました。2014年のバースデーウィークでUniversal SSLをローンチし、当社のすべてのお客様のサイト（当時約200万サイト）で、エンドユーザーとCloudflare間の安全な接続を可能にしました。この10年間で、SSLはTLSへと進化を完了しました。多くの人々が、TLSはWebコンテンツのみに関連するものと考え、おそらくブラウザのアドレスバーで🔒南京錠を探すように長年指示されてきたためかもしれませんが、TLSはSMTP（メール）、FTP（ファイル転送）、XMPP（メッセージング）など、他のプロトコルでクライアント/サーバー間の接続を暗号化するのにも使用されています。
上述したIPv4/v6分析と同様に、TLSを使用しているCloudflareのメールサーバーへのインバウンド接続の割合も計算できます。接続がTLSで行われる場合、メッセージは転送中に暗号化されます。一方、暗号化されていない接続で送信されたメッセージは、転送中に読み取りや変更できる可能性があります。幸いなことに、Cloudflareのメールサーバーが受信するメッセージの大半が暗号化された接続を介して行われており、2024年2月中に暗号化されていない状態で送信されたメッセージはわずか6%でした。TLSの使用状況の概要と時系列データは、Radar APIを通じて利用できます。
まとめ
若いインターネットユーザーはメールを避け、さまざまなメッセージングアプリを介した通信を優先するかもしれませんが、メールは依然として、個人、企業、オンラインおよびオフライン小売業者、政府などが依存しており、極めて重要なインターネットサービスです。しかし、メールは非常にユビキタスかつ重要で、安価であるため、魅力的な脅威ベクトルにもなっています。Cloudflareのメールルーティングおよびセキュリティサービスは、お客様のメールの管理と安全性の確保をサポートします。また、Cloudflare Radarの新しいメールセキュリティセクションは、セキュリティ研究者、メール管理者、その他の関係者が、悪意のあるメールの脅威、スパムや悪質メールの送信元、およびメールの不正使用を防止するように設計されたテクノロジーの採用に関する最新動向を理解するのに役立ちます。
この新しいセクションに関するご質問は、Cloudflare Radarチーム（[email protected]）またはソーシャルメディア（@CloudflareRadar（X/Twitter）、cloudflare.social/@radar（Mastodon）、radar.cloudflare.com（Bluesky））で受け付けております。
今後もニュースやお知らせ、示唆に富んだ討議をお届けいたします！Security Weekのハブページもぜひご覧ください。