Microsoft 365 ユーザーを狙うパスワード窃取キャンペーン：8,100 万件のログイン試行を観測

Massive Password Stealing Attack Targeting Microsoft 365 Users With 81 Million Login Attempts

2026/07/01 CyberSecurityNews — Microsoft の Azure CLI およびレガシー OAuth フローを積極的に悪用する、大規模な自動化パスワード・スプレー・キャンペーンにより、多要素認証 (MFA) を導入している組織においても Entra ID アカウントが侵害されている。Huntress が追跡しているのは、Microsoft 365 および Azure CLI のログインを標的とする、パスワードおよびトークンに対する継続的なスプレー・キャンペーンである。この活動は、2026年6月12日から 6月26日にかけて急増した。

この 14日間に、攻撃者は Huntress の顧客テナントに対して8,100 万件を超えるログインを試行し、64 の組織に属する少なくとも 78 件の Microsoft アカウントの侵害に成功した。

当初、日ごとの侵害数は、1 日あたり 2～4 アカウントという低水準に留まっていた。しかし、6月22日には 23 の企業に属する 30 のユーザー ID へ急増し、このキャンペーンにおける明確なエスカレーションが認識された。

この活動は、広範な傾向の一部である。Huntress によると、同社の顧客基盤全体における認証情報スプレーの件数は、過去 6ヶ月で 155 倍超に増加した。現在の平均値は、テナントあたり月間約 1,964 件の攻撃試行であり、中央値は 804 件である。

業種や垂直マーケットが標的にされたわけではなく、既存のコンボ・リストに含まれるパスワードの普及度に応じて実行されているように見える。それが示すのは、過去に漏洩したがローテーションされていない認証情報に対する、機会主義的な悪用である。

攻撃トラフィックの大部分は、自律システム AS32167 の下でアナウンスされ、インターネット・インフラ・プロバイダである LSHIY LLC に帰属する IPv6 アドレス “2a0a:d683::/32” から発信している。LSHIY は、2021年6月に登録された AS32167 と、2022年6月に登録された AS955 の、少なくとも2つの ASN を運用している。サードパーティのテレメトリは、これらの IPv6 プレフィックスを一貫して中国由来と関連付けている。

LSHIY の法人登録記録により、香港および武漢の工場所在地ならびに、ニューヨークの 42 Broadway にある共有オフィス・スペースが明らかにされているが、実際の運用主体は不明である。確認された活動に関して、Huntress は LSHIY に対して不正使用報告を提出したが、現時点では応答を受け取っていない。

脅威アクターは、過去の侵害で露出した古いユーザー名とパスワードの組み合わせを再利用し、Azure CLI が使用する OAuth の Resource Owner Password Credentials (ROPC) フローを介して検証している。

OAuth 2.1 で非推奨となった ROPC (Resource Owner Password Credentials) は、ユーザー名とパスワードをトークン・エンドポイントで直接交換し、対話型の認可ステップを経ずに、ユーザー委任のアクセス・トークンを発行する。通常において、Conditional Access Policies (CAP) は認可エンドポイントで MFA を強制するため、ROPC は設定が不適切なポリシーがバイパスされる可能性がある。その結果、MFA のチャレンジなしにトークンが正常に発行されてしまう。

Huntress が確認したのは、影響を受けた多くのテナントで MFA および CAP が展開されていたが、重大な設定上の欠陥が存在していたことだ。一般的な失敗の要因として挙げられるのは、特定のクラウド・アプリのみに限定された MFA／管理者などの特権グループに対する MFA のみの強制／信頼されない場所に対してのみの MFA 適用／レポート専用モードでのポリシーなどである。

複数の事例では、地理的位置情報の不整合により、攻撃元 IP が米国のアドレスとして誤分類されていた。これにより、他のテレメトリが中国に位置付けられていたにもかかわらず、信頼できる場所としてロジックを通過できていた。

Misconfiguration type	Effect on attack	Why it failed against Azure CLI
MFA only for specific apps	Azure CLI sign‑ins not covered	CAP never evaluated Azure CLI as an enforced app.
MFA only for certain groups	Non‑admin identities unprotected	Spray focused on users outside protected groups.
MFA only for non‑trusted locations	Geo‑mislabeled IPs treated as trusted	Inaccurate IP geolocation bypassed location conditions.
Report‑only CAP policies	No actual blocking or prompts	Policies logged events but did not enforce controls.
Legacy ROPC left enabled	MFA not invoked on token endpoint	ROPC never hit the authorization endpoint where CAP runs.

緩和策

Huntress や研究者たちがユーザー組織に対して推奨するのは、Azure CLI および ROPC を高リスクの攻撃対象領域として扱い、それに応じて CAP のコンフィグを調整することだ。

管理者として実施すべきは、すべてのユーザー／クラウド・アプリ／クライアント・アプリに対する MFA の要求もしくは、アクセスの完全なブロックである。また、ROPC ベースのトークン付与を防ぐために、クライアント・レベルで強力な認証を強制する必要がある。具体的には、userStrongAuthClientAuthNRequired 設定の使用などがあるが、可能な場合には、管理者ユーザーに限定した Azure CLI の使用や、専用の CAP ルールを用いた明示的なブロックを行うべきだ。

その他にも、組織にとって必要な対策としては、レガシーな付与および認証プロトコルの無効化／名前付きの場所の厳格化などに加えて、Microsoft の “What If” シミュレータなどのツールを用いた CAP 動作の継続的なテストなどがある。これにより、レポート専用のポリシーや除外されたポリシーを特定できる。

訳者後書：クラウド上の認証基盤を狙い、過去に流出したパスワードを悪用して総当り攻撃を試す大規模キャンペーンにより、多くの組織で管理アカウントが不正に奪われる事態が発生しています。この問題の背景には、対話的な画面を経ずに認証を完了させてしまう古い仕組み (ROPC) の悪用や、多要素認証の設定時に特定の条件や一部の権限だけに限定して適用するといった運用の隙があります。もし対策を怠ると、厳重な守りを固めているつもりでも判定の死角を突かれ、内部のデータや管理権限を完全に掌握される恐れがあります。対応策として、まずは古い認証方式を完全に無効化する必要があります。その上で、例外なくすべての接続に強力な身元確認を求めるよう、セキュリティ設定を厳格に見直すことが大切です。