LSHIYによるパスワードスプレー攻撃、Microsoft 365アカウントを標的に8100万回のログイン試行

MicrosoftのAzureコマンドラインインターフェースを狙った大規模な自動パスワードスプレー攻撃が、わずか2週間で8100万回を超えるログイン試行を記録しました。

Huntressの研究者らは、この攻撃をインターネットインフラプロバイダーLSHIY LLC(AS32167)が管理するIPv6アドレス範囲まで追跡しました。

2026年6月12日から6月26日にかけて、脅威アクターは64組織にまたがる少なくとも78件のMicrosoftアカウントを侵害し、先週には攻撃の成功率が急激に上昇したことが確認されています。

このキャンペーンは当初、6月12日から21日にかけて1日あたり2件から4件のアカウント侵害という緩やかなペースで始まりましたが、6月22日には23の企業にまたがる30件のアカウントが1日で侵害されるという急激な増加を見せました。

この急増はより大きな傾向の一部であり、Huntressは過去6か月間で顧客基盤全体における認証情報スプレー攻撃の量が155倍に増加したことを観測しています。特に5月下旬から6月上旬にかけて攻撃が急激に激化しました。

攻撃者の主な手口は、以前に流出し更新されていない認証情報を、OAuth 2.0のResource Owner Password Credentials(ROPC)フローを通じて再利用するというものでした。ROPCは非推奨のグラントタイプで、ユーザー名とパスワードをテナントの/tokenエンドポイントに直接送信するため、対話型のMFAプロンプトが発生しません。

これが問題となるのは、多くの被害組織が条件付きアクセスポリシー(CAP)を通じてMFAを導入していたにもかかわらず、この特定のレガシー認証経路をカバーするようには設定されていなかったためです。

一部のログイン活動では位置情報データに矛盾も見られ、特定のIPアドレスが中国と紐づけられている一方で、別のIPアドレスがネブラスカ州発信と誤って表示されるケースもあり、防御側による検知を複雑にしていました。

6月22日の急増を分析したところ、影響を受けた23の企業のうち15社がCAPによるMFAを導入していたにもかかわらず、設定上の不備により攻撃を防げなかったことが判明しました。

一部のケースでは、MFAの適用範囲がMicrosoft管理ポータルなど特定のアプリケーションに限定されており、「すべてのクラウドアプリ」を対象としていなかったため、Azure CLIへのサインインが対象から漏れていました。また別の組織では、管理者など特定のユーザーグループのみにポリシーを適用していたため、侵害されたアカウントが完全に対象外となっていました。

複数の企業では、信頼できない場所からのアクセスに対してのみMFAを要求する設定になっており、攻撃者が偽装したIPアドレスによってこの条件をすり抜けられてしまいました。さらに2つの組織では、ポリシーがレポートのみモードに設定されており、MFAは技術的には導入されていたものの、実際には強制されていませんでした。特筆すべきは、被害を受けた企業のうち8社にはそもそもMFAポリシー自体が存在しなかったという点です。

攻撃トラフィックの発信元は、LSHIY LLCに登録されたIPv6アドレス範囲2a0a:d683::/32でした。同社は香港、武漢、そしてニューヨークのシェアオフィスに事業所住所を構えるインフラプロバイダーで、実質的な所有関係は不透明なままです。

LSHIYはAS32167とAS955という2つの自律システム(AS)を運用しており、いずれもサードパーティのテレメトリによれば中国を発信元としているとされています。Huntressはこの活動をLSHIYの不正利用報告窓口に通報しましたが、本記事執筆時点で応答は得られていません。

セキュリティチームは、MFAさえ導入していれば十分な保護になると考えるのではなく、Azure CLIとROPCを精密なCAP設定が必要な高リスクな攻撃対象と位置づけて扱うべきです。

組織は例外なく、すべてのユーザー、すべてのクラウドアプリ、すべてのクライアントアプリの種類を対象にMFAの適用またはブロックを強制すべきです。また、userStrongAuthClientAuthNRequired設定を有効にして、クライアントレベルでの強力な認証を強制し、ROPCフローを完全にブロックすることも推奨されます。

Azure CLIアプリケーションへのアクセスを管理者以外のユーザーに制限すること、レガシー認証プロトコルを無効化すること、そしてMicrosoftの「What If」ポリシーシミュレーターを使ってCAPの動作を定期的にテストすることも、こうした穴を塞ぐのに役立ちます。

また、インシデント対応の優先順位は、スプレー攻撃の単純な試行回数ではなく、認証情報の有効性に基づいて決定すべきです。というのも、最も激しく標的にされたテナントほど、実際には侵害されていない可能性が高いためです。

翻訳元: https://cyberpress.org/lshiy-password-spray-campaign/

ソース: cyberpress.org