AzureとOffice 365のセキュリティ、MS ゆりか先生が教えます(27) ビジネスメール詐欺に備えてメールの転送を見直そう

よく知られたサービスを装ったメールやSMSを送り、ユーザーID／パスワードなどの資格情報やクレジットカードなどの金融情報を入力させるフィッシング攻撃。企業組織を狙うフィッシングでは、このような種類のほかにも、取引先や自社の経営者層などになりすました「ビジネスメール詐欺(BEC：Business Email Compromise)」の被害が報告されています。ビジネスメール詐欺では、被害者のビジネスの状況やよく利用している文面が、フィッシングメールの文面に利用されていることなどから、フィッシングであることに気が付きにくい、という特徴があります。

典型的なビジネスメール詐欺の流れ

典型的なビジネスメール詐欺の例では、攻撃者はまず、フィッシング攻撃などによって最初のターゲットとなるユーザーのメールサービスにログオンするための資格情報（ユーザーID、パスワードなど）を入手します。資格情報を入手したら、そのターゲットのメールサービスにログインして情報を収集し、「どのような相手とどのようなやり取りをしているのか」「よく使う言葉や言い回し」「ビジネスの予定や出張の予定」「ビジネス上の送金のやりとり」などを分析します。

情報の収集／分析が終わると、そのユーザーになりすまし、ユーザーがメールのやり取りをしている相手に、フィッシングメールを送ります。その際のメールは、事前に分析した内容を踏まえているため、メールを受信した相手は不信感を抱きにくく、フィッシングメールだと気が付くことは難しい内容になっています。例えば、「定期的なやりとりを行っている経理担当者から、以前のやりとりと同じ文面で、口座変更のお知らせや支払い請求が自然なタイミングで送られてきたため、気づかずに攻撃者の口座に送金してしまった」というケースが報告されています。

このように、攻撃者は、ビジネスメール詐欺の成功率を高めるために、最初のターゲットとなるユーザーのメールサービスにログオンした後、一定期間メールの内容をモニタリングして情報を収集します。このとき、メールをモニタリングするために、ターゲットのユーザーに届くメールを攻撃者自身のメールアドレスへ転送しているケースが多く報告されています。

攻撃者にとっては、一度ターゲットのメールサービスにログインして設定すれば、以降はサービスにログオンしなくても転送したメールで攻撃の準備をできるため、発覚の機会が減るというメリットがあります。転送設定をされてしまうユーザー側は、メールの転送を設定されても気が付きにくいため、被害を察知しづらいのです。

とはいえ、メールの転送設定は業務上の必要があって利用していることもあるでしょう。セキュリティ侵害の発生を恐れて一概に全て禁止するのではなく、「転送設定は、誰がどの項目で設定できるのか」「転送設定に関してどのようなコントロールができるのか」を理解し、自組織における設定の状況を把握してコントロールすることが重要です。それにより、業務効率を阻害することなくリスクを低減し、また、万が一、ユーザーのメールアカウントに不正ログオンがあった場合などは、素早く転送の設定を確認／対処することで、被害を最小限に抑えることができます。

メールの転送設定箇所は複数アリ

メールの転送は、ユーザーのメールクライアント側、管理者側などいくつかの場所で設定できます。まず、メールの転送の設定はどこでできるのか整理してみましょう。「Microsoft 365 Exchange Online」や「Outlook」、「Outlook Web Access (OWA)」を利用している場合は、次の場所で設定可能です。

ユーザーの設定：メールボックスのルール(Outlook/OWA)
ユーザーは、受信するメールを処理するルールを作成することができ、そのルールで受信するメールは別のメールアドレスに転送できます(「ファイル」→「自動応答」→「ルール」にある「転送」)。
ユーザーの設定：「自動応答」機能
ユーザーは、不在時などに、受信するメールに自動で返答したり、メールを転送したりすることができます。
ユーザーの設定：「Power Automate(旧称：Microsoft Flow)」を利用したメールの転送
ユーザーがPower Automateと自身のメールを連携し、自動的な処理を行うことができます。
Exchange管理ポータル：メールフロー設定 (ForwardingAddress)
Exchange管理センターの、「メールフロー設定」から、それぞれのユーザーの転送が設定できます。この設定は「ForwardingAddress」のプロパティ値に反映されます。
M365 管理ポータル：メールフロー設定(ForwardingSmtpAddress)
M365管理ポータルの、「メールフロー設定」から、それぞれのユーザーの転送が設定できます。この設定は「ForwardingSmtpAddress」のプロパティ値に反映されます。ただし、「ForwardingAddress」が設定されている場合は、その値が表示されます。

メールの転送を管理者が制御する方法

一方、組織の管理者には、組織のユーザーのメール転送を禁止するなど、メールの転送を制御する方法がいくつか用意されています。

◆Office 365 セキュリティ/コンプライアンスセンター：メールのフィルター処理
「Office 365 セキュリティ/コンプライアンスセンター」の「メールのフィルター処理」に関するポリシーによって、自組織から組織外に送信されるメールの処理を制御できます。既定で設定されている「送信迷惑メールフィルターポリシー」では、転送は「自動 - システム制御」となっています。この場合は、Office 365が設定するシステム既定値に従うことになります。

なお、現在は、システム既定値は「転送」が有効ですが、今後、より安全な既定値を推奨するために、自動転送を無効にするよう既定値を変更する予定です。各組織で、この自動転送の必要性のあるユーザーを確認し、必要なユーザーのみ、許可するポリシーを設定することを推奨しています。

◆Exchange管理センター：メールフローの設定(リモートドメイン)
この設定では、「ForwardingSmtpAddress parameter」に該当する値を設定することで、Outlookを利用したメール転送ルールと、不在通知を制御できます。ただし、ほかの設定で実施された設定(ForwardingAddress parameter)は制御できません。また、転送が拒否された場合、単にメール転送が行われないだけとなり、ユーザーへのNDRなどは返らないため、ユーザーが知ることができません。

◆Exchange管理センター：メールフローの設定(トランスポートルール)
Exchange管理センターのメールフローでは、トランスポートルールを設定することで、メールの転送を制御することもできます。この設定では、条件を指定して転送の可否を設定でき、ユーザーへのNDR通知を行うことも可能です。

しかしながら、ここで指定する条件は、OWAやExchange管理者が設定する転送で用いられているメッセージクラス(IPM.note.forward)をベースにした制御であり、OWAやExchange管理者が設定する転送で利用される通常のメッセージクラス(IPM.Note)ではありません。そのため、OWAやExchange管理者が設定する転送の制御を行うことはできません。

◆OWA：転送設定項目を表示しない
OWAでの転送の設定は、「Role Based Access Control(RBAC)」で、転送の設定をそもそも表示させないように設定できます。そのため、ユーザーがOWAで転送を設定しようとしても設定できない、という状態にすることが可能です。ただ、これはあくまでもOWAでの設定項目の制御なので、デスクトップ版のOutlookでの転送設定は制御できません。また、すでに組織内で設定が行われている場合は、この設定をしても転送を無効にすることはできません。

転送の設定箇所と制御まとめ

それぞれの設定／制御機能には、利点と同時に考慮すべき点もあります。各組織で必要な要件も異なるので、「これがベストだ」という方法はありません。自組織の要件を確認し、適切なコントロールを組み合わせて管理することを推奨します。例えば、同時に転送許可と拒否の設定がされているような場合は、拒否するようにしたほうがよいでしょう。

メールの自動転送の設定箇所と、転送可否のコントロール設定（◯：転送制御可能／△：一部可能／☓：不可能）

アラートで不審な挙動の確認を

組織でメールの転送を許可している場合は、転送状況を監視し、不審な挙動がないかをモニタリングすることで、万が一被害にあった際に早く気が付くことができます。

Office 365 セキュリティ/コンプライアンスの「メールフローダッシュボード」では、組織のユーザーによって転送されたメールの状況を確認できます。転送されたメールの総数や転送先ドメインなど、転送されたメールの状況を分析した結果が表示され、組織の全体的な状況の把握に役立ちます。

また、Office 365 セキュリティ/コンプライアンスの「アラートポリシー」では、不審なメールの転送に関するアクティビティを通知するアラート設定が用意されています。このアラートでは、ユーザーが組織外の宛先へメールの転送を設定したことを検出し、管理者にメールで通知します。この通知を受け取った管理者は、転送を設定したユーザー自身が設定したものか、不正ログオンの被害を受けていないかを確認することで、組織への侵害を早期に発見し対処することができます。