エグゼクティブサマリー
過去12か月間で、Okta Threat Intelligenceは、攻撃者が開始したMFA登録やパスワードリセットを、騙されたユーザーに承認させる手口の攻撃が増加していることを観測しています。
攻撃者がこうしたソーシャルエンジニアリング攻撃のテスト、改善、大規模化を進めている、関連する多数のアクティビティ群が観測されています。
先月にOktaが顧客へ送信した予防的通知の5件に1件は、「passkey」という文字列を含むフィッシングドメインに関連するものでした。最近確認されたキャンペーン（O-UNC-066）では、Entraアカウントへの永続的なアクセス権を取得する目的で、パスキー登録という口実（プリテキスト）が悪用されていました。
MFAの登録とアカウント回復の強化は、プラットフォームやユースケースを問わず、すべてのアイデンティティチームにとって今や優先事項です。
脅威分析
2025年まで、Oktaが観測したソーシャルエンジニアリング活動の大半は、ITサポートやその他のヘルプデスク担当者になりすましてユーザーを騙し、攻撃者が管理するフィッシングサイトにパスワードやOTPを入力させるというものでした。
この種の資格情報フィッシングは、組織がポリシーによってフィッシング耐性のある認証要素の使用を必須とすることで、効果がなくなります。フィッシング耐性のあるポリシー条件下では、たとえユーザーが騙されて攻撃者の管理するサイトにアクセスした場合でも、ユーザーは自身のアクセス資格情報を共有することができません。
その後、いくつかの脅威アクティビティ群は、ユーザーの資格情報を奪取してリプレイ（再利用）する必要性を回避する攻撃手法を用いることで、標的組織によるフィッシング耐性の導入に適応してきました。
以下に、脅威活動クラスターのリストを古いものから順に示し、こうした戦術のいくつかを具体的に説明します。
攻撃者 | 対象となるプロセス | TTP |
|---|---|---|
登録（パスキー登録） | 攻撃者は標的組織のセキュリティチームになりすまし、ユーザーをフィッシングページに誘導してパスキーを設定させようとします。 | |
リカバリー（パスワードのリセット） | 攻撃者は企業のITヘルプデスクになりすまし、標的をフィッシングページに誘導したり、攻撃者が制御するアプリケーションを承認させたりします。 | |
登録 | 攻撃者は音声通話で勤務先のITヘルプデスクになりすまし、標的を資格情報フィッシングサイトへと誘導する。 | |
リカバリー（パスワードのリセット） | 攻撃者は勤務先のITヘルプデスクになりすまし、パスワードリセットの必要性を急かす言動を口実として利用する。 | |
登録（パスキー登録） | 攻撃者は音声通話で勤務先のITチームになりすまして標的を資格情報フィッシングサイトへと誘導し、奪取した資格情報を用いてユーザーのアカウント内に攻撃者管理のパスキーを登録する。 | |
リカバリー（パスワードのリセット） | 攻撃者は通話中に裏で「パスワードをお忘れの場合」フローを同時に実行し、ソーシャルエンジニアリングによってユーザーにリセット処理を承認させる。 |
特筆すべき点として、OktaがO-UNC-067として追跡している攻撃者が、アカウントを乗っ取る目的で資格情報フィッシングキットを使用している様子は、現時点では観測されていません。
少なくとも2026年6月から活動しているこの攻撃者は、セルフサービスパスワードリセット（SSPR）を許可する設定になっている組織を選択的に標的としています。
攻撃者はまず標的に対して事前に偵察を行い、パスワードリセットを実行するためのリンクにアクセス可能かどうか、またそのパスワードリセットが実行された際にユーザーの本人確認用としてどのようなMFAチャレンジが適用されるかを確認します。SSPRオプションが有効化されており、かつそのフローにおいてフィッシング耐性のないMFA要素を使ってユーザーが本人確認を行える状態である場合、攻撃者は標的ユーザーに電話をかけながら、同時にパスワードリセットのフローを実行します。
アカウントリカバリプロセスの詳細分析
防御のための最低条件
ソーシャルエンジニアリング攻撃のキャンペーンが、認証要素の「登録」（例：O-UNC-066）を標的にしているか、それとも「リカバリ」（例：O-UNC-067）を標的にしているかにかかわらず、攻撃の成否は標的となる組織レベルのアカウント管理ポリシーに大きく依存します。
最も脆弱なアカウント管理設定では、以下のようになっています。
パブリックなサインインページ上でパスワードリセットのリンクが提示されている
MFA登録ポリシーにおいて、任意のMFA要素によるユーザーの本人確認が許可されている
MFA登録ポリシーにおいて、任意のIPアドレスからの検証が許可されている
この設定は一部のカスタマーアイデンティティ（CIAM）のユースケースには適しているかもしれませんが、従業員向けの環境には適していません。標的ユーザーと電話で通話中の攻撃者は、自身のデバイスからパスワードリセットをトリガーしつつ、そのリセット処理を承認させるためにOTPを共有させたり、プッシュ通知のリクエストを承認させたりするようユーザーを言いくるめることができます。
Oktaの管理者は、以下の対策を実施することで、MFA登録ポリシー内に直接「フリクション（制御や制限などのハードル）」を極めて容易に追加できます。
リセットを開始する際に、単一要素のチャレンジを超えた追加の検証を要求する
セルフサービス機能の利用を、信頼できるIPアドレス範囲のみに制限する
これにより、日和見的な無差別攻撃を防ぐためのハードルが追加されるものの、執拗な攻撃者を阻むことはできません。セルフサービスイベントをトリガーするソーシャルエンジニアリング攻撃者は、リカバリ中に提示される利用可能な検証チャレンジのリストから自由に選択できる立場にあるため、常に最も脆弱で最も「フィッシングに弱い（phishable）」認証方法を選択します。
そのため、Oktaをご利用のお客様は、Okta Account Management Policyを詳しく確認する必要があります。
認証要素の登録に対するフィッシング耐性の適用
Oktaのアカウント管理ポリシー（AMP）は、もともとパスワードレス認証を使用する組織の認証要素におけるライフサイクル要件をサポートするために導入された機能です。現在では、これらのポリシーはすべての認証要素の登録およびリカバリフローをソーシャルエンジニアリング攻撃から保護するための設定ツールとしても捉えられるようになっています。
AMPを使用することで、管理者は以前は認証に対してのみ利用可能であった高度なポリシー制約を、アカウントリカバリーにも同様に適用できるようになります。AMPを利用すると、フィッシング耐性のある要素、管理対象デバイス、信頼できるネットワーク、その他多様な基準を使用した検証を要求できるため、アカウントリカバリープロセスに実質的な「ゼロトラスト」を適用することが可能です。
Okta Threat Intelligenceでは、認証要素の登録およびリカバリにフィッシング耐性を適用するために、Oktaアカウント管理ポリシー（AMP）の利用を推奨しています。AMPを設定することで、ユーザーが認証要素を追加または変更する前に、フィッシング耐性のある認証要素を使用して本人確認を行うよう義務付けることができます。
最も強固なアカウント管理設定では、ユーザーアカウントは事前登録された物理セキュリティキーを使用して初期設定（ブートストラップ）され、アカウント管理ポリシーにより、ユーザーが認証要素を追加・変更する際には常にフィッシング耐性のある要素で本人確認を行うことが要求されます。これにより、認証要素の「登録」と「リカバリー」の両方に対する攻撃を完全に無力化できます。稀なエッジケースが発生した場合は、Oktaが身元確認（IdV）サービスと連携し、ユーザーに対し政府機関発行の身分証明書の提示とライブネスチェック（生存確認）を要求した上でリカバリーを開始させます。
次によく採られる強力なアプローチは、OktaのAMP、グループ機能、イベントフックを活用し、まだ十分な数のフィッシング耐性認証要素を登録していないワークフォースユーザーに対し、登録時の保証レベルのハードルを段階的に引き上げていく方法です。
このようなシナリオでは、最上位（最初に評価される）AMPルールにより、リクエストが管理対象デバイスから送信され、かつユーザーがフィッシング耐性のあるMFAチャレンジをクリアした場合にのみ、要素の追加・変更を許可するように設定します。最終的な目標は、すべてのユーザーをこのルールの対象グループへ段階的に移行させ、要素のライフサイクルイベントにおいてフィッシング耐性要素のみを使用するよう制限することです。これより下位のポリシールールをトリガーするユーザーについては、優先的に上位ルールへの移行を進める必要があります。
続くルールでは、ユーザーが十分な数のフィッシング耐性認証要素を登録するまで、可能な限りの制約を課すようにします。たとえば、身元確認（IdV）チャレンジのクリアを要求したり、あるいは信頼できるネットワークからの登録であれば、オンボーディング初期の数日間に限り、一時的に比較的脆弱な認証要素による本人確認を許可したりすることが考えられます。また、イベントフックやOkta Workflowsを活用することで、条件を満たしたユーザーを、保証レベルの要求が高いグループへ自動的にステップアップさせることも可能です。
意図しないアクセスシナリオを防ぐため、あらゆるポリシーの最後（一番下）のルールとして、必ず包括的な拒否ルールを追加してください。
認証要素のリカバリーに対するフィッシング耐性の適用
フィッシング耐性のあるリカバリを実現する鍵は、単一デバイスの紛失や障害が発生した場合に備え、フィッシング耐性のある十分な数の認証要素をユーザーにあらかじめ登録させておくことです。
Okta Verifyクライアントの最大の強みの1つは、ユーザーが自身のOkta Verifyアカウントに複数のデバイスを登録するにあたって、追加のコストが一切かからない点です。たとえば、ユーザーは自社の管理対象ラップトップとスマートフォンの両方から登録を行うことができます。
従業員の全ユーザーが複数のデバイスで複数のフィッシング耐性のある要素（Okta Verifyのインストール）に登録すると、ヘルプデスクを必要とするアカウント回復イベントの数が大幅に減少します。仮にユーザーが一方のデバイスを紛失したり、デバイスが反応しなくなったりした場合でも、もう一方のデバイス（例：ノートPCに対してスマートフォンなど）や外部セキュリティキーに登録されたフィッシング耐性のある強力な認証要素が手元に残っているため、それらを使用して新しい代替のデバイスを自ら登録できます。
その結果、サインインページに「パスワードをお忘れの場合」のリンクを配置する必要がなくなり、制限の緩い脆弱なアカウント管理ポリシーによって生まれるリスクを抑えることができます。
インジケーター
上記で取り上げた一連の攻撃アクティビティ（クラスター）に関連するインジケーター（IOC）は、Oktaのお客様のセキュリティ担当者向けに以下のページで提供されています。
https://security.okta.com/?product=oktathreatintelligence
推奨事項
ATT&CKのテクニック | 戦術 | 徹底した制御 |
|---|---|---|
T1590 / T1591 | 偵察 | 従業員ユーザーのリカバリー操作を、認証済みユーザーの設定画面の範囲内に制限する。従業員ユーザー組織がセルフサービスリカバリー（「パスワードをお忘れの場合」フロー）をサポートするよう設定されている場合は、Oktaのネットワークゾーン機能を使用し、サインインページにアクセス可能なIPアドレス範囲を既知または信頼できるネットワークに制限することを検討する。 |
T1583 / T1584 | リソース開発 | 拡張ダイナミックゾーン（Enhanced Dynamic Zones）を使用して、既知の匿名化サービスやプロキシからのリクエストを拒否する。 |
T1566 / T1598 | フィッシング / ビッシング | Okta FastPass、パスキー、スマートカードなどの強力な認証要素にユーザーを登録し、ポリシーでフィッシング耐性を強制する。ヘルプデスク担当者がユーザーに連絡する際の本人確認方法を確立・周知し、社内に浸透・定着させる。認証要素の変更権限を制限するOktaのアカウント管理ポリシーを適用する。身元確認後のアクセス復旧手段として、一時的なアクセスコードを推奨方式として適用する。 |
T1078 | 有効なアカウント（初期アクセス） | Oktaの認証ポリシーを使用して、設定可能な一連の前提条件に基づきユーザーアカウントへのアクセスを制限する。機密性の高いアプリケーションへのアクセスは、エンドポイント管理ツールで管理され、エンドポイントセキュリティツールで保護されているデバイスに限定することを推奨する。 |
T1621 | MFAリクエストの生成 | Okta FastPass、FIDO2 WebAuthn、スマートカードなどの強力な認証要素にユーザーを登録し、ポリシーでフィッシング耐性を強制する。 |
T1098.005 | アカウントの不正操作 — デバイス登録 | 認証要素の変更権限を制限するOktaアカウント管理ポリシーを適用する。 |
Nick Connollyが本記事に寄稿しました。
