UNC6671型攻撃とは何か：Vishing×AiTMでMicrosoft 365・Oktaを侵害するクラウド恐喝攻撃の検知と対策

UNC6671型攻撃とは？Vishing×AiTMでMicrosoft 365・Oktaを侵害するクラウド恐喝攻撃の検知と対策

2026年、Google Threat Intelligence Group（GTIG）が追跡する脅威クラスタ UNC6671 による攻撃活動が注目されています。

この攻撃で特に重要なのは、未知のマルウェアやゼロデイ脆弱性ではありません。

攻撃者はITヘルプデスクを装った電話を入口として、Microsoft 365、Microsoft Entra ID、Oktaなどの正規認証基盤を悪用します。

つまり、防御側も「怪しい実行ファイルを探す」だけでは不十分です。

Identity（認証）とSaaS上で発生する、正常に見える異常行動を検知する必要があります。

表現上の注意

Googleが追跡名として使用しているのは「UNC6671」です。

「UNC6671型攻撃」は一般的な攻撃分類や正式な規格名ではありません。

本記事では、UNC6671で観測されたVishing、AiTM、Authenticator追加、SaaSデータ窃取などを組み合わせる攻撃パターンを説明する便宜上、「UNC6671型攻撃」と表記します。

この記事の要点

• UNC6671はVishingとAiTMを組み合わせて企業のクラウド認証情報を狙う金銭目的の脅威クラスタです。

• UNC6671の主要な初期侵入経路は、公開情報上では特定CVEの悪用ではなくIT担当者を装った電話と偽認証サイトです。

• SMS・TOTP・Push型MFAだけでは、リアルタイム型AiTMや誘導操作を完全には防げません。

• FIDO2・Passkey・Windows Hello for Businessなどのフィッシング耐性認証を強制することが重要です。

• Passkeyを導入するだけでなく、PasskeyやAuthenticatorを追加・変更する処理そのものを保護する必要があります。

• UNC6671対策ではEDRだけでなくEntra ID・Okta・Microsoft 365の監査ログが重要です。

• SharePoint侵害調査ではFileDownloadedだけでなくFileAccessedの大量発生も確認する必要があります。

• IOCは短期間で変更されるため、IPアドレスやドメインのブロックだけでは十分な防御になりません。

この記事で分かること

• UNC6671とは何か

• BlackFile、REDACT、PINK、HELIX、FALCONとの関係

• VishingとAiTMの仕組み

• Microsoft 365・Entra ID・Oktaが狙われる理由

• 典型的な攻撃チェーン

• MITRE ATT&CKとの対応

• 公開されているIOC

• Microsoft Sentinelで確認する方法

• Sigma・Suricataを使った補助検知

• 侵害を疑った場合の初動対応

• フィッシング耐性MFAを使った再発防止

対象読者・前提環境

本記事は、次のような読者を想定しています。

• Microsoft 365を管理している管理者

• Microsoft Entra IDを利用している組織

• Oktaを利用している組織

• SOC・CSIRT担当者

• EDR・SIEM・NDR・IPSの運用担当者

• 社内ヘルプデスク担当者

2026年8月10日時点の公開情報を基準にしています。

脅威インフラやIOCは短期間で変更されるため、実際のインシデント対応時には最新のベンダー情報も確認してください。

結論：UNC6671対策では「Identity」を最優先で守る

UNC6671対策の中心は、EDRだけでも、IOCブロックだけでも、パッチ適用だけでもありません。

Microsoft Entra ID、Okta、Microsoft 365などのIdentityとSaaSを監視・制御することが最優先です。

UNC6671とは何か

UNC6671は、Google Threat Intelligence Groupが追跡している侵入活動クラスタです。

2026年には「BlackFile」ブランドでの恐喝活動が詳しく報告されました。

その後GTIGは、BlackFile停止後も関連する攻撃活動が継続し、

• REDACT

• PINK

• HELIX

• FALCON

など複数ブランドと技術的な重なりがあると報告しています。

ただし、すべてが完全に同一の組織であると断定されているわけではありません。

GTIGは、次のような複数の可能性を残しています。

• 同一の協調グループ

• 分裂したアフィリエイト

• 共通するPhishing-as-a-Service基盤

• 恐喝担当者の外部委託

したがって、ブランド名だけを根拠に攻撃者を断定するのは適切ではありません。

国家支援型APTなのか

今回確認した公開一次情報だけから、UNC6671を国家支援型APTと断定することはできません。

CrowdStrikeはUNC6671／BlackFileを、金銭目的のeCrimeアクター「CORDIAL SPIDER」と関連付けています。

したがって本記事ではUNC6671を、金銭目的のサイバー犯罪・恐喝活動クラスタとして扱います。

今回の攻撃はCVEを悪用する攻撃なのか

ここは非常に重要です。

GTIGが公開した代表的なUNC6671の攻撃チェーンでは、特定製品のCVEを突破口として利用することが主要な初期侵入経路とは報告されていません。

OS、ブラウザ、EDR、Identity関連製品を最新状態に保つことは当然必要です。

しかし、UNC6671対策を「パッチを適用したから終了」と考えるのは危険です。

Vishingとは何か

Vishingは「Voice」と「Phishing」を組み合わせた言葉です。

簡単に言えば、電話を使って相手を信用させ、認証操作や情報入力をさせるフィッシングです。

UNC6671では、攻撃者がITヘルプデスク担当者を装い、従業員の個人携帯電話へ連絡するケースが確認されています。

さらに、正規ヘルプデスクの電話番号に見えるようCaller IDを偽装した事例もGTIGが報告しています。

AiTMとは何か

AiTMは Adversary-in-the-Middle の略です。

簡単なたとえでは、

本物の受付窓口の直前に、攻撃者が偽の受付を設置する

ような攻撃です。

ユーザーは偽サイトへID、パスワード、MFAコードなどを入力します。

攻撃者側は、その内容をリアルタイムで正規サービスへ中継します。

被害者
  │
  │ ID / Password / MFA
  ▼
攻撃者のAiTMサイト
  │
  │ リアルタイム中継
  ▼
Microsoft 365 / Okta
  │
  ▼
正規セッション成立
  │
  ▼
攻撃者がセッションや認証情報を悪用

UNC6671型攻撃の典型的な攻撃チェーン

flowchart TD
    A[従業員の個人携帯へVishing] --> B[ITヘルプデスク担当者を装う]
    B --> C[Passkey更新・MFA再登録などを要求]
    C --> D[偽SSO・Passkeyサイトへ誘導]
    D --> E[AiTMでID・Password・MFAを取得]
    E --> F[正規Microsoft 365・Oktaへ侵入]
    F --> G[攻撃者自身のAuthenticator・Passkeyを追加]
    G --> H[SharePoint・OneDrive・SaaSを探索]
    H --> I[Python・PowerShell・Graph等で大量アクセス]
    I --> J[警告・パスワード変更通知などを削除]
    J --> K[窃取データを材料として恐喝]

Mermaidに対応していない環境では、次の流れとして読んでください。

1. 従業員の個人携帯へ電話
        ↓
2. ITヘルプデスク担当者を装う
        ↓
3. 「Passkey更新」「MFA再登録」などを要求
        ↓
4. 偽SSO / Passkeyサイトへ誘導
        ↓
5. AiTMでID・Password・MFAを取得
        ↓
6. 正規Microsoft 365 / Oktaへ侵入
        ↓
7. 攻撃者自身のAuthenticator / Passkeyを追加
        ↓
8. SharePoint / OneDrive / SaaSを探索
        ↓
9. Python / PowerShell / Graph等で大量アクセス
        ↓
10. 警告・パスワード変更通知などを削除
        ↓
11. 窃取データを材料として恐喝

なぜ通常のMFAでも突破されるのか

「MFAを導入しているから安全」とは限りません。

SMS、TOTP、Push承認などは、ユーザー自身が攻撃者の指示に従って入力・承認してしまえば、リアルタイム型のソーシャルエンジニアリングに悪用される可能性があります。

UNC6671でさらに危険なのは、最初の認証突破後に攻撃者自身が管理するAuthenticatorやPasskeyを被害者アカウントへ登録する点です。

一度追加されると、パスワード変更だけではアクセスを完全に排除できない可能性があります。

Passkey自体が危険なのか

いいえ。むしろ逆です。

FIDO2／WebAuthnベースのPasskeyは、正しく使用すればフィッシング耐性の高い認証方式です。

問題はPasskeyそのものではありません。

問題になるのは、「Passkeyを新しく登録する処理」が弱い認証だけで許可されている環境です。

重要

「Passkeyを導入する」だけでは不十分です。

Passkey・AuthenticatorのEnrollment、変更、Recoveryまでフィッシング耐性のある認証で保護する必要があります。

Microsoft 365で何が狙われるのか

侵害後は、SharePointやOneDriveなどの正規クラウドサービスからデータが取得されます。

つまり、攻撃者の操作が「不正なマルウェア通信」ではなく、正規ユーザーによるMicrosoft 365利用に見える場合があります。

GTIGは、一つの組織で100万件を超えるSharePoint／OneDriveファイルへのアクセス・取得を確認したと報告しています。

FileDownloadedだけ監視すると見逃す可能性がある

Microsoft 365で大量ファイル窃取を調査する場合、FileDownloadedだけを確認してはいけません。

GTIGのフォレンジック調査では、正規セッションCookieなどを利用したファイル取得で、監査ログ上の操作がFileDownloadedではなく**FileAccessed**として記録されたケースが確認されています。

そのため、少なくとも次の組み合わせを確認します。

• FileAccessed

• FileDownloaded

• Client IP

• User-Agent

• ユーザー

• 短時間のファイル操作件数

• 端末管理状態

• MFA・Authenticator変更履歴

MITRE ATT&CKで整理する

攻撃内容によっては、Account ManipulationやMFA関連のATT&CKテクニックとして追加整理できる場合もあります。

ただし、ATT&CKへのマッピングと「UNC6671自身が公式にそのテクニックを利用したと登録されていること」は同じ意味ではありません。

公開IOC

次はGTIGが公開した情報に含まれる代表例です。

IOCは時間とともに陳腐化するため、現在のブロックリストとしてそのまま使用するのではなく、過去ログを調査するRetro Huntにも利用してください。

注意

IOC一致だけでUNC6671と断定しないでください。

VPN、住宅系Proxy、共有IPなどが含まれる可能性があります。

User-Agentにも正常な管理処理との重複があります。

IOCはIdentityログ、MFA変更、SaaSアクセスなどと相関させて判断します。

Microsoft Sentinelで確認する

目的

SharePointでスクリプト系User-Agentから短時間に大量のファイルアクセスが発生していないか確認します。

実行場所

Microsoft Sentinel / Log Analytics Workspace。

KQL例

OfficeActivity
| where OfficeWorkload == "SharePoint"
| where Operation in ("FileAccessed", "FileDownloaded")
| where UserAgent has_any ("python-requests", "WindowsPowerShell", "Go-http-client")
| summarize
    FileEvents=count(),
    IPs=make_set(ClientIP, 10)
    by UserId, UserAgent, bin(TimeGenerated, 10m)
| where FileEvents >= 100

正常例

通常のブラウザ利用しか存在せず、短時間に異常な大量アクセスが発生していません。

異常例

普段利用しないUser-Agentから、10分間に数百～数千件規模のFileAccessedが発生しています。

同時刻に新規Authenticator登録や未知IPからのログインが確認される場合は、さらに疑いが強くなります。

判断方法

100件／10分という値はGTIGの公式検知閾値ではありません。

初期チューニング例です。

バックアップ、移行処理、管理PowerShellなど正常処理でも大量アクセスは発生するため、自組織のベースラインに合わせて調整してください。

Sigmaによる検知例

title: UNC6671-like SharePoint Scripted File Access
status: experimental

logsource:
  product: m365
  service: audit

detection:
  operation:
    Operation:
      - FileAccessed
      - FileDownloaded

  scripted_ua:
    UserAgent|contains:
      - 'python-requests'
      - 'WindowsPowerShell'
      - 'Go-http-client'

  condition: operation and scripted_ua

falsepositives:
  - Authorized backup or migration automation

level: high

このルールは「UNC6671を確定するルール」ではありません。

UNC6671で観測された特徴に近いクラウドファイルアクセスを探す検知例です。

SIEM製品によってMicrosoft 365監査ログのフィールド名が異なるため、変換後のクエリを確認してから本番環境へ導入してください。

Suricataによる既知ドメイン検知例

ネットワーク上では、公開済みフィッシングドメインへのTLS接続を補助的に検知できます。

alert tls $HOME_NET any -> $EXTERNAL_NET 443 (
    msg:"UNC6671-like known passkey phishing domain";
    flow:established,to_server;
    tls.sni;
    pcre:"/(^|\.)(passkeyhelpdesk|addssopasskey|createssopasskey|passkeymfa)\.com$/i";
    sid:6671001;
    rev:1;
)

この方法は既知IOCのRetro Huntや短期的な補助防御には有効です。

一方、GTIGはUNC6671関連インフラが高速に変更されることも指摘しています。

したがって、SNIやIPブロックを主防御にはしないでください。

EDRだけでは検知できない可能性がある

UNC6671型攻撃では、従来型マルウェアが必ず端末へ配置されるわけではありません。

攻撃者は次のような正規機能を利用できます。

• 正規Microsoft 365アカウント

• 正規Oktaアカウント

• 正規Webセッション

• Microsoft Graph

• SharePoint

• OneDrive

• PowerShell

• Python HTTPクライアント

そのため、

EDRにアラートがない＝侵害されていない

とは判断できません。

侵害を疑った場合の確認手順

最初に証拠を保存します。

いきなりAuthenticatorを削除したり、ログを消したりするとフォレンジック情報を失う可能性があります。

1. Microsoft 365 Unified Audit Logを保存する

2. Entra ID Sign-in Logを保存する

3. Entra ID Audit Logを保存する

4. Okta System Logを保存する

5. EDRテレメトリを保存する

6. メール・Teams等の関連ログを保存する

7. Authenticator・Passkeyの登録変更履歴を確認する

8. FileAccessedとFileDownloadedを確認する

9. 未知IP・新規端末・住宅系Proxy等を確認する

10. セキュリティ通知メールの削除履歴を確認する

特に「警告メールの削除」を確認する

UNC6671関連活動では、侵害後にセキュリティ通知やパスワードリセット通知などを削除する行動が報告されています。

そのため、認証ログだけを見るのではなく、メール削除履歴とIdentity変更を同一タイムラインへ並べることが重要です。

侵害が確認された場合の対処方法

1. Identityを封じ込める

疑わしいアカウントを一時停止し、既存セッションを失効させます。

Microsoft Entra IDではMicrosoft Graph PowerShellを利用できます。

目的

ユーザーの既存サインインセッションを失効させ、再認証を要求します。

実行場所

管理された管理者端末のPowerShell。

実行例

Import-Module Microsoft.Graph.Users.Actions

Revoke-MgUserSignInSession -UserId "[email protected]"

実行前の注意

必要な監査ログを先に保存してください。

また、対象ユーザーを必ず二重確認してください。

正常例

コマンドが権限エラーなく完了し、対象ユーザーの既存セッションで再認証が求められます。

異常例

• 権限不足

• ユーザー指定間違い

• 一部アクセスが継続している

結果の判断

Entra Sign-in Logと実際の再認証動作を確認します。

注意

セッション失効だけで復旧完了ではありません。

攻撃者が追加したAuthenticator、Passkey、登録端末、OAuthアクセス、他SaaSセッションなどが残っていないか確認してください。

2. 不正Authenticatorを除去する

攻撃者が追加した可能性のあるAuthenticator、Passkey、登録デバイスを特定します。

削除する前に、次の情報を保存してください。

• 登録時刻

• 登録元

• Authenticator ID

• Device ID

• 関連IP

• 操作ユーザー

• Audit Log

3. 資格情報をローテーションする

パスワードだけでなく、必要に応じて次も確認します。

• API Token

• OAuth Token

• Refresh Token

• アプリケーション資格情報

• Service Principal

• Personal Access Token

• SaaS固有セッション

4. 全テナントをスコープ調査する

一人のユーザーだけで終わらせてはいけません。

次の情報をテナント全体で検索します。

• 同一IP

• 同一User-Agent

• 同時期に追加されたAuthenticator

• 新規登録端末

• 大量FileAccessed

• 大量FileDownloaded

• PowerShell系User-Agent

• Python系User-Agent

5. 接続先SaaSまで調査する

SSOアカウントが突破されている場合、Microsoft 365だけを調べても十分ではありません。

例えば次のサービスも調査対象になります。

• Salesforce

• Zendesk

• GitHub

• CRM

• クラウドストレージ

• 社内業務SaaS

同じIdentityからアクセス可能なサービスを洗い出してください。

再発防止1：フィッシング耐性MFAを強制する

Microsoft Entra IDではConditional AccessのAuthentication Strengthを使い、Phishing-resistant MFA strengthを要求できます。

代表的な方式には次があります。

• Passkey（FIDO2）

• FIDO2 Security Key

• Windows Hello for Business

Microsoftは、本番適用前にReport-onlyで影響を確認する方法も案内しています。

再発防止2：Authenticator登録・Recoveryを守る

UNC6671型攻撃への対策では、ログイン時のMFAだけ見ても不十分です。

次の操作にも強力な認証を要求してください。

• 新しいAuthenticatorの登録

• Passkey追加

• MFA変更

• アカウントRecovery

• 新しい管理デバイス登録

Oktaも、Account Management Policyなどを利用してAuthenticator EnrollmentやRecoveryへフィッシング耐性を適用する対策を推奨しています。

再発防止3：管理端末からのみ重要SaaSへ接続する

可能であればConditional Accessや端末管理を利用して、重要なクラウドサービスへのアクセスを管理端末に制限します。

例えば次の情報を組み合わせます。

• 管理端末か

• EDRが正常動作しているか

• MDMへ登録されているか

• 既知のネットワークか

• ユーザーリスクが高くないか

再発防止4：ヘルプデスクの本人確認手順を変更する

UNC6671は技術だけでは止めにくい攻撃です。

ヘルプデスク運用もセキュリティ境界の一部として設計する必要があります。

例えば次の手順が考えられます。

• 受電中にPasskeyやMFAを登録させない

• Caller IDだけで本人・社内担当者と判断しない

• 従業員側から正式な社内番号へ折り返す

• 正式なTicket IDを確認する

• MFA初期化には追加承認を要求する

• 管理者権限ユーザーのRecoveryには複数人承認を導入する

WAF・Cloudflare・IPSでどこまで防げるか

WAFやIPSは補助対策として有効ですが、UNC6671型攻撃を完全に止める主役にはなりません。

動作確認

設定変更後は「設定した」で終わらせず、実際に防御が成立しているか確認します。

確認1：フィッシング耐性MFA

テストユーザーを使用し、対象サービスへのアクセス時にPhishing-resistant MFAが要求されることを確認します。

確認2：未管理端末

Conditional Accessで管理端末を要求した場合、テスト用の未管理端末から重要サービスへアクセスできないことを確認します。

確認3：Authenticator追加

AuthenticatorやPasskeyの追加時にも、設定した強力な本人確認が要求されることを確認します。

確認4：SIEM

過去の正常な管理処理やテストアカウントを使用し、次のフィールドがSIEMへ取り込まれていることを確認します。

• FileAccessed

• FileDownloaded

• User-Agent

• IP

• User ID

• MFA変更

• Device情報

安全な検証を行ってください

本物の認証情報を偽サイトへ入力するAiTMテストや、他者のアカウントを対象としたVishing試験を無断で実施してはいけません。

本番認証情報を使わず、許可されたテストテナント・テストユーザーで検証してください。

注意点・否定的に評価すべき3つの考え方

1. 「公開IOCを全部ブロックすれば防げる」

十分ではありません。

UNC6671関連インフラはVPN、Proxy、新規ドメインなどを利用して変化します。

IOCはRetro Huntには重要ですが、主防御は行動ベース検知に置くべきです。

2. 「EDRを入れているから検知できる」

危険な考え方です。

攻撃の中心がIdentityとSaaSであれば、端末上に明確なマルウェアが存在しない可能性があります。

Entra ID、Okta、Microsoft 365監査ログをEDRとは別に確認する必要があります。

3. 「MFAが有効だから安全」

不十分です。

SMS、TOTP、Push承認などをユーザーが攻撃者の指示で操作してしまう可能性があります。

重要なのはMFAの有無ではなく、フィッシング耐性とEnrollment／Recoveryの保護まで評価することです。

よくある誤解

UNC6671＝ShinyHuntersなのか

単純に同一組織と断定しない方が安全です。

関連する攻撃エコシステムや技術的重複は報告されていますが、GTIGは複数クラスタを別々に追跡しています。

標的企業として名前が出た会社は侵害されたのか

必ずしもそうではありません。

2026年8月の報道では多数の金融・投資関連企業を狙ったフィッシングインフラが確認されています。

しかし、

「攻撃対象になった企業」と「侵害が確認された企業」は区別する必要があります。

マルウェアのSHA-256をEDRへ登録すればよいのか

今回確認したGTIGの代表的報告では、UNC6671対策の中心となる特定マルウェアSHA-256は示されていません。

ファイルハッシュよりも次を重視してください。

• Identity

• Authenticator変更

• SaaSアクセス

• User-Agent

• IP

• Device

• セッション

• ファイルアクセス量

まとめ

UNC6671型攻撃で最も重要なのは、

「マルウェアを探す」という発想から、「正規Identityと正規SaaSの悪用を探す」という発想へ切り替えること

です。

典型的な攻撃では、

1. 電話によるVishing

2. 偽Passkey／SSOサイト

3. AiTM

4. MFA・Authenticator追加

5. Microsoft 365やOktaへの正規ログイン

6. 大量のクラウドデータアクセス

7. 通知削除

8. 恐喝

へ進みます。

そのため防御側は、

• FIDO2／Passkeyなどのフィッシング耐性認証

• Authenticator登録・Recoveryの保護

• Conditional Access

• 管理端末制御

• Entra ID監査

• Okta System Log

• Microsoft 365監査ログ

• SIEM／XDRによる相関分析

を組み合わせる必要があります。

WAF、IPS、NDR、EDR、IOCブロックも有効です。

ただし、それぞれを単独で使用するのではなく、Identityを中心とした多層防御として組み合わせることが重要です。

FAQ

Q. UNC6671はランサムウェアグループですか？

典型的なランサムウェアのようにファイル暗号化を必須とする攻撃ではありません。

公開情報では、クラウドからデータを窃取し、公開を材料に恐喝する活動が中心として報告されています。

Q. UNC6671は国家支援型APTですか？

今回確認した公開一次情報だけでは、国家支援型APTと断定できません。

CrowdStrikeは金銭目的のeCrimeアクターとして整理しています。

Q. Passkeyを停止した方が安全ですか？

いいえ。

正しく実装されたFIDO2／Passkeyはフィッシング耐性を高める重要な防御策です。

守るべきなのはPasskeyそのものだけでなく、Passkeyの新規登録、変更、Recovery処理です。

Q. Cloudflare WAFだけで防げますか？

防げません。

CloudflareなどのWAFは自社Webアプリケーションへの攻撃防御には有効ですが、従業員がMicrosoft 365やOktaの認証を奪われるIdentity攻撃を直接防ぐ製品ではありません。

Q. EDRで何も検知されていなければ安全ですか？

安全とは判断できません。

UNC6671型攻撃では正規クラウドアカウントと正規APIが利用されるため、クラウド監査ログを別途調査する必要があります。

参考情報

Google Threat Intelligence Group

• UNC6671 Rebrands: Multi-Brand Vishing Extortion Targets Financial Services and Enterprise Cloud Environments

• Welcome to BlackFile: Inside a Vishing Extortion Operation

CrowdStrike

• CORDIAL SPIDER Adversary Profile

Okta Threat Intelligence

• How to stop attackers from self-serving their way into accounts

• Vishing actors target Entra passkey enrollment

Microsoft

• Require phishing-resistant multifactor authentication

• Conditional Access Authentication Strengths

• Revoke user access in an emergency in Microsoft Entra ID

• OfficeActivity - Azure Monitor Logs reference

• Microsoft Entra authentication overview

MITRE ATT&CK

• T1078 - Valid Accounts

• T1078.004 - Cloud Accounts

• T1098.005 - Device Registration

• T1530 - Data from Cloud Storage

Sigma

• Sigma Rules Specification

• Sigma Correlations

Suricata

• Suricata SSL/TLS Keywords