メール攻撃の悪夢と被害防止のための8つのベストプラクティス

This post is also available in: English (英語)

そのお客様は、ある米国の金融サービス会社の役員でした。その会社では多分にもれず、多要素認証（MFA）モバイルアプリを利用してメールや顧客ファイルなどの機密データへのアクセス保護していました。いつもどおりのある1日、この役員のiPhoneにメールへのアクセスを要求するMFAリクエストがくりかえし送られてきました。その日は顧客とのミーティングが多かったので、たびかさなる通知はわずらわしく感じられました。きっとなにかのシステムトラブルだろう。そう判断した彼は、ひとつひとつ要求を拒否しては仕事に集中しようとしました。

そのうちリクエストがこなくなりました。そのときは「きっと解決したんだろう」と思ったそうです。ところが数ヶ月後、それらリクエストの1つがうっかり承認されており、気づかぬうちに攻撃者がメールに好きなようにアクセスしていたことがわかります。彼は、使っていた銀行が合計でおよそ100万ドルにおよぶ不審な電信送金を指摘してきたことから、この侵害を知ることになりました。その後の弊社の調査からは、同社所有の従業員データや顧客データの流出も判明しました。さいわい、この会社は盗まれた資金を回収できましたが、それでもこの手の攻撃は、会社の評判や事後処理にかかる時間やリソースといった面で依然として高くつくものです。

こうした攻撃は、BEC（ビジネスメール詐欺）と呼ばれています。Unit 42のセキュリティコンサルタントは毎年数千時間をかけ、これらBECの調査を行っています。ログを徹底的に洗い、不正行為を見つけ、利用された手法を突き止め、対処すべきセキュリティ上の問題をあぶり出すのです。

ビジネスメール詐欺は「他人事」と思われがち

大半の企業は、自社がBECへの対策をしっかり打っているものと考えていますが、じつは実施されている内容が適切でないことがあります。たとえば昨年の年初からUnit 42が担当した数百件のBEC案件のうち、89％の被害者はMFAを有効にしていませんでしたし、実施上のベストプラクティスにも従っていなかったことも、弊社コンサルタントによって明らかになっています。Microsoft 365やExchange、Google Workspaceなどの主要メールプラットフォームは、MFA実装オプションを複数提供していますから、こうしたことは意外に思われるかもしれません。どんなセキュリティ対策についても、ベストプラクティスを理解し、それに従うことが組織にとっていかに大切かがわかる結果だといえます。

なぜならそうしなかった場合には高くつくのです。2020年1月1日以降にUnit 42のコンサルタントが行った調査では、電信送金詐欺試行の平均額は56万7,000ドル、最高額は600万ドルでした。FBIの報告によると、BECによる昨年の被害額は18億7000万ドル（およそ2120億円）で、最も被害額の大きいサイバー犯罪のひとつとなっています。

ここでの救いは、MFA問題点の指摘は容易なことが多い、という点でしょう。対策の評価を行えば、不備のある部分を特定してもらい、その緩和のために推奨事項を提示してもらうことができます。

調査インテリジェンス調査チーム Unit 42 の事件簿: メール攻撃の事例

MFA導入上のベストプラクティスやメール詐欺防止のヒントについて見ていく前に、まずは「なぜそうしたベストプラクティスが大切なのか」について理解しておきましょう。ここではUnit 42の担当した事件簿からいくつか実例を取り上げて、攻撃者によるメール環境へのアクセスにつながってしまう「よくあるミス」について、MFAが導入されている場合も含めてご紹介します。なおこれらは各企業のセキュリティ対策にひそむ問題の発見につなげることを意図してご紹介するものですので、被害を受けた方々の特定を避けるため、具体的なお名前は伏せさせていただきます。

MFA設定が義務化されていなかった事例

攻撃者はある保険会社の数百人の従業員を対象にフィッシングメールを送信しました。これらのメールは偽装したMicrosoft 365メールのログインページ（当該の保険会社が設定している正規ログインページによく似ているものだった）からログイン認証情報を詐取しようとするものでした。攻撃者はMFAを設定していなかった複数の従業員のアカウントへのアクセスにまんまと成功し、そこから社内Sharepointサイト上の機密データへのアクセスに成功していました。

レガシープロトコルによるメールアクセスを許可していた事例

この事例では、攻撃者が顧客組織の従業員2名のメールアカウントにアクセスしていました。この組織はIMAP4とPOP3でメールボックスを同期するさいにレガシー認証を無効にしていませんでした。その結果、この2人のメールボックス内のすべてのデータに攻撃者がひと月以上にわたってアクセスできる状態となり、被害者の連絡先からの個人情報収集に成功していました。レガシープロトコルによるメールアクセスは、とくに正当な理由からハイブリッドで利用している環境においては、よくあるMFAバイパス手法のひとつになっています。レガシー認証の扱いかたについては、次項のベストプラクティスのアドバイスで説明します。

組織外へのメール自動転送を許可していた事例

この事例では、攻撃者が就職斡旋企業のユーザーアカウント複数を侵害し、そのアカウントを使って受信者に個人情報提供を求める求人情報を流しました。そのさいは、返信をすべて隠しフォルダに移動し、外部アカウントに転送するようなルールを設定していました。

メール攻撃を緩和するベストプラクティス8つ

ビジネスメール詐欺に効く万能薬は存在しませんので、各企業は以下の8つのベストプラクティスを実施して対策しましょう。MFA導入は基本中の基本ですが、それもメール侵害リスクの緩和や攻撃成功時の影響拡大抑止のための包括的戦略のひとつにすぎません。

1. 教育する: ありとあらゆるフィッシング詐欺にさらされているエンドユーザーは、セキュリティインシデントにおいてはアキレス腱になりがちです。その彼らも、教育を受けることでフィッシング詐欺をよりうまく見分けられるようになり、「疑わしいアクティビティを見つけたらセキュリティチームに報告して目を通してもらう」という行動をとりやすくなります。
2. MFAの設定を義務化する: 「MFAが利用できます」というだけでは利用が任意になってしまいます。これでは組織に誤った安心感を与えかねません。単純に「利用可能」にするだけでなく、アカウントにMFAを追加したらログインごとの検証を義務付けることで、MFAの利用を強制することが重要です。
3. MFAには強力なものを利用する: MFAにはワンタイムパスワード（OTP）アプリケーションを使い、SMSの使用は避けます。OTPアプリケーション（Google Authenticatorなど）の生成したコードをユーザーに手入力させれば、ブルートフォース攻撃や認証情報の窃取があった場合でも、ユーザーが誤って不正なMFAリクエストを受け入れる可能性を減らせます。
4. レガシー認証を管理する: レガシー認証のブロックをデフォルトにしましょう。古いデバイスやレガシーオンプレミスSMTPリレーなど特定の例外ケースについては、Azure Active Directoryの条件付きアクセスなどのツールを使い、例外で許可するようにしましょう。
5. ネットワーク保護を見直す: エンドユーザーがどのようなコードやアプリケーションを実行・ダウンロードできるようにするかは定期的に見直しましょう。たとえばマクロを埋め込んだOfficeドキュメントや未承認のソフトウェアやUSBデバイスなどです。以前にもUnit 42脅威インテリジェンス調査チームが推奨していたとおり、URLフィルタリングルールを設定し、「Newly Registered（新規登録ドメイン）」「Insufficient Content（コンテンツ不足）」「Dynamic DNS（ダイナミックDNS）」「Parked（パーキングドメイン）」「Malware（マルウェア）」カテゴリに属するドメインへのアクセスはデフォルトで制限すべきでしょう。
6. 委任とアカウント権限を定期的に見直す: ユーザーアカウントと権限は定期的に見直しましょう。そのさい、所有者以外のかたへのメールボックス委任や、共有メールボックス、管理者権限なども対象にしましょう。各アカウントには一意な前をつけ、特定個人に紐付けましょう。サービスアカウントや共有メールボックス用のクレデンシャル（資格情報）は、パスワード保管庫に安全に保管しましょう。そのさいは、可能なかぎりMFAで保護しましょう。
7. クライアントサイドの転送ルールを無効にする: クライアントサイドに転送ルールが存在している場合、それはすべての受信メールを攻撃者の外部アドレスへ転送する侵害の指標である場合があります。そうでなければ、エンドユーザーが会社メールを個人用メールアカウントに転送を設定していることがあります。いずれの場合も機密性が損なわれるおそれがあるので、クライアントサイド転送ルールは無効にすることを強くお勧めします。業務で転送ルールを必要とするユーザーは、マネージャーの承認を得てIT部門に定期的にレビューしてもらうようにしましょう。
8. 監査ログを取得してイベントを監視する: 管理者イベントログが有効になっていることを確認しましょう。メールプラットフォームやライセンスレベルによっては監査やログ保存がデフォルトで有効でないことがあります。Unit 42では、メールサーバーのセキュリティイベントをより実用的に監査・把握するために、メールサーバーのログをXDR（Extended Detection and Response）やSIEM（Security Information and Event Management）ツールなどの集中管理用の場所に集約することを推奨します。そうすることでデータやコンテキストが追加で得られるので、それぞれのアカウントの平時のアクティビティへの理解が深まり、インシデント発生時に侵害を受けたデータを特定しやすくなります。

弊社の専門チームは皆さんの組織のメール攻撃対策準備をお手伝いいたします。ぜひUnit 42のBusiness Email Compromise (BEC) Readiness Assessment（ビジネスメール詐欺への対応準備状況評価）をあわせてご一読ください。