サイバー脅威
組織間の信頼関係を悪用する高度なビジネスメール詐欺（BEC）の手口とその対策
トレンドマイクロのMXDRチームは、組織間の信頼関係を突いたB2B型のBEC攻撃を調査しました。攻撃者は、数日に渡って送金関連のメール対話を巧みに操作し、資金を窃取しました。
- トレンドマイクロでは最近、B2B（Business-to-Business：企業間取引）型ビジネスメール詐欺（BEC）の攻撃に遭遇し、調査しました。今回の攻撃は、複数の組織やシステムを巻き込んで綿密に計画されたものであり、一般的なBECの進化型に相当します。
- 偽装メールの送信手段として、侵害済みのメールサーバが利用されました。
- 調査にあたり、さまざまな証跡をもとにインシデントの時間的な流れを再構築しました。これにより、数日間に及ぶ攻撃計画の詳細が明らかになりました。
- 攻撃者が利用した技術を、MITRE ATT&CKに基づいて分類しました。さらに、有効なセキュリティ対策を分析しました。
- 以上に加えて本稿では、企業や組織がB2B型BEC攻撃のリスクを軽減し、先手を打ってシステムを保護する上で役立つ対策や推奨事項について解説します。
はじめに
企業や組織を狙ったビジネスメール詐欺（BEC：Business Email Compromise）は、たった1通のメールによって巨額の損失を引き起こす場合があります。BEC攻撃は年々増加する傾向にあり、その手口も単純なものから複雑なものまで多岐に及びます。
トレンドマイクロが最近対峙した事例では、単に個人相手に単発の偽装メールを送りつける従来型のBECとは異なる手口が確認されました。具体的に本攻撃者は、ビジネスパートナー間の信頼関係に踏み込み、数日間に渡って送金関連のメール対話に慎重に介入し、資金を盗み取るに及びました。これは、「B2B（Business-to-Business：企業間取引）型のBEC」と呼べるものです。
今回のインシデントには、下記の要素が絡んでいます。
- ビジネスパートナー「A」、「B」、「C」：メールによってビジネス取引を行っている。
- 攻撃者：ビジネスパートナーA、B、C間のメール対話を全て盗み取れる状態にある。
- 侵害されたサードパーティーのメールサーバ：攻撃者がBECメールの送信に不正利用する。
本インシデントでは、さまざまな手口によって複数のメールアカウントが不正アクセスを受け、アカウント乗っ取りに近い状態となっていました。こうしたメール攻撃の全体像を把握する際には、送信側と受信側を含めた全関係組織からメールのコピーを取得し、同一と見られる場合でもその詳細を照合するなど、複雑な分析が必要となります。部分的な解析（送信側のみ、受信側のみなど）だけでは、メールの全体的な流れを追いにくくなるためです。
以降、調査結果に基づく本インシデントの時間的な推移や、似たような攻撃を抑止、検知して被害を低減するための対策について、解説します。
インシデントの流れ
トレンドマイクロのMXDR（Managed XDR）チームは、今回のB2B型BEC攻撃に関する調査要請を受け、下記の情報に基づく分析を行いました。
- 「Trend Vision One™」から取得される「Trend Micro Email Sensor」のテレメトリ情報
- 複数のユーザ（メール対話の送信者と受信者）から提供されたメールヘッダー
こうした情報により、インシデントの時間的な流れを再構築し、重要な詳細を突き止めることが可能となりました。分析に基づくと、今回の攻撃は二段階で進行しました。第一段階の流れを、下図に示します。
トレンドマイクロ側から見えている範囲はパートナーBに限られているため、その範囲外でも、メール対話に介入する初期侵害工作が行われていたと考えられます。また、サードパーティーのメールサーバは別の正規業者が所有するものであり、メール対話上に直接表れることはありませんが、BECメールの送信経路として利用されました。
今回の攻撃者は、パートナーA、B、C間における全メールへのアクセス手段を持っていたように見受けられます。例えば、図中のステップ2と3でメールを再送した理由は、ステップ2でサードパーティーのサーバから送ったメールがパートナーBのメールシステムに拒否されたためであることが、証跡から示されています。
また、本攻撃者は、メール対話に介入する前に4時間半ほど待機していたことが判明しました。考えられる理由として、ステップ1の初期メールに続いてすぐに不正な銀行口座情報を送信しても、警戒される可能性が高い点が挙げられます。本攻撃者は、メール対話がさらに進行するまで待った上で、ステップ2に移行して会話に紛れ込みました。こうした形で、パートナーBの担当者が不審がることなく銀行口座の変更を受け入れるように仕向けたと予想されます。ステップ2と3で攻撃者が送ったメールには、それぞれパートナーAが発した送金依頼の更新事項が含まれ、新たな送金先として不正な銀行情報が指定されていました。
第二段階では、攻撃者がパートナーAとBの対話に割って入り、両者を完全に分断しました。この間、当該メールスレッドには4名から6名の受信者が含まれていましたが、除々に攻撃者のメールアドレスに置き換えられていきました。
攻撃者は、パートナーA、B、Cに送るメールを正規なものと見せかけるため、送信元（From）としてはパートナーA、B間で想定されるユーザをそのまま残す一方、返信先（Reply-To）には攻撃者のメールアドレスを指定しました。メールの内容については、パートナーAやBの文体（冒頭や末尾の挨拶、言葉遣いなど）を真似ながら、短めの文章で切り上げました。
BECメールの一部は、サードパーティーのメールサーバ経由で送信されました。当該サーバには設定不備があり、送信ドメイン認証技術「SPF（Sender Policy Framework）」を無視してメールを通過させるようになっていました。これがメールサーバの初期設定における不備なのか、攻撃者によって設定を改変された結果なのかは、不明です。
図2のステップ5において、攻撃者はパートナーAから受け取った追加情報のうち、銀行口座を第一段階と同様に不正なものに置き換え、パートナーBに確認を求める形で送信しました。パートナーAとBは、この時点でなお、本来想定される相手と対話しているものと思い込んでいました。結果、パートナーBが攻撃者の銀行口座に送金を実施するに至りました。
ステップ1から8に至る時系列的な流れを、下表に示します。内容を踏まえると、本攻撃は計画的かつ慎重に実行されたと考えられます。
請求書に関する初回リマインダが送信されてから12日後、パートナーAがパートナーBに支払いの状況を問い合わせました。しかし、この時点で、パートナーBが支払った金額は完全に攻撃者側の手に渡っていました。
なお、当該のメールスレッドから派生した別のトピックでは、パートナーAとBの受信者が、依然としてメールのやり取りを続けていました。多くのメールクライアントは、エンドユーザがメールに返信した際に、その返信先アドレスを自動補完の対象として加える仕組みを備えています。そのため攻撃者は、自動補完されたメールアドレスを適宜選択して本来の正しいものに書き換え、会話が正常に進行するように仕向けました。
最初の請求（送金されたもの）以外にも、攻撃者が介在したメールスレッドが5件確認されました。これらのスレッドでも、パートナーAやBが出したメールがまず攻撃者に届き、後になってから本来の送信先に行き着く流れとなっていました。そして先程と同様、メールの送信者や受信者として信頼関係にあるパートナーA、B、Cが表示されたため、どの関係者から見ても、対話が自然に進行しているように映りました。
B2B型BEC攻撃を成功しにくくするための対策
こうしたインシデントを確実に阻止することは難しいかも知れませんが、攻撃を成功しにくくするための対策が存在します。はじめに、サイバー犯罪の知識ベース「MITRE ATT&CK」に基づくと、本インシデントには下記の技術的特徴が見られます。
- 攻撃者はメール収集（T1114）の手段を数多く持っていたため、標的組織内の重要なやり取りを見逃すことなく察知できたと考えられる。
- メール送信を容易に行う手段として、本攻撃者は、セキュリティ制限の緩いサードパーティーのメールサーバを侵害し、利用した（T1584.004）。このメールサーバ自体は正規の組織が管理するもので、不審なものとは映らなかったが、メール送信時のセキュリティ設定がほとんど適用されていなかった。
- 当該サーバでは、標的ユーザのメールアドレスを偽装したアカウントが用意されていた。例えば、標的ユーザのアドレスが「user1[@]partnerA.com」の場合、偽装アドレスとして「user1[@]free-email-domain.com」などが用いられた。このように攻撃者は、パートナーA、B、Cの標的組織や各従業員に関する知識を有し、偽装用のアカウントを事前に準備していた（T1585.002）。メールアドレスを真似るだけでなく、アカウントの表示名についても、実際の標的ユーザと同じ名前を設定していた。
- 今回のB2B型BEC攻撃は、その全体を通して、関係者間に築かれていた信頼関係を極力活用したものと言える（T1199）。
- 本インシデントによる被害として、「金銭窃取（T1657）」が挙げられる。侵害済みメールサーバの所有者にとっては、「リソース乗っ取り（T1496）」が該当する。
攻撃がさまざまな要因でさまざまな経路から発生するのに対し、一組織として実施できることは、自身の管理下にある環境を強化することにとどまります。しかし、少なくとも、B2B型BEC攻撃を成功しにくくするための対策があり、防衛上の効果が見込まれます。
以降に述べる推奨事項は、類似の攻撃で狙われたことのある企業や組織の多くに当てはまると考えられます。
1. メールセキュリティ技術「DMARC（Domain-Based Message Authentication, Reporting & Conformance）」や「DKIM（DomainKeys Identified Mail）」、「SPF（Sender Policy Framework）」についてメールセキュリティベンダーに確認し、導入を検討する。
本インシデントで攻撃者が作成したメールは、こうした認証関連のチェックを通過できない点で、不正を示唆する兆候が十分にありました。
ARC-Authentication-Results: i=2; mx.microsoft.com 1; spf=softfail (sender ip
is 11.22.33.44) smtp.rcpttodomain=PartnerA.com smtp.mailfrom=PartnerB.com;
dmarc=fail (p=none sp=none pct=100) action=none header.from=PartnerB.com;
dkim=none (message not signed); arc=pass (0 oda=0 ltdi=0 93)
ARC-Authentication-Results: i=1; rspamd-587694846-cqc8b; auth=pass
smtp.auth=spamcontrol26 smtp.mailfrom=finance-person@PartnerB.com
Authentication-Results: spf=softfail (sender IP is xx.yy.aa.bb)
smtp.mailfrom=PartnerB.com; dkim=none (message not signed)
header.d=none;dmarc=fail action=none header.from=PartnerB.com;compauth=other
reason=501
Received-SPF: SoftFail (protection.outlook.com: domain of transitioning
PartnerB.com discourages use of xx.yy.aa.bb as permitted sender)
（IPアドレスやメールドメインは除去、または伏せ字としています）
しかし本インシデントでは、DMARCのポリシー設定が「チェック失敗時の対応動作なし（action=none）」となっていため、不正なメールも素通りし、パートナーAのメールボックスに届きました。DMARCのポリシーを厳しく設定していれば、チェックに失敗するようなメールをユーザ側に届けないようにするか、最低でも件名に「SPAM（スパム）」や「Suspicious（不審）」などのタグを付加し、スパムフォルダやジャンクフォルダに送るなどの制御が可能だったと考えられます。
こうした設定を全メールドメイン向けに一括適用しようとすると、対象ドメイン名からのメール送信に支障をきたすことが懸念されるため、ビジネスステークホルダーを交えた協議が必要になるでしょう。しかし、今回のB2B取引に関しては、特に送金絡みのメール取引に対して一定の制御を設けるといった内容で合意できた可能性があります。
2. メールで送金絡みのやり取りを行う際には、デジタル署名を施すことについて検討する。
今回の攻撃者が侵害済みのメールサーバ経由で送信したメールには、下記のヘッダー情報が含まれていました。
Received: by webmail.emailsrvr.tld (Authenticated sender:
compromised-account@compromised.email.server, from: finance-person[@]PartnerB.com) with HTTP
Authentication-Results: spf=pass (sender IP is xx.yy.aa.bb)
smtp.mailfrom=compromised.email.server; dkim=none (message not signed)
header.d=none;dmarc=fail action=none header.from=PartnerB.com;compauth=fail
reason=001
Received-SPF: Pass (protection.outlook.com: domain of compromised.email.server designates
xx.yy.aa.bb as permitted sender) receiver=protection.outlook.com;
client-ip=xx.yy.aa.bb; helo=smtp116.sub.emailsrvr.tld; pr=C
X-Auth-ID: compromised-account@compromised.email.server
Reply-To: finance-person[@]free-email-domain.com
（IPアドレスやメールドメインは除去、または伏せ字としています）
上記のヘッダー情報より、送信者が規定外のメールアドレスを使用し、異なる送信元（Reply-To）を指定したにも関わらず、SPFのチェックを通過したことが分かります。
ここでも、先述したDMARCを的確に設定していれば、被害を抑制できた可能性があります。もう1つの有力な対策として、「メールのデジタル署名」が挙げられます。これにより、メール送信者の正当性を確認し、メール内容の改ざんを検証することが可能となります。
さらに、ネットワークの多要素認証（MFA：Multi-Factor Authentication）やログイン監視などのベストプラクティスを組み合わせることで、送信元を偽りながらデジタル署名付きメッセージを作成するといった工作を防げる可能性が高まります。
先と同様、こうした制御を会社全体で全メールドメインに適用することは、良いアイデアかも知れませんが、ビジネスステークホルダーとの調整や協議が必要になります。B2B取引のパートナー企業については、メールの改ざんを防ぎ、正規のデジタル署名付きメールのみが受信されるように、的確なメール制御の施行を必須条件とすることも考えられます。
3. メールで送金関連のやり取りを行う担当者など、特定個人に関する検証のプロセスを強化する。
BECで狙われやすい標的ユーザと言えば、B2B型であるかは問わず、企業の中でも高プロファイル（地位や知名度が高いなど）の人物が候補として挙がります。そのため、こうした特定ユーザに特化したアラートの強化が望まれるかも知れません。具体例として、セキュリティツールの機能によりますが、下記の事象に対してアラートを出すユースケースが考えられます。
- MFAが無効化された。
- ログオンプラットフォームで異常な挙動が見られた（通常ではあり得ないアクセス順序など）。
- 不審な活動が検知された。例えば、「予期しないフォワーディングルールの追加」は、BECの初期段階にありがちな兆候の一つである。
企業や組織がこうした対策を円滑に進めるためには、まずメールのサービスプロバイダやセキュリティプロバイダを通してBECのユースケースについて確認し、アカウント乗っ取りの監視やアイデンティティの保護といった取り組みに向けて調整することが重要です。
4. 狙われやすい高プロファイルのユーザ向けに個別トレーニングや業務プロセスを実施する。
今回のインシデントでは、特定の個人が複数組織を通して築いていた信頼関係が大いに利用されました。対策の1つは、こうした高プロファイルの個人向けに、フィッシングの看破やB2B型BECのシミュレーションといった教育プログラムを別枠で実施することです。一連の取り組みにより、対象者は受信トレイ上の名前だけで安全と思い込むことなく、慎重にメールを精査する習慣を身に着け、送金口座の変更依頼に対して格別の警戒心を持って対応するようになると期待されます。
また、本インシデントでは、メールスレッドのCCに含まれていたさまざまな組織のメールアドレスが、フリーメールの別アドレスに置き換えられていました。ユーザ側で異常を検知することは確かに難しいですが、特に送金依頼などのメールについては、こうした不審な変更点に注意するように努めることが、重要な一手となります。
5. パートナー間で検証用のプロトコルを確立する。
表1に示したインシデントの流れを踏まえると、送信者の本人確認をメール以外の経路で行う手段があれば、攻撃者からの指示を受けた際に、その正当性を検証することも可能だったでしょう。例えば、パートナーAとBの間で、ビデオ通話や電話を介してメール取引について確認する合意があれは、その場で指示内容を二重にチェックできたと考えられます。
「MITRE's M1060」のガイドラインで述べられているように、通常とは異なる安全なコミュニケーション経路を用意しておくことで、仮にメインのネットワークが侵害されたとしても、その影響を受けることなくパートナーとの間で安全に確認や検証を行うことが可能になります。こうした対策により、攻撃者が機密情報の窃取や改ざんといった不正行為に乗り出した際にも、そのリスクを緩和できると考えられます。非常用のコミュニケーション経路として、最近では、暗号化されたメッセージアプリや安全性に優れた電話ラインなど、さまざまな方式が存在します。
以上の他、口座情報の変更に際しては事前の検証や承認を課すなど、手続き面での対策も有効です。例えば、資金移動の指示を含むメールを送信する際には、事前にメール以外での手続きを要求する方式が挙げられます。この場合、前触れなく口座情報の変更を指示するようなメールが届けば、その時点で規約違反となり、アラートの発信対象となります。
6. 高プロファイルのユーザを対象に、規約に違反したメールが取り交わされていないか検査する。
少なくとも組織内部では、標準的な手続きを義務化し、それが守られていることを監視することが推奨されます。例として、下記のようなケースを考えます。
受信メール
送信者（From）：invoicing[@]partner_organizationA.com
受信者（To）：accounts_payable[@]partner_organizationB.com
件名（Subject）：Invoice from < Partner Organization> - reference ticket number
（件名部の訳は、「<パートナー企業名>からの請求書 - 照会番号」）
メール認証の設定
- SPFとDKIMが設定されている
- DMARCが適用され、「恒久的にブロック」のオプションが指定されている
上記設定が組織間の標準として合意されていれば、規定のパラメータから外れたメールに対してアラートを出すことが考えられます。「Trend Vision One」で「Trend Micro Email Sensor」をご利用の場合、下記のロジックによって当該のアラートルールを設定できます。
(mailFromAddresses: invoicing[@]partner_organizationA.com OR
mailToAddresses: accounts_payable[@]partner_organizationB.com) AND
(mailMsgSubject:Invoice) AND (mailWantedHeaderValue:dmarc=fail OR
mailWantedHeaderValue:dkim=none) AND (mailDirection:3)
上記のハンティング・ルールでは、下記の全条件に一致するメールを監視対象とします。
- 受信した全メール
- 送信者が「invoicing[@]partner_organizationA.com」または受信者が「accounts_payable[@]partner_organizationB.com」となっている
- 件名部が、事前に合意した条件に一致する
- SPFやDKIM、DMARCなどによる認証結果が、2組織間のビジネス基準を満たしていない
本ルールの内容は、要求に応じて追加、変更することも可能です。
Trend Vision Oneをご利用中で、かつ「Threat Insights」（現在プレビュー版）が有効となっている場合、さらに多くのハンティング用クエリをご確認いただけます。
まとめ
ビジネスメール詐欺（BEC）攻撃が的確なタイミングで実行されれば、企業や組織は大きな損害を被る可能性があります。一方、組織がすでに導入しているセキュリティ技術の中に、こうした攻撃の影響を抑え込むメール保護機能が組み込まれていることも、多々あります。そのため、メールサービス・プロバイダやメールセキュリティ・ベンダーに連絡を取り、効果的なサイバーセキュリティ対策について入念に検討、評価することが推奨されます。また、信頼されるビジネスパートナーとの間でも、標準的なビジネス上の習慣や手続きについて認識しておくことが重要です。
例えば、適切なDMARC設定の導入は、BECの成功率を抑え込むための重要な対策となります。一方、本技術は確かに効果的ですが、それさえも、広範なセキュリティフレームワークの一部に過ぎない点に注意が必要です。具体的には、「DMARC」は「SPF」や「DKIM」を基に構築されたものであり、これらもまた、M3AAWGなどの業界団体やGoogleが推奨する基本的なベストプラクティスに数えられます。DMARCを導入しようとする組織は、その複雑さゆえの課題に直面するかもしれません。そのため、メール、メッセージング、コラボレーションベンダーと協力しながら、設定や統合を適切に行うことが重要です。
追加の対策として、DMARCの検証を通過したメールに組織のブランド・ロゴを表示させる「BIMI（Brand Indicators for Message Identification）」が挙げられます。これにより、信頼できる組織から正規の経路で届いたメールと、そうでないメールを見分けることが可能になります。
Trend Vision One™を活用したプロアクティブなセキュリティ対策
Trend Vision One™は、脅威の検知や阻止を迅速かつ容易に行うためのエンタープライズ向けサイバーセキュリティ・プラットフォームであり、さまざまなセキュリティ機能の一元化、アタックサーフェスの高度な制御、サイバーリスクの完全な可視化を実現します。本プラットフォームはクラウド環境で動作し、世界各地に配備された2億5千万のセンサーと16の脅威リサーチセンターに基づく脅威インテリジェンスやAI技術を活用することで、単一のソリューション上で広範なリスク情報を提供し、脅威やリスクの迅速な検知と自動対応を可能とします。
トレンドマイクロによる脅威情報の活用
脅威の高まりに備え、Trend Vision Oneをご利用のお客様は、さまざまなインテリジェンス・レポート（Intelligence Report）や脅威インサイト（Threat Insight）にアクセスできます。脅威インサイトは、サイバー攻撃の脅威が生じる前に対策を確立し、準備体制を整える上で役立ちます。さらに、不正な活動や手口を含めた攻撃者に関する情報を、幅広く網羅しています。こうした脅威情報を活用することで、ご利用の環境を保護し、リスクを軽減し、脅威に的確に対処するための対策を自発的に講じていくことが可能となります。
Trend Vision Oneのアプリ「Threat Insights」
Emerging Threats：From Event to Insight: Unpacking a B2B Business Email Compromise (BEC) Scenario（高まる脅威：組織間の信頼関係を突いた高度なビジネスメール詐欺（BEC）の手口とその対策）
参考記事：
From Event to Insight: Unpacking a B2B Business Email Compromise (BEC) Scenario
By: Hitomi Kimura, Jay Yaneza, and Chrystian Bisi
翻訳：清水 浩平（Core Technology Marketing, Trend Micro™ Research）