Entra IDとGoogle WorkspaceにおけるTycoon 2FA AiTM攻撃の検出

Tycoon 2FAは現在、AiTMのフィッシングキットの中で最も普及しているフィッシング・アズ・ア・サービス（PhaaS）プラットフォームです。 2023 年8月に初めて確認され、 Storm-1747に起因するとされた（Microsoft Threat Intelligenceによる）。このキットは、多要素認証を回避し、Microsoft 365 およびGoogle Workspaceアカウントから認証済みセッショントークンを盗むターンキー型の中間者攻撃（AiTM）機能を提供する。Tycoon 2FAは、最盛期にはマイクロソフトがブロックしたフィッシング攻撃の約62%を占め、毎月50万以上の組織にリーチしていた。

マイクロソフトとユーロポールが主導し、Cloudflare、SpyCloud、eSentire、その他のパートナーの支援を受けて3月に 2026 の協調的な摘発が行われ、 300 件以上のドメインが押収されたにもかかわらず、オペレーターは数週間以内に適応した。2026年4月下旬までに、 eSentireはTycoonの手口とOAuthデバイスコードフィッシングの手法を組み合わせたキャンペーンを記録しており、このキットはANY.RUNのマルウェアトレンドトラッカーで依然として1位となっている。

Tycoon 2FAの仕組み

AiTMメカニズム

Tycoon 2FAは、被害者と正規のIDプロバイダー（Entra IDまたはGoogle）との間のリバースプロキシとして機能します。これは静的な認証情報収集ツールではありません。これは、実際のログインフローをリアルタイムでプロキシします。

1. 被害者は、PDF、SVG、HTML、またはPPTX形式の添付ファイルに埋め込まれたリンクまたはQRコードを含むフィッシングメールを受け取ります。
2. このリンクは、多層リダイレクトチェーンを経由してルーティングされます。このキットは、ログインページを表示する前に、ブラウザのフィンガープリンティング、CAPTCHA認証、および解析対策チェックを実行します。
3. 被害者は、MicrosoftやGoogleのログインページとピクセル単位で完全に一致する複製を目にする。多くの場合、標的組織のブランドロゴは実際のサービスから動的に取得され、表示される。
4. 認証情報は、正規のIDプロバイダーにリアルタイムで送信されます。実際のMFAチャレンジがトリガーされ、被害者側にプロキシ経由で戻されます。
5. 被害者はMFAを正常に完了する。IDプロバイダーはセッショントークンを発行する。プロキシは、このトークンが被害者のブラウザに到達する前に傍受します。
6. 攻撃者は現在、完全に認証されたアクセストークンを保有している。

セッションクッキーは、事業者が収益化する価値です。いったんMFAが取得されると、MFAは無意味になる。なぜなら、オペレーターはMFA取得後に発行したトークンを再利用できるからだ。

現在の回転における2つの構造異性体

我々が分析した2種類のキットが実際に使用されていた。

WebSocket AiTM（「古典的な」タイクーン2FAフロー）：被害者はキットでホストされているプロキシを介して認証を行い、WebSocket（Socket.IO）経由でMicrosoftまたはGoogleにトラフィックを転送し、MFA後のセッションクッキーを取得します。このキットのJavaScriptクライアントコントローラは、C2サーバーとの間でリアルタイムの双方向チャネルを維持し、被害者が入力するたびに認証情報と認証応答を中継します。これらの応答には、使用可能なアクセストークンとリフレッシュトークンが含まれます。

デバイスコード付与の悪用（Microsoftのみ）：キットリレーは、Microsoft Authentication Broker（ 29d9ed98-a469-4536-ade2-f981bc1d605e ）をクライアントとして、Microsoftのoauth2/devicecodeエンドポイントからデバイスコードを取得し、「検証コード」という誘い文句で被害者に表示し、被害者が正規のmicrosoft.com/deviceloginにサインインした後、そのコードをアクセストークン/リフレッシュトークンと交換します。終点。

回避技術

このキットは、JavaScriptの逆コンパイルによって確認されたように、多層的な解析対策メカニズムを採用している。

• IPベースの研究者フィルタリング：コンテンツが表示される前に、キットはapi.ipapi.is （または同等のサービス）を呼び出し、訪問者のIPをクラウド/ホスティングプロバイダーのブロックリスト（Leaseweb、M247、DigitalOcean、Linode、Amazon、OVH、Hetzner、Google、Microsoft、Cloudflare、Akamai、Fastly。静的スキャンを回避するために逆順の文字列として保存されています）と照合します。クラウドインフラストラクチャ上の訪問者は、無害な偽サイトにリダイレクトされます。
• ボット/ツールの検出: ユーザーエージェント文字列にnavigator.webdriver (Selenium)、 window.callPhantom / window._phantom (PhantomJS)、および "Burp" が含まれているかどうかを確認します。検出により、about:blankにリダイレクトされます。
• 開発者ツールのブロック：開発者ツールのキーボードショートカット（F12、Ctrl+Shift+I/J/C、Ctrl+U、macOSの同等のキー）を傍受し、右クリックのコンテキストメニューを無効にします。
• デバッガートラップ：100ミリ秒ごとに実行されるsetIntervalループがデバッガーステートメントを挿入し、実行時間を計測します。DevToolsが開いている場合（実行が100ms以上一時停止する場合）、被害者は偽サイトにリダイレクトされます。
• DOM消失：悪意のあるJavaScriptは実行後にDOMから自身を削除し、静的検査のための痕跡を一切残しません。
• 被害者ごとの暗号化：ペイロードは、セッションごとの値でシードされたカスタムの2段階暗号（シーザーシフト＋PRNGで生成されたキーストリームとのXOR）を使用します。シード、キー、および暗号化されたデータ塊は、被害者ごとにサーバー側で生成されるため、静的署名による検出は不可能です。
• プラットフォームのターゲティング：Linuxデスクトップでは、ページを空白にするために空の文字列を書き込みます。これはおそらく、Linuxユーザーはセキュリティ研究者である可能性が高いという想定に基づいていると考えられます。
• 偽CAPTCHA：現在のバージョンでは、Cloudflare Turnstileの代わりにカスタム画像グリッドCAPTCHAが使用されています。Unsplashから提供された画像を3×3のグリッドに配置することで、フィッシングページが読み込まれる前に人間による確認が可能になります。

Googleをターゲットとしたキャンペーンでは、最初のホップとなる誘引サイトは、GoogleストレージやGoogleサイトといった正規のGoogleインフラストラクチャ上に設定されることが多いが、オペレーターが管理するドメインや侵害されたドメインも確認されている。Google独自のホスティングを使用する場合、 storage.googleapis.comまたはsites.google.comオリジンは、被害者がAiTMリレーに到達する前に、組み込みの評判保護を提供します。

他のケースでは、被害者のメールアドレスが自動入力され、「次へ」ボタンが自動クリックされます。被害者は直接パスワード入力ページに移動し、すでに部分的に認証されているように見えます（信頼度が高まります）。

var emailcheck = "victim@email.corp";
// ...
function tryfindingele(email) {
   emailinputcheck.value = email;
   emailsectionelecheck.querySelector(".btn-blue-next-btn").click();
}
if (emailcheck !== "0") { tryfindingele(emailcheck); }

マイクロソフト 365 / エントリーID

2層構造の運用アーキテクチャ

Tycoon 2FAの現在の運用モデルは、それぞれ独自のASN、役割、および動作特性を持つ2つの異なるインフラストラクチャ層に分かれています。単一のパターンを探している防御側は、一方の層は捉えても、もう一方の層を見逃してしまうだろう。

ティア 1 - キットリレー

トークンの取得と更新を処理する自動化されたバックエンド。特徴：

• クラウドVPSの送信元IPアドレスは、ホスティングプロバイダー（Alibaba Cloud、同様の安価なVPS AS）から提供され、単一のエンゲージメント中に異なる/16ブロック内の複数のIPアドレスをローテーションします。
• Node.js HTTP クライアントのユーザー エージェント: node (bare、デフォルトの Node.js UA)、axios/1.15.2、node-fetch/1.0、undici。
• クライアントアプリ: Microsoft Authentication Broker (29d9ed98-a469-4536-ade2-f981bc1d605e)。後にデバイス登録サービス (DRS)で使用され、プライマリリフレッシュトークン (PRT) を生成します。
• トークンタイプの進行: incomingTokenType: none (最初の被害者認証) > refreshToken (キットリレー更新ループ、ローテーションするIPアドレスで繰り返される) > 不正デバイス登録 > primaryRefreshToken (PRTリプレイ、より広い範囲)。
• 非対話型サインイン：最初の対話型デバイスコード完了後、以降のトークン操作はサーバー間更新となります。

ティア 2 - オペレーターコンソール

侵害後の偵察活動を行う人間（または人間を模倣したツール）。特徴：

• 住宅向けISPまたはプロキシの出口であり、通常は一般的なホスティングプロバイダーの脅威フィードには含まれていない小規模なAS番号である。単一の/24内に複数のIPアドレスが割り当てられ、すべてが連携して動作する。
• クラスタ内のすべてのIPアドレスで、単一のブラウザユーザーエージェント（例：Windows上のFirefox）が固定されている。設定済みのツールであり、独立したユーザーではない。
• Microsoft Web アプリへのブラウザベースの対話型サインイン: マイ プロファイル、マイ サインイン、Microsoft 承認管理、Outlook Web、OfficeHome。
• 単一のc_sid（Graphアクティビティログ内のクライアントセッションID）がすべてのIPアドレスで共有されており、プール全体に分散された単一のセッションであることが確認できます。
• 運用ペース：通常、キットリレーによる最初のトークン発行成功後10～20分で出現する。その隙間は、キットをオペレーターに引き渡すための時間間隔を表しています。

耐久性のあるクロスティア検出シグナル：2つの異なるAS番号（1つはクラウドVPS、もう1つは住宅環境型）が、数分以内に同じユーザープリンシパルとして認証される。単一ASNルールは1つの階層を対象とし、階層間ピボットは高い信頼性を示す指標となる。

妥協後のグラフAPI列挙

オペレーターコンソールが有効なトークンを取得すると、Microsoft Graph API呼び出しが急速に発生し、通常は30～60秒以内に数十件のリクエストが、価値の高い偵察エンドポイントに送信されます。

侵害後の自動偵察における主要なテレメトリ指標：

• 通話量と速度：30～60秒の間に20～30回以上の通話が発生し、それぞれが異なるエンドポイントに接続されます。
• HTTP メソッドの組み合わせ: ほとんどのエンドポイントには GET、 getResourceTenantsなどのアクションには POST を使用します。
• 構造化クエリパラメータ: $select 、 $top=999 、 $count=true - 1回の呼び出しで最大のデータ抽出を行うように最適化されています。
• /beta/ APIの使用状況：通常のポータルナビゲーションと比較して、攻撃ツールによって不均衡に使用されています。
• 成功/失敗が混在: 一部のエンドポイントは 400 または 403 を返します (キットは関係なくすべてをプローブします) が、ほとんどは 200 を返します。偵察の試みが失敗したとしても、それは依然として偵察である。
• C_DeviceIdが空です：トークンは管理対象外、未登録のデバイスに発行されました。
• 広範な事前同意スコープを持つファーストパーティアプリ: My Profile のトークンには、 RoleManagement.ReadWrite.Directory 、 MailboxSettings.ReadWrite 、 UserAuthenticationMethod.ReadWrite 、 User.RevokeSessions.Allなどのスコープが含まれます。これらはすべて事前同意済みであり、OAuth の同意プロンプトは不要です。

デバイスPRTの持続性

前述のとおり、このキットは、標準的なセッション取り消し手順にも耐えうるデバイス登録の永続性を確立できます。そのメカニズム：

1. MAB リフレッシュ トークンは、 oauth2/tokenでリソース スワップされ、 audがurn:ms-drs:enterpriseregistration.windows.netのアクセス トークンに置き換えられます (クライアント ID は同じですが、オーディエンスが変わり、同意プロンプトは表示されません)。
2. このキットは、urn:ms-drs:enterpriseregistration.windows.netアクセストークンを使用して、ローカルで生成された PKCS#10 CSR、合成デバイスメタデータ、およびトランスポートキーブロブとともにエンドポイントEnrollmentServer/deviceに POST リクエストを送信します。DRSはデバイスオブジェクトを作成し、デバイスIDを割り当て、デバイス証明書に署名して返します。
3. このキットは、ユーザーのリフレッシュトークンを含むJWTを作成し、デバイスの秘密鍵を使用してRS256で署名し、デバイス証明書をJWTヘッダーに埋め込みます。これはlogin.microsoftonline.com/common/oauth2/tokenに POST されます。JWT無記名証券として。Entraは証明書に対して署名を検証し、PRTと暗号化されたセッションキー（JWE）を返します。
4. 防御側がrevokeSignInSessionsを発動した場合（これにより、すべてのユーザーレベルのトークンとリフレッシュトークンが無効になります）、デバイスは Entra ID において別のプリンシパルであるため、デバイスの PRT は有効なままです。
5. 新しいリレーIPから、キットはPRTとセッションキーを使用して、 /oauth2/tokenへのリクエストごとのHMAC-SHA256アサーションに署名し、指定されたすべてのファーストパーティclient_id （Teams、Outlook、OneDrive、Office、Intune）のアクセストークンを仲介します。

セッションの取り消しがTycoon 2FAを阻止しないのはなぜですか？

これはつまり、「セッションの取り消し > パスワードのリセット」という標準的なインシデント対応手順では不十分であることを意味する。防御側は、デバイスとPRT間の連鎖をアトミックに断ち切るために、セッションを取り消す前に登録済みのデバイスを列挙して削除する必要があります。

検出のニュアンス - マイクロソフト

身元保護機能は、キットのインフラストラクチャを検出しない可能性があります。Tycoon 2FAの現在の送信元IPアドレスは頻繁に変更されており、Microsoftのリスクコーパスには含まれていない可能性があります。Entra IDのリスクシグナルのみに頼ってAiTMを検出しようとする防御側は、何も得られないだろう。

Graph Activity Logs の c_sid は、ユーザーオブジェクト ID ではありません。これはセッション／セキュリティコンテキストの識別子です。Graphアクティビティログをc_sid == user_object_idでフィルタリングするアナリストは、空の結果を受け取り、攻撃者がGraphトークンを使用しなかったと結論付けます。正しい探索の出発点は、送信元IPアドレスとアプリIDの組み合わせであり、サインインログと照合してIPアドレスをユーザーにマッピングします。

クラウドプロバイダーのIPアドレスの場合、位置情報は信頼性が低い。同じキットリレーIPアドレスでも、同じサインインセッション内で異なる都市に位置情報が紐づけられる可能性がある。ASNは、検出ルールにとって唯一信頼できる情報強化手段である。

トークン発行の可視性。トークンの発行や生成はログに記録されません。これらのトークンを利用した認証イベントは、より迅速な検出を可能にするシグナルとなります。

Entra ID保護におけるリスクの高いユーザー状態。Entra ID保護機能は、サインインイベント、セッション、トークンなどを分析し、ユーザーにリスクレベルとステータスを適用します。aiConfirmedSafeはティア 2 リレー中に観測され、ユーザーにリスクがないと判断されました。その後、異常トークンに基づいてユーザーリスクの異常が特定され、ユーザーは中リスクに戻されました。aiConfirmedSafeが、Microsoftのラベル付けによる偽陰性を見落としてしまう可能性のあるイベントを単純に除外するだけではいけません。

Google Workspace

単層キットリレー

Google版は、Microsoft版に見られるような明確なオペレーターコンソール層を持たず、単一層のキットリレーとして動作する。複数のキットリレーIP（通常はClouvider、Host Telecomなどの安価なホスティングASNのもの）が、それぞれ同じ4つのイベントシーケンスを実行し、数分以内に同じユーザーを認証します。

1. login_success パスワードが検証されました (T+0.000秒)
2. login_verification is_second_factor: trueの場合 - キットはTOTP/SMS/プッシュコードをリアルタイムで中継し、2SV（T+0.000秒）を完了します。
3. トークン: Google Chrome OAuthクライアントの認証 (77185425430) (T+0.4〜0.6秒)
4. DEVICE_REGISTER_UNREGISTER_EVENT （プロファイル認証により、新しいデバイスがGoogleに登録されました）（T+0.6～1.2秒）

その約1秒の圧縮は、自動ログインの兆候です。

このキットは、すべてのリレーセッションにおいて、常に同じOAuthクライアントを認証します。

OAuthLoginスコープは、Chromeの内部ブートストラップサインインスコープです。これはデータプレーンのスコープではありません（これ単体ではGmail、Drive、またはCalendarへのアクセス権は付与されません）。このキットの単一のスコープからの爆発範囲は、Chrome Sync セッションになることができる、長期間有効なサインインに限定されており、追加のトークン交換呼び出しなしにメールボックスやファイルに直接アクセスすることはできません。

VPS ASNからのtoken.authorizeイベントが確認できるのは、認証がリレー中にサーバー側で行われ、被害者のデバイスから行われていないということであり、オペレーターの意図に関係なく疑わしいということになる。

Kit JavaScriptアーキテクチャ（Google版）

GoogleをターゲットとしたWebSocketの派生版を逆コンパイルすると、5層アーキテクチャであることが明らかになった。

15 入力フィールドは、パスワード、TOTP、SMS、音声通話、バックアップコード、復旧メール、電話認証、セキュリティキーのフォールバック、モバイルプロンプト、強制パスワード変更など、すべての Google 2FA 方式を捕捉します。Socket.IO イベント名「recieveid」（スペルミスに注意）は、一貫したキットのフィンガープリントです。

検出のニュアンス - Google

Googleアラートセンターは沈黙したままになる可能性がある。たとえ数分以内に複数のASNから同じユーザーに複数回のサインインがあったとしても、アラートセンターのレコードがアラートAPIに送信されない場合があります。Googleの被害者メールボックス向けセキュリティ警告メールは、管理者画面ではなく、侵害されたユーザーの受信トレイに送信されるため、代替手段にはなりません。

is_suspicious は発火しない可能性があります。安価なホスティングAS番号からのキットリレーIPは、Googleのリスクコーパスに含まれていない可能性があります。このフィールドを主要な情報源として頼る守備側は、死角が生じるだろう。カナリアテストでは、ClouviderとHost Telecomの両方の4つのキットIPすべてにおいて、 login_successのすべてでis_suspiciousがfalseでした。

ログインイベントにユーザーエージェントは含まれません： Reports APIのログインイベントには、ユーザーエージェントやデバイスフィンガープリントデータは含まれません。Entra側（node / axios / undici）で機能するUAベースの検出機能には、Googleには直接対応する機能はありません。

OAuthワークフローの可視性は浅い： Googleのtoken.authorizeイベントはclient.idを顕在化します、アプリ名、クライアントタイプ、およびスコープ値、以上が全セットです。スコープとは異なるresource_id 、grant-typeフィールド、incoming-token-typeフィールドは存在しません。

ほとんどの補助ストリームは静止状態です: google_workspace.context_aware_accessは使用されていません（ユーザーに関する 5 つの新しいデバイスレコードがあったにもかかわらず）イベントが発生しましたが、アラートセンターのレコードはアラート API に到達しませんでした。キットのフットプリントは、ログイン、トークン、デバイスの3つのストリームのみに存在します。他の水流に依存する狩猟では、このキットは検出されません。

Entra IDとGoogle WorkspaceにおけるTycoon 2FA

M365バージョンは運用負荷が高く、ログには個人情報漏洩の前後の詳細な情報が記録される。Google Workspace版は軽量で（サインインのみが観測された）、デフォルトのログ記録には重要なコンテキストが欠けている。

タイクーン2FA行動検出ルール

当社は、MicrosoftとGoogleのテレメトリソース全体にわたる検出ルールを配信し、初期のAiTMフィッシング、トークンリレー、オペレーターコンソール偵察、デバイスの永続性といった攻撃チェーン全体を網羅しました。

マイクロソフト - キットリレー検出

Entra ID の可能性 AiTM サインイン (OfficeHome 経由、Tycoon2FA) - これは、Node.js スタイルのユーザー エージェント ( node 、 axios 、 undici ) を使用した Graph/Exchange への Auth Broker または OfficeHome サインイン時にトリガーされる高シグナル検出です。キットリレー層のサーバー側トークン操作を捕捉します。

M365 潜在的な AiTM ユーザーが Office アプリ経由でログイン (Tycoon2FA) - Entra サインイン ルールと同じ検出ロジックですが、Entra サインイン ログの代わりに (またはそれに加えて) o365.auditを取り込むテナントの M365 統合監査ログを対象とします。

Entra ID OAuth デバイスコードフィッシング（AiTM経由） ：認証ブローカーを介してExchange、Graph、またはSharePointをターゲットとした、インタラクティブなデバイスコードフローによるサインインの成功を検出します。デバイスコード付与の悪用を具体的に検出します。

Entra ID Microsoft 認証ブローカーによる通常とは異なるリソースへのサインイン: 対象リソースが一般的に観測されるファーストパーティ セットの範囲外である場合でも、認証ブローカーによるサインインが成功したことを検出します。FOCIトークンが予期しないAPIやエンタープライズアプリケーションに交換されるのを検出します。

マイクロソフト - 永続性検出

Entra ID による異常なユーザー エージェントを使用したデバイスの登録 (Azure AD Join) : ユーザー エージェントが既知のネイティブ登録クライアント( Dsreg 、 DeviceRegistrationClient 、 Dalvik )の 1 つではない場合の、デバイス登録の成功イベントを検出します。axiosユーザーエージェントから発生する、キットのデバイスPRT永続化プレイも捕捉します。

妥協後のグラフAPI列挙（ES|QL）

オペレーターコンソール層の侵害後偵察のために、各Microsoft Graph APIリクエストを5つの偵察カテゴリのいずれかに分類し、集約ウィンドウ（60秒以内）内で 4 以上の異なるカテゴリに該当する場合にトリガーされるES|QLルールを作成しました。

Microsoft Graphのマルチカテゴリ偵察バーストは、侵害後の組織的な列挙を検知すると同時に、自然なポータル利用を除外します。通常のユーザーアクティビティでは、これらのカテゴリのうち 1 つまたは 2 つに該当する可能性がありますが、短い時間 (33 秒) 内に単一のセッションで 4 以上の異なる偵察カテゴリに該当する場合は、自動化ツールによる活動の痕跡です。

Google - Kitリレーと永続性検出

Google Workspace の不可能な移動ログイン- 地理空間関数を使用して 500 st_distance() 800 ている場所からのサインイン成功を検出する ES|QL ルール。異なる地理的位置にある複数のIPアドレスが数分以内に同じユーザーを認証する、マルチASNキットリレーパターンを検出します。

Google Workspace のユーザーログイン（非定型 ASN から） - 14 日間の履歴ウィンドウ内で、指定されたソース ASN から Google Workspace ユーザーが初めて正常にサインインしたことを検出する新しい用語ルール。

Google Workspace デバイス登録は、疑わしい ASN からの OAuth 後に行われます。EQL シーケンスルールは、安価なホスティング ASN からの Chrome クライアント ( 77185425430.apps.googleusercontent.com ) の OAuth 認証を検出し、 30 秒以内にアカウント状態REGISTEREDでのデバイス登録が行われます。

単一ユーザーに対する Google Workspace デバイス登録バースト- 1 分以内に 3 つ以上の異なる
google_workspace.device.id値が発信される、同一ユーザーの Google Workspace デバイス登録イベントのバーストを検出します。

Elastic Workflowsによる封じ込めの自動化

検出コンテンツが配置されたら、次に問題となるのは、アラート発報から対応までの時間です。先に説明した Tycoon 2FA M365 キットからオペレーターへのハンドオフのウィンドウは 10〜20 分で、これはキットリレーによる最初のトークン発行が成功してから、オペレーター層のセッションが侵害後のグラフ偵察を開始するまでの時間です。

手動によるSOC（特殊作戦センター）の対応は通常、その時間枠よりも長くかかるため、オペレーターは封じ込め作戦開始前に偵察作業を行う必要がある。そのギャップを埋めることが、検出を実用的なものにする鍵となる。

Elastic Workflows （スタックに同梱、バージョン9.4以降）を使用すると、検出ルールに基づいて、アラートが発生するたびにYAMLで定義された一連のステップを含むカスタムワークフローを呼び出すことができます。

概念実証（PoC）として、必要な応答アクションを反映する、Entra ID Potential AiTM Sign-In via OfficeHome（Tycoon2FA）検出ルールに接続されたカスタムワークフローを構築しました。

すべてのアラートで、ワークフローは次のようになります。

1. client_credentialsを介してグラフベアラーを取得します（実行ごとに 1 回）。
2. 侵害されたUPNをaccountEnabled: falseでパッチして、新しい認証を停止します。
3. ユーザーに登録されているデバイスと所有しているデバイスを列挙します。
4. 各デバイスプリンシパルを削除します。これが、デバイスに紐づくPRTを実際に無効にするものです。
5. ユーザーレベルのリフレッシュトークンとセッションクッキーを無効にするために、 revokeSignInSessions に POST リクエストを送信します。
6. 事後インシデント対応監査（パスワードリセット、認証方法レビュー、OAuthグラント監査）のためのアラートコンテキストが設定されたKibanaケースを開きます。

このチェーンは、Microsoft Graph に対してエンドツーエンドで 10 秒未満で実行され、Tycoon 2FA のハンドオフ時間である 10〜20 分以内に収まります。オペレーター層のセッションは、偵察を開始する機会すら得られない。

このパターンは、この一つのルールを超えて拡張される。同じワークフロー構造は、即時の封じ込めが有効なあらゆるクラウドID検出に適用できます。例えば、AiTMサインイン、不可能な移動、不正なOAuth同意付与、ロール昇格、MFA疲労、異常なデバイス登録などです。関連するクラウドAPIを呼び出すワークフローにルールを接続すれば、SOCは秒単位の封じ込めを実現できます。

Tycoon 2FA AiTM攻撃に対する防御

• フィッシング対策に優れた多要素認証（MFA）を導入しましょう。FIDO2セキュリティキーとパスキーは、AiTMセッションの盗難に対して耐性のある唯一の方法です。TOTP、SMS、プッシュ通知型MFAはすべてプロキシ経由で利用できます。
• 条件付きアクセスによるデバイスのコンプライアンスの強制：トークンの発行には、管理対象でコンプライアンスに準拠したデバイスのみを要求します。これは、AiTMトークンの盗難に対する最も効果的な対策です。
• ブロックデバイスコードフロー: Block device code flow条件付きアクセス ポリシーは、許可フェーズでキットリレーを正常に拒否します (エラー 53003)。明示的に承認されたキオスク端末やヘッドレス端末のシナリオを除き、すべてのユーザーに対して有効にしてください。
• トークン保護（トークンバインディング）を有効にする：トークンを発行されたデバイスに紐付けます。別のデバイスから再生された盗まれたトークンは拒否されます。
• 継続的アクセス評価（CAE）を有効にする：リスク状況の変化に応じて、ほぼリアルタイムでトークンを失効させる。
• Entra ID でセキュリティのデフォルト設定を有効にする (カスタム条件付きアクセスを設定していないテナントのみ): ROPC などの従来の認証を拒否し、デバイスコードの流れをデフォルトでブロックします。セキュリティのデフォルト設定を有効にすると、カスタムCAポリシーが無効になるため、既に詳細なCAを実行しているテナントには適用されません。

MITRE ATT&CK マッピング

参照資料

• マイクロソフト セキュリティ ブログ - Tycoon2FA の内部構造：大手 AiTM フィッシング キットが大規模に運用されていた方法(2026 年 3 月)
• Tycoon 2FAマルウェアの分析と概要（ANY.RUN提供）
• Cloudflare - Tycoon 2FA対策（2026年3月）
• SpyCloud - Tycoon 2FA テイクダウングローバルなフィッシングインフラの混乱の内幕（2026年3月）
• eSentire -大手2要素認証事業者がOAuthデバイスコードフィッシング対策を採用（2026年5月）
• Sekoia - Tycoon 2FA：AiTMフィッシングキットの最新バージョンの詳細分析（2024年3月）