Huntressは2026年上半期にパスワードスプレー攻撃が155倍に増加したことを観測しました。ブルートフォース自体は目新しい手口ではありませんが、今回の急増を後押ししている工夫は新しいものです。
この急増の大きな要因となったのが、Microsoftの Azure CLI(管理者がAzureおよびEntraのリソースを管理する際に使うコマンドラインツール)を標的としたキャンペーンです。この通信は、インターネットホスティングプロバイダーであるLSHIY LLCが管理するIPv6アドレス範囲から発信されていました。
キャンペーン自体は数か月前から始まっていましたが、6月中旬の2週間だけでも、Huntressはこのキャンペーンに関連する8,100万件以上のログイン試行と78件のアカウント侵害を観測しています。
時代に取り残された認証フロー
典型的なパスワードスプレー攻撃は、おおむね次のようなパターンをたどります。
-
1. 偵察: 攻撃者はLinkedIn、企業サイト、データ漏洩ダンプ、フィッシングなどを通じて有効なユーザー名を収集し、標的リストを作成します。
-
2. パスワードリストの作成: 攻撃者は、漏洩済みのパスワードや「Password123」のようなよくあるパスワード、会社名の派生パターン、季節にちなんだ単語などを集めた短いリストを用意します。
-
3. アカウント群へのスプレー: 攻撃者は標的リスト上の全アカウントに対して1つのパスワードを試します。アカウントロックの閾値に注意しながら、次のパスワードに移る前に間隔を空ける「低速・慎重」なアプローチを取ります。
-
4. 足がかりの獲得: アクセス権を得た場合、攻撃者は横展開、ビジネスメール詐欺(BEC)、データ窃取、さらなる認証情報の窃取へと移行します。
LSHIYキャンペーンは、大規模なパスワードスプレーと、過去の漏洩で流出したまま一度もローテーションされていない有効なユーザー名・パスワードの組み合わせの再利用を組み合わせたものでした。これにより、成功した1回の試行が通常の総当たりよりもはるかに価値の高いものになっていました。
攻撃者はさらに、OAuth 2.1で非推奨となったレガシーなOAuthグラントである「Resource Owner Password Credentials(ROPC)」も悪用しました。ROPCは元々、アプリケーションが直接認証方式からOAuthへ移行する際の橋渡しとして導入されたものです。
ROPCはMFAやSSOといった最新の認証フローに対応していません。その代わりにユーザー名とパスワードを直接/tokenエンドポイントへ送信するため、対話的なMFAの確認は発生しません。攻撃者にとっては、まだ使い回されている有効なパスワードさえあれば、そのままアクティブなセッションを獲得できてしまうわけです。
ここで重要なのは、侵害された企業の多くが条件付きアクセスポリシー(CAP)を通じて多要素認証(MFA)を導入していたにもかかわらず、攻撃者が悪用したこの特定の認証フローをMFAの適用対象としてカバーしていなかった点です。
Huntressのプリンシパル脅威インテリジェンス・インシデントコマンダーであるAndrew “Spike” Brandt氏は、次のように述べています。
「これを認可(authorization)の仕組みと呼んではいますが、技術的にはなりすまし(impersonation)の手段だと言えます」
Huntressは、LSHIYキャンペーンに関連するログイン成功の後に、侵害後の活動は確認していません。HuntressのスタッフプロダクトマネージャーであるRich Mozeleski氏は、攻撃者はダークウェブでの転売に向けて認証情報の有効性を検証していた可能性があると見ています。
LSHIYはその後、元のIPアドレス範囲からの攻撃を停止し、攻撃者が同社のBring Your Own IP(BYOIP)サービスを利用していたことを確認しました。
IPv6のBYOIP乱用祭り
BYOIPは、ISPの顧客が自ら保有するIPアドレス範囲を使い、そのプロバイダー経由でトラフィックをルーティングできる正規のサービスです。BYOIPを使えば攻撃者はIPアドレス範囲やプロバイダーを次々と切り替えられるため、ブロックや検知が難しくなります。この柔軟性は、IPベースの検知やアカウントロックアウトの制御を回避する助けにもなります。
LSHIYキャンペーンによる攻撃は、IPv6アドレス範囲2a0a:d683::/32から発信されていました。IPv6は攻撃者に膨大なアドレスのプールを与えるため、防御側が少数のIPをブロックするだけでは対処しきれなくなります。
LSHIYが元の活動を停止させた後、スプレー攻撃はまずFranTechがホストするIPv6アドレス範囲へと移行しました。その後は3xK TechによるIPv4を使った活動も確認されています。プロバイダーの切り替えが容易であることから、防御側にとってはインフラのブロックがおなじみの「モグラ叩き」状態になってしまいます。
こうした仕組みはプロバイダー間で簡単に乗り換えられるため、防御側にとってはおなじみの「モグラ叩き」的な脅威ハンティングの状況を生み出しています。
「範囲の甘さ」が弱点
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に登録する →
組織の環境を守る責任を担う方々のために設計された、リアルタイムの脅威インテリジェンスと技術教育で、自組織の防御態勢を一段階引き上げましょう。
