組織改変により開発部としての業務より情シスとしての仕事が増えたことに伴い、当記事も情シス目線での記事になっています。
0. 「なりすまし＝怪しい」時代の終わり
BEC（Business Email Compromise）とは、経営者や取引先になりすまし、偽の指示によって金銭や情報を詐取する詐欺の総称です。
なりすまし・フィッシングメールと聞くと「怪しい日本語の幼稚なメッセージ」を思い浮かべる方もおられるかもしれません。
「気をつけてよく見れば」判別できることの多いサイバー攻撃でしたが、それは過去の話になっているようです。
AI が便利なツールとして急速に浸透していることは、攻撃者にとっても有力なツールが手近な存在になっていることを意味しています。 この記事では、実際のメールを解析するとともに、BEC のトレンドについて少しだけ触れていきます。
1. 発端
ある日、弊社の総務チームのメールアドレス宛に、こんなメールが届きました。
今後の業務を円滑に進めるため、メールを受け取った後、ご自身の個人LINEのQRコードをメールで送付してください。今後、業務に関する連絡はLINEを通じて行いますので、よろしくお願いします。
代表取締役：堤 大輔
この件が社内で注意喚起として周知されたことをきっかけに調査が始まりました。
2. BEC のトレンド
「自分はまず引っかからない」と思われる方もおられるかもしれません。
しかし、2026 年 4 月の NHK 報道 によると、同様の “ニセ社長詐欺”（BEC）による被害は、2026 年 1〜2 月の 2 か月間に全国で 20 億円超に達した（警察庁まとめ）と報じられました。
なぜこれほどまでに被害が起きているのでしょうか？
日本語は BEC 詐欺を行なう攻撃者にとって参入障壁の高い言語でしたが、AI の普及により「言語の壁を実質的に乗り越えた」（「情報セキュリティ 10 大脅威 2026 解説書［組織編］」）からです。
言語の壁によって守られてきたゆえに、「”不審な” あるいは “怪しい” メールへのアンテナを張っていれば騙されない」という認識がまだまだ強い日本は、攻撃者にとって格好の市場となっています。
AI の普及による BEC 詐欺の巧妙さは、2024年 Arup（アラップ）社で起きた事例からも分かります。
Arup 社は、シドニー・オペラハウスの構造設計を手がけたことで知られる英国の多国籍エンジニアリング企業です。
Arup 社の事例
香港の財務チームの社員は、英国拠点の CFO を名乗る人物からの複数の支払い実行を求めるメールを発端に、CFO と他のスタッフが参加するビデオ会議に参加しました。
被害者は CFO の様子について一瞬違和感を覚えたようですが、他の参加者に確認を求めたところ全員が指示内容に同意したため、送金を実行し、最終的に 5 つの香港の銀行口座に対して 15 回に分けて、合計 2 億香港ドル（約2,560万米ドル）を送金しました。
しかし実際には、ビデオミーティングの参加者全員がディープフェイクであったことが後に分かりました。 攻撃者は一般公開されている動画や映像素材をディープフェイク技術で加工し、会議参加者の偽映像を作成したのです。
ref. https://edition.cnn.com/2024/05/16/tech/arup-deepfake-scam-loss-hong-kong-intl-hnk
AI を使えば、企業サイトから簡単に入手できるわずかな手がかりからディープフェイクを作成できます。
2024 年 5 月に公開された McAfee の調査 によると、3 秒間の音声サンプルだけで 85% 一致する音声クローンが作成できるとされ、映像についても Deep-Live-Cam のように、たった 1 枚の写真から学習不要でリアルタイムの顔交換（フェイススワップ）が可能になっています。
3. 認証と信頼性
話を冒頭のメールに戻しましょう。
冒頭のメールは「LINE 誘導型」なので「ディープフェイク」ではありませんが、攻撃者は技術的な抜け道ではなく、人間の心理や認知にアプローチし、焦らせたり権威を使うことによって正常な判断を鈍らせるという本質は変わりません。
メールとしての信頼性を確認するために、私はまず SPF・DKIM・DMARC を確認しました。 認証はすべて pass していましたが、内容は明らかに詐欺でした。
「メールとしての信頼性」と「メールの内容の信頼性」は整合しないことも今回の重要なポイントでした。
SPF・DKIM・DMARC が pass していたのは、あくまで「 BreedenShryock8940@outlook.com という Outlook のメールアドレスからのメールを、 Microsoft のメールサーバーが正規のルートとなって Outlook のメールを送信した」ことを証明しているにすぎないからです。
SPF は、「そのメールサーバーがそのドメインから送信することを許可されているか」を検証し、 DKIM は「メールが送信途中で改ざんされていないか」を署名で検証し、 DMARC は、 SPF と DKIM の結果をもとになりすましへの対処方針を定めています。
これらの認証は「送信元ドメインとその経路の組合わせの正当性」を証明するものであり、メール送信者の表示名の正当性を証明するものではないため、差出人を「堤 大輔」と設定したメールを @outlook.com から送ると、技術的には正規の組み合わせをもったメールとして届くのは正常な挙動なのです。
表示名の偽装は、攻撃として巧妙であることと技術的に高度であることが必ずしも一致しない典型例です。
4. メールヘッダーの分析
そこで認証ではなく、メールヘッダーを見ることで以下の 5 つの不審な痕跡を確認しました。
- 表示名の偽装
実際の送信アドレスはBreedenShryock8940@outlook.comでした。弊社のドメインは@quartetcom.co.jpであり、社長が@outlook.comから送信することはありません。 - Reply-To の偽装
メールヘッダーのReply-Toフィールドにはrusskundjodyglepoll@gmail.comが設定されていました。受信者が「返信」を押すと、送信元のBreedenShryock8940@outlook.comではない別のメールアドレスに返信が届く仕組みでした。 - タイムゾーンのずれ
ヘッダーのDateフィールドのタイムゾーンが+0800になっていました。国内にいる社長が送信したメールであれば+0900になるはずです。 - 送信ツールの痕跡
X-Mailer: Supmailer 46.0.3という記録が残っていました。これは一括送信ツールの名前です。社長が通常使うメールクライアントとは明らかに異なります。 - 本文の Base64 エンコード
メール本文が Base64 でエンコードされていました。マルチバイト文字（日本語）を扱う際のメール仕様によるものである可能性もありますが、キーワードベースのスパムフィルターや自動解析ツールによる検出を回避する意図があった可能性も考えられます。
とはいえ、このようなメールヘッダーの確認をすべてのメールに実施するのは現実的ではなく、ヘッダーを調査したところで分かることは限られています。
5. おわりに
AI により、自然な日本語の詐欺が自然な業務の中に紛れ込む時代になってしまいました。
組織として BEC 対策をするには、もちろん技術的な対策や従業員教育もありますが、「経営者や上長からの金銭・個人情報の要求、連絡手段の変更・切り替えの要求は、その要求のあった連絡手段以外の手段（電話・社内チャット）で必ず本人確認する」というポリシーを策定・周知するといった運用的な対策も重要です。
攻撃者は技術的な抜け道ではなく、人間の心理や認知にアプローチしてくるため、BEC 詐欺を見極める力を個人個人が意識することも引き続き大切ですが、従業員が何か不審に感じた時の相談先やルールを組織として設計することに加え、相談しやすい雰囲気や関係性を醸成することも被害に遭わないために重要な要素です。
また、昨今では「被害に遭うことを前提に、被害を最小限にとどめる力と回復力を重視する」レジリエンスという概念もセキュリティ対策では重要な関心になっています。
AI の力も借りながら、組織が安心してアクセルを踏むためのガードレールを整備していきたいです。
とはいえ情シスの領域については勉強し始めたばかりなので、どのようなフレームワークで考え、どのようなロードマップを描けばよいか、とても悩みました。 そのあたりについては、また別の機会に書きたいと思います。