新フィッシングツール「iAuthFlow v2」、Googleアカウントに不正パスキーを登録パスワード変更後の再侵入を販売者が実演|セキュリティニュースのセキュリティ対策Lab

投稿日時: 2026年08月25日更新日時: 2026年08月25日

セキュリティ企業Abnormal AIは2026年8月20日、Googleアカウントへのフィッシング後に攻撃者管理のパスキーを登録し、パスワード変更やセッション失効後もアクセスを維持できるとうたうフィッシングツール「iAuthFlow v2」を分析した結果を公表しました。

販売者のデモでは、Googleを装ったフィッシングページと攻撃者側のブラウザを中継し、被害者が認証を完了した直後に新しいパスキーをアカウントへ登録しています。その後、アカウント所有者がパスワードを変更して既存セッションを無効化しても、攻撃者は登録済みのパスキーを使ってGmailへ再度アクセスできる様子が示されました。

ただし、Abnormal AIはiAuthFlow v2を購入・実行しておらず、攻撃を独自に再現したわけではありません。分析は販売者のフォーラム投稿、Telegramチャンネル、デモ動画などに基づいています。実際の組織や個人がこのツールで侵害されたとの確認も公表されていません。

iAuthFlow v2のサマリー

確認済み：Abnormal AIは2026年8月20日、フィッシングツール「iAuthFlow v2」の分析結果を公開しました。
確認済み：同ツールはロシア語圏のサイバー犯罪フォーラムで販売されており、基本価格は1万ドル、追加機能はモジュールとして別売りされています。
確認済み：Abnormal AIが分析した販売者デモはGoogleアカウントを対象としていました。
販売者主張：Microsoft、iCloud、LinkedIn向けのバージョンも提供するとされていますが、Abnormal AIはこれらの動作を検証していません。
確認済み：販売者デモでは、Browser-in-the-Middle（BitM）型のフィッシングを使い、被害者の認証操作を攻撃者側ブラウザへ中継しています。
確認済み：デモでは、認証完了から約6秒後に攻撃者管理のパスキーがGoogleアカウントへ登録されたことを示すログが確認されています。
確認済み：その後にパスワードを変更して既存セッションを失効させても、登録済みパスキーを利用してGmailへ再アクセスする様子が示されました。
確認済み：Googleの公式ヘルプでも、パスキーはアカウントに登録された独立した認証情報であり、削除する場合はパスキー設定から個別に削除する手順が案内されています。
重要：既存のパスキーの秘密鍵を盗んだり、パスキーの暗号方式を破ったりする攻撃ではありません。初期侵入でフィッシング可能な認証方式を突破した後、新しいパスキーを追加する手法です。
確認済み：Google Workspaceでは「Passkey enrolled」イベントをSecurity Investigation Toolで確認でき、管理者はパスキー利用状況を監視できます。
未確認：Abnormal AIはiAuthFlow v2を実際に動作させておらず、販売者デモの攻撃を独自に再現していません。
未確認：実際の攻撃でiAuthFlow v2が利用され、被害が発生した組織やユーザーは確認されていません。

項目	内容
公表日	2026年8月20日
調査元	Abnormal AI
ツール名	iAuthFlow v2
種別	フィッシングツール／PhaaSとして販売
販売価格	基本価格1万ドル、追加モジュールは別売り
分析対象	Googleアカウントを狙う販売者デモ
初期侵入	Googleを装ったフィッシングとBrowser-in-the-Middleによる認証中継
永続化	攻撃者管理のパスキーを被害アカウントへ追加
パスワード変更後	販売者デモでは登録済みパスキーによる再アクセスを確認
その他の対象	Microsoft、iCloud、LinkedIn版も販売者が宣伝。動作は未検証
実攻撃での悪用	確認できませんでした
被害件数	確認できませんでした
CVE	該当なし。製品脆弱性の悪用ではなく、認証後の正規機能を悪用する手法
独立検証	Abnormal AIはツールを実行・再現していません

iAuthFlow v2は1万ドルで販売、Google向けデモをAbnormal AIが分析

Abnormal AIによると、iAuthFlow v2はロシア語圏のサイバー犯罪フォーラムに登場したフィッシングツールで、基本価格は1万ドルです。追加の機能はモジュール形式で販売されています。

販売者はGoogleのほか、Microsoft、iCloud、LinkedIn向けのバージョンも宣伝しています。ただし、Abnormal AIが今回詳細に分析したのはGoogleアカウントを標的としたビルドと販売者のデモです。

この点は区別が必要です。「iAuthFlow v2がMicrosoftやiCloudでもパスキーによる永続化を実証した」とまでは一次情報から確認できません。

また、Abnormal AIはツールそのものを購入しておらず、認証情報を入力して実行したり、攻撃チェーンを独自に再現したりしていません。分析は販売者が公開したフォーラム投稿、Telegramチャンネル、動画、提供されたテストインスタンスなどを基に行われています。

そのため、本件は「攻撃キャンペーンが確認された」というより、犯罪市場で販売されているツールの能力を販売者デモと関連情報から分析したものと捉えるのが適切です。

Browser-in-the-MiddleでGoogleへの認証を中継

販売者のデモでは、iAuthFlow v2はBrowser-in-the-Middle（BitM）型の構成を利用しています。

標的にはGoogleのログイン画面を装ったページが表示されますが、背後では攻撃者のサーバー上に別のブラウザが動作しています。利用者が入力したメールアドレス、パスワード、追加認証の情報などを攻撃者側ブラウザへ中継し、そのブラウザが実際のGoogle認証を進めます。

デモで使われたテストアカウントにはすでにパスキーが登録されていましたが、利用者役はパスキーではなく認証アプリのコードを選択してログインしていました。このコードがリアルタイムで攻撃者側ブラウザへ中継され、Google上で認証済みセッションが成立しています。

ここで重要なのは、パスキーそのものがフィッシングされたわけではない点です。

Googleは、パスキーはWebサイトやアプリのIDに結び付けられており、作成元の正規サービスでしか利用できないため、フィッシング耐性を持つと説明しています。今回のデモでは、その仕組みを破るのではなく、パスワードやTOTPなどフィッシング可能な認証経路から先にアカウントへ入り、その認証済み状態を使って攻撃者自身のパスキーを新規登録しています。

セキュリティ対策Labでは、パスキーの認証方式とフィッシング耐性について「パスキーとは？メリットや概要を解説」で整理しています。

認証から約6秒後に攻撃者管理のパスキーを登録

販売者デモでは、Googleへのログインが成立した後も、iAuthFlow v2は利用者をすぐにGmailへ遷移させません。

フィッシングページには処理中を装う画面を表示したまま、攻撃者側の認証済みブラウザからGoogleアカウントのパスキー設定へアクセスし、新しい認証情報の登録を進めます。

Abnormal AIが確認した販売者ログでは、Googleへの認証完了から約6秒後にパスキーが作成・保存されたことを示す記録が残っていました。

この時点で攻撃者は、単に一時的なセッションCookieを持っているだけではありません。被害者のGoogleアカウントに対して、新たな認証手段を登録した状態になります。

Googleは、パスキーを追加しても既存の認証・復旧手段は自動的に削除されないと説明しています。逆に、不審なパスキーを削除する場合も、Googleアカウントの「パスキーとセキュリティキー」から対象の認証情報を個別に削除する必要があります。

パスワード変更後もパスキーは残り、販売者デモでは再アクセスに成功

販売者デモでは、その後アカウント所有者がGoogleアカウントのパスワードを変更しています。

Googleの公式ヘルプによると、パスワードを変更またはリセットすると、多くの端末やセッションからサインアウトされます。ただし、パスキーはパスワードから派生するセッショントークンではなく、アカウントに別途登録された認証情報です。

デモでは、パスワード変更によって攻撃者側の既存セッションが無効になった後、再度ログインを試み、「別の方法を試す」から先ほど登録したパスキーを選択しています。その結果、新しいパスワードを知らない状態でGmailへ戻る様子が示されました。

Abnormal AIは、この動作についてパスキーの仕組みと整合すると評価していますが、同社自身が再現したものではない点には注意が必要です。

Googleの現在のヘルプでは、新しい認証・復旧手段がリスクの高い変更として扱われる場合があり、反映まで最大7日かかる可能性や、追加のセキュリティ確認を要求する仕組みも案内されています。販売者デモのアカウント条件と、現在のすべてのGoogleアカウントで同じ挙動が成立するかは確認できません。

「パスキーがフィッシングに弱い」という意味ではない

今回の事例を「パスキーのフィッシング耐性が破られた」と捉えるのは正確ではありません。

パスキーの強みは、秘密鍵をユーザーが入力したりサイトへ送信したりせず、認証対象のドメインに結び付けて利用する点にあります。そのため、偽ログインページへパスキーを入力して盗ませるという従来型フィッシングは成立しにくくなります。

iAuthFlow v2が狙っているのは、その前段ではなく「認証後」です。

パスワードやTOTPなどのフィッシング可能な認証経路を使って一度正規アカウントへのアクセスを得た後、その権限で攻撃者自身のパスキーを登録します。つまり、既存パスキーの窃取ではなく、アカウント乗っ取り後の永続化手段としてパスキー登録機能を悪用するものです。

同様に、正規のパスキー登録機能を攻撃者が悪用するケースは別の攻撃でも確認されています。セキュリティ対策Labでは、Microsoft 365利用者を電話で誘導し、攻撃者管理のパスキー登録につなげる攻撃について「Okta、Microsoft 365利用者を狙うビッシング攻撃を警告」で解説しています。

実攻撃での利用や被害件数は確認されていない

Abnormal AIは、iAuthFlow v2が犯罪フォーラムで販売されていることや、販売者が示したテスト環境、デモ動画、ツールの一部アーティファクトを確認しています。

一方、同社はツールを実際に購入・実行しておらず、Googleアカウントへの一連の攻撃を独自に再現していません。

また、公開資料では、iAuthFlow v2を使った攻撃によって実在する企業や個人のGoogleアカウントが侵害された事例、パスキーによる再侵入が成功した被害件数なども示されていません。

したがって、「iAuthFlow v2によるGoogleアカウント侵害が広がっている」「パスキーを利用するGoogleユーザーが実際に被害を受けている」と断定することはできません。

Abnormal AIが公開したIoCについても、販売者から提供されたテストインスタンスから取得したものであり、実際の攻撃インフラとして観測されたものとは区別する必要があります。

Google Workspaceではパスキー登録イベントを監視可能

Google Workspace管理者は、パスキーが新たに登録された事実を監査できます。

Googleの管理者向けドキュメントでは、Security Investigation ToolのUser log eventsから「Passkey enrolled」を条件に検索し、パスキーを登録したユーザーを確認する方法が案内されています。

また、ログにはパスキーの登録や利用に関するイベントが記録されるため、アカウント侵害が疑われる場合は、ログイン履歴だけでなく認証手段の変更履歴まで確認することが重要です。

Google Workspaceの一部エディションでは、パスキーの利用をハードウェアセキュリティキーに限定する設定も提供されています。すべての組織に適用できるわけではありませんが、高権限アカウントや重要部門では、認証手段の登録そのものをより厳しく制御する選択肢になります。

情報システム部門への示唆

iAuthFlow v2の分析で最も重要なのは、アカウント侵害時の復旧手順を「パスワード変更とセッション失効」で終わらせないことです。

フィッシングによるGoogle Workspaceアカウント侵害が疑われる場合は、まず利用者のパスワードを変更し、セッションを失効させるだけでなく、攻撃中に追加された認証手段や設定変更がないかを確認する必要があります。

具体的には、パスキーとセキュリティキー、2段階認証手段、復旧用メールアドレスや電話番号、OAuthアプリの認可、Gmailの転送設定やフィルタ、委任設定などを確認します。不明なパスキーや認証手段が存在する場合は削除し、必要に応じてOAuthトークンやアプリのアクセス権も取り消します。

Google Workspaceを利用している組織では、「Passkey enrolled」イベントを継続監視し、通常利用していないユーザーや高権限アカウントで新しいパスキーが登録された場合に確認できる運用を検討する必要があります。

認証方式の設計も見直しポイントです。今回の販売者デモでは、既存パスキーがあるにもかかわらず、利用者役がTOTPを選択したことでBitM型フィッシングが成立しました。パスキーやハードウェアセキュリティキーを導入していても、SMSやTOTPなどフィッシング可能な方式を常時フォールバックとして残している場合、その経路が狙われる可能性があります。

パスキー導入を「認証方式を1つ追加する」だけで終わらせず、高リスクユーザーではフィッシング耐性のない方式をどこまで残すのか、認証手段の新規登録をどう監視するのか、侵害時に何を削除・失効させるのかまで含めて運用を設計する必要があります。