Forg365はデバイスコード×AitMでMicrosoft 365セッションを奪う——PhaaS量産時代のMFAバイパスが現実化しています

今日の深掘りポイント

• デバイスコード流用は「正規のMicrosoftドメインで操作させる」ため、URL目視チェックや一般的な啓発だけでは止まりにくい構造です。ポリシーと認可面を締めることが肝心です。
• AitMによるセッションクッキー窃取はMFA実施後でも有効です。デバイス準拠やCA（条件付きアクセス）、CAE（Continuous Access Evaluation）で「クッキーの持ち出し価値」を下げる発想が有効です。
• Forg365はPhaaSとして月額/年額で販売され、正規のメール配信基盤を悪用して広域に拡散します。防御側は「認証」「メール」「OAuth/アプリ権限」の3面で一体運用が必須です。
• インシデント対応は「パスワード変更」だけでは不十分です。セッション無効化、OAuth同意の取り消し、悪性メーラールール削除までを標準手順に組み込むべきです。
• 本件は今すぐ着手して成果が出やすい領域（アプリ同意/CA/メールルール監査）に直結します。現実的かつ行動可能な対策を優先実装する局面です。

はじめに

Microsoft 365アカウントを狙う新しいフィッシング・アズ・ア・サービス（PhaaS）「Forg365」が観測されています。報道によれば、Telegram経由で提供され、月額400ドル/年額3,800ドルで購買でき、正規のメール配信インフラを経由したフィッシング配信、Microsoftのサインイン画面に酷似したページによる誘導、そしてAitM（Adversary-in-the-Middle）でのセッション奪取を組み合わせる構成です。さらに、OAuthのデバイスコード認可フローを悪用して、ユーザーに「正規ページ上」で操作させる点が、受信者の警戒心と組織の検知回避に働くのが厄介なところです。この手口はMFA迂回の実効性が高く、サプライチェーン横断でのBEC（二次不正送金）やデータ持ち出しの足がかりになりやすいと見ます。
一次報道の要点はThe Hacker Newsがまとめていますが、本稿では技術的・運用的な文脈を接続し、現場の優先順位に落とし込む深掘りを行います。

参考: Forg365 PhaaS targets Microsoft 365 via device code and AitM (The Hacker News)

深掘り詳細

まず事実関係（報道と仕様の確認）

• Forg365はTelegramで流通するPhaaSで、月額400ドル/年額3,800ドルの価格帯と報じられています。正規のメール配信基盤を経由してフィッシングリンクを送り、攻撃者管理のドメインへ誘導する運用です。AitMでMicrosoft 365のセッションを奪取し、MFA後のクッキーを再利用できる設計が示唆されています。The Hacker News
• OAuth 2.0のデバイス認可（Device Code）フローは、画面のない/操作が限定的なデバイスでの認可に用いられ、ユーザーは正規のMicrosoftドメイン上でコードを入力し、同意・認証を完了します。攻撃者が用意したアプリ登録へ被害者が「正当な操作」のつもりで同意してしまうと、攻撃者側がトークンを取得できてしまいます（仕様としては正当ですが、ソーシャルエンジニアリングに弱い）Microsoft Docs: OAuth 2.0 device code。
• AitMは被害者と正規サイトの間に挟まり、資格情報やセッションクッキーを奪う代表的な戦法です。MITRE ATT&CKでも定義されており、セッションクッキー自体の窃取・再利用は別テクニックとして整理されています（後述のマッピング参照）。

以上は、Forg365固有の「新機能」というより、実績のある技法の組み合わせをPhaaSで量産・即応化した点が本質です。

Packet Pilotの視点（なぜいま問題か、どこで止めるか）

• ユーザー教育の限界が露呈します。デバイスコード誘導はlogin.microsoftonline.comなど正規ドメインでの操作を前提にするため、「URLを確認しましょう」という啓発は回避されがちです。したがって、テナント側で「誰が・どのアプリに・どのスコープを」同意できるかを締める運用（ユーザー同意の原則禁止＋管理者承認ワークフロー必須化）が、最短距離のリスク低減になります。
• AitM＋セッションクッキー奪取はMFA後でも有効です。対抗は「そのクッキー（またはトークン）を別環境へ持ち出しても使い物にならない」状態にすることです。条件付きアクセスで「準拠デバイス必須」「ハイリスクサインインのブロック」「サインイン頻度の短縮」「場所/ネットワーク制限」を組み合わせ、CAE（Continuous Access Evaluation）でセッションの再評価トリガーを強化すると、攻撃者が別IP/別デバイスでクッキーを再利用する困難度が上がります。Microsoft Docs: CAE
• メール基盤への依存だけでは追いつきません。正規配信インフラを用いたフィッシングは、SPF/DKIM/DMARC整合性や送信評判を盾に初期検出網をくぐりやすいです。メールセキュリティの強化は必要条件ですが、同時に「同意・セッション・アプリ権限」の後段対策を前提に設計すべきタイミングです。
• インシデント対応の標準手順を刷新すべきです。MFAリセットやパスワード変更だけでは、攻撃者が取得したリフレッシュトークン、既存のOAuth同意、設定済みのメール自動転送/隠蔽ルールなどが温存されます。セッション無効化、アプリ同意の取り消し、メールルールの検査/削除までを「一括廃棄の型」として持つことが、短時間での業務復旧と再侵入阻止につながります。

なお、「AI生成ルアー」等の工夫がForg365で特定的に使われているかは一次情報では確証がありません。本稿では可能性として留保し、対策の本質（同意・セッション・端末拘束）に焦点を当てます。

脅威シナリオと影響

以下は報道に基づく一般化シナリオであり、一部は防御側設計を促す目的の仮説を含みます（仮説は明記します）。

• シナリオ1（デバイスコード同意型：持続的APIアクセス）［事実＋一般化］

  1. フィッシングリンクで攻撃者管理のランディングへ誘導（MITRE: T1566.002 Spearphishing Link）。
  2. ユーザーに正規のデバイスコード入力を促す。ユーザーはMicrosoftの正規ページで認証・同意を完了。
  3. 攻撃者のアプリ登録に対するトークン（＋offline_accessがあればリフレッシュトークン）を取得（MITRE: T1528 Steal Application Access Tokenの観点で結果は同等）。
  4. Graph API等を通じてメール/ファイルへ継続アクセス、データ持ち出し（MITRE: T1567 Exfiltration Over Web Services）。
     影響: パスワード変更やMFAリセットだけではトークン/同意が生き残るため、静かな長期侵害になりやすいです。

• シナリオ2（AitMセッション奪取：即時の業務アカウント乗っ取り）［事実＋一般化］

  1. AitMで正規ログインを中継し、MFA後のセッションクッキーを窃取（MITRE: T1557 Adversary-in-the-Middle、T1539 Steal Web Session Cookie）。
  2. 攻撃者環境でクッキーを再利用しOutlook/SharePointへ即時侵入（MITRE: T1550.004 Use Alternate Auth Material: Web Cookies）。
  3. 受信トレイ隠蔽や自動転送のためのメールルールを作成（MITRE: T1114.003 Email Forwarding Rule）。
  4. 既存スレッドの乗っ取りでBEC/請求書改ざん、サプライヤ/顧客へ水平展開。
     影響: 複数テナントを跨いだ財務不正のリスク。クッキー再利用を難しくするCA/CAE設計が効果的です。

• シナリオ3（仮説：AitM後にOAuth同意で永続化）［仮説］

  1. シナリオ2の後、被害者セッションを用いて「攻撃者管理のエンタープライズアプリ」に高権限同意を追加（管理者ロール不在でもユーザー同意範囲で侵害継続）。
  2. クッキーが失効してもリフレッシュトークン/OAuth同意が残るため継続アクセス。
     影響: 「クッキー→アプリ同意」への切替で持続化。対応はアプリ同意一覧の棚卸しと取り消しが鍵です。

総じて、Forg365系の運用は到達率・即応性・再現性が高く、短い時間軸での侵害成立と、長い時間軸での持続化の両方に適しています。メトリクス的に見ても緊急性と実行可能性が高いタイプの脅威で、まずは「いま有効な運用ガード」を差し込むのが得策です。

セキュリティ担当者のアクション

• すぐにやること（今週中）

  • アプリ同意とOAuthガバナンス
    • ユーザーの自己同意を原則禁止し、管理者承認ワークフローを必須化します。
    • 既存の「同意済みアプリ」を棚卸しし、不要/過剰スコープの同意を取り消します（特にMail.、Files.、offline_access）。
  • 条件付きアクセス（CA）とセッション管理
    • 機密度の高いクラウドアプリ（Exchange Online/SharePoint/Teams/Entraポータル）に対し「準拠デバイス必須」「場所/ネットワーク制限」「サインイン頻度の短縮」を段階的に適用します。
    • Continuous Access Evaluation (CAE)を有効化し、IP/リスク変動でセッション再評価を促進します。
  • メールセキュリティと運用
    • 受信トレイの自動転送/仕分け等の新規ルール作成を重点監査し、未知の転送先や不可視化パターンをブロック/是正します（監査ログでNew-InboxRule等を確認。参考: Microsoft Purview 監査）。
    • 新規登録ドメイン/短命ドメインからのURLを積極的に検査するポリシーをメールゲートウェイ/Defender for Office 365で強化します。
  • インシデント対応の型の更新
    • 侵害疑い時の「標準セット」を定義・訓練します：セッション失効、パスワード/リフレッシュトークン無効化、OAuth同意の取り消し、メールルール削除、二次被害（BEC/請求書）の対外連絡。

• 短期（30日以内）で固めること

  • 認証強度の底上げ
    • 管理者/高価値ユーザーにはフィッシング耐性の高い認証（FIDO2/CBA等）を適用し、「認証強度」を条件付きアクセスの必須条件に設定します。
  • デバイスコード/クライアントの取り扱い設計
    • デバイスコードフローやブラウザーレス/レガシークライアントの取り扱いを明文化し、必要最小限へ。該当クライアントには厳格なCAを適用します。
  • 検知とハンティング
    • 監査・サインインログで「短時間の新規同意→大量APIアクセス」「不審UA/ASNからのクッキー再利用」「New-InboxRuleの直後に外部転送」等の相関ルールを用意します。
  • サプライチェーン準備
    • BEC発生時に即時周知できる対外コミュニケーション手順（請求書差替えの注意喚起など）を整備します。

• 現場Tips（よくある落とし穴の回避）

  • 「パスワード変更で安心」は禁物です。セッション・トークン・同意・ルールに必ず目を配ります。
  • メール対策の強化だけに偏らず、「認可（OAuth）」「セッション（CA/CAE）」「端末（準拠）」に均等に投資します。
  • 例外（非常口アカウント）は最小に保ち、運用レビューを定期化します。

参考情報

• Forg365報道: The Hacker News: Forg365 PhaaS targets Microsoft 365
• OAuthデバイスコード仕様: Microsoft identity platform and OAuth 2.0 device authorization grant
• 管理者承認ワークフロー: Configure the admin consent workflow
• Continuous Access Evaluation: Concept - CAE
• 監査ログの検索（Purview）: Search the audit log
• MITRE ATT&CK: T1566.002 Spearphishing Link, T1557 Adversary-in-the-Middle, T1539 Steal Web Session Cookie, T1550.004 Use Alternate Authentication Material: Web Cookies, T1114.003 Email Forwarding Rule, T1567 Exfiltration Over Web Services, T1528 Steal Application Access Token

本稿は一次情報で確からしい範囲に絞って記述し、推測は明示しました。Forg365は特別な魔法ではなく、既存手口の「量産と即戦力化」に価値があるタイプです。だからこそ、防御側も「型」を整え、「いま効く運用ガード」を素早く差し込むことが勝ち筋になります。明日の攻撃メールを止めるために、今日の設定変更から始めます。