リバースブルートフォース攻撃とは？ 10分でわかりやすく解説

リバースブルートフォース攻撃とは、少数のパスワード候補を固定し、多数のアカウントに対して分散して試す攻撃です。特定のアカウントに大量のパスワードを試す従来型のブルートフォース攻撃とは異なり、1アカウントあたりの失敗回数を少なく見せやすいため、単純なアカウントロックや連続失敗の監視だけでは検知が遅れる場合があります。

一般には、パスワードスプレー攻撃と近い意味で説明されます。攻撃者は、社名、季節、年度、短い数字列、既知の弱いパスワードなどを候補にし、メールアドレスや社員番号などのIDへ広く試行します。対策では、推測されやすいパスワードを許可しないこと、多要素認証を導入すること、分散試行を前提に認証ログを監視することが欠かせません。

リバースブルートフォース攻撃とは

リバースブルートフォース攻撃は、攻撃者が少数のパスワード候補を用意し、多数のアカウントへ順番に試す攻撃です。従来型のブルートフォース攻撃が「1つのIDに大量のパスワードを試す」攻撃であるのに対し、リバースブルートフォース攻撃は「1つまたは少数のパスワードを多数のIDへ試す」攻撃として整理できます。

パスワードスプレー攻撃との関係

リバースブルートフォース攻撃は、パスワードスプレー攻撃として説明されることがあります。パスワードスプレー攻撃では、攻撃者がよく使われるパスワードや組織名を含むパスワードを選び、多数のユーザーアカウントに対して少しずつ試行します。

この方法では、1つのアカウントに対する失敗回数が少なくなるため、単純なロックアウト設定を回避される場合があります。特に、外部公開されているメール、VPN、SaaS、クラウド管理画面では、IDが推測されやすいと攻撃対象になりやすくなります。

ハッシュ解析とは別の攻撃

リバースブルートフォース攻撃は、ログイン画面や認証APIに対して試行するオンライン攻撃です。一方、漏えいしたパスワードハッシュから元のパスワードを推測する攻撃は、オフラインのパスワードクラッキングに分類されます。

両者はどちらもパスワードを狙いますが、防御の層が異なります。リバースブルートフォース攻撃には、認証試行の制御、弱いパスワードの拒否、多要素認証、ログ監視が有効です。パスワードクラッキングには、ソルト、専用のパスワードハッシュ方式、ハッシュ情報へのアクセス制御が必要になります。

通常のブルートフォース攻撃との違い

通常のブルートフォース攻撃とリバースブルートフォース攻撃では、試行の集中先が異なります。違いを理解すると、アカウントロックや監視ルールをどのように設計すべきか判断しやすくなります。

攻撃の流れ

典型的な流れは、次の通りです。

1. 攻撃者が、社名、季節、年度、連番、漏えい済みパスワードなどから候補を用意する
2. メールアドレス、社員番号、ユーザー名などのIDを収集または推測する
3. 同じパスワード候補を、多数のIDに対して少数回ずつ試す
4. ログインに成功したアカウントを使い、メール、クラウド、SaaS、VPNなどへアクセスする
5. 成功後に、転送設定、権限変更、追加認証情報の登録、別システムへのアクセスを試みる

攻撃者は、すべてのアカウントを突破する必要はありません。1つのアカウントでも突破されると、メールの閲覧、クラウドストレージへのアクセス、業務SaaSの操作、追加の認証情報収集へつながる場合があります。

狙われやすい環境

リバースブルートフォース攻撃は、IDが推測しやすく、弱いパスワードが残り、多要素認証が未導入の環境で成立しやすくなります。外部からログインできるサービスが多い組織ほど、認証面の管理が重要になります。

• メールアドレスの命名規則が単純で、IDを推測しやすい
• 社名、年度、季節語、連番を含むパスワードが許可されている
• 漏えい済みパスワードや既知の弱いパスワードを拒否していない
• メール、VPN、SaaS、クラウド管理画面に多要素認証がない
• レガシー認証など、多要素認証を適用しにくい認証方式が残っている
• 認証ログをアカウント横断で分析していない

リバースブルートフォース攻撃の危険性

リバースブルートフォース攻撃の危険性は、試行が目立ちにくいことと、ログイン成功後の被害が広がりやすいことにあります。認証成功後は正規ユーザーの操作に見えるため、検知が遅れる場合があります。

単純なアカウントロックを回避される場合がある

アカウントロックは、同一アカウントに対する連続失敗には有効です。しかし、攻撃者が多数のアカウントへ少数回ずつ試行する場合、各アカウントの失敗回数はしきい値に届かないことがあります。

そのため、同一アカウント単位の失敗回数だけではなく、同じ送信元、同じユーザーエージェント、同じ国・地域、同じパスワード候補の可能性がある失敗を横断的に確認する必要があります。

メールやクラウドから被害が広がる

メールアカウントが突破されると、取引先とのやり取り、添付ファイル、パスワードリセットメール、請求情報にアクセスされるおそれがあります。クラウドストレージやSaaSにログインされると、ファイルの閲覧、共有設定の変更、データの持ち出しにつながる場合があります。

攻撃者は、ログイン成功後にメール転送設定、回復用情報、MFA設定、管理者権限、APIトークンを確認することがあります。成功後の重要操作を監視しなければ、侵害に気づくまで時間がかかります。

パスワード使い回しで被害が連鎖する

同じIDとパスワードを複数サービスで使い回している場合、1つのサービスで認証情報が通ると、別サービスでも試行される可能性があります。この動きはパスワードリスト攻撃とも関係します。

組織では、業務SaaS、メール、VPN、クラウド管理画面、社内システムで同じパスワードを使わせない設計が必要です。パスワードマネージャーの利用やシングルサインオンの整理も、使い回し削減に役立ちます。

検知で見るべきログと兆候

リバースブルートフォース攻撃を検知するには、アカウント単位の連続失敗だけでなく、組織全体の認証失敗の分布を見る必要があります。失敗の件数、対象アカウント数、送信元、時間帯、成功後の操作を組み合わせて判断します。

アカウント横断の失敗

一定時間内に多数のアカウントで少数の認証失敗が発生している場合、リバースブルートフォース攻撃の可能性があります。1アカウントごとの失敗は少なくても、組織全体では不自然な広がりが出ます。

• 短時間に多数のアカウントで認証失敗が発生している
• 普段ログインしない国・地域から失敗が増えている
• 同じ送信元IPまたは近いIP帯から、多数のIDへ試行されている
• 特定の時間間隔で規則的に失敗が発生している
• レガシー認証や古いプロトコルからの認証失敗が目立つ

成功直後の不審操作

攻撃者がログインに成功した場合、通常の閲覧だけでなく、長期的なアクセスや権限拡大に関わる操作を行うことがあります。認証成功だけで判断せず、成功直後の操作を確認します。

• メール転送設定や受信ルールが追加されている
• MFA設定、回復用メール、電話番号が変更されている
• 管理者権限やアプリ権限が追加されている
• 短時間に大量のファイル閲覧やダウンロードが発生している
• 通常と異なる端末、国・地域、時間帯からアクセスしている

SIEMやID基盤との連携

SIEMやID基盤のログを使うと、複数サービスの認証失敗と成功後の操作を関連付けやすくなります。メール、SaaS、VPN、クラウド管理画面のログを分けて見るだけでは、攻撃全体の流れを見逃す場合があります。

特に、認証成功後に権限変更やメール転送設定が発生している場合は、通常のログインではなく侵害後の操作として扱う必要があります。

リバースブルートフォース攻撃への対策

リバースブルートフォース攻撃への対策は、パスワード品質、多要素認証、レート制限、レガシー認証の制御、監視を組み合わせます。どれか一つだけでは、攻撃を十分に抑えられません。

弱いパスワードを許可しない

リバースブルートフォース攻撃では、少数のよく使われるパスワードが試されます。そのため、社名、サービス名、年度、季節、連番、短すぎる文字列、漏えい済みパスワードを拒否する仕組みが有効です。

パスワードポリシーでは、長さを確保し、既知の弱いパスワードをブロックします。複雑な記号の組み合わせを要求するだけでは、利用者が規則的な文字列を作りやすくなる場合があります。長く推測されにくいパスフレーズと、使い回しを避ける運用を組み合わせます。

多要素認証を導入する

多要素認証は、パスワードが推測された場合でも、追加の認証要素で不正ログインを防ぎやすくします。特に、メール、VPN、クラウド管理者、重要SaaS、ID管理者には優先的に適用します。

可能であれば、SMSや音声通話だけに依存せず、認証アプリ、FIDO2、パスキー、証明書など、より耐性の高い方式を検討します。管理者や高権限アカウントでは、耐フィッシング性のある認証方式を優先します。

レート制限と段階的制御を設計する

同一アカウントの連続失敗だけでロックする設計では、分散試行を検知しきれない場合があります。送信元IP、端末、国・地域、対象アカウント数、失敗分布を組み合わせて制御します。

正規ユーザーを巻き込む強いロックだけに頼らず、追加認証、遅延、チャレンジ、リスクベース認証を組み合わせると、業務影響を抑えながら攻撃を止めやすくなります。

レガシー認証を制限する

古い認証方式やプロトコルは、多要素認証や条件付きアクセスを適用しにくい場合があります。POP3、IMAP、SMTP AUTHなどの利用が残っている環境では、パスワードスプレー攻撃の対象になることがあります。

利用状況を確認し、業務上不要なレガシー認証は停止します。停止できない場合は、対象アカウント、送信元、利用用途を限定し、監視と期限付き例外を設定します。

成功後の操作を監視する

認証失敗だけでなく、ログイン成功後の操作を監視します。特に、メール転送設定、権限追加、MFA設定変更、回復用情報の変更、アプリ連携の追加、短時間の大量ダウンロードは重点的に確認します。

攻撃を完全に防げない前提で、突破後の被害拡大を抑える設計にします。最小権限、管理者権限の分離、重要操作の承認、異常操作の通知を組み合わせます。

パスワードクラッキングへの補足対策

リバースブルートフォース攻撃とは別に、漏えいしたハッシュ値からパスワードを推測する攻撃もあります。これはログイン画面への試行ではなく、攻撃者が入手したハッシュを手元で解析するオフライン攻撃です。

ソルトと専用ハッシュ方式

パスワードを保存するシステムでは、平文保存を避け、ソルトを使い、パスワード保存に適したハッシュ方式を利用します。ソルトにより、同じパスワードでも同じハッシュ値にならないようにできます。

パスワードハッシュには、一般的な高速ハッシュではなく、Argon2、bcrypt、scrypt、PBKDF2など、計算コストを調整できる方式が使われます。これにより、総当たりや辞書攻撃の効率を下げられます。

ハッシュ情報へのアクセス制御

ハッシュ化していても、ハッシュ情報が漏えいすれば攻撃対象になります。認証データベースへのアクセス権限を制限し、管理者操作をログに残し、バックアップやテスト環境にも同等の保護を適用します。

オンライン攻撃とオフライン攻撃を分けて対策することで、認証突破と認証情報漏えいの両方に備えられます。

運用で確認すべき項目

リバースブルートフォース攻撃への対策は、設定して終わりではありません。ユーザー数、外部公開サービス、認証方式、業務端末、クラウド利用状況が変わるため、定期的に確認します。

確認項目

• 推測されやすいパスワードや漏えい済みパスワードを拒否できているか
• メール、VPN、クラウド管理者、重要SaaSに多要素認証を適用しているか
• レガシー認証や多要素認証を適用できない認証方式が残っていないか
• 多数アカウントにまたがる失敗を検知できるか
• 成功直後のメール転送設定、権限変更、MFA設定変更を監視しているか
• 高権限アカウントの利用場所、端末、時間帯を制限しているか
• パスワードリセット手順や回復用情報の変更を監査できるか

まとめ

リバースブルートフォース攻撃は、少数のパスワード候補を多数のアカウントへ分散して試す攻撃です。一般にはパスワードスプレー攻撃として説明されることもあり、同一アカウントへの連続失敗が目立ちにくい点に注意が必要です。

対策では、弱いパスワードを許可しないこと、多要素認証を導入すること、レート制限と段階的制御を設計すること、レガシー認証を制限すること、アカウント横断の認証失敗と成功後の操作を監視することが中心になります。

ハッシュ値からパスワードを推測する攻撃は、リバースブルートフォース攻撃とは別のパスワードクラッキングです。オンラインの認証試行と、オフラインのハッシュ解析を分けて考えることで、必要な対策を漏れなく整理できます。

よくある質問（FAQ）