UNC3944 に対する防御: 最前線からのサイバー犯罪対策強化ガイダンス

背景

※この投稿は米国時間 2025 年 5 月 7 日に、Google Cloud blog に投稿されたものの抄訳です。

UNC3944 は、金銭目的の脅威アクターであり、その活動には Scattered Spider に関する公開報告との一致が見られます。ソーシャル エンジニアリングを執拗に使用し、大胆な方法で被害者にコンタクトを取ることが特徴です。UNC3944 は当初、SIM スワップ攻撃を仕掛けるために主に通信関連の企業を標的としていました。しかし、2023 年初頭からランサムウェアとデータ窃盗による恐喝に焦点を移したことで、より幅広い業界の企業に影響が拡大しました。それ以降、UNC3944 は特定の業種を集中的に攻撃する時期が定期的に訪れることが確認されています。たとえば、2023 年後半には金融サービス企業、2024 年 5 月には食品サービス企業が標的になっています。以前は有名ブランドを攻撃の対象にしていたこともあり、これは名声を確立し、ニュース メディアから注目を集めることが狙いだったと考えられます。

Google Threat Intelligence グループ（GTIG）は、UNC3944 との関連が疑われる個人に対する法的措置が実施された 2024 年以降、UNC3944 の活動が減少したことを確認しました。多くの場合、脅威アクターは取り締まりを受けると一時的に活動を停止または大幅に縮小します。これには、法執行機関の注意をそらす、能力やパートナーシップを再構築する、検出を回避するために新しいツールに移行する、といった目的が背景にあると考えられます。UNC3944 は、より広範な脅威アクター コミュニティとの既存のつながりを利用することで、法的措置から迅速に復活する可能性があります。

最近公開された報告では、脅威アクターが Scattered Spider と一致する手法を使用して英国の小売業者を標的に DragonForce ランサムウェアを展開したとされています。BBC ニュースによるその後の報道では、DragonForce とのつながりを持つ攻撃者が英国の複数の小売業者を標的とした攻撃について犯行声明を出したことが報じられています。さらに、DragonForce ランサムウェアの運営者は、今年 3 月に活動を停止したと思われていた Ransomware-as-a-Service（RaaS）である RansomHub を引き継いだという声明を最近になって発表しました。UNC3944 は、ALPHV（別名 Blackcat）RaaS が活動を停止した後、2024 年に RansomHub のアフィリエイトになりました。UNC3944 や DragonForce RaaS の関与は個別に確認されていないものの、過去数年間にわたって、GTIG の追跡対象となっているデータ漏洩サイト（DLS）に小売業者のデータを投稿するケースが増加しています。こうしたサイトは、恐喝犯が、被害者への脅迫や、窃取した被害者データの漏洩を目的として使用するものです。2025 年に入ってから DLS への投稿の被害に遭った企業のうち、小売業が占める割合は 11% であり、2024 年の約 8.5%、2022 年と 2023 年の 6% と比べて上昇しています。一般的に小売業者は大量の個人情報（PII）と財務データを保有していることから、UNC3944 を含む脅威アクターが小売業者を魅力的な標的と見なしている可能性は十分にあります。さらに、これらの企業は、自社の金融取引処理機能がランサムウェア攻撃の影響を受けた場合に身代金の要求に応じやすい傾向があります。

UNC3944 の被害者については、次のパターンを確認しています。

• 標的になっている業種: UNC3944 は、テクノロジー、通信、金融サービス、ビジネス プロセス アウトソーシング（BPO）、ゲーム、ホスピタリティ、小売、メディア、エンターテイメントを中心に、幅広い業種の企業を標的としています。

• 重視されている地域: 米国、カナダ、英国、オーストラリアなどの英語圏の国に所在する企業が主に標的になっています。最近のキャンペーンでは、シンガポールやインドも標的になっています。

• 被害組織の規模: UNC3944 は多くの場合、より大きな被害をもたらし、高額な身代金を要求することができるという理由から、大企業を攻撃の対象にしています。特に、ソーシャル エンジニアリングの手法への耐性が低い、大規模なヘルプデスクや外部委託された IT 機能を備えた組織を標的にしています。

UNC3944 の戦術、手法、手順（TTP）の概要を次の図に示します。

予防的なセキュリティ強化策に関する推奨事項

以下では、UNC3944 が使用する戦術に対抗するための推奨事項を次の柱に沿って紹介していきます。

• ID

• エンドポイント

• アプリケーションとリソース

• ネットワーク インフラストラクチャ

• モニタリング / 検出

通常、このガイドに示す推奨事項をすべて実行すれば IT 運用や通常の運用に一定の影響があるものの、これまで UNC3944 の防御、封じ込め、根絶のために組織をサポートしてきた Mandiant の豊富な経験から、まずは特定の領域を優先することが効果的であることがわかっています。組織は、初めに以下の推奨事項に重点的に取り組む必要があります。

• すべてのインフラストラクチャ、ID、重要な管理サービスにわたって完全な可視化を実現する。

• インフラストラクチャ全体で ID の分離を確保する。

• 厳格な認証条件を強化する。

• パスワードの再設定と多要素認証（MFA）の登録に対して厳格な ID 制御を適用する。

• 最新のソーシャル エンジニアリング攻撃 / キャンペーンを常に警戒することの重要性を説明し、周知する（この投稿の「ソーシャル エンジニアリングに対する意識の向上」セクションを参照）。UNC3944 のキャンペーンは、エンドユーザーだけでなく、企業環境内の IT 担当者や管理者も標的としています。

これらの対策は、このガイド内の他の推奨事項を実行する際の重要な基盤となります。

Google SecOps をご利用の場合は、UNC3944 のアクティビティを積極的に検出してアラートを発する既存の保護機能を利用できます。

ID

確実な本人確認

UNC3944 は、ソーシャル エンジニアリング手法を使用してユーザーになりすましてヘルプデスクに連絡する事例が多く存在することが知られています。そのため、「確実な本人確認」のプロセスをさらに強化することが重要です。

• ヘルプデスクのスタッフが、セキュリティ情報の初期登録、変更、提供の前に従業員を確実に特定できるようにトレーニングを提供します。少なくとも特権アカウントについては、以下のような方法での本人確認のプロセスを義務付ける必要があります。

• カメラ / 対面での本人確認

• 身分証明書による確認

• チャレンジ レスポンス方式での確認

• セキュリティ侵害の脅威が差し迫っている場合や、侵害がすでに発生している場合は、ユーザー自身によるパスワードの再設定を一時的に無効にするか、再設定に必要なユーザー確認のプロセスを強化します。アカウント管理の操作では、最初のステップとして確実な本人確認を実施する必要があります。また、従業員が新しい MFA デバイスを追加するなど、認証方法を変更する場合は、その前に厳格な認証方法を使用した認証を要求する必要があります。さらに、以下を活用します。

• 信頼できる場所

• 認証やセキュリティの変更に関する通知

• 高リスクの変更に対するアウトオブバンド認証。たとえば、機密性の高いリクエストに応じる前に、登録された電話番号へのコールバックまたは既知の企業メールによる確認を要求します。

• UNC3944 は一般に公開されている個人データ（生年月日や社会保障番号の下 4 桁など）を所有していることが多いため、そうしたデータを本人確認に使用しないようにします。可能な場合は、社外秘の情報またはリアルタイム プレゼンスの確認によって本人確認を行います。

• 脅威のリスクが高い期間はユーザー自身による MFA の再設定を一時的に無効にし、そのような変更はすべて詳細な調査を伴う手動のヘルプデスク ワークフローを通じて行うようにします。

厳格な認証

認証機能を回避するために使用されるソーシャル エンジニアリングなどの手法を防ぐには、以下の方法をとります。

• SMS、電話、メールを認証手段から除外する。

• フィッシング耐性のある MFA（ナンバー マッチングや位置情報の確認など）を必要とする認証システム アプリを使用する。

• パスワードなしの認証に移行する（可能な場合）。

• 特権ロールが割り当てられている ID の認証に FIDO2 セキュリティ キーを使用する。

• 管理者権限を持つユーザーが以前の MFA 手法を登録または使用できないようにする（下位レベルのユーザーには許可されている場合でも同様）。

• マルチ コンテキスト基準を適用して認証トランザクションを強化する。たとえば、認証トランザクションの一環として、ID 以外に特定のデバイスと場所の属性の検証も行います。

• Google Workspace を利用している組織では、コンテキストアウェア アクセス ポリシーを使用して、これらのコンセプトを適用できます。

• Microsoft Entra ID を利用している組織では、条件付きアクセス ポリシーを使用して、これらのコンセプトを適用できます。

MFA の登録と変更

侵害された認証情報を利用して MFA 手法の変更や、攻撃者が制御する MFA 手法の登録が行われることを防ぐには、次の対策を講じます。

• ユーザー登録に使用できる認証方法を確認し、不要な方法や重複する方法を無効にします。

• 信頼できる IP アドレスからコンプライアンス ポリシーに準拠したデバイスを使って試行したときのみ許可されるように MFA の登録と変更の操作を制限します。Microsoft Entra ID を利用している組織では、これは条件付きアクセス ポリシーを使用することで可能です。

• セキュリティ侵害の疑いがある場合は、MFA の再登録が必要になる場合があります。この操作は、企業の所在地または信頼できる IP アドレスからのみ実施できるようにする必要があります。

• MFA 要件を回避できる特定の IP アドレスを確認します。Microsoft Entra ID を使用している場合は、[名前付きロケーション] や以前の [サービス設定] の画面で確認できます。

• 複数のユーザー アカウントで同じ MFA 手法または電話番号が登録されている場合は、攻撃者が制御するデバイスが登録されている可能性があるため、調査してアラートを発します。

管理者ロール

権限昇格と環境へのアクセス拡大を防ぐには、次の対策を講じます。

• 特権アクセスについては、組織の ID ストア（Active Directory など）をインフラストラクチャ プラットフォーム、サービス、クラウド管理コンソールから分離させます。組織はローカル管理者アカウント（VMware vCenter のローカル管理者アカウントなど）を作成する必要があります。ローカル管理者アカウントは、次の原則に従います。

• パスワードを長く複雑なものにする

• パスワードは、組織のパスワード管理ソリューションやパスワード保管ソリューションに一時保存しない

• 多要素認証（MFA）を適用する

• 管理ポータルは、信頼できる場所から特権 ID でのみアクセスできるようアクセス権を制限します。

• 特権が必要な操作に関連する認証情報を使用（「チェックアウト」）するのにジャスト イン タイム アクセス管理を利用するようにします。

• クラウド リソースへのアクセスと管理に対して、最小権限の原則に従ったアクセス制限と境界を適用します。

• Google Cloud を利用している組織では、IAM 拒否ポリシーまたはプリンシパル アクセス境界ポリシーを使用して、これらのコンセプトを適用できます。

• Microsoft Entra ID を利用している組織では、Azure のロールベース アクセス制御と Entra ID のロールベース アクセス制御を使用して、これらのコンセプトを適用できます。

• 特権アカウントのセキュリティを強化して、Tier 0 以外のエンドポイントや特権アクセス ワークステーション以外のエンドポイントでの公開や使用を防止します。

プレイブック

現代における認証は、単一のパスワードだけに依存するものではありません。そのため、組織はプロセスや関連するプレイブックに次のステップを含める必要があります。

• トークンとアクセス キーを取り消す。

• MFA デバイス登録を確認する。

• 認証要件に加えられた変更を確認する。

• 新しく登録されたデバイスとエンドポイントを確認する。

エンドポイント

デバイスのコンプライアンスと検証

認証トランザクションには、厳格な本人確認要件だけでなく、デバイスの認証と検証も必要です。組織は、以下の機能を検討する必要があります。

• 環境にリモート接続するデバイス（VPN 経由など）に対して、ポスチャー チェックを実施します。デバイスのポスチャー チェックの例を以下に示します。

• 必要なホストベースの証明書が各エンドポイントにインストールされていることを検証する。

• エンドポイントが承認済みのオペレーティング システム（OS）で動作し、バージョン要件を満たしていることを確認する。

• 組織のエンドポイント検出対応（EDR）エージェントがインストールされ、アクティブに実行されていることを確認します。すべての管理対象エンドポイント デバイスに対して EDR のインストールとモニタリングを行います。

不正または未承認のエンドポイント

脅威アクターが不正なエンドポイントを悪用して環境にアクセスするのを防ぐため、組織は次の対策を講じる必要があります。

• 新しく作成された、または最近マネージド ドメインに追加された不正な踏み台インスタンスまたは仮想マシンがないかどうかをモニタリングする。

• デバイスを Entra やオンプレミスの Active Directory に追加する機能を制限するようにポリシーを強化する。

• デフォルトの Windows ホスト名が含まれるデバイスの認証ログを確認する。

ラテラル ムーブメントに対するセキュリティ強化

不正に入手された認証情報を使ったラテラル ムーブメントを防ぐため、組織は次の対策を講じる必要があります。

• ローカル アカウントをリモート（ネットワークベース）認証に使用する機能を制限する。

• ローカルの管理共有や隠し共有へのリモート アクセスを無効化または制限する。

• ローカルのファイアウォール ルールを適用して、SMB、RDP、WinRM、PowerShell、WMI を介した受信をブロックする。

GPO: ユーザー権利の割り当てのロックダウン（Active Directory）

組織は、エンドポイントへのリモート認証にドメインベースの特権アカウントとサービス アカウントが利用される可能性を、可能な限り低減する必要があります。これは、以下のユーザー権利の割り当てに対してグループ ポリシー オブジェクト（GPO）構成を使用することで実現できます。

• ローカル ログオンを拒否する。

• リモート デスクトップ サービスを使ったログオンを拒否する。

• ネットワーク経由でのコンピュータへのアクセスを拒否する。

• バッチジョブとしてのログオンを拒否する。

• サービスとしてのログオンを拒否する。

アプリケーションとリソース

バーチャル プライベート ネットワーク（VPN）アクセス

脅威アクターは、セキュリティ チームがネットワークの状況を把握できないように、VPN エージェントを変更または無効化しようとする場合があります。そのため、組織は次の対策を講じる必要があります。

• エンドユーザーが VPN エージェントの構成を変更できないようにします。

• VPN エージェントの構成の変更時に適切なロギングが行われるようにします。

• 管理対象デバイスについては、継続的な保護を確保するために常時接続 VPN 構成の使用を検討します。

特権アクセス管理（PAM）システム

特権アクセス管理（PAM）システムへのアクセスを試みる脅威アクターから組織を保護するには、次の対策を講じる必要があります。

• 企業向けのパスワード マネージャーや特権アクセス管理（PAM）システムに対し、ネットワーク アクセスと ID アクセスの分離と制限を適用します。これには、企業インフラストラクチャや仮想化プラットフォームから分離された PAM システム専用のサーバーやアプライアンスを利用することも含まれます。

• PAM システムにアクセスできるアカウントの範囲を限定し、強力な認証（MFA）を要求するようにします。

• PAM システム内にロールベース アクセス制御（RBAC）を適用し、アクセスできるアカウントの範囲を（割り当てられたロールに基づいて）制限します。

• PAM システムに保存されている認証情報をチェックアウトする際には、ジャスト イン タイム（JIT）アクセスの原則に準拠します。

仮想化インフラストラクチャ

仮想化インフラストラクチャへのアクセスを試みる脅威アクターから組織を保護するには、次の対策を講じる必要があります。

• ESXi ホストや vCenter Server Appliance を分離し、これらのホストやアプライアンスへのアクセスを制限します。

• 仮想マシンのバックアップが分離および保護され、可能であれば不変であることを確認します。

• 仮想化プラットフォームに対する管理者権限の認証と、一元化された ID プロバイダ（IdP）とのバインドを解除します。これには、個々の ESXi ホストと vCenter Server が含まれます。

• 仮想化プラットフォームに関連する特権 ID のローカルルートと管理者パスワードを頻繁にローテーションします。

• より強力な MFA を使用し、仮想化インフラストラクチャに対するすべての管理者権限をローカル SSO にバインドします（可能な場合）。

• アグリゲート プールの一部である各仮想ホストに関連付けられたローカルルートと管理者 ID に対して、ランダムなパスワードを適用します。

• SSH（シェル）を利用した仮想化プラットフォームへのアクセスを無効化または制限します。

• すべての ESXi ホストでロックダウン モードを有効にします。

• モニタリングを強化して、仮想化プラットフォームに対する不正または不審な認証の試みやアクティビティを特定します。

バックアップ インフラストラクチャ

バックアップ インフラストラクチャとデータへのアクセスを試みる脅威アクターから組織を保護するには、次の対策を講じる必要があります。

• アカウントに MFA を適用するのに加え、バックアップ インフラストラクチャへのアクセスと管理に一意かつ独立した（ID プロバイダに統合されていない）認証情報を使用します。

• 本番環境から分離された専用のネットワーク内にバックアップ サーバーを設置します。バックアップをさらに保護するには、変更不可のバックアップ ソリューション内に保存する必要があります。

• バックアップ インフラストラクチャに関連する管理インターフェースにアクセスする受信トラフィックとプロトコルを制限するアクセス制御を実装します。

• 敵対的行動（レッドチーム）をシミュレートして、バックアップの保護と完全性を定期的に検証します。

エンドポイント セキュリティ管理

脅威アクターがエンドポイントのセキュリティや管理に関するテクノロジー（EDR やパッチ管理ツールなど）を悪用することを防ぐため、組織は次の対策を講じる必要があります。

• エンドポイント セキュリティ ツール プラットフォームに対する管理者権限をセグメント化します。

• オンプレミスの Active Directory でグループ ポリシー オブジェクト（GPO）を作成、編集、削除できる ID の範囲を限定します。

• Microsoft Intune を利用している場合は、変更の承認と適用に対して複数の管理者承認（MMA）を要求する Intune アクセス ポリシーを適用します。

• EDR とパッチ管理テクノロジーへの不正アクセスをモニタリングおよび確認します。

• EDR とパッチ管理テクノロジーを使用して、エンドポイントとシステムでのスクリプトやアプリケーションのデプロイをモニタリングします。

• 「許可リスト」に登録された実行可能ファイル、プロセス、パス、アプリケーションを確認およびモニタリングします。

• エンドポイントにインストールされているアプリケーションのインベントリを作成し、不正なリモートアクセス ツール（RAT）や偵察ツールがインストールされていないかを確認します。

クラウド リソース

脅威アクターがクラウド インフラストラクチャへのアクセスを悪用して永続的なアクセスを獲得するのを防ぐため、組織は次の対策を講じる必要があります。

• クラウド リソース構成のモニタリングと確認を通じて、新しく作成されたリソース、公開されたサービス、その他の不正な構成を特定し、調査します。

• クラウド インフラストラクチャをモニタリングして、新規に作成または変更されたネットワーク セキュリティ グループ（NSG）ルール、ファイアウォール ルール、またはリモートからアクセス可能な一般公開リソースを検出します。

• プログラムによるキーや認証情報（アクセスキーなど）の作成をモニタリングします。

ネットワーク インフラストラクチャ

アクセス制限

公開されているアプリケーションと内向き経路を事前に特定し、不正アクセスのリスクを軽減するため、組織は次の対策を講じる必要があります。

• 脆弱性スキャンを使って外部未認証スキャンを実行し、一般に公開されているドメイン、IP、IP 範囲（CIDR 表記）を特定します。

• 一般公開されているアプリケーションやサービスへのアクセスに対して厳格な認証（フィッシング耐性のある MFA など）を適用します。

• 機密性の高いデータやアプリケーションについては、特定の（信頼できる）IP 範囲からのみクラウド環境 / SaaS アプリケーションへの接続を許可するよう設定します。

• Tor の出口ノードと VPS の IP 範囲をブロックします。

ネットワーク セグメンテーション

「信頼されているサービス インフラストラクチャ」（TSI）という用語は通常、組織にコアサービスを提供するプラットフォームとテクノロジーの管理インターフェースのことを指します。次に例を示します。

• アセットやパッチの管理ツール

• ネットワーク管理用のツールやデバイス

• 仮想化プラットフォーム

• バックアップ テクノロジー

• セキュリティ ツール

• 特権アクセス管理システム

TSI の管理プレーンへのダイレクト アクセスと公開を最小限に抑えるため、組織は次の対策を講じる必要があります。

• TSI へのアクセスを、内部ネットワーク セグメント、強化されたネットワーク セグメント、または PAW からのアクセスのみに限定します。

• TSI に直接アクセスするネットワーク トラフィック パターンのモニタリングに焦点を当てた検出機能を作成して、異常な点や不審なトラフィックについてアラートを発します。

外向きトラフィックの制限

コマンド＆コントロールの能力を制限し、大量のデータが引き出される可能性を低減するため、組織は次の対策を講じる必要があります。

• すべてのサーバーからの外向き通信を制限します。組織は、TSI に関連するサーバー、Active Directory ドメイン コントローラ、重要なアプリケーション サーバーやデータサーバーからの外向き通信の制限を優先させる必要があります。

• 悪意のあるドメイン名、IP アドレス、リモート アクセス ツール（RAT）に関連付けられたドメイン名 / アドレスへの送信トラフィックをブロックします。

モニタリング / 検出

偵察

UNC3944 は侵害の初期段階において、ユーザー プロビジョニング、MFA やデバイスの登録に関するドキュメント、ネットワーク図、ドキュメントやスプレッドシート内の共有認証情報を検索することで知られています。

UNC3944 は、ADRecon、ADExplorer、SharpHound などのネットワーク偵察ツールも使用します。そのため、組織は次の対策を講じる必要があります。

• こうしたドキュメントを格納するサイトやポータルに対して、必要なアカウントのみがアクセスできるようにアクセス制限を設定します。

• 共有認証情報が含まれている可能性があるドキュメントやスプレッドシートを探して削除します。

• EDR エージェントを使用するエンドポイントに、既知の偵察ツールの実行に関するアラート ルールを実装します。

• ID モニタリング ソリューションを利用している場合は、検出ルールが有効になっていること、偵察と探索の検出に対してアラートが発生することを確認します。

• ドメインの登録を継続的にモニタリングする自動メカニズムを実装します。組織の命名規則を模倣したドメインを特定します。たとえば [組織名]-helpdesk.com や [組織名]-SSO.com などです。

MFA の登録

MFA 登録プロセスのセキュリティをさらに強化するため、組織は次の対策を講じる必要があります。

• ログを確認して、新しい MFA デバイスや MFA 手法の登録または追加に関連するイベントを特定します。これには、次のような操作が含まれます。

• MFA デバイスの登録

• 認証システム アプリの追加

• MFA 用の電話番号の追加

• 同一の MFA デバイス、MFA 手法、電話番号の複数のユーザーへの関連付け

• 新規登録の正当性を、期待されるユーザーの挙動とオンボーディングやデバイス登録の記録に照らし合わせて確認します。

• 新しい登録が検出された場合は、ユーザーに連絡してその操作が意図したものかどうかを確認します。

コラボレーションとコミュニケーションのプラットフォーム

ソーシャル エンジニアリングや、コミュニケーション プラットフォームに対する不正アクセス、改ざんを防ぐために、組織は次の対策を講じる必要があります。

• Microsoft Teams などのコミュニケーション ツールに関する組織のポリシーを確認します。

• 想定されるベンダーとパートナーの信頼できる外部ドメインのみを許可します。

• 外部ドメインをブロックできない場合は、信頼できるドメインのベースラインを作成し、従業員に連絡しようとする新しいドメインについてアラートを発します。

• 従業員やスタッフにセキュリティ意識向上トレーニングを提供し、不審な電話やメッセージを受け取った場合は組織のヘルプデスクに直接連絡するよう教育します。

以下は、Microsoft Defender の高度なハンティング クエリの例です。このクエリは、（ヘルプデスクになりすまそうとしている）外部アカウントが組織のユーザーに連絡しようとする試みを検出する目的で記述されています。

注: DisplayName フィールドを変更して、組織固有のその他の関連フィールド（「IT Support」や「ServiceDesk」など）を含めることができます。

CloudAppEvents
| where Application == "Microsoft Teams"
| where ActionType == "ChatCreated"
| extend HasForeignTenantUsers = 
parse_json(RawEventData)["ParticipantInfo"]["HasForeignTenantUsers"]
| extend DisplayName = parse_json(RawEventData)["Members"][0]["DisplayName"]
| where IsExternalUser == 1 or HasForeignTenantUsers == 'true'
| where DisplayName contains "help" or AccountDisplayName contains "help" 
or AccountId contains "help"

Google SecOps の検索クエリの例を以下に示します。

注: DisplayName フィールドを変更して、組織固有のその他の関連フィールド（「IT Support」や「ServiceDesk」など）を含めることができます。

metadata.vendor_name = "Microsoft"
metadata.product_name = "Office 365"
metadata.product_event_type = "ChatCreated"
security_result.detection_fields["ParticipantInfo_HasForeignTenantUsers"] = 
"true"
(
principal.user.userid = /help/ OR
principal.user.email_addresses = /help/ OR
about.user.user_display_name = /help/
)

ID セッションのリスクと可視性

以下を検出する必要があります。

• プロキシや VPN サービス プロバイダなど、普段使われていない場所からの認証。

• 認証方法や認証条件を変更しようとする試み。

• ソーシャル エンジニアリングの手法に基づく認証の異常のモニタリングとハンティング。

多要素認証のすり抜け

UNC3944 は多要素認証の使用に関する要件を変更することが知られています。そのため、組織は次の対策を講じる必要があります。

• Entra ID を利用している場合は、MFA の要件を回避するために使用される可能性がある「信頼できるネームド ロケーション」に対する変更をモニタリングします。

• Entra ID を利用している場合は、MFA を適用する条件付きアクセス ポリシーの変更をモニタリングします。特に、関連するポリシーで侵害されたユーザー アカウントやデバイスが除外されているかどうかに注目します。

• 不審なアクティビティが検出された場合にステップアップ（再）認証をトリガーできるワークフローを構築し、SOC がトークン リプレイや不審なデバイスのログイン状況を把握できるようにします。

ドメイン フェデレーションの不正使用

Microsoft Entra ID を使用している組織は、Entra ID の ID フェデレーションの不正使用をモニタリングします。

• Entra ID テナントに登録されているドメイン名を確認します。特に、フェデレーションが有効になっているドメインに注意してください。

• これらのドメインのフェデレーション構成が正しいことを確認します。

• テナント内で新しいドメインが作成されたり、認証方法がフェデレーション方式に変更されたりしていないかモニタリングします。

• ドメイン フェデレーションを不正使用するには、変更を実行するアカウントに Entra ID の管理者権限が付与されている必要があります。そのため、すべての管理者アカウント、ポータル、プログラムによるアクセスのセキュリティを強化することが不可欠です。

ソーシャル エンジニアリングに対する意識の向上

UNC3944 は、複数のソーシャル エンジニアリング手法を駆使し、アクセス権を手に入れるためにユーザーを誘導することに非常に長けています。組織は、次の手法を利用した攻撃について理解し、そうした攻撃に遭遇した場合に社内のセキュリティ チームに通知するようユーザーを教育する必要があります。

• IT 部門をかたってユーザーにソフトウェアをダウンロードしてマシンにインストールするよう要求する SMS フィッシング メッセージ。ユーザーのマシンがコンプライアンス違反である、または内部管理システムに報告されていないと主張する場合もあります。

• 正規のものに似たドメイン名を参照し、SSO（シングル サインオン）と会社名のバリエーションを参照するサイトへのリンクが記載された SMS メッセージまたはメール。メッセージには、パスワードや MFA を再設定する必要があることをユーザーに知らせるテキストが含まれる場合があります。

• パスワードや MFA を再設定したり、検証済みのワンタイム パスコード（OTP）をデバイスから入力したりすることをユーザーに依頼する IT 部門からの電話。

• 特定のシステムに対するアクセス権を付与するようリクエストする SMS メッセージやメール。特に、組織がアクセス権のプロビジョニング方法をすでに確立している場合は、こうしたメッセージやメールに注意する必要があります。

• MFA 疲労攻撃。攻撃者は、ユーザーがうっかり、またはイライラして承認するまで、MFA プッシュ通知を被害者のデバイスに繰り返し送信します。組織は、予期しない MFA プロンプトを拒否し、そのようなアクティビティを直ちに報告するようユーザーを教育する必要があります。

• コラボレーション ツールを使用したなりすまし。UNC3944 は、Microsoft Teams などのプラットフォームを使用して、社内の IT サポート担当者やサービス デスク担当者になりすまします。組織は、普段とは違うチャット メッセージを見抜き、Microsoft Teams などの社内コラボレーション ツールで認証情報や MFA コードを共有しないようにユーザーを教育する必要があります。外部ドメインを制限し、なりすましの試み（例: 「helpdesk」や「support」を含むユーザー名）をモニタリングすることをおすすめします。

• まれに、攻撃者が晒し行為や攻撃的な言葉を使ってユーザーを脅し、要求に従うよう迫ることがあります。従業員がこの戦術を理解し、このようなインシデントを報告した場合に組織がサポートしてくれることを認識できるようにします。

その他の関連情報

• ランサムウェアの防止および封じ込め戦略: インフラストラクチャ、ID およびエンドポイントの強化と防御のための実践ガイダンス

• UNC3944 の標的は SaaS アプリケーション

• なぜ私にテキスト メッセージを？UNC3944、SIM スワップ詐欺やランサムウェア攻撃および恐喝を目的とした SMS フィッシング キャンペーンで悪名を馳せる

-Mandiant