― セキュリティの“盲点”を突いた4つの仕組み ―
はじめに
2025年4月、ある極めて巧妙なフィッシング攻撃が報告されました。
表面上はGoogleからの正当なセキュリティ通知に見えるこのメール、実は巧妙な技術によってGoogle自身のインフラと認証機構（DKIM）を逆用した偽装メールでした。
しかも、Gmailで一切の警告表示なし。
多くのユーザーが“本物”と信じてしまうのも無理はありません。
今回は、このフィッシングがなぜ成立したのか、その「4つの仕組み」を分解しながら解説します。
正規のGoogleメールを“合法的”に取得する
攻撃者はまず、Google自身が発行する署名付きメールを手に入れる必要があります。
そのために取った手段が、自らGoogleアカウントを作成し、OAuthアプリを登録するというもの。
me@phishing-example.comのようなGoogleアカウントを作成- OAuthアプリをこのアカウントに連携
- Googleが「このアプリがアカウントにアクセスした」というセキュリティ通知を送信
この通知メールはGoogleが発信した正規メールなので、DKIM署名付きかつDMARC・SPFも通る完璧な正当メールです。
補足：メール認証技術 ― SPF・DKIM・DMARCの基本
現在のメールセキュリティでは、SPF・DKIM・DMARCという3つの仕組みが、送信者のなりすまし防止（なりすまし対策）のために広く使われています。
– SPF（Sender Policy Framework）
「どのサーバーから送っていいか」を制限する仕組み
- ドメイン所有者は、自分のドメインからメールを送信してよいIPアドレスのリストをDNSに登録
- 受信側は、実際の送信元IPがそのリストに含まれているか確認
- 正しくないサーバーから来た場合は、「このメールは偽物の可能性あり」と判定される
例：example.comは「192.0.2.10 だけが送信してよい」と定義 → 別のIPなら失格
– DKIM（DomainKeys Identified Mail）
「メールが改ざんされていないか、正規に署名されたか」を検証する仕組み
- メール送信時に、ドメイン所有者の秘密鍵で署名を生成
- 受信側は、DNSに公開されている公開鍵で検証し、整合性を確認
- 改ざんや不正送信があれば、署名の整合性が取れず検知される
今回の攻撃では、この仕組みを“合法的な署名付きメールの再利用”で回避されている点が問題
– DMARC（Domain-based Message Authentication, Reporting and Conformance）
SPFとDKIMの結果を元に、どう扱うかをポリシー化する仕組み
- ドメイン所有者が、SPF・DKIMが失敗したときにどうするか（拒否・隔離・受け入れ）を定義
- また、なりすましが発生した場合のレポートも受け取れるようにできる
- Gmailなどの大手メールプロバイダは、DMARCに従ってメールを処理する
正しく設定されていれば、なりすましメールの受信を未然に防げるはずだったが…
今回のようにSPF・DKIMの両方を回避されて“通ってしまった”場合には意味をなさない
なぜ突破されたのか？
今回のフィッシングでは
- SPF：転送元が異なるドメインなので無効化される可能性はある
- DKIM：正規署名付きメールをそのまま使用 → 完全に通過
- DMARC：SPF or DKIMのいずれかが通ればOK、なので回避された
→ この“技術のすき間”を突くのが、今回の攻撃の巧妙さです。
DKIMリプレイによる“認証済みメール”の再送信
次に、攻撃者はこの正規メールを他者に転送することで、認証を偽装します。
- Outlookなど外部メール経由で、署名をそのまま保持した状態で転送
- Gmailでは「DKIM署名が正しい」と認識し、フィルタリングや警告なし
こうして、まるでGoogle本体から届いたかのようなメールが、ターゲットの受信箱に届きます。
実際の攻撃シナリオ（今回の例）
- 攻撃者は、自分のGoogleアカウント（
me@fake-domain.com）で正規のセキュリティ通知メールを入手（DKIM付き） - このメールを、別のメールサービス（例：Outlook）から第三者に転送
- 本文やヘッダーが改変されていないため、受信者側のメールサーバは「DKIM署名OK」と判定
- DMARC検証にも合格し、スパム判定も回避される
– なぜ防げないのか？
- DKIM署名はメール全体の整合性を守るが、再送の事実までは追えない
- 転送元（MTA）が変わっても、「内容が同一であればOK」という前提を突かれる
- 正当なメールの“使い回し”という、グレーゾーン的な悪用方法
– 対策は？
現時点では、受信者側だけでDKIMリプレイ攻撃を完全に検出するのは困難です。
そのため
- ドメイン管理者側でDMARCポリシーを厳格に設定する（
p=rejectなど） - MLAT（Mail Transfer Agent）レベルでの転送制限や再署名処理
- メールの異常転送パターンを検知するAI/ML型フィルタの導入
といった多層的なアプローチが必要です。
Google Sitesを使って偽サイトをホスティング
メール内のリンク先は、Googleのサブドメインである sites.google.com。
- 本物のGoogleサポートページに似せた見た目
- 「ケースを表示」「追加資料をアップロード」といった選択肢をクリックすると、
- Googleログイン画面そっくりの偽ページに誘導され、ID・パスワードを盗まれる
Google Sitesは古いサービスで、自由にHTMLやJavaScriptが埋め込める仕様。
それが、こうした偽装に悪用されました。
GmailのUI特性を使った“見せかけの信頼”
メールの宛先が me@～ の場合、Gmailは「To: me」と表示します。
攻撃者はこれを逆手に取り、アカウント名をあえて「me@～」に設定。
結果として、Gmail上では自分あての正式な通知のように見えるのです。
ユーザーが気づくためのヒントを、Gmailの表示仕様ごと潰す。これが最後の一手でした。
まとめ：技術と心理の“隙間”を突いたフィッシング
このフィッシングは、以下のような認証技術の“前提”を逆手に取る攻撃です：
| 手口 | 信頼の誤認誘導 |
|---|---|
| DKIM署名の再利用 | メール認証技術そのものの信頼性を逆用 |
| Googleドメインの利用 | ドメインベースの信頼判断を回避 |
| Gmail UIの利用 | 表示上の「本物らしさ」で心理的警戒を低下 |
対策について
現時点では、受信者側だけでDKIMリプレイ攻撃を完全に検出するのは困難です。
そのため、次のような多層的な防御が求められます。
- ドメイン管理者側でDMARCポリシーを厳格に設定する（例：
p=rejectで不正メールの拒否） - メール転送時の再署名（再DKIM）やMTA側での転送制御
- AIや機械学習を活用した異常検知型メールフィルタの導入
- ユーザー教育とフィッシング模擬訓練
補足：BIMI + VMC による“視覚的な信頼性の付与”
さらに最近では、視覚的な要素で信頼性を補強する技術も普及しつつあります。
– BIMI（Brand Indicators for Message Identification）
- 正式な送信ドメインから届いたメールに、その企業のブランドロゴを表示する仕組み
- 受信者は、一目で“本物の企業から来たメール”かどうかを識別可能
– VMC（Verified Mark Certificate）
- BIMIを支える証明書ベースの仕組み
- ブランドロゴが認証局（CA）によって検証済みであることを証明
- DMARCポリシーが適切に設定されていることが前提条件
効果と限界
| メリット | 説明 |
|---|---|
| ユーザーが視覚で真贋を判断できる | ロゴ付きかどうかで不審メールを見分けやすくなる |
| ブランド保護にも有効 | 正規の企業ドメインを詐称する攻撃への抑止力 |
ただし、送信ドメインが正しくてもメール本文に偽リンクが含まれるケースなど、BIMIだけでは防ぎきれない攻撃も存在します。あくまで多層防御の一要素として導入するべき技術です。
最後に
攻撃者は、日々セキュリティの「盲点」を狙って手法を進化させています。
技術だけでなく、視覚・心理・行動のすべてにまたがるセキュリティ対策が求められています。
