Microsoft Azure・Google Firebase悪用の新型フィッシングが企業を狙う 「正規ドメインだから安全」を崩す最新手口と防御策
企業向けフィッシングは「怪しい新規ドメインをブロックすれば防げる」という前提が崩れつつあります。攻撃者はMicrosoft AzureのBlob Storage、Google Firebase、AWS CloudFront、さらにCloudflare CDNなど“信頼されやすい”クラウド基盤に不正ページや中継基盤を置き、検知と遮断を難しくする方向へ進化しています。citeturn0search0turn0search1turn0search6
いま起きている変化：不正サイトが「正規クラウド上」に乗る
従来のフィッシングは、作られたばかりの紛らわしいドメイン（例：m1crosoft-login…）を使うため、ドメイン年齢・レピュテーション・DNSの不自然さが手掛かりになりました。ところが最近は、blob.core.windows.net（Azure）、firebasestorage.googleapis.com（Firebase）、cloudfront.net（CloudFront）といった正規サービスの配下に不正コンテンツを置く例が増えています。結果として「ドメインが有名＝安全」という指標が当てにならず、メールゲートウェイやURLフィルタをすり抜けやすくなります。citeturn0search0turn0search1turn0search14
AiTM（中間者）型が主流化：MFAすら突破される理由
特に厄介なのが、Adversary-in-the-Middle（AiTM）と呼ばれる“中継（プロキシ）”型フィッシングです。偽ログイン画面を見せるだけでなく、被害者と本物の認証サービスの間に攻撃者が入り、入力されたID/パスワードに加え、セッショントークン（クッキー等）をリアルタイムで奪います。これにより、多要素認証（MFA）を通過した“有効なセッション”を横取りされ、ワンタイムコードを入れていても乗っ取りが成立します。citeturn0search5turn0search13
代表的な企業標的キット：Tycoon2FA／Sneaky2FA／EvilProxy
最近の企業標的で言及が多いのが、以下の3系統です。いずれも正規クラウドやCDNを悪用し、検知回避を組み込みやすい点が共通します。citeturn0search0turn0search8turn0search9
-
Tycoon2FA：MFA突破を目的に設計された“サービス化”されたフィッシング基盤（Phishing-as-a-Service）。大量展開とテンプレ化が進みやすい。citeturn0search0turn0search5
-
Sneaky2FA：企業アカウントに絞るため、無料メール（例：Gmail/Yahoo等）を除外するなどターゲット選別を行うとされます。citeturn0search0turn0search9
-
EvilProxy：逆プロキシ技術で幹部層のアカウント乗っ取りを狙う文脈で語られることが多いタイプ。citeturn0search0turn0search8
なぜCloudflare＋クラウドが効くのか：遮断・追跡を鈍らせる設計
CDNや大手クラウドは、攻撃者にとって「防御側の運用を逆手に取りやすい」環境です。
-
正規の証明書・HTTPS：通信が自然に見え、ブロックの心理的ハードルも上がる
-
CDNの裏側が見えない：Cloudflare等のリバースプロキシにより、オリジンサーバが隠れ、IP遮断が効きにくい
-
多段リダイレクト／CAPTCHA：リンク解析や自動巡回を弾き、調査を遅らせる（「人間だけ通す」）
これらが合わさると、SOCが見ているのは“正規ネットワーク上のそれっぽいHTTPS通信”になりがちで、一次遮断が難しくなります。citeturn0search0turn0search12turn0search8
企業への実害：奪われるのは「パスワード」より「セッション」
AiTMの怖さは、漏れる情報の質です。パスワード変更だけでは被害が止まらず、既に盗まれたセッショントークンでログインされる可能性があります。結果として、Microsoft 365やGoogle Workspace、SaaS、VPN、社内ポータルなどへ横展開され、メール転送ルール悪用、請求書詐欺、権限昇格、内部不正の偽装に発展し得ます。citeturn0search6turn0search5
今日からできる対策：ポイントは「耐フィッシングMFA」と「セッション防御」
ツール導入以前に、効果が出やすい順で要点をまとめます。
-
耐フィッシングMFAへ移行
SMS/OTP中心から、FIDO2セキュリティキーやパスキー等の耐フィッシング方式を優先（“中継されても成立しにくい”） -
条件付きアクセスの強化（Microsoft/Google双方で発想は同じ）
端末準拠（管理端末のみ許可）、地理・ASN・リスクベース、レガシー認証遮断、特権アカウントの追加制約 -
セッション異常の検知運用
不可能移動、短時間での国/ネットワーク変化、MFA直後の別IP利用、普段と異なるユーザーエージェント、異常なトークン利用を重点監視 -
URLの“ドメイン許可”思考を捨てる
「azurewebsites/firebase/CloudFront/Cloudflareだから安全」を前提にせず、パス・クエリ・リダイレクト連鎖・最終到達先で判定する設計へ -
教育は“クリックするな”より“兆候を言語化”
「急なMFA要求」「再ログイン強要」「CAPTCHAの後に認証」「社外ファイル共有を装う」など、今回型の共通サインを社内で統一する
まとめ：正規クラウド悪用は“主流の手口”として備える
クラウド活用が当たり前になった今、攻撃者も同じ土俵で「信頼の借用」を行います。防御側に必要なのは、怪しいドメイン探しから一段進めて、認証・セッション・端末・挙動で止める設計へ移行することです。特にAiTM型は、MFAを導入していても突破され得るため、「耐フィッシングMFA」と「条件付きアクセス＋ログ監視」をセットで整えることが、最短距離の現実解になります。citeturn0search5turn0search13turn0search6
