パスワードスプレー攻撃とは？ブルートフォースとの違い・被害例・対策をわかりやすく解説

「アカウントのパスワードは複雑にしているのに、なぜ不正ログインされたのだろう？」
社内のMicrosoft 365アカウントが突然ロックされる。VPNのアカウントに見知らぬログイン履歴がある。こうしたインシデントの原因として、意外なほど多いのが「パスワードスプレー攻撃」です。

パスワードスプレー攻撃は、よく知られたブルートフォース攻撃とは仕組みが異なります。その違いを理解せずにいると、せっかく導入したアカウントロックの仕組みをすり抜けられてしまいます。

この記事では、パスワードスプレー攻撃の仕組み・ブルートフォースとの違い・実際の被害事例・そして情シス1人でも今日から実践できる対策を、現場目線でわかりやすく解説します。

パスワードスプレー攻撃とは？

パスワードスプレー攻撃（Password Spraying）とは、1つのパスワードを大量のアカウントに対して「ばらまく（スプレーする）」ように試行する攻撃手法です。

通常のアカウントロック機能は「同じアカウントへの連続ログイン失敗」をトリガーとして機能します。ところがパスワードスプレー攻撃は、各アカウントへの試行回数を意図的に1回程度に抑えながら、多数のアカウントに対して「Password1!」「Spring2024!」「CompanyName123」といった予測しやすいパスワードを順番に試みます。

ロックアウト閾値が「5回連続失敗」に設定されていても、各アカウントへ1回ずつ試すだけなので閾値に引っかかりません。まるでスプリンクラーで広範囲に水をまくように、多数の標的を効率的に探索するところからこの名称が付いています。

ブルートフォース攻撃・パスワードリスト攻撃との違い

混同されやすい3種類の攻撃を比較します。

重要な点は、パスワードスプレー攻撃には「流出した認証情報」は不要だということです。攻撃者はターゲット組織の従業員メールアドレス一覧さえ手に入れれば攻撃を開始できます。LinkedInや企業ホームページから収集できるメールアドレスが出発点になります。

攻撃の仕組み——なぜ見つかりにくいのか

パスワードスプレー攻撃が発見しにくい理由は、攻撃のパターンが「通常の業務ログイン」に紛れ込むからです。

1. 時間を分散させる

組織のアカウントロックポリシーが「30分で5回失敗」であれば、攻撃者は30分ごとに別のパスワードを試みます。1日に10個のパスワードを試しても、各アカウントへのログイン試行は散発的にしか見えません。

2. IPアドレスを分散させる

クラウドサービスや複数のプロキシを経由することで、同一IPからの大量リクエストとして検知されることを避けます。Microsoft 365やGoogleワークスペースのような広く使われるSaaSへの攻撃では、正規ユーザーのアクセス元IPと攻撃のIPが混在するため、IPベースの検知が困難になります。

3. ありふれたパスワードを狙う

攻撃者が使うパスワード候補は、毎年発表される「最も使われているパスワードランキング」の上位や、企業名＋年数、季節＋年数などのパターンです。「1000社の従業員に試して1社でも1アカウントでも突破できれば成功」という考え方で攻撃が行われます。

実際の被害事例

パスワードスプレー攻撃は国内外で多数の組織が被害を受けており、特にリモートワーク環境の普及とともに増加しています。

・Microsoft 365・Azure ADへの攻撃: 米CISAおよびFBIが繰り返し注意喚起を出しており、政府機関・医療機関・金融機関が被害を受けています。クラウド移行後にMFAを設定していないアカウントが標的になるケースが多く報告されています。
・VPNゲートウェイへの攻撃: リモートアクセスVPNの認証ポイントに対してパスワードスプレー攻撃を行い、成功後に内部ネットワークへ侵入する手口が多数確認されています。2019年以降のNSA・CISAの共同勧告でも、ロシア系APTグループがこの手法を多用していることが明記されています。
・国内企業のM365アカウント侵害: 国内でも、取引先へのメール詐欺（BEC）の起点として、パスワードスプレー攻撃でメールアカウントが乗っ取られる事例が報告されています。

具体的な防御手順

1. 多要素認証（MFA）の全アカウント適用

パスワードスプレー攻撃への最も効果的な対策は、MFAです。パスワードが突破されても、認証アプリやハードウェアキーによる2段目の認証を通過できなければ、攻撃者はアカウントにアクセスできません。

Microsoft 365やGoogleワークスペースでは、すべてのユーザーにMFAを義務付ける設定が可能です。「MFA未適用のアカウントがあるか」を棚卸しすることが最初の一歩です。パスキー（パスワードレス認証）への移行も長期的な解決策として検討に値します。

# Microsoft 365 の MFA 適用状況をPowerShellで確認する例
# Azure AD PowerShell モジュールが必要
Connect-MsolService
Get-MsolUser -All | Select-Object DisplayName, UserPrincipalName, StrongAuthenticationRequirements | Where-Object {$_.StrongAuthenticationRequirements -eq $null} | Export-Csv mfa-not-enabled.csv -NoTypeInformation
# mfa-not-enabled.csv に MFA 未設定アカウントが出力される

2. スマートロックアウトとサインインログ監視

Microsoft Entra ID（旧Azure AD）のスマートロックアウト機能は、通常の場所からのログイン失敗と、見知らぬ場所からのログイン失敗を区別してロックをかけます。この機能を有効化し、閾値を適切に設定することが重要です。

また、サインインログを定期的に確認し、以下のようなパターンに注意します。

・異常な時間帯のログイン試行: 業務時間外の深夜・早朝のログイン失敗
・複数アカウントへの同一IPからのログイン失敗: 同一送信元から短時間に複数のアカウントへの失敗
・地理的に不自然なアクセス: 普段アクセスしない国や地域からのログイン試行

3. 条件付きアクセスポリシーの設定

Microsoft Entra IDの条件付きアクセスを使うと、「社内ネットワーク外からのアクセスにはMFAを要求する」「特定の国からのアクセスはブロックする」といったポリシーを設定できます。リスクベースのアクセス制御により、疑わしいログインを自動でブロックすることが可能です。

4. パスワードポリシーの見直し

攻撃者が試みるのは「よく使われるパスワード」です。単純な長さや複雑さの要件だけでなく、「よく使われるパスワードのブラックリスト」を適用することが有効です。

Microsoft Entra IDにはカスタム禁止パスワードリストの機能があります。社名・ブランド名・一般的な単語を禁止リストに登録することで、スプレー攻撃で最初に試みられるパスワードを事前に封じることができます。

5. SIEMやログ集約ツールでの相関検知

Wazuhやクラウドネイティブのログ分析ツールを使い、「異なるアカウントへの短時間の認証失敗が複数発生している」という相関ルールを定義します。個別のアカウントログインではなく、組織全体のログインパターンを横断的に見ることで、スプレー攻撃の兆候を早期に発見できます。

中小企業でも今日からできること

セキュリティ専任担当が1人しかいない環境でも、優先度順に取り組めることがあります。

・まず全員にMFAを義務化: M365・Google Workspace・VPNの管理者アカウントから始め、順次一般ユーザーへ展開します。これだけでパスワードスプレー攻撃の成功率を大幅に下げられます
・月1回のサインインログ確認: Microsoft Entra IDの「危険なサインイン」レポートを月1回確認するだけでも、異常を見逃すリスクが下がります
・よく使われるパスワードの禁止: パスワードポリシーに「Company名＋数字」「季節＋年」パターンを禁止する指示を加え、次回のパスワードリセット時に適用します
・VPNとRDPへのGeoIPブロッキング: 業務上アクセスのない国からのVPN・RDP接続をブロックするだけで、攻撃のほとんどは到達前に止まります

予算が限られていても、MFAは多くのSaaSで追加費用なしに有効化できます。まずこれだけを徹底することが最優先です。

よくある誤解と注意点

【誤解1】「うちはアカウントロックを設定しているから大丈夫」

パスワードスプレー攻撃はアカウントロックをすり抜けるように設計されています。ロック機能は必要ですが、それだけでは不十分です。MFAと組み合わせることが必須です。

【誤解2】「クラウドサービスのセキュリティはベンダーが守ってくれる」

Microsoft 365やGoogleワークスペースのインフラはベンダーが守りますが、アカウントの認証設定はユーザー側の責任です。責任共有モデルの観点でも、MFA設定はユーザー側に属します。「クラウドに移行したから安全」という誤解が、アカウント侵害の温床になります。

【誤解3】「強いパスワードにすれば攻撃は成功しない」

複雑なパスワードは有効ですが、組織内に1人でも「Spring2024!」のような弱いパスワードを使っているユーザーがいれば、その1アカウントが突破点になります。ポリシーの徹底とMFAの組み合わせが重要です。

【注意】メールアドレスの露出を最小化する

攻撃の前提として、攻撃者は対象組織のアカウント名（メールアドレス）を収集します。企業ホームページや名刺情報、LinkedInの公開情報から収集されるケースが多いため、組織のメールアドレス体系（例: 「姓.名@company.co.jp」）が丸見えにならないよう注意することも対策の一つです。

本記事のまとめ

パスワードスプレー攻撃の巧みさは、「組織全体を見ると異常なのに、個別アカウント単位では正常に見える」という点にあります。横断的なログ監視とMFAの組み合わせが、この攻撃への最も現実的な防御です。

関連記事として、fail2banを使ったブルートフォース攻撃の自動ブロックや、パスキー（FIDO2）によるパスワードレス認証もあわせて参照してください。パスワード自体を廃止するパスキーへの移行は、スプレー攻撃を根本から無効化する長期的な解決策として注目されています。