Google傘下のMandiantは、音声によるフィッシング（vishing）と偽の認証情報入力サイトを組み合わせ、SSOのID・パスワードとMFAコードをだまし取ってSaaSに侵入する攻撃活動の拡大を報告しました。目的はクラウド上の機密データや社内コミュニケーションを持ち出し、恐喝へつなげることだとされています。
The Hacker News：Mandiant Finds ShinyHunters-Style Vishing Attacks Stealing MFA to Breach SaaS Platforms
この記事のポイント
影響のあるシステム
- クラウド型のSaaSアプリケーション（機密データ・社内コミュニケーションが保管される環境）
- SSO（シングルサインオン）を利用する認証環境
- MFA（多要素認証）を利用するアカウント運用
- Oktaの顧客アカウント（少なくとも一部の事例で不正アクセスが示唆）
- SharePoint / OneDrive（PowerShellを用いたデータ取得が報告）
- メールアカウント（侵害後に追加のフィッシング送信へ悪用された事例が報告）
推奨される対策
- ヘルプデスク手続きの強化（本人確認をライブのビデオ通話で行う等）
- 強固なパスワードの徹底と、SMS・電話・メールを認証手段から外す検討
- 管理系のアクセス（管理プレーン）を制限し、露出したシークレットの監査や端末アクセス制御を徹底
- 認証操作・権限付与・SaaSのエクスポート動作に関するログを整備し可視性を高める
- MFAデバイス登録やMFAライフサイクル変更、OAuth/アプリ認可イベント、営業時間外の認証イベントを検知対象にする
- 可能な範囲でフィッシング耐性の高いMFA（FIDO2セキュリティキーやパスキー等）へ移行を検討
上記の対策は、元記事の事実に基づき日本の読者向けに整理したものです。
この記事に出てくる専門用語
- vishing（ボイスフィッシング）：電話など音声通話を使い、相手をだまして情報を聞き出す手口です。
- SSO（Single Sign-On）：一度の認証で複数のサービスへアクセスできる仕組みです。
- MFA（Multi-Factor Authentication）：パスワード以外の要素も組み合わせて認証する方式です。
- Okta：企業向けのID管理・認証基盤として利用されることがあるサービスです。
- SharePoint / OneDrive：組織内のファイル共有・保存に利用されるクラウドサービスです。
- OAuth（認可）：アプリに対してアクセス権限を付与するための仕組みです。
- フィッシング耐性の高いMFA：だまし取り（ソーシャルエンジニアリング）に強い認証方式を指します。
- FIDO2セキュリティキー / パスキー：フィッシングに強いとされる認証手段として言及されています。
なにが起きているのか：脆弱性ではなく“認証の手前”を狙う侵入
今回報告されているのは、製品の脆弱性を突く侵入ではなく、電話によるなりすましと偽サイトで「認証情報そのもの」を奪う攻撃です。Mandiantは、恐喝を目的としたShinyHuntersブランドの活動に整合する手口として、音声フィッシング（vishing）と、標的企業になりすました認証情報入力サイト（credential harvesting sites）を用い、SSOの認証情報に加えてMFAコードまで収集する動きがあると述べています。攻撃者は入手した情報を使って被害組織の環境へ不正にアクセスし、クラウド型SaaSアプリケーションから機密データや社内コミュニケーションを持ち出したうえで、恐喝へつなげることが狙いだとされています。さらに最近の事案では、被害者側の担当者に対する嫌がらせなど、恐喝のやり方が強まっている可能性も示されています。
観測された手口：偽のIT担当を装いMFA登録まで奪う流れ
Mandiantは活動を複数のクラスター（UNC6661、UNC6671、UNC6240）として追跡しており、手口の変化や模倣の可能性も踏まえて整理しています。報告によると、UNC6661は標的組織の従業員に対しIT担当者になりすまして電話をかけ、MFA設定の更新を口実に、認証情報を入力させるリンクへ誘導する様子が観測されました。この活動は2026年1月上旬から中旬にかけて記録されたとされています。盗まれた認証情報は、攻撃者自身の端末をMFAデバイスとして登録するために使われ、その後ネットワーク内を横展開してSaaSからデータを流出させたと記載されています。さらに少なくとも1件では、侵害したメールアカウントを使って暗号資産関連企業の連絡先に追加のフィッシングを送信し、そのメールを削除して痕跡を隠したと報告されています。その後、UNC6240による恐喝活動に続いたとも述べられています。
日本の組織が直ちに確認すべき点：検知と運用の“穴”を塞ぐ
元記事では、SaaSを狙う脅威に対して、ハードニング・ログ整備・検知の強化が広く推奨されています。まず、ヘルプデスクの本人確認プロセスを見直し、担当者を名乗る電話だけで手続きが進む運用を避けることが挙げられています（例として、ライブのビデオ通話による本人確認が提示されています）。また、信頼できる出口ポイントや物理的な場所にアクセスを限定し、強固なパスワードを徹底したうえで、SMS・電話・メールを認証手段から外すことが推奨事項として並んでいます。加えて、管理系アクセスの制限、露出したシークレットの監査、端末アクセス制御の強化も示されています。検知面では、認証操作や権限付与、SaaSのエクスポート動作に関するログを整備して可視性を高め、MFAデバイス登録やMFAのライフサイクル変更、OAuth/アプリ認可イベント、営業時間外の認証イベントなどを監視対象にする考え方が述べられています。さらにGoogleは、この種の活動がベンダー製品の脆弱性に起因するものではなく、ソーシャルエンジニアリングの有効性を示すとしたうえで、可能な範囲でフィッシング耐性の高いMFA（FIDO2セキュリティキーやパスキー等）へ移行する重要性を強調しています。
