ThreatLabzは、大規模に展開されている新手のフィッシングキャンペーンを発見しました。このキャンペーンは、AiTM (Adversary in the Middle)攻撃の手法を用いたもので、いくつかの検出回避策も組み込まれています。これと類似したAiTMフィッシング手法は別のキャンペーンでも使用されており、Microsoftが最近公開したこちらのページで紹介されています。

2022年6月、ThreatLabzの調査チームは、ある大規模なキャンペーンで高度なフィッシングキットの使用が増加していることに気づきました。新規登録ドメイン数件が、資格情報の窃取を目的とした進行中のフィッシングキャンペーンで使用されていることを、Zscalerクラウドで得られた分析データから突き止めたのです。

このキャンペーンには、他のよくあるフィッシング攻撃とは異なる特徴がいくつかあります。使用されているのは、多要素認証を回避するAiTM攻撃という手法です。また、攻撃のさまざまな段階にわたって複数の検出回避策が使用されており、従来のメールセキュリティやネットワークセキュリティソリューションをかいくぐるように設計されています。

このキャンペーンの具体的なターゲットは、Microsoftのメールサービスを使用する組織のエンドユーザーです。組織にとって、ビジネスメール詐欺(BEC)は今後も絶えず付きまとう脅威です。今回のキャンペーンは、こうした攻撃に対する防御の必要性をいっそう浮き彫りとするものになりました。

この記事では、今回のキャンペーンのTTP (戦術、技術、手順)の詳細をご説明します。

なお、当該キャンペーンはこの記事の公開時点で進行中のため、記事の最後にあるセキュリティ侵害インジケーター(IOC)のリストは、すべてを網羅したものであると見なさないようお願いいたします。

重要なポイント

Microsoftのメールサービスを使用する組織のユーザーが主なターゲットとなっている。
最初のプロセスとして、すべての攻撃で悪意のあるリンクを含むメールがターゲットに送信されている。
キャンペーンはこの記事の公開時点で進行中で、脅威アクターはフィッシングに使用するドメインをほぼ毎日新たに登録している。
このフィッシング攻撃によって組織の最高責任者のビジネスメールアカウントが侵害され、そのアカウントを使用して同一キャンペーンのフィッシングメールが送信されるケースも確認されている。
米国、英国、ニュージーランド、オーストラリアなどの地域で、フィンテック、融資、保険、エネルギー、製造などといった重要業種の一部が狙われている。
多要素認証(MFA)を回避できるプロキシベースのカスタムフィッシングキットが使用されている。
脅威アクターは、さまざまなクローキング手法やブラウザーフィンガープリンティング手法を活用し、URLの自動分析システムをかいくぐっている。
多数のURL転送手法を用いて、組織のメールURL分析ソリューションをかいくぐっている。
キャンペーンの寿命を延ばすために、CodeSandboxやGlitchなど、合法的なオンラインコードエディターが悪用されている。

フィッシングキャンペーンの概要

2022年6月初め、ThreatLabzは、特定の業界と地域を標的にする高度なフィッシング攻撃の急増を確認しました。

また、Microsoftのメールサービスのユーザーを狙うべく脅威アクターが新たに立ち上げた、数々の新規登録ドメインも特定しました。

ThreatLabzのクラウドデータテレメトリーによれば、ターゲットの大部分は、フィンテック、融資、金融、保険、会計、エネルギーおよび連邦信用組合に属する組織でした。ただし、標的となった業界は他にも存在します。

また、ターゲットの大部分は、米国、英国、ニュージーランド、オーストラリアの組織でした。

ThreatLabzでは、このキャンペーンで使用された膨大なドメインを解析し、いくつかの興味深いパターンを特定しました。このキャンペーンのドメイン名の特徴を以下で見ていきましょう。

連邦信用組合を装ったドメイン

攻撃者が登録したドメインの中には、米国の本物の連邦信用組合のドメインに似せて作られたものがありました。

攻撃者が登録したドメイン名	連邦信用組合の本物のドメイン名
crossvalleyfcv[.]org	crossvalleyfcu[.]org
triboro-fcv[.]org	triboro-fcu[.]org
cityfederalcv[.]com	cityfederalcu[.]com
portconnfcuu[.]com	portconnfcu[.]com
oufcv[.]com	oufcu[.]com

注：連邦信用組合の名称を利用した初期のメールを分析した結果、興味深いパターンが見つかりました。こうしたメールは、対応する連邦信用組合の最高責任者のメールアドレスから送信されていたのです。脅威アクターがこのフィッシング攻撃で組織の最高責任者のメールを侵害し、侵害したビジネスメールを使って、同キャンペーンのフィッシングメールをさらに送信していた可能性が示唆されています。

パスワードの再設定メールを装ったドメイン

一部のドメイン名は、パスワードの再設定メールやパスワードの有効期限を知らせるメールを想起させるキーワードを含んでいました。このキャンペーンのフィッシングメールは、パスワードの再設定のリマインダーとも関連している可能性があります。

expiryrequest-mailaccess[.]com

expirationrequest-passwordreminder[.]com

emailaccess-passwordnotice[.]com

emailaccess-expirynotification[.]com

今回の進行中のキャンペーンで使用されているドメインは他にもあり、その一部は完全に無作為なもので、特定のパターンに従っていないものもある点には注意が必要です。

配布方法

フィッシングURLの配布に使われたメールの詳細については、ThreatLabzでも限られた情報しか把握できていません。ただし、悪意のあるリンクがメール本文で直接送信されるケースと、リンクを含むHTMLを添付したメールが送信されるケースが確認されています。

下の図1は、悪意のあるフィッシングURLが埋め込まれたHTMLファイルを添付したメールの例です。

図1：HTMLファイルが添付されたフィッシングメール

下の図2は、添付されたHTMLファイルの内容です。window.location.replace()を使用し、ブラウザーでHTMLを開いた際に、ユーザーをフィッシングページにリダイレクトするようになっています。

図2：ユーザーをフィッシングページにリダイレクトするHTMLの添付ファイル

下の図3は、悪意のあるリンクを本文で直接送信するフィッシングメールの例です。

図3：メール本文に含まれる悪意のあるリンク

ThreatLabzでは、多くの事例でさまざまなURLのリダイレクト手法が使用されていることを確認しています。攻撃者は、実際のフィッシングURLをメールで送信するのではなく、さまざまなリダイレクト手法を駆使したリンクを使用し、最終的にフィッシングページのURLを読み込ませる方法を取っています。この手法のいくつかについて、以下で詳しく見ていきます。

合法的なWebリソースをリダイレクトに悪用

フィッシングサイトは、極めて多様な方法で配信、リダイレクト、ホストされています。

リダイレクトコードをホストする一般的な方法の1つに、Webコードの編集およびホスティングサービスを利用したものがあります。こうしたサイトは本来、Web開発者が正当な目的で使用するものですが、攻撃者はこれを利用して新たなコードページをすばやく作成することができ、そこへ最新のフィッシングサイトのURLを含むリダイレクトコードを貼り付け、ホストされたリダイレクトコードへのリンクをターゲットに一斉送信しています。

こうしたサービスを利用することで、リダイレクトコードの内容をいつでも変更できるため、攻撃者は柔軟なキャンペーン展開が可能になります。キャンペーンの進行中でも、リダイレクトページのコードを変更することで、悪意のあるものとしてマークされたフィッシングサイトのURLを未検出の新しいURLに更新するケースが確認されています。

この目的で最もよく悪用されているサービスはCodeSandboxです。

以下の図4に示すのは、CodeSandboxでホストされ、フィッシングサイトで利用された最も一般的なリダイレクトコードです。

図4：攻撃者がコントロールするCodeSandboxインスタンスのリダイレクトコードスニペット

下の図5には、同じように悪用されているサービス「Glitch」でホストされたリダイレクトコードの例です。

図5：攻撃者がコントロールするGlitchインスタンスのリダイレクトコード

数百とはいかないまでも、数十に上るCodeSandboxコードのページが、フィッシングサイトへのさまざまなリダイレクトコードのホストに使用されていることが確認されています。

こうしたページの多くは、あるネットワークに属する登録済みCodeSandboxユーザーが書いたもので、ユーザー登録に使用されたGoogleアカウントの名前は確認することが可能です。

ThreatLabzが発見したGoogleアカウントのほとんどは匿名の使い捨てアカウントで、作成者の特定作業は行き詰まったものの、いくつかのアカウント名をインターネットで検索したところ、一部の作成者が以前に初期のフィッシングキャンペーンや、暗号通貨に関わる投資詐欺や回収詐欺に関与していたことがわかりました。

URLのリダイレクト手法としては、上記のほか、Google広告とSnapchatがホストするオープンリダイレクトページを悪用したものも確認されています。詳細を図6に示します。

URLリダイレクト

図6：オープンリダイレクトページを悪用したさまざまなURLリダイレクト手法

これらのリンクを開くと、クライアントは、GETパラメーター(水色の部分)で指定されたURLに直ちにリダイレクトされます。

攻撃者にとってのこの手法の利点は、送信するメールに含めるリンクを正当なサイトへのものにし、それをエントリーポイントにできる点です。実際のフィッシングサイトのアドレスはGETパラメーターのどこかに現れるだけになるため、メールクライアントによる悪意のあるURLの検出を回避できる可能性が高くなります。

フィンガープリントの取得による検出回避

このキャンペーンでは、この記事で取り上げるすべてのフィッシングサイトでクライアントのフィンガープリントを取得する手法が利用されています。このプロセスは、ページにアクセスすると直ちに実行されます。

クライアントに提供される最初のページは、FingerprintJSプロジェクトから抜き出したJavaScriptコードで構成されています。このコードは、クライアントのブラウザーから情報を収集するためのものです。これによって無防備なターゲットがブラウザーを操作しているのか、実はアナリストやボットなどの招かれざる客が探りを入れに来ているのかを判断しています。

このスクリプトは、クライアントのオペレーティングシステム、画面サイズやタイムゾーンなどの識別情報を収集し、その結果をWebSocketトラフィックによってサイトに返します。クライアントのマシンから収集される情報の一覧は、この記事の最後に参考情報として記載しています。

図7：WebSocket経由でサーバーに送信されるクライアントのフィンガープリントデータ

サイトでは、この情報を受信したうえで、クライアントをそのまま引き込むべきか、Googleのホームページにリダイレクトして追い払うべきかを判断します。

このロジックはサーバー側にあるため、判断の正確なメカニズムは不明ですが、仮想マシンで実行されているブラウザーについては、WebGL APIが明らかにしているような形で、クライアントのグラフィックス用ドライバーの名前を調べて検出していることが確認されています。

デフォルトでは、VirtualBoxとVMwareはこの方法で認識されるため、このチェックに合格するには、Firefox上のブラウザー設定「webgl.override-unmasked-renderer」を使用するなど、何らかの形でマスキングを行う必要があります。

クライアントを疑う理由が見つからない場合は、サイトからクライアントに認証Cookieが提供され、クライアント側のコードはこのCookieを保存して同じページをリロードし、この際フィッシングページの本体をサイトから受信します。

図8：適切なターゲットのフィンガープリント取得時にサイトが返す認証Cookie「__3vjQ」

プロキシベースのAiTMフィッシング攻撃の概要

従来のクレデンシャルフィッシングのサイトは、ユーザーの資格情報を収集するだけで、実際のメールプロバイダーのサーバーで認証プロセスを通過することはありません。ユーザーが多要素認証(MFA)を有効にしていれば、盗んだ資格情報だけではアカウントにログインできないのです。

AiTMフィッシング攻撃は、この多要素認証を回避するために利用されることのある手法です。この記事で説明する攻撃はすべてこの手法を使用したものです。

AiTMフィッシング攻撃は、従来のクレデンシャルフィッシングのキットとは異なり、実際のメールプロバイダー(今回のキャンペーンではMicrosoft)のサーバーで認証プロセスを通過するものです。認証プロセス通過のため、フィッシングキットはMiTMプロキシとして動作し、クライアント(ターゲット)とサーバー(メールプロバイダー)間を行き来するすべての通信を中継します。

現在入手可能な、この界隈で広く知られているオープンソースのAiTMフィッシングキットは次の3つです。

Evilginx2
Muraena
Modlishka

ThreatLabzでの調査の結果、今回のキャンペーンの脅威アクターは、カスタムのフィッシングキットを使用していると見ています。クライアントとサーバー間の通信において、一般に入手可能な既製のAiTMフィッシングキットとは異なる点がいくつか見つかったのです。次のセクションでは、この特徴について詳しく見ていきます。

なお、AiTMフィッシングキットの一般的な動作の仕組みに関する詳しい技術的な情報については、こちらのページなどでもまとめられ一般公開されているため、この記事では割愛します。

今回のフィッシングキットの特徴

高度なAiTMフィッシングキットはすべて共通して、ターゲットとするユーザーとサイト(今回のキャンペーンではMicrosoftのサーバー)間のプロキシとして機能します。

MicrosoftのサーバーからHTMLコンテンツを傍受し、フィッシングプロセスが機能するよう必要に応じてさまざまな方法でコンテンツを操作したうえでターゲットユーザーに送信します。

今回のフィッシングキットの動作については、前述の3つのオープンソースキットとは異なる点がいくつか判明しています

HTML解析

今回のフィッシングキットのバックエンドでは、明らかにBeautiful SoupなどのHTMLパーサーライブラリーが使用されています。

これはHTMLコードの比較によって推測できます。Microsoftから直接受信したものは、以下のように整理およびインデントされていません。

一方、同じHTMLコードでも、フィッシングキットに中継されたものは以下のように整理され、適切にインデントされています。

このフィッシングキットは、Microsoftのサーバーから読み取ったHTMLをパーサーにフィードし、HTMLツリー全体のプログラム表現を生成していると思われます。こうすることで、プログラマーが各要素を表現するオブジェクトの意図を理解し、さまざまな要素を操作しやすくなります。

この操作が完了すると、ツリーにすべての変更が適用されたHTMLがライブラリーから生成されます。その結果、上記のように整理された出力となることが多くなるというわけです。

前述の3つのオープンソースキットはHTMLパーサーを使用しておらず、基本的な文字列操作を加えるだけで受信したHTMLデータを処理しています。

ドメイン変換

キットではさまざまな処理を行います。その1つとして、セッション全体を通じてターゲットの通信先がフィッシングサイトとなるよう、Microsoftドメインへのすべてのリンクが、対応するフィッシングドメインへのリンクに置き換えられます。

下の図9では、その例としてHTMLスニペットを並べて比較しています。左はMicrosoftが提供する元のコード、右は同じ部分のコードがターゲットに中継される過程で変換されたものです。

図9：変換前後のHTMLスニペット

変換後のコードでは、元のサブドメイン(緑)、元のドメイン名(青色、TLDを除く)、生成された一意のID(ピンク色)がダッシュで結合され、フィッシングサイトのドメイン(オレンジ)下のサブドメインになっています。

リンクに16進数で8桁のIDが付加されるこの変換パターンは、このフィッシングキットに固有のものと思われ、前述の3つのオープンソースキットでは使用されていません。

ただし、この変換が行なわれていない場合もあります。

Microsoftには、「Azure Active Directoryシームレスシングルサインオン」と呼ばれる機能があります。認証を行おうとするクライアントにこの機能を提供するために、Office 365のログインページでは、Microsoftのサーバー「autologon.microsoftazuread-sso.com」との通信が行われます。

このサーバーへの参照は、Office 365のメインのログインページから取得した以下のJavaScriptのスニペットで確認できます。

何らかの理由で、上の図中の「autologon.microsoftazuread-sso.com」へのリンクの変換が実行されず、リンクが無傷のままターゲットに送信されることがあるのです。

この場合、ターゲットのブラウザーでは、ログインページの読み込み中に以下のようなHTTPリクエストが実行されます。

これは実質的に、Microsoftのサーバーへのリクエスト内の参照先サイトとして、フィッシングサイトのアドレスを公開していることになります。

したがって、ディープパケットインスペクションが可能なネットワークセキュリティソリューションでターゲットのHTTPトラフィックを監視していれば、動作中のキットを検知できる可能性があります。

侵害後のアクティビティー

侵害後のアクティビティーを調査するため、ThreatLabzでは、自らの制御下に置けるダミーアカウントとドメインを用意して、Azure ADのインスタンスをセットアップしました。稼働中のフィッシングURLの1つにアクセスし、ダミーアカウントの資格情報を提供し、多要素認証のプロセスを実行しました。

ある事例では、攻撃者のサーバーに資格情報を送信してから8分後に、攻撃者がそのダミーアカウントにログインするのを確認しています。ここで注目すべきは、ダミーアカウントへのログインが、(フィッシングドメインのIPアドレスとは異なる)別のIPアドレスから行われていたという点です。侵害後のアクティビティーまでに8分の時差が生じていることを考えると、アカウントへのログインは手動で行われていることが疑われます。

下の図10に示すのは、ThreatLabzがAzure ADから取得した監査/サインインログです。侵害後のアクティビティーを示す部分を赤で囲んでいます。

図10：Azure ADのサインインログ(赤で囲んだ部分は侵害後のアクティビティーを示す)

ThreatLabzでの調査時に確認された脅威アクターの侵害後の具体的なアクティビティーは、アカウントへのログイン、メールの閲覧、ユーザーのプロファイル情報の確認のみでした。

Zscalerによる検知状況

Zscalerの多層クラウドセキュリティプラットフォームは、さまざまなレベルの指標を検出しています。詳細は以下のページからご確認ください。

HTML.Phish.Microsoft

まとめ

ビジネスメール詐欺(BEC)は、今後も大きな脅威であり、組織には防御策が求められます。この記事で説明したとおり、脅威アクターはTTP (戦術、手法、手順)を絶えず更新し、さまざまなセキュリティ対策を回避しようとしています。

多要素認証(MFA)などのセキュリティ機能によってセキュリティのレイヤーを拡充しても、それがフィッシング攻撃に対する特効薬になると考えてはいけません。脅威アクターは、AiTM攻撃などを利用した高度なフィッシングキットや、その他の巧妙な検出回避策を用いることで、従来のセキュリティソリューション、そして高度なセキュリティソリューションまでをもかいくぐることがあるのです。

さらなる侵害予防策として、ユーザーは、メールの発信元が信頼できないまたは不明な場合に添付ファイルやリンクをクリック開かないようにする必要があります。また、ベストプラクティスとして、通常、資格情報の入力前にブラウザーのアドレスバーでURLを確認することが必要です。

ZscalerのThreatLabzでは、この進行中のキャンペーンをはじめとした種々の攻撃を継続的に監視し、お客様の安全を守ります。

IOC（Indicator of Compromise、侵害の指標）

※当該キャンペーンはこの記事の公開時点で進行中であり、脅威アクターは新しいドメインをほぼ毎日作成しているため、以下のリストがすべてのIOCを網羅しているとはお考えにならないようお願いします。

IOCの一覧はこちらのGitHubリポジトリーに掲載されています。
https://github.com/threatlabz/iocs/blob/main/aitm_phishing/microsoft_iocs.txt

付録

収集されたクライアントのフィンガープリントデータ

{u'data': {u'appCodeName': <string>,
u'appName': <string>,
u'audioCodecs': {u'aac': <string>,
u'm4a': <string>,
u'mp3': <string>,
u'ogg': <string>,
u'wav': <string>},
u'automation': [<boolean>,
<boolean>,
<boolean>,
<boolean>,
<boolean>,
<boolean>,
<boolean>,
<boolean>,
<boolean>,
<boolean>,
<boolean>,
<boolean>,
<boolean>,
<boolean>,
<boolean>,
<boolean>,
<boolean>,
<boolean>],
u'battery': <boolean>,
u'cookieEnabled': <boolean>,
u'debugTool': <boolean>,
u'devtools': <boolean>,
u'document': {u'characterSet': <string>,
u'charset': <string>,
u'compatMode': <string>,
u'contentType': <string>,
u'designMode': <string>,
u'hidden': <boolean>,
u'inputEncoding': <string>,
u'isConnected': <boolean>,
u'readyState': <string>,
u'referrer': <string>,
u'title': <string>,
u'visibilityState': <string>},
u'etsl': <integer>,
u'hardwareConcurrency': <integer>,
u'hasChrome': <boolean>,
u'javaEnabled': <boolean>,
u'language': <string>,
u'languages': [<string>, <string>],
u'mediaSession': <boolean>,
u'mimeTypes': [<string>, <string>],
u'multimediaDevices': {u'micros': <integer>,
u'speakers': <integer>,
u'webcams': <integer>},
u'permissions': {u'accelerometer': <string>,
u'ambient-light-sensor': <string>,
u'ambient_light_sensor': <string>,
u'background-fetch': <string>,
u'background-sync': <string>,
u'background_fetch': <string>,
u'background_sync': <string>,
u'bluetooth': <string>,
u'camera': <string>,
u'clipboard-write': <string>,
u'clipboard_write': <string>,
u'device-info': <string>,
u'device_info': <string>,
u'display-capture': <string>,
u'display_capture': <string>,
u'geolocation': <string>,
u'gyroscope': <string>,
u'magnetometer': <string>,
u'microphone': <string>,
u'midi': <string>,
u'nfc': <string>,
u'notifications': <string>,
u'persistent-storage': <string>,
u'persistent_storage': <string>,
u'push': <string>,
u'speaker-selection': <string>,
u'speaker_selection': <string>},
u'platform': <string>,
u'plugins': [<string>,
<string>,
<string>,
<string>,
<string>],
u'referrer': <string>,
u'screen': {u'cHeight': <integer>,
u'cWidth': <integer>,
u'orientation': <string>,
u'sAvailHeight': <integer>,
u'sAvailWidth': <integer>,
u'sColorDepth': <integer>,
u'sHeight': <integer>,
u'sPixelDepth': <integer>,
u'sWidth': <integer>,
u'wDevicePixelRatio': <integer>,
u'wInnerHeight': <integer>,
u'wInnerWidth': <integer>,
u'wOuterHeight': <integer>,
u'wOuterWidth': <integer>,
u'wPageXOffset': <integer>,
u'wPageYOffset': <integer>,
u'wScreenX': <integer>},
u'serviceWorker': <boolean>,
u'timezone': <string>,
u'userAgent': <string>,
u'vendor': <string>,
u'videoCodecs': {u'h264': <string>,
u'ogg': <string>,
u'webm': <string>},
u'visitorId': <string>,
u'webRTC': <boolean>,
u'webXR': <boolean>,
u'webgl': <string>},
u'ftype': <string>}