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

Oct 28, 2021
1 minutes
... views

そのお客様は、ある米国の金融サービス会社の役員でした。その会社では多分にもれず、多要素認証(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(ビジネスメール詐欺への対応準備状況評価)をあわせてご一読ください。


Nightmare Email Attacks (and Tips for Blocking Them)

Oct 21, 2021
7 minutes
... views

It was a typical day for our client, an executive with a U.S. financial services firm that relies on a widely used multi-factor authentication (MFA) mobile app to protect access to email, customer files and other sensitive data. His iPhone kept pinging him with MFA requests to access his email, interrupting him on a day packed with customer meetings. He was annoyed by the intrusion, figuring it was some kind of system error, and rejected each request so he could focus on work.

He thought it was over when the requests stopped. Months later, however, he learned he had mistakenly authorized one of those many requests, unknowingly granting an attacker unfettered access to his email. He learned about the compromise when his bank flagged suspicious wire transfers totalling nearly $1 million and our investigation uncovered the exposure of data belonging to the company, its employees and clients. Fortunately, the company was able to recover the stolen funds, but attacks of this nature can still be costly in terms of reputation and time and resources spent cleaning up after them.

This type of attack is known as a business email compromise, or BEC. Each year, Unit 42 security consultants spend thousands of hours on BEC investigations, combing through logs to identify unauthorized activity, determine how unauthorized access occurred and find security gaps that need to be addressed.

 

BEC: “It Can’t Happen to Me”

Many organizations think they’ve already taken steps to protect themselves against BECs. However, those steps may not have been properly implemented. Among the hundreds of BEC cases Unit 42 has worked on since the beginning of last year, our consultants determined that 89 percent of victims failed to turn on MFA or follow best practices for its implementation. That may seem surprising since the top email platforms – including Microsoft’s 365 and Exchange, as well as Google Workspace – offer multiple options for implementing MFA. This highlights just how important it is for organizations to understand and follow best practices for any security tool.

The consequences are costly: In investigations by Unit 42 consultants since Jan. 1, 2020, the average wire fraud attempted was $567,000 and the highest was $6 million. The FBI reports that BECs caused $1.87 billion in losses last year, making it one of the most expensive types of cybercrime.

The good news is that identifying MFA shortcomings is typically straightforward. Assessments can identify deficiencies in security controls and provide recommendations to mitigate those shortcomings.

 

Real-World Email Attacks From the Unit 42 Case Files

Before diving into best practices for implementing MFA, plus other tips for preventing email compromise, it helps to understand why these best practices matter. Here are some more examples from the Unit 42 case files that show common mistakes that can lead to attackers gaining access to email environments – including when MFA is in place. We’re presenting scenarios to help organizations identify potential gaps in their own security, but have anonymized the examples to protect the identities of the victims.

 

Unenforced MFA Implementation

Attackers targeted hundreds of employees at an insurance company with phishing emails. These emails led to an attempt to harvest login credentials through spoofed Microsoft 365 email login pages that looked identical to legitimate ones set up by that firm. The attackers succeeded in gaining access to a few of those accounts, which belonged to employees who hadn’t set up MFA, which led in turn to gaining access to sensitive data on an internal Sharepoint site.

 

Allowing Legacy Protocols for Email Access

Attackers gained access to the email accounts of two employees at one client organization that failed to disable legacy authentication for synchronizing email boxes via IMAP4 and POP3. That gave the threat actors access to everything in both mailboxes for over a month, enabling them to collect personally identifiable information (PII) from the victims’ contacts. This is one of the most common ways of bypassing MFA, especially in hybrid environments that have legitimate use for legacy protocols. (We provide more detail about how to handle legacy authentication below.)

 

Allowing Automatic Email Forwarding Outside the Organization

Threat actors compromised multiple users at a job placement agency, then used those accounts to circulate job postings that asked recipients to provide personal data. They set up rules that moved all responses to hidden folders and forwarded them to an external account.

 

Best Practices for Mitigating Email Attacks

While there’s no silver bullet to stop email compromises, we recommend that organizations implement the following best practices. MFA implementation is crucial, but it’s only one component of a comprehensive strategy for reducing the risk of email compromise and minimizing the impact of successful attacks.

  • Education: End users are commonly the weakest link in security incidents because we’re susceptible to all kinds of phishing scams. Education makes users significantly more likely to be able to identify phishing attempts and report suspicious activity to security teams for appropriate review.
  • Enforce MFA: Simply enabling MFA allows users to choose whether they want to set up MFA, which gives organizations a false sense of security. It’s critical to not only enable, but enforce MFA by requiring users to add it to their accounts and verify every time they log in.
  • Use Strong MFA: Use a one-time password (OTP) application for MFA and avoid the use of SMS for verification. Requiring a user to manually type a code generated in an OTP application (such as Google Authenticator) reduces the likelihood of a user mistakenly accepting unauthorized MFA requests in the event of brute-forcing or stolen credentials.
  • Control Legacy Authentication: We recommend blocking legacy authentication by default and leveraging tools such as Azure Active Directory’s conditional access to allow any specific exceptions, such as older devices or legacy on-premises SMTP relays.
  • Review Network Protections: Regularly review end users’ ability to execute or download code and applications, such as macro-enabled Office documents, unauthorized software, USB devices, etc. As previously recommended by our Unit 42 Threat Intelligence team, URL filtering rules should be established to restrict access by default to the following categories of domains: Newly Registered, Insufficient Content, Dynamic DNS, Parked and Malware.
  • Regularly Review Delegation and Account Permissions: Regularly review user accounts and permissions, including non-owner delegation, shared mailboxes and administrative rights. Every account should be uniquely named and mapped to an individual, and credentials for service accounts or shared mailboxes should be securely stored in a password vault and protected with MFA where possible.
  • Disable Client-Side Forwarding Rules: Client-side forwarding rules can be an indicator of a compromise that allows attackers to forward all inbound emails to an external address. They can also be set up by end users to forward company emails to personal email accounts. In both cases, this creates a risk to confidentiality, and we highly recommend disabling client-side forwarding rules. Users who require forwarding rules for business should have manager approval and be regularly reviewed by IT.
  • Audit Logging and Event Monitoring: Ensure the logging of administrative events is enabled. Depending on the email platform or licensing level, auditing and log retention may not be enabled by default. Unit 42 recommends the aggregation of email server logs to a centralized location such as an extended detection and response (XDR) or security information and event management (SIEM) tool to retain logs for more actionable auditing and insight into email server security events. Additional data and context helps organizations better understand what normal activity looks like for an account and determine what data has been compromised in the event of an incident.

Your organization can prepare to defend against email attacks with expert assistance. Learn about Unit 42’s Business Email Compromise (BEC) Readiness Assessment.

 


Subscribe to the Blog!

Sign up to receive must-read articles, Playbooks of the Week, new feature announcements, and more.