脅威アクターは、マルウェアを展開する代わりにMicrosoft 365のIDセッションを悪用する手口を増やしています。クラウドのみで完結するビジネスメール詐欺(BEC)の事例がそれを裏付けています。
Malwareremoval tool
攻撃者はアドバーサリー・イン・ザ・ミドル(AiTM)フィッシングキットを使い、認証済みのMicrosoft 365セッショントークンを窃取して多要素認証(MFA)を回避し、取引先への支払いを攻撃者が管理する銀行口座へひそかに転送していました。
誘導メールには「View PTO Conflicting Dates(有給休暇の重複を確認)」というボタンが設置されており、SendGridのトラッキングURLと複数回のリダイレクトを経由して、偽のMicrosoft 365ログインページへ誘導される仕組みでした。
このメールは正規に認可されたSendGridの送信ドメインから送られていたため、社内のHR担当者になりすました表示名が使われていたにもかかわらず、SPF・DKIM・DMARCの各認証チェックをすり抜けていました。
このAiTMインフラは単なる認証情報の窃取にとどまらず、被害者が認証を完了した後にアクティブなMicrosoft 365セッションクッキーを傍受していました。
これこそが、従来型の認証情報フィッシングとAiTMフィッシングを分ける決定的な違いです。攻撃者は事前に認証済みのブラウザセッションを手に入れ、新たなMFAプロンプトを発生させることなくそれを再生できてしまいます。
Microsoftはこれまでにも、盗まれたクッキーによって攻撃者が通常の認証フローを回避しつつ被害者本人になりすませる危険性について警告してきました。
MDR(マネージド検知・対応)の調査により、再生されたセッションが商用VPNの出口ノードを経由して動作していたことが判明しました。
サインインのテレメトリでは、同一のMicrosoft 365セッションがアムステルダムとロサンゼルスでおよそ1分間隔で出現しており、物理的に不可能な移動パターン、すなわちトークンの再生を強く示唆する挙動が確認されました。
観測されたログインはすべて単一要素の認証イベントで、「MFA previously satisfied(MFAは以前に満たされている)」と記録されており、トークン保護は未紐付け、条件付きアクセスも適用されていませんでした。
メールボックスへのアクセスを得た後、攻撃者はマルウェアを展開したり、エンドポイントに永続化の仕掛けを作ったり、横展開を行ったりはしていませんでした。
その代わり、財務担当ユーザーの委任権限を使ってExchange Online、SharePoint、Microsoft 365検索、そして共有の買掛金(accounts-payable)メールボックスにアクセスしていました。
攻撃者はその後、3つの悪意ある受信トレイルールを作成しました。これらのルールは、取引先からの督促通知や不正な支払い変更を露見させかねない社内メールを含む受信メッセージを自動的にアーカイブし、既読扱いにするものでした。
さらに、それ以降のルール処理を停止させることで、正規のメールボックスのワークフローが隠された通信を表面化させないようにしていました。
TrendAI Visionの研究者らによると、この攻撃キャンペーンは財務担当従業員に送られた「PTO Request Denied(有給休暇申請却下)」という個人を狙ったスピアフィッシングメールから始まったといいます。
こうした受信トレイルールの悪用は、BECにおいてよく使われる隠蔽手口です。Microsoftは、侵害された可能性のあるアカウントを調査する管理者に対し、隠されたものも含めすべての受信トレイルールを確認するよう推奨しています。攻撃者はしばしばメールをリダイレクトしたり、削除したり、目立たないフォルダへ移動させたりして、ユーザーが警告や返信に気づかないようにするためです。
Microsoft 365の受信トレイルール
この詐欺は、2つの段階が並行して進行する形で展開されました。第一段階では、攻撃者が無料のウェブメールアカウントを使い、取引先の買掛金担当者になりすましました。
約20件の実在する未払い請求書を引き合いに出し、支払い方法を小切手からACH(自動決済)へ切り替えるよう要求し、偽造されたACH認可書とW-9(納税者番号提出書類)を提出しました。この手口はおよそ3週間にわたり、11回のメールのやり取りを通じて続けられました。
第二段階では、攻撃者は似せたドメイン(look-alike domain)を使い、被害組織自身の買掛金担当上級社員になりすましました。
この社内へのなりすましによって、取引先の銀行口座変更に対する見かけ上の確認が得られた形となり、攻撃者が管理する口座情報について誤った安心感が生み出されてしまいました。
今回の重要な検知の手がかりは、エンドポイントのアラートではありませんでした。ホストのフォレンジック分析では、情報窃取型マルウェアやリモートアクセスツール、横展開の痕跡は一切見つかりませんでした。
その代わり、対応チームはMicrosoft Entra IDのサインイン記録、Microsoft 365メールボックスの監査ログ、クラウドメールのテレメトリを相互に照合しました。
特に価値の高い検知イベントとしては、海外または社外のIPアドレスから発生したNew-InboxRule、Set-InboxRule、SoftDelete、HardDeleteの各操作が挙げられます。
アナリストは、これらの操作を不審なセッションID、異常なアクセス元、商用VPNインフラ、そして「MFAは以前に満たされている」と記録されたサインインと突き合わせて分析すべきです。
Microsoft 365の監査ログは、受信トレイルールの変更やSend As(代理送信)アクティビティといった、BECの実態をしばしば明らかにするメールボックスイベントを可視化できます。
組織は、予期しない受信トレイルールの作成を、とりわけそれがメールをアーカイブする、既読扱いにする、削除する、あるいは支払い関連の通信を狙ったものである場合には、ID侵害の兆候として扱うべきです。
Exchange Online管理者は、以下のコマンドで表示可能なルールと隠されたルールの両方を一覧表示できます。
Get-InboxRule -Mailbox -IncludeHidden
侵害が確認された場合、インシデント対応チームはアクティブなセッションの失効、認証情報のリセット、悪意あるルールの削除、メール転送設定の確認、支払い変更内容の帯域外(out-of-band)での検証、そして影響を受けたSharePointおよびExchangeのアクティビティ分析を実施すべきです。
Microsoftはまた、セッションクッキー窃取のリスクを低減するため、条件付きアクセスポリシーの適用、リスクのあるサインインの監視、フィッシング耐性のある認証手段の利用も推奨しています。
今回のインシデントは、財務チームが銀行口座情報の変更をすべて独自に検証しなければならない理由を浮き彫りにしています。
現代のBECにおいて、攻撃者はワークステーションに侵入する必要すらありません。必要なのは、説得力のあるメール1通、承認されたMFAプロンプト1回、そして不正な支払い指示をごく普通のことのように見せかけるだけの時間だけなのです。
★ どのセキュリティツールを削減すべきか？1ページでスコア化 – 継承されたセキュリティスタックガイドをダウンロード
Securityconsulting services
翻訳元: https://gbhackers.com/microsoft-365-inbox-rules/
