Microsoft 365環境へ8,100万回超のログイン試行-大規模パスワードスプレー攻撃|セキュリティニュースのセキュリティ対策Lab

投稿日時: 2026年07月06日更新日時: 2026年07月06日

マネージド・サイバーセキュリティ企業Huntressは2026年6月30日、Microsoft AzureのコマンドラインインターフェースAzure CLIを標的にした大規模かつ自動化されたパスワードスプレー攻撃を観測していると公表しました。

攻撃は香港・中国武漢に拠点を持つインターネットインフラ事業者LSHIY LLCが管理するIPv6アドレス帯から発信されており、2026年6月12日から26日までの2週間でHuntressの顧客に対して8,100万回超のログイン試行が記録され、64組織にまたがる78件のMicrosoftアカウントが実際に侵害されました。

今回のサイバー攻撃で特筆すべきは、被害組織の多くがConditional Access Policy(CAP)による多要素認証(MFA)をすでに導入していたにもかかわらず、その設定が攻撃者の使用した認証フローをカバーしていなかったために回避されてしまった点です。MFAを導入していれば安全という前提そのものを問い直す必要がある事例といえます。

サマリー

Huntressが2026年6月12〜26日の2週間で観測。8,100万回超のログイン試行のうち78件のMicrosoftアカウント(64組織)が侵害された
攻撃者は過去の情報漏えいで流出したまま更新されていないユーザー名・パスワードの組み合わせをAzure CLIに対して試行。有効な組み合わせを見つけるとOAuthのROPC(Resource Owner Password Credentials)フローで認証を完了させる
ROPCはOAuth 2.1で非推奨とされた古いフローで、パスワードを/tokenエンドポイントに直接送信するためMFAやSSOなど最新の認証フローに対応しない。結果としてMFAプロンプトが一切表示されずに認証が完了してしまう
6月22日には1日で23組織・30アカウントが侵害される急増が発生。このうち15組織はConditional Access PolicyでMFAを設定していたが、対象アプリの範囲・対象ユーザーグループ・信頼済みの場所の判定・レポート専用モードなどの設定不備により、攻撃で使われたAzure CLIのROPCサインインをカバーできていなかった
侵害を受けた組織のうち8組織はMFAポリシーそのものが未設定だった
Huntressは過去6か月でクレデンシャルスプレー攻撃の量が155倍以上に増加したと報告。1テナントあたり月平均1,964回の失敗ログインを記録している
有効な対策として、Conditional Accessで「全ユーザー・全クラウドアプリ・全クライアントアプリ種別」を対象にMFAを無条件で要求する設定、userStrongAuthClientAuthNRequiredによるROPCフローのブロック、Azure CLIアプリケーションの非管理者ユーザーへの制限が挙げられる

項目	内容
観測主体	Huntress
観測期間	2026年6月12日〜26日(2週間)
総ログイン試行回数	8,100万回超
侵害されたアカウント数	78件
影響を受けた組織数	64組織
攻撃急増日	2026年6月22日(1日で23組織・30アカウント侵害)
悪用された認証フロー	OAuth ROPC(Resource Owner Password Credentials)
標的アプリケーション	Microsoft Azure CLI
攻撃元IPv6アドレス帯	2a0a:d683::/32
攻撃元組織	LSHIY LLC(AS32167・AS955)
LSHIYの登録拠点	香港・中国武漢・米ニューヨーク(シェアオフィス)
クレデンシャルスプレー攻撃の増加率	過去6か月で155倍超(Huntress全顧客ベース)
テナントあたり月間失敗ログイン数	平均1,964回(中央値804回)

1 攻撃の全体像-何が起きたか
2 Azure CLIとROPC認証フローが悪用された仕組み
3 MFAを導入していた組織が回避された理由
4 攻撃元インフラ-LSHIY LLCとIPアドレス地理判定の不整合
5 過去6か月で155倍に急増するクレデンシャルスプレー攻撃
6 情報システム部門への対応策
7 出典

攻撃の全体像-何が起きたか

Huntressは過去数週間にわたり、Microsoft 365環境を標的とした認証情報・トークンスプレー攻撃の波を追跡してきました。この動きはRedditの複数のスレッドでもコミュニティから報告されるなど、広範囲で観測されていた現象です。数百万件規模の失敗ログイン試行が発生していたにもかかわらず、当初確認された侵害件数は1日あたり数件程度にとどまっていました。6月12日から21日までは、1日あたり2〜4アカウント程度の緩やかな侵害が続いていましたが(6月19日のみ12アカウントを記録)、6月22日に状況が一変します。この日、23組織にまたがる30アカウント(Huntressが「アイデンティティ」と呼ぶ単位)が一気に侵害されました。

最終的に6月12日から26日の2週間で、64組織・78アカウントが侵害され、この期間の総ログイン試行回数は8,100万回を超えました。トラフィックの大部分はAS32167という自律システム番号(ASN)に由来しており、これはインターネットインフラ・ホスティングプロバイダーのLSHIY LLCに紐づいています。

Azure CLIとROPC認証フローが悪用された仕組み

攻撃者が使用した手口の核心は、Azure CLI経由のROPC(Resource Owner Password Credentials)フローの悪用です。Azure CLIはAzureのクラウドリソースを管理するためのコマンドラインツールで、仮想マシンの管理・アプリケーションのデプロイ・データベース管理・クラウド運用の自動化などに使われます。攻撃者はまず、過去の情報漏えいで流出したものの一度もローテーションされていない古いユーザー名・パスワードの組み合わせを、Azure CLIに対して大量に試行しました。

有効な組み合わせが見つかると、攻撃者はOAuth 2.0のROPCというグラントタイプを使って認証を完了させます。ROPCはOAuth 2.1では非推奨とされた古い認証フローで、テナントの/tokenエンドポイントにユーザー名とパスワードを直接送信し、正しい認証情報が提供されると新しいユーザー委任トークンを即座に発行するという仕組みです。この方式が問題視される理由の一つが、MFAやSSOのようなモダンな認証フローに対応していないことです。今回のキャンペーンで確認されたとおり、ROPCはパスワードを/tokenエンドポインへ直接送信するため、対話的なMFAプロンプトが一切表示されないまま認証が完了してしまいます。

MFAを導入していた組織が回避された理由

今回の事案で最も重要な発見は、6月22日の急増時に侵害された23組織のうち15組織がConditional Access Policy(CAP)でMFAを実装・強制していたという事実です。これらの組織は自分たちがMFAで保護されていると認識していましたが、さまざまな理由でMFAが今回の攻撃に対して発動しませんでした。Huntressが確認した具体的な設定不備は以下のとおりです。

一部の組織では、MFAが「全クラウドアプリ」ではなく特定のアプリケーションのみに適用されていました。例えばMicrosoft管理ポータルに対してのみMFAを強制していた組織では、攻撃者が使用したAzure CLIのログインがそのポリシーの対象外になっていました。別の組織では、MFAが管理者などの特定ユーザーグループにのみ有効化されており、実際に侵害されたユーザーはそのグループの範囲に含まれていませんでした。また、複数の組織ではMFAが「信頼できない場所からのみ」要求される設定になっており、地理的位置情報を誤って「米国」と判定された攻撃者のIPアドレスがこの制限を回避していました。さらに2件のケースでは、MFAポリシーが「レポート専用モード」のまま運用されており、実質的に一度も強制されていませんでした。

この攻撃に影響を受けた組織のうち8組織はそもそもMFAポリシーが一切設定されていませんでした。Huntressは「今回のキャンペーンで攻撃者がMFA設定済みの組織にも侵入できたことをもって、MFAが機能しないという結論を導くべきではない。むしろ組織はMFAポリシーがこうしたインシデントで使われた認証フローに対して適切に構成されているかを確認すべきだ」と強調しています。

攻撃元インフラ-LSHIY LLCとIPアドレス地理判定の不整合

今回の攻撃の発信元は、IPv6アドレス帯2a0a:d683::/32です。この帯域に対応するIPv4アドレスは存在しません。この帯域はLSHIY LLCという事業者に帰属しており、同社は香港と中国武漢の2つの工業団地、および米ニューヨーク・ブロードウェイ42番のシェアオフィス「TKO Suites」にビジネス住所を登録しています。TKO Suitesは特定の業種に限らない共有オフィス賃貸スペースであり、そこに拠点を置く企業の実際の所有者は非公開になっているのが実情です。

LSHIYは2つの異なるASNを運用しており、AS32167(2021年6月14日登録)に加えてAS955(2022年6月22日登録)も保有しています。サードパーティの情報筋によれば、両ASNに紐づくIPv6帯域は中国を発信元としているとされていますが、Huntressの調査では一部のIPアドレスが米国(ネブラスカ州)として地理判定されるという不整合も確認されています。この地理情報のブレによって、一部のインシデントは異常なIPアドレスからのログインとして検知される一方、条件付きアクセスの「信頼できる場所」判定を回避する結果にもなりました。実際、教育セクターの被害組織の一つでは、SOCが中国由来と判定されたログインイベントを確認しています。

Huntressは同社の悪用報告ポータルを通じてLSHIYへ活動内容を報告済みですが、この記事の公開時点で回答は得られていません。

過去6か月で155倍に急増するクレデンシャルスプレー攻撃

Huntressは今回のLSHIYキャンペーンについて、より大きなトレンドの一部として位置づけています。過去6か月間で、Huntressの全顧客ベースにおけるクレデンシャルスプレー攻撃の量は155倍以上に増加しました。特に2026年5月末から6月初旬にかけて急増しており、Huntressが保護するテナントあたりの月間失敗ログイン試行数は現在平均1,964回に達しています(中央値は804回)。攻撃対象の選定は業種や事業規模とは無関係で、もっぱら漏えい済みパスワードの組み合わせリストにおけるパスワードの出現頻度に基づいているとみられます。

この傾向は、当サイトで既報のFortiBleedキャンペーンや生成AIを悪用したFortiGate侵害キャンペーンとも軌を一にしています。攻撃者が過去の漏えいデータベースと自動化ツールを組み合わせ、大規模かつ低コストで認証情報を試行する攻撃モデルが、Fortinet製品に限らずMicrosoft 365環境にも同様に適用されている構図です。

情報システム部門への対応策

Huntressが示す対策の中で最も重要なのは、Conditional Access Policyの設計を根本から見直すことです。MFAまたはブロックを「全ユーザー・全クラウドアプリ・全クライアントアプリ種別」に対して無条件で適用する設定に変更することが推奨されています。特に強力なConditional Access設定であるuserStrongAuthClientAuthNRequiredは、クライアント認証レベルで強力な認証を強制し、ROPCフローそのものをブロックする効果があるため、この種の攻撃を根本から失敗させることができます。

次に、Azure CLIアプリケーションへのアクセスを管理者以外のユーザーに制限することも有効な対策です。日常業務でAzure CLIを使う必要のない一般ユーザーに対してこのアプリケーションへのアクセスを許可している場合、それ自体が不要な攻撃対象領域になります。

また、Huntressは「スプレーの量そのものに基づいてアラートを発報しないこと」も推奨しています。スプレー攻撃の量が最も多いテナントは、必ずしも侵害の成功率が高いわけではありません。むしろ有効な認証情報を持つかどうかで優先順位をつけ、実際にログインが成功した(またはROPCフローで有効なトークンが発行された)イベントを優先的に検知・対応する体制の方が実効性が高いという指摘です。

サーバサイド・ネットワークエンジニアとして企業のクラウド基盤の設計に携わってきた経験からいうと、Conditional Access Policyは一度設定すれば終わりというものではなく、企業が利用するアプリケーションやクライアントの種類が増えるたびに保護対象が漏れていないかを継続的に点検する必要があります。Microsoft自身がAzureへのMFA必須化を段階的に進めてきた経緯からも分かるとおり、Azure CLIやPowerShell、IaCツールのような「対話的ではない」経路は見落とされやすく、今回の攻撃はまさにその隙を突いたものです。自組織のConditional Access Policyの適用範囲を「All Cloud Apps」ベースで設定できているか、レポート専用モードのまま放置されているポリシーがないかを、この機会に棚卸しすることを強くお勧めします。