ハッカーがMFAの脆弱性を悪用し、パスワードスプレー攻撃が155倍に急増

Huntressは、2026年上半期にパスワードスプレー攻撃が155倍に増加したことを確認しました。ブルートフォース攻撃自体はもはや珍しくありませんが、この急増の背景にある新たな動きが注目されます。

その主な要因の一つは、管理者がAzureおよびEntraリソースの管理に使用するコマンドラインツールであるMicrosoftのAzure CLIを標的としたキャンペーンでした。このトラフィックは、インターネットホスティングプロバイダーであるLSHIY LLCが管理するIPv6アドレス範囲から発信されていました。

このキャンペーンは数ヶ月前から始まっていましたが、6月中旬の2週間だけで、Huntressは8,100万件以上の関連するログイン試行と78件のアカウント侵害を検知しました。

時代に取り残された認証フロー

典型的なパスワードスプレー攻撃は、おなじみのパターンに従います：

1. 1. 偵察：攻撃者は、LinkedIn、企業のウェブサイト、データ漏洩ダンプ、フィッシングを通じて有効なユーザー名を収集し、標的リストを作成します。

2. 2. パスワードリストの作成：攻撃者は 、漏洩したパスワード、「Password123」などの一般的なパスワード、企業名のバリエーション、季節的な用語などを組み合わせた短いリストを作成します。

3. 3. アカウントへのスプレイ：攻撃者は、ターゲットリスト上のすべてのアカウントに対して、1つのパスワードを試行します。ロックアウトの閾値に注意を払いながら、低頻度かつ緩やかなアプローチで、次のパスワードに移るまで待機します。

4. 4. 足場を固める：アクセス権を取得した場合 、攻撃者は横方向の移動、ビジネスメール詐欺（BEC）、データ流出、またはさらなる認証情報の窃取へと移行します。

LSHIYキャンペーンでは、パスワードスプレー攻撃の規模と、過去の侵害事件で流出し、一度も変更されていない有効なユーザー名とパスワードの組み合わせの再利用を組み合わせていました。これにより、成功した1回の試行が、通常の推測攻撃よりも高い価値を持つものとなりました。

また、攻撃者は、OAuth 2.1 で非推奨となったレガシーな OAuth グラントである「リソース所有者パスワード認証情報（ROPC）」を悪用しました。ROPC は、アプリケーションが直接認証方式から OAuth へ移行するのを支援するために導入されました。 

ROPCは、MFAやSSOのような最新の認証フローをサポートしていません。その代わりに、対話型のMFAプロンプトを表示することなく、ユーザー名とパスワードを直接/tokenエンドポイントに送信します。攻撃者にとっては、依然として有効な再利用されたパスワードが、アクティブなセッションにつながる可能性があります。

これが問題となるのは、侵害を受けた企業の多くが条件付きアクセスポリシー（CAP）を通じて多要素認証（MFA）を導入していたにもかかわらず、攻撃者が利用したこの特定のフローをカバーするようにMFAが設定されていなかったためです。

Huntressのプリンシパル・スレット・インテリジェンス・インシデント・コマンダー であるアンドルー・“スパイク”・ブラント氏は、次のように述べています。

「私たちはこれを『認証手法』と呼んでいますが、技術的には『なりすまし手法』です。」

Huntressは、LSHIYキャンペーンに関連するログイン成功の後、侵害後の活動は確認されませんでした。Huntressのスタッフプロダクトマネージャーであるリッチ・モゼレスキ氏は、攻撃者がダークウェブでの転売を目的として認証情報を検証していた可能性があると推測しています。

LSHIYはその後、元のIPアドレス範囲からの攻撃を遮断し、攻撃者が同社のBYOIP（Bring-Your-Own-IP）サービスを利用していたことを確認した。

IPv6のBYOIPパーティー

BYOIPは、ISPの顧客が自ら所有するIP範囲を使用して、プロバイダーを経由してトラフィックをルーティングできるようにする正規のサービスです。BYOIPを利用することで、攻撃者はIP範囲やプロバイダー間を移動できるようになり、ブロックや検知が困難になります。この柔軟性により、攻撃者はIPベースの検知やアカウントロックアウト対策をかいくぐることが可能になります。

LSHIYキャンペーンによる攻撃は、IPv6アドレス範囲2a0a:d683::/32から発信されていました。IPv6は攻撃者に膨大なアドレスプールを提供するため、防御側が少数のIPアドレスのブロックに依存することは困難になります。

LSHIYが当初の活動を停止させた後、スプレイ攻撃の試みはまずFranTechがホストするIPv6アドレス範囲へと移行しました。その後の活動は、IPv4を使用する3xK Techから確認されました。プロバイダーを切り替えるのが容易であるため、インフラのブロック対策は防御側にとって、お馴染みの「モグラたたき」のような問題となってしまいます。

こうした構成はプロバイダー間で容易に切り替えられるため、防御側にとってはお馴染みの「モグラたたき」のような脅威ハンティングのシナリオが生じることになる。

対象範囲が弱点

LSHIYキャンペーンは、特定の業界を標的にしているようには見えません。その代わりに、パスワード管理や多要素認証（MFA）のポリシーに、攻撃者が悪用できる隙間がある組織を標的にしています。

Huntressは、影響を受けた23社を分析しました。そのうち8社はMFAを導入していませんでした。残りの15社については、ポリシーが特定のアプリやユーザーグループに限定されていたり、信頼された場所を前提としていたり、あるいは「報告のみ」モードのままであったため、攻撃者のサインイン試行に対してMFAが適用されませんでした。

この調査結果から、MFAを導入していても、組織は条件付きアクセスポリシーの適用範囲と施行方法を再検討する必要があることが示されています。ポリシーがMFAを要求しているように見えても、特定のユーザー、アプリケーション、またはサインイン方法が対象外となっている場合があります。

正当なユーザーを締め出さずに条件付きアクセスを微調整することは困難であり、その難しさこそが、攻撃者にとってこの手法が依然として有効である理由の一部となっている。 

攻撃の源を断つ

以下の対策により、これらの攻撃が利用している脆弱性を塞ぐことができます：

• パスワード管理の徹底、パスワードレス方式の導入を検討する

• システムから ROPC（またはそれに依存するアプリ）を無効化する

• 管理者以外のユーザーに対するAzure CLIアプリケーションの使用を制限する

• 攻撃の集中度（スプレー量）に基づいて対応の優先順位を付けないでください。最も集中攻撃を受けているテナントは、実際には侵害されている可能性が最も低い場合が多いからです。代わりに、認証情報の有効性に基づいて優先順位を付けてください。

• すべてのユーザー、すべてのクラウドアプリ、およびすべてのクライアントアプリタイプに対して、例外なく MFA を必須とする。レガシーな ROPC グラントを含め、MFA 要件を満たせない認証方法をブロックする。

• userStrongAuthClientAuthNRequiredのような強力な条件付きアクセス設定を使用して、クライアントレベルで強力な認証を強制し、ROPC をブロックしてください。 

Mozeleski氏が述べたように、「適切に構成・管理された条件付きアクセスは、まさに超能力のようなものです」。

攻撃者は、防御側がブロックするよりも速くプロバイダーやIP範囲を切り替えることができます。パスワードだけではドアを開けられないようにすることで、これを阻止しましょう。つまり、パスワードを強力に保ち、Azure CLIへのアクセスを必要な人に限定し、すべてのユーザー、クラウドアプリ、およびクライアントアプリの種類に条件付きアクセスを適用します。

Tradecraft Tuesday：製品も営業トークもなし。ただハックだけ。

「Tradecraft Tuesday」は、サイバーセキュリティの専門家に対し、最新の脅威アクター、攻撃ベクトル、および対策戦略に関する詳細な分析を提供します。毎週開催される各セッションでは、最近のインシデントに関する技術的な解説、マルウェアの動向に関する包括的な分析、そして最新の侵害指標（IOC）が紹介されます。

参加者が得られるもの：

• 新たな脅威キャンペーンやランサムウェアの亜種に関する詳細なブリーフィング
• 証拠に基づいた防御手法と是正技術
• インシデント対応に関する知見を得るための、Huntressアナリストとの直接的な対話
• 実用的な脅威インテリジェンスおよび検知ガイダンスへのアクセス

「Tradecraft Tuesday」へ登録する →

組織の環境保護を担う責任者の皆様のために特別に設計された、リアルタイムのインテリジェンスと技術トレーニングを通じて、防御体制を強化しましょう。

Huntress Labsによる提供・執筆。