チェックが「OK」でも、メールはうそをつく

数十年前に生まれた技術の舞台裏で、攻撃者たちはルールを逆手に取る方法を身につけてきました。メールには身元確認の仕組みが追加され、それはきちんと機能しています。けれども、その仕組みが答えるのは「このメッセージはどこから来たのか？」という問いだけです。いちばん大切な「その内容は本当か？」には答えてくれません。

最初のうそ：「こちらはあなたの銀行です」

話は1通のメールから始まります。毎日何千通と届くメールと同じようなものです。

差出人：support@mybank.example
件名：⚠️ お客様のアカウントは本日停止されます

ロゴ、署名、アドレス、きちんとした文面。すべて普通に見えます。でも、このメッセージを本当に送ったのは誰でしょうか？

ここで、インターネットの奇妙な遺産が見えてきます。メールはもともと、送信者の身元を証明するようには設計されていなかったのです。

書留ではなく、はがき

メールを送るのは、はがきを出すのに少し似ています。文面を書き、差出人の名前を書けば、郵便配達員が届けてくれます。でも配達員は、書かれた名前が本当にそのはがきを投函した人のものかどうかは確かめません。（この配達員の道のりを順に追うには、ガイドメールは送信者から受信者までどう届くのかをご覧ください。）

最初のメールのプロトコルは、ほとんど全員が顔見知りのような小さなインターネットで生まれました。信頼は当たり前のものでした。いまでは同じ技術が、私たちの通信の膨大な部分を運んでいます。すべてを止めてメールを作り直すことはできません。飛行中の飛行機のエンジンを交換するようなものです。

入口の3人の検査官：SPF・DKIM・DMARC

作り直せない以上、エンジニアたちは上から身元確認の仕組みを重ねました。技術的な定義で覚えるより、受信箱の入口に立つ3人の登場人物として想像してみましょう。

• 探偵の SPF：「このマシンに、このドメインとしてメールを送る権利はある？」ドメインは許可したサーバーの一覧を公開しており、探偵はそれを照合します。
• 封印の番人の DKIM：「メッセージにドメインのデジタル署名はある？ その署名は無傷？」封蝋のように、メッセージが本当にそのドメインの設備から送られ、途中で書き換えられていないことを示します。
• 用心棒の DMARC：「合わないときはどうする？」ドメインが指示を残しています。通す、迷惑メールに入れる、または拒否する。

紙の上では万全に見えます。では、攻撃者はなぜ今もすり抜けるのでしょうか？

どんでん返し：本物のメールなのに、詐欺

ここが問題の核心です。3人の検査官が確かめるのは、メッセージの技術的な身元です。ところが、まったく正当な技術的身元を手に入れる方法が少なくとも4つあります。

わなその1：ほぼ完璧なにせドメイン

攻撃者は、銀行のものと見分けがつかない自分のドメイン名を買います。

support@mybank-pr1vate.example   （mybank-private ではない）

「i」がたった1つの「1」に置き換わっています。攻撃者は SPF・DKIM・DMARC を正しく設定します。自分のドメインなので、その権利があるのです。検査官たちはまったく正直にこう答えます。✅「このドメインには、このメッセージを送る権限があります」。その一方で、読む人の脳はこう読みます。😱「うちの銀行だ！」

ツールが確かめるのは誰が送ったかです。メッセージの意図までは理解しません。

わなその2：忘れられた裏口

大きな銀行は何百ものサブドメインを持っています。キャンペーン用、昔の懸賞用、5年前に終了したサービス用……。どこかにはまだ promo.old-bank.example が残っていて、もう誰もきちんと管理していません。

そのサブドメインが、もう存在しないサービスを指したままだったり、保護が甘かったりすると、攻撃者がその管理権を奪えることがあります。正面玄関をこじ開ける必要はありません。みんなが忘れてしまった通用口を探すだけでよいのです。そして、そこで公開されるものには銀行の本物の名前が付いています。

わなその3：本物の鍵を盗む

攻撃者がにせのアドレスすら作らなかったら？ たとえば以前のフィッシングで本物の従業員のパスワードを盗めば、攻撃者のメールは企業の本物の設備から送られます。SPF・DKIM・DMARC は通常どおり機能します。当然です。すべてが本物なのですから。今回はにせの身元ではありません。本物の身元を、別の人間が使っているのです。

わなその4：みんなが使うツールに紛れ込む

企業はニュースレターやキャンペーンを、よく知られ、フィルターからの評価も高い専用プラットフォームで送ります。設定が甘かったり、そこにある顧客アカウントが乗っ取られたりしていれば、攻撃者はそのプラットフォームを悪用しようとします。つまり攻撃者は、いつも自前の仕組みを作るわけではありません。他人の仕組みに入り込み、目立たずに紛れることもあります。こうした送信の手口は、ガイドフィッシング：詐欺師はどうやってメールを届けているのかで詳しく説明しています。

攻撃者が来る前から、問題が始まっていることもある

現場に戻りましょう。メールサーバーは、動いているからといって安全だとは限りません。

コピー＆ペーストのわな

ある管理者が「Postfix サーバー 手早く構築」と検索します。手順書を見つけ、コマンドをコピーすると……動きました。これで終わり？ そうとは限りません。すぐに動かせる設定が、攻撃に耐えるよう調整された堅牢化済みの設定だとは限らないのです。

スパム送信機になるサーバー

設定を誤ると、サーバーがオープンリレー（open relay）になることがあります。本来は自分の利用者だけにサービスすべきなのに、誰のメッセージでも中継してしまうマシンです。攻撃者にとっては願ってもない話です。評判のよい正直なサーバーが、代わりにメールを送ってくれるのですから。

しかも手作業で探す必要はありません。流れは単純で、スキャン → テスト → 発見 → 悪用。これは簡単に自動化できます。ですから、画面の前で被害者を探す攻撃者がいるとは限りません。多くの場合、昼も夜も、機械が別の機械を探しているのです。

考えている間に、機械はもう攻撃している

悪意のあるメールは、数分のうちに送信 → 受信 → 開封 → クリック → 悪用まで進みます。その間、守る側では、システムがメッセージを分析し、チームが警告を受け取り、誰かがそれを読み解き、フィルタールールを更新しなければなりません。1分1分が大切です。

ここから、シンプルな考えが導かれます。誰も見ていないセキュリティシステムは、やがて本当の意味で安全ではなくなる。ルールは古くなり、攻撃者は適応し、警告は読まれないまま積み上がっていきます。

この数分を稼ぐために作られたのが Baitback です。怪しいメールを貼り付けると、実際に送信したサーバーとそのホスティング事業者を突き止め、通報を準備します。送信サーバーを早く通報すればするほど、早く停止してもらえます。

メールを絶対に安全にできるのか？

おそらく、1つの技術だけでは無理です。問題にはいくつもの層があるからです。

• 📨 プロトコル：別の時代に、別のインターネットのために設計された。
• 🔐 インフラ：設定ミスがあったり、古くなっていたり、忘れられていたりする。
• 🤖 検知システム：膨大なことを見抜けるが、すべてではない。
• 🧑 人間：わなに気づくこともできるが……操られることもある。

技術だけで足りないなら、研究者は検知をより賢くするために何をしているのでしょうか？ それが次のガイドのテーマです：フィッシング：研究者と攻撃者のいたちごっこ。