ハッカーはAIエージェントを使って従来のログインを突破しています。パスワードを捨て、パスキーのようなフィッシング耐性のある認証情報に移行する時です。
長年、組織はパスワードやSMSコード、ワンタイムパスワード（OTP）などの共有シークレットに基づく多要素認証（MFA）をアイデンティティセキュリティの基盤としてきました。コンピュータ利用エージェント（CUA）の台頭により、攻撃者はフィッシングやクレデンシャルスタッフィング攻撃を自動化・大規模化する能力を加速させ、ほとんど労力をかけずに実行できるようになります。その結果、フィッシング耐性のある認証情報の導入は、ベストプラクティスから必須事項へと変わりました。組織はFIDO2、パスキー、証明書ベース認証などのデバイスに紐づいた暗号化ソリューションを優先し、SaaSアプリケーションへのアクセスを保護すべきです。同様に、SaaSプロバイダーもフィッシング耐性のある認証情報をサポートするアイデンティティプラットフォームとの統合を確実にし、全体的なセキュリティ体制を強化する必要があります。
パスワード利用パターン：根本的な原因
組織はSaaSへの依存を高めており、平均的な企業は106個のSaaSアプリケーションを利用しています。
これほど多くのアプリのためにユニークで複雑なパスワードを管理することがいかに大変かについては、十分な研究があります。
- 最小努力の原則： 私たちの脳は認知負荷を減らすために近道を探すため、パスワードの使い回しが合理的に思えてしまいます。
- セキュリティ疲れ： 頻繁なパスワード変更や複雑なルールはユーザーを苛立たせ、使い回しを促します。
その結果、ユーザーはしばしば4～10個の主要なパスワードを使い回しています。Enzoicの記事によると、平均的な人は最大14個のアカウントで同じパスワードを再利用しています。
Google-Harris Pollの調査によれば、アメリカ人の66％が複数のアカウントでパスワードを使い回していると認めています。
ユーザーが一意性を試みても、その変更はたいてい些細なものや定型的なもので、最初の文字を大文字にしたり、数字や記号を追加したりする程度です。
例：Winter2025 → Winter2025!
攻撃者はこれらの予測可能な変更をマスク攻撃で悪用し、一般的なバリエーションを体系的にテストします。さらに、SaaSサインイン時に露出するパスワードルールを利用して予測ロジックを最適化します。
さらに悪いことに、73％のユーザーが個人用と業務用アカウントでパスワードを使い回しており、攻撃者が企業リソースにアクセスする直接的な経路を作っています。もし侵害されたユーザーが特権アクセスを持っていれば、その影響は壊滅的になり得ます。
攻撃者がこれらのパスワード利用パターンを悪用する方法
攻撃者は以下のような一般的な手法で認証情報を入手すると：
- フィッシング： 偽のログインページでユーザー名とパスワードを取得
- データ漏洩： 数百万件の認証情報がオンラインに流出
- キーロガー： キーストロークを記録するマルウェア
- 中間者攻撃： 公共Wi-Fiでの通信傍受
- ソーシャルエンジニアリング： ユーザーを騙して秘密を明かさせる
これらの盗まれた認証情報をクレデンシャルスタッフィングで武器化し、複数のSaaSアプリで自動的にテストして不正アクセスを試みます。
クレデンシャルスタッフィングの進化
手動ログイン試行
この従来の手法では、攻撃者が盗んだユーザー名とパスワードを複数のSaaSアプリで手作業でテストしていました。
制限事項：
- 時間がかかり、労力も大きい。
- 1つ以上のSaaSアプリで異常検知アラートが発生しやすく、攻撃者がターゲットアプリ全体でクレデンシャルスタッフィングを完了する前にユーザーが対応する時間が生まれる。
ボットによる自動化
攻撃を拡大するため、攻撃者はボットを使ってログインページでのクリックを模倣したり、利用可能な場合はSaaSアプリのAPIを呼び出したりし始めました。時間の経過とともに、これらのボットもIP拒否リスト、レート制限、CAPTCHA、ボット行動検知などSaaSアプリが設けた自動化対策を回避するよう進化しています。しかし、課題も残っています：
- ボットやスクリプトは多くの場合アプリ固有であり、SaaSアプリのUI要素が変わるたびに継続的な更新が必要です。
- コーディングスキルやカスタム設定、場合によってはAPIアクセスが求められます。
- すべてのボットがあらゆる自動化対策を回避できるわけではなく、攻撃者は各SaaSアプリの防御に応じて特定のボットを選択する必要があります。
- 要するに、ウェブアイデンティティは何千ものSaaSアプリで独自に実装されており、SaaSアプリも頻繁にUIを変更するため、クレデンシャルスタッフィング攻撃の大規模化は困難です。広範なボット対策もこれをさらに複雑にしています。
CUAの登場
コンピュータ利用エージェントは、AI駆動のシステムで、人間と同じようにコンピュータやアプリケーションのユーザーインターフェースを操作します。これらはビジョン・ランゲージモデル（VLM）や大規模言語モデル（LLM）によって動作し、知覚・推論・行動計画を組み合わせることができます：
- 知覚： ピクセルデータやスクリーンショットを通じて画面を観察し、表示内容を解釈する。
- 理解： ボタン、テキストフィールド、メニューなどのUI要素を人間のように認識・解釈する。
- 行動： クリック、入力、スクロール、ナビゲーションなどを自律的にアプリやウェブサイト上で実行する。
CUAはボットを凌駕し、クレデンシャルスタッフィング攻撃を大規模化できる
攻撃者が活用すると、CUAの能力は従来のボットや自動化ツールよりもはるかに効果的に認証情報の悪用キャンペーンを実行できます：
人間のようなインタラクション
従来のボットやスクリプトがSaaSアプリのAPIに依存したり、アプリごとにカスタム自動化を必要とするのに対し、CUAは人間と同じユーザーインターフェースを直接操作するため、APIやカスタムコードが不要です。このCUAによる人間的なアプローチにより、攻撃者はターゲットにできるSaaSアプリの範囲を大幅に拡大できます。
自然言語による指示
CUAは平易な言葉で指示できるため、コーディングスキルや技術的知識が不要です。これにより攻撃者の参入障壁が劇的に下がります。
動的な適応性
UI要素が変わるたびに失敗したり継続的な修正が必要なボットと異なり、CUAはピクセルを認識し、要素を推論し、ワークフローをその場で調整します。この動的な適応性により、CUAは進化するレイアウトや多様なプラットフォームにもシームレスに対応し、複雑さを大幅に軽減します。
適応学習
ボットと異なり、CUAは失敗から学習し、攻撃シーケンスを最適化し新たな防御を回避します。
アンチボット防御への耐性
CUAは完全なブラウザスタックと人間らしいインタラクションパターン（リアルなクリックや入力速度）を用います。これらの行動により、CAPTCHAや行動分析などの一般的な防御策を回避できます。
大規模な並列実行
CUAはマシンのスピードで並列にタスクを実行できるため、攻撃者は数千件のクレデンシャルスタッフィングを同時に仕掛けることができ、手動攻撃より桁違いに速くなります。
CUAがソーシャルエンジニアリングやフィッシング攻撃をどう変革するか
CUAのこれらの能力により、攻撃者はソーシャルエンジニアリングやフィッシングも全く新しいレベルに引き上げることができます。CUAはフィッシングの発生場所や方法を再定義し、メールからソーシャルプラットフォームやコラボレーションツールへと移行させます。これらの場所では企業のアンチフィッシング対策が通常導入されておらず、効果も低いのです。攻撃者は自然言語でCUAに指示し、ソーシャルプラットフォームでアカウント作成、メッセージ投稿、信頼構築を行い、その信頼を利用して認証情報を盗むフィッシングリンクを配信できます。
さらに、特定のユーザーを狙う場合、CUAはAIを活用して様々なソーシャルプラットフォームからユーザー情報を収集し、それをもとに極めて個別化されたメッセージを作成して関係を築き、最終的に被害者を悪意のあるサイトへ誘導するフィッシングの餌として利用できます。
フィッシング耐性のある認証情報への推奨される移行
これらの高度な攻撃に対抗するため、CISAなどのサイバーセキュリティ機関は、パスキー（FIDO2）や公開鍵基盤（PKI）ベースの認証情報など、フィッシング耐性のある認証情報の導入を組織に推奨しています。
FIDO2／パスキー
FIDO2セキュリティキー： これは物理的なデバイスで、USB、近距離無線通信（NFC）、Bluetoothなどで接続し認証を行います。ユーザーの秘密鍵を保持し、暗号署名によってサービスへの安全な認証を実現します。
プラットフォームベースのパスキー： これはFIDO認証情報の一種で、スマートフォンやノートPCなどユーザーの消費者デバイスに保存できます。これらのパスキーによる認証は、デバイスの生体認証やPINの入力でロック解除が必要です。
PKIベースの認証情報
証明書ベース認証／スマートカード：物理的なスマートカードにデジタル証明書と秘密鍵を格納します。認証にはカードの挿入と、カード内の秘密鍵を解除するためのPIN入力が必要です。
これらの認証情報がフィッシングに強い理由
- 共有シークレットなし：パスワードやワンタイムコードが存在しないため、フィッシングで盗まれたり、リプレイ攻撃で再利用されたりしません。
- 暗号的に検証可能：パスワードやワンタイムコードの代わりに暗号鍵ペアでユーザー認証を行い、秘密鍵はユーザーのデバイスから決して出ません。サーバーはこの秘密を送信せずにユーザーの身元を検証できます。
- デバイスに紐づく：暗号鍵ペアの秘密鍵は特定の物理デバイスに紐づいています。攻撃者がユーザーのデバイスにサインインできない限り、秘密鍵で暗号署名を生成できません。
- オリジンに紐づく：パスキーの場合、鍵は特定のウェブサイトやアプリのドメインに暗号的に紐づいており、そのサービスでしか使えず、悪意あるサイトや偽サイトでは利用できません。
行動を呼びかけます
- 組織： すべてのSaaSアプリでフィッシング耐性のある認証情報を徹底してください。
- SaaSプロバイダー： フィッシング耐性のある認証情報をサポートするアイデンティティプラットフォームと統合してください。
- セキュリティリーダー： これは理想ではなく必須事項と捉えてください。遅れの代償は大規模な侵害です。
この記事はFoundry Expert Contributor Networkの一部として公開されています。
参加をご希望ですか？
