UNC6671がリブランド、複数ブランドを使ったビッシング恐喝が金融サービスと企業クラウド環境を標的に

執筆者: Tyler McLellan,Austin Larsen

はじめに

Google Threat Intelligence Group(GTIG)は、2026年5月にBlackFile恐喝ブランドの引退が発表されたとされているにもかかわらず、UNC6671がデータ窃取型の恐喝につながる侵害活動を積極的に続けている実態を追跡しています。テレメトリとインフラの分析から明らかになったのは、同グループが解散したのではなく、Redact、Pink、Helix、Falconといった複数の恐喝フロントに活動を分散させているという実態です。 

UNC6671は引き続き音声フィッシング(ビッシング)を悪用し、ITヘルプデスク担当者を装って企業従業員に接触し、緊急かつ必須のセキュリティ移行を装って標的を狙っています。特筆すべきは、この脅威アクターがしばしば従業員の個人携帯電話を通じて連絡を取っている点です。こうした電話によって被害者はなりすましログインポータルへ誘導され、そこでAdversary-in-the-Middle(AiTM)インフラが認証情報と多要素認証(MFA)トークンを窃取します。セッションの持続性を確保した後、攻撃者はMicrosoft 365やOktaを含む企業クラウド環境からのデータ窃取のために自動化スクリプトを展開します。

今回は2026年5月のブログの続報として、これらの恐喝ブランドをつなぐインフラの関連性を詳しく解説します。また、金融サービス、プライベートエクイティ、専門サービスへの注力といった最近の動向を含め、UNC6671のターゲティングがどのように変化してきたかを検証し、組織がこの脅威から自らを守るための強化策も紹介します。 

UNC6671関連の恐喝ブランド 

UNC6671が関与する侵入事案全体を通じて、初期アクセスや侵害後の戦術・技術・手順(TTP)は驚くほど一貫しています。これらの活動はいずれも、標的に合わせたITヘルプデスクを装ったビッシング、AiTMによる認証情報窃取用パネル、そしてSaaSアプリケーションからのデータ窃取を共通して用いています。この技術的な基盤は統一されているにもかかわらず、恐喝メッセージには異なるブランド名が使われ、こうした侵入の過程で盗まれた被害者データはそれぞれ別のデータリークサイト(DLS)で公開されています(図1)。公開されているグループの発信内容では、当初Redactへリブランドした理由としてアフィリエイトの離脱が挙げられていましたが、その後フィッシングテンプレート、被害者の属性、共有インフラの経路に重複が見られることから、関連するアクターがその後もPink、Helix、Falconといった恐喝ブランドを活動の収益化に利用してきたことがうかがえます。

当初のREDACTへのリブランド 

2026年6月27日、Redactの運営者は新たに開設したデータリークサイト(DLS)上でブログ記事を公開し、BlackFileからのリブランドと称する経緯について説明しました。この投稿でグループは、元のBlackFileブランドが追放されたアフィリエイトによって侵害・乗っ取られたと主張しています。Redactによれば、この元関係者はリンクされていないTox識別子を使い、無許可のなりすましDLSを運営し、Redactの名を騙って独自の恐喝キャンペーンを行っていたとされています。運営者は、この不正なアフィリエイトが2026年5月のBlackFileブランドの「閉鎖」を意図的に演出し、脅威インテリジェンスアナリストやサイバー保険交渉担当者の間に混乱を引き起こすことで、ブランドの評判を傷つけようとしたと主張しました。BlackFileとの関係を断つため、運営者はRedactへリブランドしたと述べ、今後のすべてのやり取りを認証するための単一の検証済みTox IDとPGP鍵を導入したとしています。さらに投稿では、競合グループからの圧力がリブランドの決定に影響したとの見方を明確に否定しています。

共有インフラ: フィッシングエコシステムのつながり

UNC6671は、パスキーに関連しているかのように見せかけた汎用のルートドメイン上に認証情報窃取用パネルをホストし、標的を絞ったビッシングキャンペーンを行うために被害者固有のサブドメインを付加しています。この一貫したデジタルフットプリントを監視した結果、複数の恐喝ブランドにまたがって特定の被害者ターゲティングに重複が見られることが判明しました。こうした重複から、BlackFile、Redact、Pink、Helix、Falconという各恐喝ブランドには共通の脅威アクター集団が関与しているとGTIGは評価していますが、分裂したアフィリエイトや共有のPhishing-as-a-Serviceインフラといった他のシナリオも考えられます。 

UNC6671は標的ごとに独立したインフラを維持するのではなく、複数の標的組織にまたがって汎用のルートドメインを再利用しており、これが恐喝ブランド間を結ぶ追跡可能な連鎖を生み出しています。

• Falcon: ルートドメインpasskeyhelpdesk[.]comは、Falconブランドで恐喝された少なくとも1組織の標的化に使用されていました。同じドメインは同時に、Helixブランドで恐喝された組織の標的化にも使われていたほか、後にDLSへの掲載を確認できなかった他の多数の企業にも使用されていました。さらに、portalpasskey[.]comやaddssopasskey[.]comといったルートドメインは、Falconに恐喝された組織を標的にしつつ、直接Helixのインフラへとつながる中間標的をホストしていました。

• Pink: 一部の未掲載企業は、別のルートドメイン(passkeyms[.]comやmysecurepasskey[.]comなど)を使って同時に標的にされており、これらはpasskeydeploy[.]comに集約された別のインフラクラスタへの中間的な橋渡し役として機能していました。この最終的なドメインは同時に、Pinkに恐喝された少なくとも1組織の標的化にも使われていました。

• Helix: ルートドメインpasskeyhelpdesk[.]comはFalconとHelixの標的化を直接結びつけていました。さらに、中間標的組織はoskeysync[.]comやkeysyncos[.]comのサブドメインクラスタへ追加のインフラを橋渡ししていました。これらのクラスタは、後にHelixのDLSに掲載された複数の組織を標的にしていました。

• BlackFile: setupsso[.]comやidokta[.]comなどのルートドメインは、BlackFileブランドで恐喝された組織の標的化に使用されていました。setupsso[.]com上の中間標的組織はpasskeydeploy[.]com(Pink)への橋渡し役となっていました。同時に、passkeyuser[.]comは別のBlackFile被害者の標的化に使用され、そこでは中間標的組織がpasskeyportal[.]com(Helix)やmysecurepasskey[.]comへと橋渡しされていました。

フィッシングテンプレート

分析の結果、これらすべてのドメインで同一のフィッシングテンプレートが使用されており、addssopasskey[.]com、createssopasskey[.]com、passkeyhelpdesk[.]comを含む複数のウェブサイト上で同一のコードとデザインが同時にホストされていることが分かりました。例えば、addssopasskey[.]comは後にFalconに恐喝された組織の標的化のみに厳密に使用されていた一方で、同一構成のpasskeyhelpdesk[.]comドメインは同時に、まったく別の2組織の標的化に使われており、そのうち1組織はFalcon、もう1組織はHelixによって恐喝されたとされています。複数のDLSブランドの認証情報を窃取するために、これほど広範囲にわたって一致するテンプレートが展開されていることは、共通の基盤インフラに依存していることを示唆しています。

ターゲティングの変遷

UNC6671のドメイン登録パターンからは、機密情報を保有している可能性が高い標的へと定期的に選定対象をシフトさせている様子がうかがえます。UNC6671は、想定される被害者名を組み込んだサブドメインを活用し、標的に合わせた認証情報窃取用パネルをホストしています。ルートドメインは企業の認証登録ポータルを模倣しており、「passkey」「mfa」「sso」といった用語を動詞と組み合わせています。

2026年4月から5月にかけて、製造業、不動産、医療、保険といった複数の業界にわたる、成熟した大規模企業を幅広く標的とするドメインが確認されました。この一連の活動期間中、脅威アクターはこうした確立された企業分野において、大量の認証情報窃取を優先していたとみられます。

その後の数か月間に確認されたサブドメインは、UNC6671の恐喝モデルの発展を反映しているように見えます。2026年6月には、標的が大手テクノロジー、運輸、ホスピタリティ業界の組織へと移行し、価値の高い知的財産、ソフトウェアのソースコード、あるいは機密性の高いVIP顧客データを保有する組織に狙いを絞っているようでした。2026年7月までには、標的プロファイルはさらに絞り込まれ、金融・法律分野に焦点が当てられ、確認されたインフラはプライベートエクイティ会社、法律事務所、金融格付機関に向けられていました。合併・買収、資本配分、訴訟に関わる組織に集中していることは、恐喝要求の交渉力を最大化するために、価値の高い企業データや機密データを狙う戦略を反映している可能性があります。

この2つの期間を比較すると、活動テンポの上昇も見て取れます。新たに確認されたインフラの件数は2026年6月1日から7月31日までの間に均等に分布しており、主にCloudflareとDDOS-GUARDを利用しながら、約1.6日に1つのドメインというペースで加速していました。7月20日から22日にかけては一時的に急増も見られ、72時間の間に7つのドメインが稼働を開始しています。この6月から7月にかけての全体的なテンポは、それ以前の2026年4月1日から5月31日までの活動と比べて明らかに増加しており、この期間には28件のルートドメインが2.2日に1件というやや低い頻度で登録されていました。

本ブログの公開日時点で、依然として名前解決が可能な8件のフィッシングドメインのうち7件はワイルドカードDNSを使用していませんでした。これは、パッシブDNSデータを通じて発見された標的が、UNC6671によって個別に狙われた可能性が高いことを示しています。 

新たな手口 

前回のブログ公開以降、UNC6671による侵入事案全体の手口はおおむね一貫していますが、いくつかの新たな手口も確認されています。

ITヘルプデスクとパスキーを装う口実

UNC6671の発信者は、企業のセキュリティ対策を回避するため、引き続き標的の従業員の個人携帯電話番号に電話をかけています。少なくとも最近の一部の事例では、脅威アクターが正規のヘルプデスクの電話番号をなりすまして、信憑性を高めていました。この通話では、FIDO2パスキーの有効化や多要素認証の登録更新を求める緊急のヘルプデスク指示であるという偽の口実のもと、発信者は従業員をなりすまし認証情報窃取用サブドメイン(例: [company].createssopasskey[.]comや[company].addssopasskey[.]com)へ誘導します。

回避技術

UNC6671は、アカウントレベルでの持続性を維持し、活動を隠蔽するために、防御回避への依存をますます強めています。最近の侵入事案では、グループは侵害したメールアカウントを利用し、SSO非対応の企業アプリケーションに対して不正なパスワードリセットを実行していました。エンドユーザーによる検知や自動セキュリティアラートを防ぐため、運営者はパスワードリセットの確認通知、二次的なセキュリティ通知、全社的なセキュリティアラート、そしてアカウントセキュリティやMFA設定の変更時に生成されるあらゆるアラートを、組織的に削除していました。

身代金交渉とブロックチェーン分析

2026年1月7日から2026年5月12日までの間、GTIGはBlackFileのビットコインウォレットアドレス18件を確認し、合計141.65 BTC、取引当時の価値でおよそ1,069万米ドル相当を受領していたことを確認しました。特筆すべき点として、これらのウォレットへの身代金支払いは、2026年5月11日に公表されたBlackFileデータリークサイトの閉鎖通知後も続いていました。4月下旬から5月上旬にかけて確認された複数の大規模な現金化の動きは、リブランド期間中も金銭面の活動が中断なく続いていたことを裏付けています。

当初の身代金要求額は通常、100万米ドルから300万米ドル以上の範囲にわたります。ただし恐喝の運営者は交渉の過程で要求額を変動させ、最終的には当初の身代金要求額から50%から75%の減額に応じることが多く見られました。この期間に追跡できた事例の53%以上で、最終的な支払額は平均75万米ドル(約10.2 BTC)でした。 

対策と強化のためのガイダンス

GTIGは、アイデンティティを標的としたビッシング、AiTMフィッシング、そしてプログラムによるSaaSデータ窃取を緩和するため、企業の防御担当者に以下の対策の実施を推奨します。

1. フィッシング耐性のある多要素認証を義務化する:すべてのSSO環境および企業のID プロバイダー(IdP)で、FIDO2準拠のローミングセキュリティキー、パスキー、プラットフォーム認証機能(Windows Hello for Business、Okta Fastpassなど)といったフィッシング耐性のある認証手段を義務付けます。これらの認証手段はWebAuthn標準を実装しており、認証装置と認証可能な特定のドメインとの間で暗号的なオリジンバインディングを強制するため、なりすましドメインやAiTMプロキシを無効化できます。

2. SaaSアプリケーションとクラウドプラットフォームをSSOと統合する: 複数のプラットフォームにまたがって認証基準を維持していると、設定のばらつきが生じやすくなります。SaaSアプリケーションごとに求められる、あるいはサポートされるセキュリティ機能は異なります。業務上重要なアプリケーションをEntra IDやOktaのような標準的なSSOプラットフォームと統合することで、異なるプラットフォーム間で一貫したセキュリティ管理を適用できます。

3. セッション制御を徹底する:少なくとも1営業日に1回は再認証を求めるよう、セッションの有効期間を短縮します。特権アクセスについては、アイドルセッションのタイムアウトを徹底してください。フィッシングキャンペーンが活発化している間は、これをさらに短縮できます。重要または機密性の高いリソースへのアクセス時には、追加認証(ステップアップ認証)を義務付けます。IPセッションバインディング、デバイスバインドセッションクレデンシャル、継続的アクセス評価(Continuous Access Evaluation)といった、認証プラットフォーム内のトークン窃取対策を活用してください。

4. 信頼できるネットワークソースへの認証を制限する:企業ネットワーク、VPN範囲、Secure Access Service Edge(SASE)プラットフォームといった既知のソースから来る、定義済みのネットワークゾーンを利用します。これらの範囲を、SaaSアプリケーションやクラウドプラットフォーム内、さらにはEntra IDやOktaの認証ポリシー内でも定義・適用してください。

5. アクセスには企業管理下のデバイスを要求する: MDMおよびEDRを備えた企業管理下のエンドポイントからの認証を義務付けることで、攻撃対象領域と、攻撃者が任意のデバイスをアクセスに利用できてしまう可能性を減らせます。デバイスチェックは、Entra IDやOktaの認証ポリシーの一部として設定できます。

6. エンドポイントおよびブラウザの認証情報保護機能を導入する:企業のパスワードハッシュが未許可のドメインに入力された際に、自動的な管理者アラートやリセットをトリガーするよう、Google Workspace Password Alertを有効にします。Microsoft 365環境については、未検証のサイトへの認証情報の入力をブロックするよう、Microsoft Defender SmartScreenとCredential Protectionを設定してください。

7. 放棄された認証チャレンジのパターンをIdPログで監視する:認証失敗(user.authentication.auth_via_mfa)や放棄されたプッシュチャレンジの直後に発生するMFA登録イベント(system.multifactor.factor.setup)がないか、OktaおよびMicrosoft Entra IDの監査ログを照会してください。

8. 直接的なストリーム窃取についてUALテレメトリを監査する: SOC(セキュリティオペレーションセンター)の検知パイプラインを設定し、UserAgent文字列がスクリプトライブラリ(python-requests、WindowsPowerShell、Go-http-client)であることを示す場合や、アクセス量が通常の人間によるブラウジングのしきい値を超える場合には、FileAccessedイベントをFileDownloadedと同等の重大度として扱ってください。

9. レジデンシャルプロキシ経由の認証を制限し、アラートを設定する: 商用VPNプロバイダー(Mullvad、Private Layerなど)や、従業員の通常の地理的傾向から外れた無関係のレジデンシャルブロードバンドプロキシプール(AT&T、Comcast、Charterなど)を発信元とするSSO認証試行に対して、条件付きアクセスポリシーと異常検知アラートを作成してください。

見通しと示唆

UNC6671に関連する活動は、持続的な戦術・技術・手順に対して脅威アクターのブランドがいかに流動的であるかを浮き彫りにしています。この活動に関連する恐喝ブランドは増え続けている一方で、これらの活動全体を貫く手口は、ヘルプデスクを装ったビッシング、AiTMによるセッション傍受、SaaSデータ窃取に一貫して根ざしています。

これはおそらく、活動を区分し、侵害の全体規模を隠し、交渉決裂時の影響を局所化する狙いから、複数の公開恐喝ブランドを運営する連携した脅威アクター集団の存在を反映している可能性が高いと、GTIGは考えています。この評価は、BlackFile、Redact、Pink、Helix、Falconの各ブランドで観測された緊密なインフラの重複、共有されているビッシングパネルの展開、そして被害者ターゲティングの重複によって裏付けられています。ただし、これらのブランド間の広範な力学を説明しうる他のシナリオもいくつか考えられます。

• アクターの分裂: 内部対立、金銭的な争い、あるいは運用上のセキュリティ侵害は、グループの分裂を招くことが日常的にあります。共有された初期アクセスの手順書、パネルのコード、標的リストへのアクセスを保持し続ける元アフィリエイトや分派グループは、まったく同一のTTPを実行し続けながら、容易に独立した恐喝フロントを立ち上げることができます。

• 共有エコシステムとパネルの利用: 別々の脅威グループが、単に同一のコモディティ化されたフィッシングパネル、音声フィッシングの発信者、共有インフラを利用しているだけという可能性もあります。こうしたAiTMパネルやVaaSサービスが広く出回るようになるにつれ、異なる脅威アクターが、組織的なつながりを持たなくても、一致するインフラや口実を展開できるようになります。

• 恐喝業務のアウトソーシング: 初期アクセスとクラウドデータ窃取を主導する侵入担当のアクターは同一の中核集団のままであり、恐喝と交渉のフェーズだけが別のアクターに外注されている可能性もあります。

この活動が分裂した脅威グループを反映しているのか、外注された恐喝交渉担当者を反映しているのか、あるいはより広範なアフィリエイトネットワークを反映しているのかにかかわらず、これらのキャンペーンで利用されている初期感染経路と目的は一貫しています。組織は、こうしたアイデンティティを標的とした攻撃を阻止するため、フィッシング耐性のある認証手段と、SaaSの行動監査を優先すべきです。

侵害指標(IOC)

本ブログ記事で取り上げた活動の追跡・特定に広くコミュニティの助けとなるよう、登録済みユーザー向けの無料GTIコレクションにて侵害指標(IOC)を提供しています。本ブログの公開時点で、特定されたフィッシングドメインはGoogle Safe Browsingに追加済みです。

このコレクションには包括的なIOCの一覧が含まれていますが、防御担当者は、特定されたIPアドレスの大半が商用VPNノードであり、実際の送信元IPはアクターが絶えず新しいインフラへと切り替えるため変動しやすい点に留意する必要があります。さらに、これらのドメインは登録から数分以内に立ち上げられ使用されることが多いため、リアルタイムのブロックのための主要な手段としてではなく、あくまで過去の命名規則や利用パターンの一例として提供するものです。