多くのMFA（多要素認証）手法が「フィッシング可能」（すなわちフィッシング耐性がない）であるという認識が広まる中、YubiKey、Okta FastPass、Windows HelloのようなパスワードレスでFIDO2ベースの認証方法（いわゆるパスキー）がますます推奨されています。
これは良い傾向です。最も一般的に使われているMFA要素（SMSコード、プッシュ通知、アプリベースのOTPなど）は、現代のリバースプロキシ型「中間者攻撃（AitM）」フィッシングキットによって日常的に回避されており、これが現在のフィッシング攻撃の標準的な手法となっています。
これらは、被害者がパスワードを入力しMFAチェックを完了した際に作成される認証済みセッションを傍受することで機能します。そのために、フィッシングサイトは単にユーザーと本物のウェブサイトの間でメッセージを中継するだけです—これが「中間者攻撃」と呼ばれる理由です。
対照的に、パスキーを使ったログインはフィッシングされません。パスキーによるログインはドメインに紐付いているため、microsoft.com用のパスキーをphishing.comで使おうとしても、AitMキットでプロキシされた場合でも認証チェックを通過する正しい値は生成されません。
しかし、攻撃者はそう簡単には諦めていません。パスキーの普及に伴い、認証プロセスをダウングレードしたり、回避したりしてフィッシング攻撃に対して脆弱にするためのさまざまな手法が登場しています。
そこで、これまでに攻撃者がパスキーを回避するために使ってきた全ての手法を紹介します。
ダウングレード攻撃
ダウングレード攻撃は、攻撃者がフィッシング耐性MFAを回避するための定番手法です。MFAダウングレード機能は、複数の犯罪用AitMキットで確認されており、Evilginxのような市販キットでも実現可能です。
中間者型フィッシング攻撃を行う際、攻撃者は全てのメッセージを正確に中継する必要はありません。一部を改ざんすることができます。たとえば、アプリがユーザーに「MFAが必要です—パスキーを使いますか、それともバックアップ認証コードを使いますか？」と尋ねる場面で、フィッシングサイトはこのページを「MFAが必要です—バックアップ認証コードを使ってください」と書き換え、セキュアなパスキーを使う選択肢を与えません。これがダウングレード攻撃です。
この手法は、SSOをデフォルトのログイン方法として使っているアカウントにも適用できます。この場合、フィッシュキットがバックアップのユーザー名とパスワードのオプションを選択し、フィッシング攻撃を継続できるようにします。
以下は、Evilginxでカスタムフィッシュレットを使い、Windows Helloを利用するMicrosoftアカウントの認証をダウングレードする例です。
このように、たとえフィッシング耐性のあるログイン方法が存在しても、より安全性の低いバックアップ方法がある限り、アカウントは依然としてフィッシング攻撃に対して脆弱です。
デバイスコードフィッシング
フィッシング耐性認証方法を回避するために、攻撃者はデバイスコードフィッシング攻撃も利用しています。これは、パスキーによるログインをサポートしていないデバイス（例：ウェブブラウザがない、入力機能が限られている等）のための代替認証フローを悪用するものです。
この代替ログインフローは、ユーザーに一意のコードを提供し、別のデバイスのブラウザで特定のウェブページにアクセスしてコードを入力するよう指示することで、デバイスの認可を行います。
これを利用して、攻撃者はターゲットに認証プロバイダーのウェブサイトにアクセスし、攻撃者が提供したコードを入力させることで、アカウントへのアクセス権を得るフィッシング攻撃を仕掛けることができます。
この攻撃の利点は、ターゲットを正規のURLに誘導できること、デバイスコードの入力とサインイン以外に明示的な権限同意を求めるプロンプトが表示されないことです。さらに、場合によっては正規アプリのなりすましも可能です。
この手法は、最近の複数のキャンペーンで確認されており、ロシアが支援するM365アカウントの標的型攻撃(1) (2)などがあります。
同意フィッシング
同意フィッシングは、SaaS攻撃マトリクスに最初に追加された手法の一つで、以前から存在していますが、最近悪用事例が増加しています。
OAuthは、ユーザーがサードパーティアプリに自分のデータへのアクセス権を付与できる仕組みです。攻撃者はこの機能を悪用し、ユーザーを騙して悪意のあるOAuthアプリへのアクセス権を承認させます。
同意フィッシング攻撃では、攻撃者がターゲットにフィッシングリンクを送り、機密データへのアクセスや危険な操作を行う権限を要求します。ターゲットがこれらの権限を承認すると、攻撃者はそのレベルのアカウントアクセスを得ます。このアクセスはMFAを回避し、パスワード変更後も持続します。
同意フィッシングは、Microsoft AzureやGoogle Workspaceテナントへのアクセスを狙う攻撃と最も関連しています。しかし、最近ではSaaSアプリが独自のOAuth認証APIやアプリストアを実装することが一般的になり、同様の攻撃対象となっています—最近のGitHubユーザーを標的とした事例もあります。
一度承認されると、攻撃者はアカウントに広範なアクセス権を持ちます。このGitHubの例では、攻撃者はリポジトリを改ざんしてさらなる攻撃（例：マルウェア感染）を仕掛けたり、リポジトリや関連サービスを汚染したり、アカウントがアクセスできる機密データを流出させたりできます。
認証フィッシング
メール認証は、新規アカウント登録時などにコントロール手段として使われることがあります。これは通常、ターゲットユーザーにクリック可能なリンクや認証コードをメールで送り、認証を促す形で実装されます。
認証フィッシングは、攻撃者がフィッシングやその他のソーシャルエンジニアリングを使って、ユーザーに認証リンクをクリックさせたり、認証コードを渡させたりして、このコントロールを突破する手法です。
この手法を使ってMFAを回避する例として、クロスIdPなりすましがあります。これは、攻撃者が被害者の企業メールドメインで新しいIdPアカウントを登録するだけで、多くの場合、追加のチェックなしに新しいIdP経由でSSOログインできてしまうものです。実際、5つのうち3つのアプリでこの挙動が確認されています。
SSOのIdPとして機能できるアプリの数を考えると、アプリや対応ログイン方法によってはかなり多くの攻撃対象が存在します。
管理されたIdPは組織が一元管理できます（IdPとそのIDを所有・運用）。一方、未管理の「ソーシャル」IdPはベンダーが管理し、IDはユーザーが所有・管理します。
この例は下記の動画でも確認できますし、実際の事例分析はこちらからもご覧いただけます。
アプリ固有パスワードのフィッシング
アプリ固有パスワードのフィッシングは、攻撃者がユーザーを騙してアカウント用の「アプリ固有パスワード」を生成させ、それを攻撃者に共有させるソーシャルエンジニアリング手法です。これらのレガシーパスワードは、GoogleやAppleなど一部の主要SaaSプロバイダーで、OAuth 2.0のような最新認証をサポートしていない古いアプリケーションからアカウントデータにアクセスできるようにするための機能です。
攻撃の流れは、攻撃者が信頼できる存在（例：テクニカルサポートやサービスプロバイダー）になりすまし、ユーザーをアカウントのセキュリティ設定ページに誘導します。ユーザーは新しいアプリ固有パスワードの作成手順を案内され、そのパスワードを攻撃者が管理するフォームやチャットウィンドウに貼り付けるよう指示されます。
アプリ固有パスワードはMFAをサポートしない環境で使われることを想定しているため、攻撃者がこのパスワードを入手すると、API経由でユーザーのアカウントデータ（メール、連絡先、ファイルなど）に持続的かつプログラム的にアクセスできるようになります。多くの場合、未認識デバイスからの従来型インタラクティブログインほどのセキュリティ警告は発生しません。
このため、アクセスはセッショントークンよりも目立たず、ユーザーが手動で無効化するまで有効なことが多いです。
最近公開された事例では、ロシアの情報活動専門家が高度で個別化されたソーシャルエンジニアリング攻撃の標的となり、攻撃者がメールクライアントにASPでログインすることで被害者のメールボックスへの持続的アクセスを確立しました。
この攻撃では、米国国務省になりすました巧妙な誘導で、被害者にASPの作成と攻撃者への共有方法を指示し、Googleメールボックスへのアクセス権を与えていました。
ボーナス：パスキー未対応のローカルアカウントを狙う
おそらくパスキーを回避する最も簡単な方法は、パスキーをネイティブにサポートしていないアプリを狙うことです。パスキーは通常、SSOと組み合わせて使われ、まずセキュアなパスキー保護ログインで主要IdPプロバイダーにログインし、その後SSO経由で接続アプリにアクセスします。多くのアプリはパスキーによる直接ログインを許可していません。
その結果、Slack、Mailchimp、Postman、GitHubなどの一般的なビジネスアプリが直接標的とされるケースが増えています—通常より堅牢な認証制御を持つIdP（MS、Google、Okta等）をバイパスして攻撃されます。
パスキーと一緒にバックアップMFA方法が登録されることが多いのと同様に、ローカル「ゴーストログイン」方法もSSOと一緒に登録されることが多く、アカウントには複数の侵入経路が存在します。
多くの場合、MFA自体が導入されていないため、盗まれた認証情報を使った攻撃に対しても同様に脆弱です（昨年のSnowflake攻撃や、今年のJira攻撃で見られるように）。
これにより、組織が管理すべき膨大かつ脆弱なID攻撃対象面が生じます。
まとめ
多くの場合、攻撃者はパスキーを回避するために特別なことをする必要はありません。通常使っているフィッシングツールや手法をそのまま使えば、アカウントにバックアップの非パスキーMFA方法が登録されている限り、十分に攻撃可能です。
本当に安全なのは、パスキーのみが登録されていて、バックアップ方法が一切なく、かつ非パスキー認証を防ぐ条件付きアクセス制御があるアカウントだけです。
しかし、ここにも落とし穴があります（たとえば、最近のこの事例のように、Microsoft提供のCAテンプレートが「リスキー」なサインインを誤検知して許可してしまうなど）。
また、アプリやIDの乱立状況を監査するのは容易ではありません。アプリごとにセキュリティチームが利用できる可視性やコントロールのレベルが異なり、多くのアプリはそもそも中央管理されていなかったり、存在自体が把握されていないことも多いからです。
Push Securityでフィッシング攻撃を防止・検知
AitMフィッシングキットを使ったダウングレード攻撃は、パスキー回避型フィッシング攻撃の大多数を占めています。
Push Securityのブラウザベースのセキュリティプラットフォームは、AitMフィッシング、クレデンシャルスタッフィング、パスワードスプレー、盗まれたセッショントークンを使ったセッションハイジャックなどの手法に対し、包括的なID攻撃の検知・対応機能を提供します。
また、Pushを使えば、従業員が使う全てのアプリにおけるID脆弱性（ゴーストログイン、SSOカバレッジのギャップ、MFAのギャップ、弱い・漏洩・使い回しパスワード、リスキーなOAuth連携など）を発見・修正できます。
Pushがどのようにして一般的なID攻撃手法の検知・防御に役立つか詳しく知りたい方は、弊社スタッフとのライブデモをご予約ください。
Push Securityによるスポンサードおよび執筆。