SSPRから開始される手口

SSPRは、セルフサービスパスワードリセットです。
いろいろな仕組みを利用する際に、パスワード認証を利用することになります。
そして、この機能の広がりとともに、パスワードを忘れたしまった場合に対策する機構の実装も広がります。
このパスワードリセット機能が悪用されているという事例がありました。

今回話題にするのはStorm-2949の事例です。
Storm-2949はMicrosoft が追跡している脅威アクター名です。
まだ全体の観測された活動の量の蓄積が十分でなく、複数ベンダーで統一された通称が付与されるほど特定された状態になっていない脅威アクターです。
彼らの活動のなかで、SSPRが悪用されています。
流れを見てみましょう。

• 偽のITサポート担当者になる
  脅威アクターは偽のITサポート担当者として活動を開始します。
  ターゲットにすることにした組織の人物にITサポート担当者として連絡します。
  攻撃者が標的の従業員のアカウントのパスワードリセットを開始し、その後、被害者をだまして多要素認証（MFA）のプロンプトを承認させます。
• 攻撃者だけがそのアカウントを利用できる状態にする
  パスワードリセットのプロセスを承認するように操作をされてしまった瞬間から、攻撃者はその標的の人物のアカウントを操作できる状態になります。
  攻撃者は標的のアカウントでMFAを削除します。
  そのまま攻撃者は標的のアカウントでMFAを設定します。
  ここで攻撃者は対象アカウントのMFAを設定した正規の操作者として活動できる状態になってしまいます。
• データを集める
  システムにアクセスができるようになった攻撃者は情報を集めます。
  集めた情報は売ることに利用されるかもしれませんが、別の目的が主体と考えられます。
  各種情報を収集し、さらなる価値を持ったユーザに関する情報や、価値のある情報の保存されたシステムに関する情報を探します。
• 侵害範囲を広げる
  集めて解釈した情報をもとに侵害範囲を広げます。
  取得済みの認証情報を使い、Azureへの侵害に移行します。
  侵害されたユーザの特権的なAzure RBAC権限を利用することで、FTP、Web Deploy、Azureアプリサービスを管理するためのKuduコンソールをデプロイできる認証情報を取得します。
  攻撃者はファイルシステムを閲覧したり、環境変数を確認したり、アプリのコンテキスト内でリモートからコマンドを実行したりすることができる状態になっています。
  攻撃者はAzure Key Vaultの設定も変更し、それにもアクセスし、保存された機密情報を取得します。
  Azure VMも勝手に使い、不正な管理者アカウントの作成、リモートスクリプトの実行、認証情報の窃盗を展開します。

これらは実際に観測された脅威活動です。
単なる概念実証の情報ではありません。
この事例のレポートを公開しているマイクロソフトは、対策として認証に関連する各種サービスのアクセス許可を設定することやログの保管やその監視などを実行することを推奨しています。
そして、フィッシング耐性のあるMFAを利用することを推奨しています。
フィッシング耐性のあるMFA自体は、そうでないMFAより有用であることは確かです。
しかし、この事例のように、そもそもとしてソーシャルエンジニアリングを組み合わせて脅威活動を展開されてしまうと、フィッシング耐性のあるMFAを使っているから安心ということにはなりません。
YubiKeyなどのFIDO2準拠の安全な機構を使っていても、ソーシャルエンジニアリングでパスワードリセットを誘導されてしまえば侵害を防ぐことはできないのです。
結局は人間の部分が最後の砦ということになります。
この点、よく認識しておくことが必要ですね。

How Storm-2949 turned a compromised identity into a cloud-wide breach

https://www.microsoft.com/en-us/security/blog/2026/05/18/storm-2949-turned-compromised-identity-into-cloud-wide-breach/