ブルートフォース攻撃とは？リスト型攻撃の手口・事例と対策、AIで防ぐ方法【2026年】

結論：ブルートフォース攻撃対策は「多要素認証」から始める

ブルートフォース攻撃（総当たり攻撃）とは、ID・パスワードの組み合わせを機械的に大量に試し、ログインを破る攻撃手法の総称である。辞書攻撃、パスワードスプレー、リスト型攻撃（クレデンシャルスタッフィング）はいずれもその変種であり、国内サービスへの被害は2025〜2026年も継続している。

対策の優先順位は明確だ。第一に多要素認証（MFA）の全アカウントへの適用、第二にパスワードの使い回し防止と漏えい済みパスワードの拒否、第三に試行回数制限と補助策、そして第四以降でリスクに基づくAI検知を導入する。AIによる行動分析は強力な補完手段だが、MFAの代替にはならない。

IPAの相談窓口への「SNS等の不正ログイン」に関する相談件数は、2025年7月に144件と過去最多を記録した（出典：Impress Watch「IPAが不正ログインへ注意喚起」2025年8月29日付 https://internet.watch.impress.co.jp/docs/news/2042722.html）。対策を先送りにできる状況ではない。

---

関連記事多要素認証の突破の手口とAIで防ぐ方法は？ ／ VPNの脆弱性を狙う侵入の手口と対策は？ ／ ラテラルムーブメントの手口とAIで止める方法は？

ブルートフォース攻撃とは何か：仕組みと手口の種類

ブルートフォース攻撃は、認証システムの「何度でも試行できる」という弱点を突く。攻撃者は自動化ツールを使い、短時間に数十万〜数百万件の認証試行を送り込む。IPAはアカウント乗っ取り（不正ログイン）の基本的な手口として、総当たり攻撃・辞書攻撃・リスト型攻撃・フィッシングを挙げている（出典：Impress Watch 2025年8月29日付、IPAの注意喚起は同年8月28日）。

攻撃が成立する根本的な理由は、利用者がパスワードを使い回していること、そしてサービス側が試行回数を十分に制限していないことの組み合わせにある。どちらか一方の問題を解消するだけでは不十分であり、両面からの対策が必要になる。

手口の種類と特徴

手口名	概要	検知の難しさと対策のポイント
総当たり攻撃（ブルートフォース）	考えられる全組み合わせを機械的に試す	試行回数が膨大なため試行数の監視で検知しやすい。長いパスワードが有効な抑止力になる
辞書攻撃	よく使われる語句・単語リストを順に試す	全組み合わせより効率的。弱いパスワードや辞書に載る語句に有効。漏えい済みリストとの照合で防げる
リスト型攻撃（クレデンシャルスタッフィング）	他サービスから漏えいしたID・PWの組を別サービスに投入する。OWASPはブルートフォースの一種と位置づける（出典：OWASP「Credential stuffing」）	パスワードを「推測」しないため成功率が相対的に高い。パスワード使い回しがある限り成立する。MFAが主たる対策
パスワードスプレー	少数アカウントへの試行を分散し、失敗回数を意図的に抑える	ロックアウトや失敗回数ベースの検知を回避するよう設計されている。Microsoftは住宅用プロキシ経由で実行されIPアドレス指標が信頼しにくいと報告（出典：Microsoft Security Blog 2024年1月25日）。行動パターン分析が補完手段になる

---

このほか、よく使われるパスワードを1つ決めてIDの側を次々に変える「リバースブルートフォース攻撃」や、盗み出したパスワードのハッシュ値を攻撃者の手元のコンピューターで解析する「オフライン攻撃」もある。オフライン攻撃はログインの試行回数の制限では止められないため、パスワードの保存方式（ソルト付きで計算に時間のかかるハッシュ）と、漏えいが分かった時点でのパスワード変更が対策になる。

ブルートフォース攻撃の国内被害事例（2025〜2026年）

ブルートフォース攻撃は抽象的な脅威ではなく、2025〜2026年にかけて国内主要サービスで被害が相次いでいる（2026年10月時点）。各事例から共通する構造的問題を読み取ることが、対策設計の起点となる。

不正ログインの被害は増え続けている。国家公安委員会・総務省・経済産業省の公表（2026年3月12日）によると、2025年の不正アクセス行為の認知件数は7,190件で、前年より約34%増えた。

被害は「お金」「情報」「なりすまし」の3つに分かれる。同じ公表では、IDとパスワードを盗まれた手口のうち「パスワードの設定や管理の甘さにつけ込まれた」が84件、「フィッシングサイトから入手された」が77件だった（2025年に検挙した事件）。

女の転職type（2026年5月公表）

株式会社キャリアデザインセンターが運営するスマートフォンアプリに対し、2026年5月26〜28日にリスト型攻撃が実行された。試行件数は1,141,828件、不正ログインが確認されたのは38,442件（ユニークユーザー18,253名）。公表された数値から計算すると、成功率は約3.4%に当たる。他サービスから流出したとみられるID・パスワードのリストが使われたと推測され、同社内からの漏えいは確認されていないとしている。

対応として外部アクセスの遮断、全会員の強制ログアウト、不正ログインが確認された会員のパスワード初期化と再設定案内、個人情報保護委員会への報告が行われた。初動の流れは、後述する「優先度6：被害発生時の対応」の実例として参照価値が高い。（出典：ロケットボーイズ https://rocket-boys.co.jp/?p=34400）

PinT（2025年8月公表）

東京電力エナジーパートナーの関連会社PinTが運営する顧客向け「マイページ」に、複数IPアドレスからのリスト型攻撃が行われた。2025年8月14〜16日にログイン試行の急増を検知し、遡り調査で2025年4月1日〜8月16日に不正ログインを確認。ポイントの不正利用は444件にのぼった。検知から遡り調査に至るまでの期間が4か月以上に及んだ点は、定常的な監視体制の重要性を示している。（出典：ScanNetSecurity 2025年9月10日 https://scan.netsecurity.ne.jp/article/2025/09/10/53593.html）

毎日新聞デジタル（2025年7月〜9月公表）

株式会社毎日新聞社が運営する毎日新聞デジタルのログイン識別システムに対し、2025年7月8日以降に大量の不審アクセスが発生。7月10日午前に検知し、7月11日に第一報、同年9月11日に調査結果を公表した。パスワードリスト攻撃（リスト型攻撃）と確認されており、個人情報ページの閲覧形跡は確認されていないとしている。（出典：ScanNetSecurity 2025年9月25日 https://scan.netsecurity.ne.jp/article/2025/09/25/53675.html）

Microsoft（海外・パスワードスプレーの事例）

Microsoftは2024年1月12日、自社の企業システムへの攻撃を検知した。攻撃者（ロシア国家支援グループMidnight Blizzard）は、MFAが有効でない旧式の非本番テストアカウントをパスワードスプレーで侵害した。試行回数を意図的に少なくすることでロックアウトや検知を回避し、多数の住宅用プロキシIPアドレスを経由してIPアドレスに基づく侵害指標を信頼しにくい状況を作り出した。その後、旧テスト用OAuthアプリの高い権限を悪用し、Exchange Onlineの企業メールにアクセスした。この事例が示すのは、AI検知以前に「MFA未設定の旧アカウント」という見落としが入口になるという構造的問題である。（出典：Microsoft Security Blog 2024年1月25日 https://www.microsoft.com/en-us/security/blog/2024/01/25/midnight-blizzard-guidance-for-responders-on-nation-state-attack/）

AIハッキングと情報漏洩の最新被害動向については、AIハッキングと情報漏洩の被害一覧も参照されたい。

---

AIで防ぐ方法：リスクに基づく検知の仕組みと適用段階

AIや機械学習がブルートフォース対策に貢献できるのは、主に「攻撃を見分ける段階」と「パスワード設定の段階」である。ただし、AIは基本対策（多要素認証・試行回数制限）を代替するものではなく、それらの上に積み重ねる補完層として機能する。

特に、パスワードスプレーのように試行を分散してIPアドレス単体では判別しにくい攻撃に対して、行動パターンの異常を評価するアプローチが有効な補完手段となる。Microsoftは住宅用プロキシ経由の攻撃を踏まえ、IPアドレスに依拠した検知の限界を明確に指摘しており、行動パターンに基づくリスク検知（Microsoft Entra ID Protection）の活用を推奨している。

適用段階	AIが担う機能	根拠・注記
試行の段階 大量・自動の認証試行	レート制限の補助。CAPTCHAや待ち時間の増加、リスクに基づく手法を組み合わせ、正規ユーザーの締め出しを最小化しながら制限を維持する	NIST SP 800-63Bは連続失敗を1アカウントあたり100回以下に制限し、CAPTCHA・待ち時間・リスクに基づく手法で補う考え方を示している
攻撃の識別段階 IPで見分けにくい攻撃	ログインの行動パターン（アクセス元・使用端末・操作速度・試行の分散）の異常をリスクとして評価し、追加認証やパスワード変更を発動する	Microsoftは住宅用プロキシ経由の攻撃でIPアドレス指標が信頼しにくいことを踏まえ、行動パターンに基づくリスク検知の活用を推奨（Microsoft Security Blog 同上）
パスワード設定の段階	新規パスワードをよく使われる値・漏えい済みパスワードのリストと照合し、一致すれば理由を示して変更を促す	NIST SP 800-63Bは、過去の漏えい（breach corpus）との照合を検証側に求めている

リスクに基づく検知は、「スコアが高ければ追加認証を動的に発動する」という仕組みにより、ユーザー体験を過度に損なわずにセキュリティを強化できる点が利点である。ただし、その限界も直視する必要がある。

AIセキュリティ対策の全体像については、AIセキュリティ対策の解説が参考になる。

---

AIの限界と注意点：見落としが起きるケース

AIによるリスク検知を過信すると、むしろ対策の穴が生じる。確認されている限界を整理する。

IPアドレスによる判定の限界

Microsoftが報告したMidnight Blizzardの事例では、攻撃者は正規ユーザーと同じ住宅用プロキシのIPアドレス帯を経由して侵害を実行した。場所やIPアドレスだけに依拠する検知では、攻撃者が正規ユーザーと区別しにくいIPを使うと機能しない。IPアドレスは補助的な指標の一つとして位置づけ、単独の判断基準にしないことが重要である。

試行回数を意図的に抑えた攻撃

パスワードスプレーは、少数のアカウントへの試行回数を故意に少なくし、失敗回数に基づくロックアウトや閾値検知を回避するよう設計されている（Microsoft Security Blog 同上）。回数のしきい値だけに依存する検知は、この設計に対して有効に機能しない。行動パターン全体を評価するリスクベースの検知が必要になる理由がここにある。

棚卸しされていないアカウントが入口になる

MicrosoftへのMidnight Blizzard攻撃の侵害経路は、MFAが有効でない旧テストアカウントだった。AIによるリスク検知が機能していても、監視対象から外れた古いアカウントやOAuthアプリが存在する限り、それが攻撃経路になりうる。アカウントの定期棚卸しは、AI導入以前の前提条件である。

誤検知と正規ユーザーの締め出し

NISTは、ロックアウトを厳しくしすぎると正規ユーザーが締め出されることを踏まえ、CAPTCHA・待ち時間・リスクに基づく手法で補う考え方を示している。判定精度がどれほど高くても、誤検知が発生した際の運用フロー（正規ユーザーの復旧手順・問い合わせ対応）を事前に整備しておかなければ、運用コストがセキュリティ強化の効果を相殺する可能性がある。

---

AIだけに頼らないブルートフォース攻撃対策と導入の優先順位

次の順番で進めると、効果の大きい対策から手当てできる。各推奨の根拠を出典とともに示す。

優先度1：多要素認証（MFA）の全アカウントへの適用

IPAはパスキーを含む多要素認証の設定を日頃の対策に挙げ、OWASPはクレデンシャルスタッフィングの主たる対策として多要素認証を位置づけている。Microsoftの事例では、MFA未設定の旧アカウントが侵害の入口となった。重要な点は「全アカウントへの適用」であり、本番環境だけでなく非本番テストアカウントも含める必要がある。一部のアカウントにMFAが適用されていなければ、そこが最も脆弱な経路になる。

優先度2：パスワードの使い回し防止と漏えい済みパスワードの拒否

IPAは「長く複雑なパスワードを作り、使い回さない」ことを推奨する。NIST SP 800-63Bは、新規パスワードを過去の漏えいリスト（breach corpus）と照合し一致すれば拒否して理由を示すこと、侵害の証拠があるときはパスワード変更を強制すること（SHALL）を求めている。注目すべき点として、NISTは侵害の証拠なしに一律の定期変更を要求しないこと（SHOULD NOT）も示しており、旧来の「90日ごとの定期変更ポリシー」の見直しも検討に値する。定期変更の強制は、利用者が「Password1」→「Password2」のような予測しやすい変更をする傾向を生む可能性がある。

優先度3：試行回数制限と補助策

NIST SP 800-63Bは1アカウントあたりの連続失敗を100回以下に制限することを求め、CAPTCHA・待ち時間の増加・リスクに基づく手法で補うよう示している。ロックアウトのみに頼ると、正規ユーザーの締め出しと、試行を分散したパスワードスプレーへの無力化という二重の問題が生じる。試行回数制限は「閾値を設ける」だけでなく、閾値の前後で動作する補助策とセットで設計する。

優先度4：アカウントとアプリの棚卸し

Microsoftは不要な権限の監査・削除、旧テストアカウントへのMFA適用を推奨している。使われていないアカウントやOAuthアプリが残存していると、AI検知の監視対象外となった侵害経路になる。棚卸しの対象は、人のアカウントだけでなくシステムアカウント・APIキー・連携アプリも含める。

優先度5：リスクに基づく検知の導入

上記1〜4が整った上で、行動パターン（場所・端末・速度・試行の分散）の異常をリスクとして評価し、追加認証やパスワードリセットに連動させる仕組みを導入する。Microsoftはこの考え方をMicrosoft Entra ID Protectionとして提供している。基盤となるMFAや試行回数制限が機能していない状態でリスク検知のみを導入しても、根本的な対策にはならない。

優先度6：被害発生時の初動

女の転職typeの対応を参考にすると、外部アクセスの遮断、全会員の強制ログアウト、不正ログインが確認されたアカウントのパスワード初期化と再設定案内、個人情報保護委員会への報告が初動として実施された。IPAは利用者側の対応として、パスワードの速やかな変更、登録情報の確認、多要素認証の設定を挙げている。被害発生時の手順を事前にインシデント対応フローとして文書化しておくことで、実際に攻撃が起きた際の判断遅延を防ぐことができる。

---

パスワードを使わない認証（パスキー）への移行

ブルートフォース攻撃とリスト型攻撃は、どちらも「パスワードがあること」を前提にした攻撃だ。パスキーは、端末の中の秘密鍵と、サービス側の公開鍵の組み合わせでログインする方式で、盗んで使い回せるパスワードがそもそも存在しない。サービス側にもパスワードを保存しないため、データベースが漏えいしても流出するパスワードがない。鍵は作成したサイトでしか使えないため、偽サイトに入力させて盗む手口も成り立たない（FIDO Alliance「Passkeys」）。

米国立標準技術研究所（NIST）の認証の指針 SP 800-63B（第4版、2025年）は、端末間で同期できるパスキーを、条件を満たせば多要素認証の水準（AAL2）を支えられる方式として位置づけた。FIDO Allianceが委託した調査（2024年）では、回答者の53%が少なくとも1つのアカウントでパスキーを有効にしていた。

導入は、管理者や重要なシステムのアカウントから始め、パスキーに対応していないサービスでは、長く使い回さないパスワードと多要素認証を続ける。

被害に気づいたら確認するログ

• Googleアカウント：セキュリティ通知で、ログインした端末の種類・日時・場所を確かめる。心当たりがなければ通知から「アカウントを保護」に進む（Google アカウント ヘルプ）。
• Google Workspace（管理者）：ユーザーのログイベントで、ログインの成功と失敗を最長6か月分さかのぼって確認できる。不審なログインには警告が表示される（Google Workspace 管理者ヘルプ）。
• AWS：CloudTrailのログで、誰の権限で（userIdentity）、どこから（sourceIPAddress）操作されたかをたどる（AWS Security Blog、2026年9月）。

ほかの侵入の手口と対策

ブルートフォース攻撃は、ほかの手口と組み合わせて使われることが多い。関係する手口の仕組みと対策は、それぞれの解説ページにまとめている。

手口全体の見取り図と、AIを使った対策の優先順位はAIセキュリティ対策の解説で扱っている。

よくある質問

Q. ブルートフォース攻撃とリスト型攻撃は何が違うのか？

OWASPによると、クレデンシャルスタッフィング（リスト型攻撃）はブルートフォースの一種である。ブルートフォースが複数のパスワードを「推測して試す」のに対し、クレデンシャルスタッフィングは他のサービスから漏えいした既知のID・パスワードの組み合わせを別サービスに投入する点が異なる。パスワードを推測する必要がないため、パスワードが強固であっても使い回しさえあれば攻撃が成立する。（出典：OWASP「Credential stuffing」 https://community.owasp.org/attacks/Credential_stuffing）

Q. アカウントロックをかければブルートフォース攻撃対策は十分か？

十分ではない。Microsoftが公表したパスワードスプレーは、試行回数を意図的に少なく抑えることで失敗回数に基づくロックアウトや検知を回避していた。NISTも連続失敗の制限に加え、CAPTCHA・待ち時間・リスクに基づく手法で補う考え方を示している。ロックアウト単独では、パスワードスプレーのような分散型攻撃には有効に機能しない。

Q. 多要素認証を入れれば十分か？

最も重要な対策の一つだが、全アカウントに適用されていることが前提条件となる。Microsoftの事例では、侵害の入口となったのはMFAが有効でない旧テストアカウントだった。MFAの導入と並行して、パスワードの使い回し防止・漏えい済みパスワードの拒否・古いアカウントの棚卸しを組み合わせる必要がある。

Q. 国内でリスト型攻撃の被害はあるか？

2025〜2026年に複数の事例がある。女の転職type（2026年5月公表、試行約114万件・不正ログイン38,442件）、PinT（2025年8月公表、ポイント不正利用444件）、毎日新聞デジタル（2025年7〜9月公表）が確認されている（2026年10月時点）。いずれも攻撃者が外部から入手したリストを使っており、サービス内からの漏えいとは異なる攻撃経路である。

Q. AIで不正ログインをどう見分けるのか？

IPアドレスだけでは見分けにくい攻撃があるため、Microsoftは行動パターンに注目し、リスクに基づく検知で多要素認証やパスワード変更を発動させる考え方を示している。アクセス元・使用端末・操作速度・試行の分散といった行動の異常をリスクスコアとして評価し、スコアに応じて追加認証を動的に発動させる仕組みが、IP依存の限界を補う手段となる。ただし、この検知はMFAや試行回数制限といった基本対策が機能していることを前提とした補完的な層である。

---

参考文献

• 国家公安委員会・総務大臣・経済産業大臣「不正アクセス行為の発生状況」（2026年3月12日）
  https://www.soumu.go.jp/main_content/001059979.pdf
• FIDO Alliance「Passkeys」
  https://fidoalliance.org/passkeys/
• NIST SP 800-63B-4「Syncable Authenticators」
  https://pages.nist.gov/800-63-4/sp800-63b/syncable/
• Google アカウント ヘルプ（不審なログインの確認）
  https://support.google.com/accounts/answer/2590353?hl=ja
• Google Workspace 管理者ヘルプ「侵害されたアカウントを特定して保護する」
  https://knowledge.workspace.google.com/admin/support/troubleshooting/identify-and-secure-compromised-accounts?hl=ja
• AWS Security Blog「Incident response guide for AWS CloudTrail investigations – Part 2」（2026年9月3日）
  https://aws.amazon.com/blogs/security/incident-response-guide-for-aws-cloudtrail-investigations-part-2/
• Impress Watch「IPAが不正ログインへ注意喚起、SNS等の不正ログイン相談が2025年7月に144件で過去最多に」（2025年8月29日付） https://internet.watch.impress.co.jp/docs/news/2042722.html
• Microsoft Security Blog「Midnight Blizzard: Guidance for responders on nation-state attack」（2024年1月25日公表、2024年2月13日更新） https://www.microsoft.com/en-us/security/blog/2024/01/25/midnight-blizzard-guidance-for-responders-on-nation-state-attack/
• NIST SP 800-63B「Digital Identity Guidelines: Authentication and Lifecycle Management」（2025年8月1日にSP 800-63-4へ置き換え済みと表示） https://pages.nist.gov/800-63-3/sp800-63b.html
• OWASP Community「Credential stuffing」 https://community.owasp.org/attacks/Credential_stuffing
• ロケットボーイズ「女の転職typeへのリスト型攻撃に関する発表内容」（2026年5月30日公表内容を掲載） https://rocket-boys.co.jp/?p=34400
• ScanNetSecurity「PinTへのリスト型攻撃に関する報告」（2025年9月10日） https://scan.netsecurity.ne.jp/article/2025/09/10/53593.html
• ScanNetSecurity「毎日新聞デジタルへのパスワードリスト攻撃に関する報告」（2025年9月25日） https://scan.netsecurity.ne.jp/article/2025/09/25/53675.html