This post is also available in: English (英語)
概要
ここ数カ月、ランサムウェアやRaaS(Ransomware-as-a-Service)による攻撃がサイバーセキュリティ業界の話題の中心となっていますが、犯罪者やハッカーは、金銭的な利益を得るために企業やビジネス、個人の電子メールも侵害し続けています。これらの詐欺、つまりビジネスメール詐欺(BEC)と個人用のメールアカウント侵害(EAC)は、日々ユーザーに報告されるサイバー脅威の中でもとくに広くみられるもので、対応コストも非常に高いものになっています。米国連邦捜査局(FBI)は最新の年次レポートで「BECおよびEACは、2020年に米国国内において少なくとも18億6,000万ドルの損失要因となっており、これは2019年に報告された損失との比較で5%の増加である」と報告しています。米国で報告された2020年のサイバー犯罪被害のうち、じつに45%がBECとEACに占められており、報告された被害者の11%が60歳以上の個人とされています。
大まかな比較でいうと、これまでに知られているランサムウェアの最大支払額は4,000万ドルとなっています。『2021 Unit 42ランサムウェア脅威レポート』によると、2020年のランサムウェアの平均要求額は84万7,344ドルで、被害者が支払った身代金の平均額は31万2,493ドルでした。2021年上半期にこの平均身代金支払額は82%上昇して57万ドルに達しています。なお、これら平均身代金支払額の数字は、「支払われた身代金」という直接的な金銭被害だけを含んでいることから、かなり控えめな数値となっています。さらにこれらの金額は、攻撃を受けた組織が事業縮退を余儀なくされた結果として生じた逸失利益関連損害も含んでいませんし、侵害調査に費やされたリソースについても含んでいません。これらはあくまでも既知の攻撃による直接的損失だけの金額です。攻撃の性質や潜在的なデータ侵害によっては、企業はランサムウェア攻撃を報告しない選択をする場合もありますので、結局はこうした選択が、サイバーセキュリティ業界や法執行機関による犯罪の全容解明をむずかしくしています。
これらBEC、EAC、ランサムウェア攻撃に共通しているのは「ターゲットのネットワークやアカウントへの特権的アクセスが必要」という点です。平均ないしそれより下のサイバー防御力を持つ組織をターゲットとする大多数のアクターにとっては、正規ユーザーや通信業者になりすましてネットワークやアカウントに侵入することが、検出リスクを低くおさえつつ、秘密裡にアクセスを得るための最もシンプルでコスト効率にすぐれた方法であることに変わりはありません。APT(Advanced Persistent Threats 持続的標的型攻撃)により明らかとなり、米国・英国政府がこれまで観測してきたように、正当なクレデンシャル(認証情報)と一般公開された技術を使用することで、悪意のあるアクターは「防御を回避してネットワーク内のさまざまな情報を収集・漏出させる」ことができます。APTがブルートフォースによるクレデンシャル攻撃でキャンペーンの目標を達成する一方で、犯罪者たちはたいていの場合、もっとシンプルに、無警戒な被害者たち自身に、意図せずクレデンシャルを明け渡させているのです。
パロアルトネットワークスNext-Generation Firewallのお客様は、Advanced URL Filteringセキュリティサブスクリプションとクレデンシャルフィッシング防止機能で保護されています。さらに、次世代ファイアウォールをご利用のお客様は、悪意のあるドメインを自動的にブロックし、プロアクティブな検知機能を備えたDNSセキュリティサブスクリプションを使用して保護されます。
クレデンシャルハーベスティングのような電子メールベースの攻撃を防止する方法については、 Business Email Compromise (BEC) Readiness Assessment(ビジネスメール詐欺対応準備状況の評価)を合わせて参照してください。
メールクレデンシャルハーベスティングの進化するテクニック
BECやEACなどの詐欺は儲かります。そのため、犯罪者たちは保護をかいくぐる戦術に日々磨きをかけています。そうした新たな手法の1つが、スピアフィッシングやカスタムWebページ、複雑なクラウド用シングルサインオンのエコシステムを組み入れてユーザーを騙し、意図せずクレデンシャルを漏らさせる、というものです。その一般的な手口は、「利用者の多いサービスの正規ログイン画面を忠実にまねて一見無害に見えるWebページを開かせる」というものです。
- Office 365とOutlook(login[.]microsoftonline[.]com)
- OutlookとHotmail(login[.]live[.]com)
- Dropbox(www[.]dropbox[.]com/login)
- Zimbra(mail[.]zimbra[.]com)
(Dropboxはその声明の中で、「当該の活動はDropboxのサービスとは関係がありません。このことは、お客様にたよって真偽を見分けることがますますむずかしいものとなっていることを示しています。これは私たちのサービスには関係ありませんが、私たちは信頼できるパートナーと常に協力し、お客様がどこでどのように私たちのブランドに触れるかを積極的に改善し、それに応じてブランドを保護しています」と述べています。)
詐欺師がこうした手口を使うときはふつう、受信者が添付ファイルを開いたり、Webページへのリンクをクリックしたりしやすいように、「餌」を付けた電子メールから始めます。このメールは通常、特定のビジネスオペレーション(たとえば財務、人事、物流、一般事務など)にフォーカスし、トピックと関連する添付ファイルやリンクを示したうえで、ユーザーにアクションをとるよう迫ります。そうしたトピックには、送金、請求書、未払い金、見積依頼、購入確認、出荷状況、ボイスメールや電子メールによるFAX配信などが含まれます。なかにはメールがもっともらしく見えるよう、件名などにターゲットに関する具体的な情報を意味ありげに組み込む犯罪者もいます。最近よくあるメールのテーマは以下の通りです。
- OneDrive Document to {username}({ユーザ名}宛のOneDriveドキュメント)
- {Company Name} New FaxMail Received {DD/MM/YYYY}({会社名} 新しいFaxをメールで受信しました {DD/MM/YYYY})
- {Company Name} New FaxMail Received {DDMMYYYY}({会社名} 新しいFaxをメールで受信しました {DDMMYYYY})。
- {username} 1 voice message received {M/D/YYYY}({ユーザー名} 1件のボイスメッセージを受信しました {M/D/YYYY})
- VNotes transmitted to {username}(VNotesが{username}に送信されました。)
- Mailbox Verification for {email address}({メールアドレス}のメールボックス検証)
メールを開くとありふれたログインページが表示されます。詐欺師たちはユーザーが疑問を抱かぬよう、セキュリティ強化の必要性や、サービスがユーザーをログアウトさせたことを強調してきます。場合によっては、ユーザーのメールアドレスをすでに含めた状態でページが送信され(これもクレデンシャルを要求することへの正当性を高める試み)、単にパスワードを要求するだけのこともあります。こうした誤解を招くログイン画面には次のような警告が表示されます。
- You need to sign in with your email to ensure you are the rightful recipient of the protected file. File is protected by [insert security vendor] for Mail Servers.(保護されたファイルの正当な受信者であることを確認するため、お使いの電子メールでサインインする必要があります。ファイルはメールサーバー用の[ここにセキュリティベンダ名を挿入]で保護されています。)
- To read the document, please enter with the valid email credentials that this file was sent to.(ドキュメントを読むにはファイルの宛先となっている有効な電子メールクレデンシャルを入力してください。)
- Because you're accessing sensitive info, you need to verify your password.(機微な情報にアクセスするためパスワードを確認する必要があります。)
- Authentication needed because you're accessing a sensitive document.(機微な文書にアクセスするために認証が必要です。)
- This device is not recognized.For security, [company name] want [sic] to make sure it's really you.(このデバイスは認識されていません。セキュリティのため[会社名]が[略]の本人確認を求めています。)
- Your email account {username} has been signed out, click ok to sign in.(お使いのメールアカウント{username}はサインアウトされています。[OK]をクリックしてサインインしてください。)
- Please log in to your account to view secured files(保護されたファイルを見るにはアカウントにログインしてください。)
- You have been logged out!Please enter your correct Email and password!(ログアウトされました。正しいEmailとパスワードを入力してください。)
- Get to your documents from anywhere by signing into Office.(Officeにサインインすれば、どこからでもドキュメントにアクセスできます。)
- Your password is security to view your fax message.(お使いのパスワードがFaxのメッセージを見るためのセキュリティです。)
詐欺師たちはユーザーを騙しやすいよう、さらに巧妙な手口を編み出しています。場合によっては、ターゲットとなった企業の使用している企業メールシステムの見えかたに合わせ、「ログイン」のテンプレートをカスタマイズしていることもあります。このほか、ユーザーのメールアドレスのドメイン部分から関連会社を自動的に検出し、その会社のロゴを不正Webページに組み込んでいるケースもあります。
このほか、多くの犯罪者はユーザーのクレデンシャル入力が正確かどうかを確認するためにコードにロジックを追加しています。メールアドレスの形式が正しくない場合や、パスワードが空欄の場合は、再試行を促すエラーを発生させます。なかには、正しい形式で入力されていても、ひとまず「Incorrect password please try again(パスワードが正しくありません。もう一度入力してください)」という応答を自動で返す犯罪者もいます。このテクニックを使うことで、有効なパスワードを受け取れる可能性が高まります。というのは、クレデンシャル要求が正当なものかを確認するために、最初は偽のクレデンシャルを入力してみるという慎重なユーザーであっても、このテクニックなら疑念をもたれにくいからです。
詐欺師たちが、ユーザーに添付ファイルを開かせられる可能性があまりにも低いと考えたり、ある程度信憑性のある完全修飾ドメイン名を作成できると考えているとしましょう。その場合は、シンプルに正規ホスティングサービス上にあるWebサイトをユーザーに案内しておいて、そのサイトにホストしておいたページに、上記で説明したテクニックを組み込んでおくこともできるでしょう。ユーザーにうっかりアクセスさせるために最近よく使われる悪質なWebサイトは以下のようなものです。
- excel-client-login[.]azurewebsites[.]net
- excel-docs-storage[.]us-south[.]cf[.]appdomain[.]cloud
- microsoftvoicemessage-office365voicemessage-releaseandlistentov[.]s3[.]eu-de[.]cloud-object-storage[.]appdomain[.]cloud
- online-access-app[.]azurewebsites[.]net
- redirect-office365[.]web[.]app
ユーザーがクレデンシャルを入力して送信すると、Webブラウザはその情報をHTTP POSTリクエストとして、多くの場合は「*.php」で終わるURLに送信します。ハイパーテキストプロセッサであるPHPなら、受信したクレデンシャルを取り込んでデコードしてデータベースに保存することも容易です。犯罪者たちは、こうした詐欺のアクティビティを支えるドメインとして自身が購入・維持するドメインを使うこともありますが、過去に侵害ないし乗っ取りをしておいた正規のドメインを使い、彼らのニーズを満たす例も多数観測されています。
乗っ取り被害にあった正規インフラを悪意を持って使用することは、ネットワークの防御側に2つ、大きな課題をもたらします。1つめの課題は、潜在的に信頼されている2つのネットワーク間で発生しているトラフィックを悪意のあるものとして特定するのはむずかしいということです。2つめの課題は、悪意のあるアクティビティをホストしていることが特定された正規ドメインをブロックすることで、そのドメインにある正規のコンテンツや必要とされるコンテンツもブロックすることになり、対策として不可能な場合も多い、ということです。これらの理由に加え、侵害しておいた正規ドメインのインフラにはコストがかからないので、ハッカーが目的達成にこれらのインフラを利用するケースが増えています。
偽サイトへのログインが失敗した場合でも、ユーザーが不審に思わないよう、詐欺師は以下のような工夫を凝らしています。
- ユーザーがログインしている可能性が高い正規サイトにリダイレクトします。すでにそのユーザーがログインしていれば、そのアカウントに直接アクセスすることになり、リクエストの正当性も演出しやすくなります。
- 「サービスが利用できません」というエラーを出して後でもう一度やり直すことを勧めます。
- 「ファイルが見つかりません」というエラーを発生させます。
- 「スキャンしたファイルがロックされました」というエラーを出し、「お客様のアカウントにリダイレクトします」と表示してから正規の受信箱に差し戻します。
- あたりさわりのない内容を表示します。
- 特定のフィッシング用にカスタマイズされたコンテンツを表示します。
犯罪者が有効なユーザークレデンシャルを手に入れられれば、企業やユーザーから金銭を詐取することに一歩近づくことができます。犯罪者は盗まれたクレデンシャルを使って、まずユーザーの文書、取引、通信を偵察するでしょう。これらの情報を得ると、価値のあるターゲットのさらなる特定や、平時の業務慣行や承認チェーンの把握、ユーザーの文書や共有ファイルへのアクセスを利用したカスタムフィッシング文書の作成、同アカウントを利用した金銭的利益の取得、または当該アカウントのユーザーになりすまし、より有利な環境への展開が可能になります。
結論
企業やユーザーが上述のような悪意のある手口を検知するのは非常に困難です。サイバーセキュリティ製品の大半は、これらの行為を悪質なものとして自動検出しないケースが多いでしょう。詐欺師たちは正規のWebページの正確なコピーを使って詐欺を行っていますし、トロイの木馬やスパイウェア、キーロガーなどのマルウェアをハーベスティングの試行時には組み込んでいません。Unit 42のリサーチャーはこうした手口によるメール侵害リスク軽減のため、以下を推奨します。
- すべてのビジネスアカウントや個人アカウントに多要素認証を導入する
- BECや個人のEAC詐欺で使用される最新の手口やソーシャルエンジニアリングについて、ユーザーに継続的に情報を提供し、トレーニングを行う
- "Never Trust, Always Verify"(信用するな、常に検証せよ)というゼロトラストの考え方を取り入れる
- ウイルススキャンにパスしたファイルであっても、悪意のある目的を持っている可能性があることをユーザーや管理者は理解しておく
- どのサービスがシングルサインオンに対応しているか、またそれらのアカウントにアクセスする正当なURLについてユーザーに把握してもらう
- パスワードを定期的に変更し、「1つのアカウントにつき1つの複雑なパスワード」を使用し、パスワードマネージャを使ってクレデンシャルを管理する
パロアルトネットワークスNext-Generation Firewallのお客様は、Advanced URL Filteringセキュリティサブスクリプションとクレデンシャルフィッシング防止機能で保護されています。さらに、次世代ファイアウォールをご利用のお客様は、悪意のあるドメインを自動的にブロックし、プロアクティブな検知機能を備えたDNSセキュリティサブスクリプションを使用して保護されます。
クレデンシャルハーベスティングのような電子メールベースの攻撃を防止する方法については、 Business Email Compromise (BEC) Readiness Assessment(ビジネスメール詐欺対応準備状況の評価)を合わせて参照してください。
これらの手法で使用される一般的なJavaScripts/HTMLのハッシュ
基本的なJavaScriptの例
- e431d360ace31e17596b7017e1a11009aa3a02000d319919a266136ec11be479
"+my_slice"と2回試行後のリダイレクションの例
- 3ed082d4de4fe1d4155cb605276eecee07d11888c6cf45ffb7d9f00c6bc036b1
東南アジア在住の可能性があるアクターによる"+my_slice"再利用の例
- b920ac8eb9b1ac92e64fdd2df083dc7a84bca3dedcb42fd2b3959f76711607f7
JavaScriptのKeyCodeを使ったショートカット(Ctrl-Sなど)防止の例
- 58ebf83741da3805955edfcf83f2b1af56a320d76954c243991fed92faeebe63