クレデンシャルスタッフィング攻撃とは？ 10分でわかりやすく解説

クレデンシャルスタッフィング攻撃とは、過去の情報漏えいなどで入手されたIDとパスワードの組み合わせ（クレデンシャル）を悪用し、別のWebサービスへの不正ログインを大量に試みるサイバー攻撃です。攻撃が成立する前提は「パスワードの使い回し」にあり、特別な脆弱性が見つかっていないサービスでも被害が発生します。本記事では、攻撃の仕組み、被害の出方、似た手口との違い、そして現場で効く対策を体系的に整理します。

クレデンシャルスタッフィング攻撃とは

クレデンシャルスタッフィング攻撃（Credential Stuffing Attack）は、認証情報の使い回しを突いてアカウントを乗っ取る代表的な手口です。攻撃者は、漏えいしたID・パスワードの組み合わせを大量に入手し、自動化ツール（ボット）でログインを試行します。

ここで重要なのは、攻撃が「正規のログイン処理」を利用して実行される点です。SQLインジェクションのようにアプリケーションの欠陥を突くのではなく、ユーザー側のパスワード運用の弱さと、認証周辺の防御の薄さを狙って成立します。

クレデンシャルの意味

ITセキュリティにおけるクレデンシャルは、ユーザーを識別・認証するための情報を指します。一般的にはID（ユーザー名、メールアドレス）とパスワードの組み合わせを意味しますが、文脈によってはセッショントークン、APIキー、秘密鍵なども広く含めて指される場合があります。

本記事では、クレデンシャルスタッフィングの中心となるIDとパスワードの組み合わせを主対象として扱います。

スタッフィングの意味

スタッフィング（stuffing）は「詰め込む」「大量投入する」という意味合いを持ちます。クレデンシャルスタッフィングでは、漏えいした認証情報を機械的かつ高速に投入し、成功する組み合わせを拾い上げます。人手で試す攻撃ではなく、ボットによって短時間に膨大な試行が行われる点が特徴です。

クレデンシャルスタッフィング攻撃の仕組み

クレデンシャルスタッフィングは、概ね次の流れで実行されます。個別の手口に差はあっても、サービス提供者側はこの一連のプロセスを前提に「どこで止めるか」を設計する必要があります。

認証情報の入手

攻撃者は、過去に別サービスから漏えいした認証情報を入手します。入手経路は多様で、情報漏えい事件の流出データ、マルウェア（情報窃取型）による収集、フィッシングによる搾取などが混在します。こうしたリストは、第三者間で売買・共有されることもあり、攻撃者本人が最初の漏えいを起こしていないケースもあります。

つまり、あなたのサービスが直接侵害されていなくても、別の場所で漏れたID・パスワードの使い回しがあれば被害が起きます。

自動化ツールによるログイン試行

入手した認証情報は自動化ツールに読み込まれ、対象サービスのログイン画面や認証APIに対して大量に試行されます。攻撃者は成功率を上げるために、次のような工夫を組み合わせます。

• IPアドレスの分散：プロキシやボットネットを使い、単純なIP制限を回避する
• 試行速度の調整：一気に叩かず、検知されにくいレートで継続する
• 端末・ブラウザの偽装：User-Agentやヘッダを変え、機械的な特徴を薄める
• ログイン導線の迂回：フォームではなくAPI経由で試す、複数エンドポイントを使い分ける

ログイン試行自体は正規の処理に見えるため、検知できない状態だと「どこまでが通常の失敗で、どこからが攻撃か」の線引きが難しくなります。

ログイン成功後の不正行為

ログインに成功すると、攻撃者は目的に応じて行動します。典型例は次の通りです。

• アカウント内情報の窃取：氏名、住所、連絡先、購入履歴、保存カード情報など
• 不正購入・不正送金：決済機能の悪用、配送先の改ざん、ポイント消費など
• ポイント・クーポンの換金：換金性の高い要素を狙って現金化する
• 乗っ取りの固定化：メールアドレス変更、電話番号登録、2要素の設定変更など
• 追加侵害の足場化：同一IDの別サービス攻撃、社内アカウント探索など

被害はユーザーにとっての金銭・プライバシー被害に留まらず、サービス提供者側にも不正取引対応、補償、調査、信用低下といった形で波及します。

なぜクレデンシャルスタッフィング攻撃が成立するのか

最大の要因は、利用者によるパスワードの使い回しです。1つのサービスで漏れた認証情報が、別のサービスでも通用してしまうと、漏えいが連鎖し、被害範囲が急拡大します。

さらに、ログインは本来「失敗して当たり前のイベント」でもあります。入力ミスやパスワード忘れが日常的に起きるため、サービス側が失敗の増加＝即攻撃と判断しにくい点も、攻撃が成立しやすい理由です。

つまり、クレデンシャルスタッフィングは「脆弱性を突く攻撃」というより、現実の運用習慣（使い回し）と、認証の許容範囲（失敗は起きるもの）の隙間を突いて成立します。

他の攻撃手法との違い

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

ブルートフォース攻撃は、特定アカウントに対してパスワード候補を総当たりで試す手口です。成功率は低い一方、パスワードが極端に弱い場合には突破されます。

一方のクレデンシャルスタッフィングは、すでに別サービスで使われていた実在のID・パスワードの組み合わせを大量に投入します。推測ではなく「再利用」なので、使い回しがある環境では成功率が上がりやすい点が特徴です。

辞書攻撃との違い

辞書攻撃は、よく使われる単語やパターン（パスワード辞書）を用いてパスワードを推測します。ユーザーの命名習慣に依存するため、強いパスワード運用がされていれば成功しにくくなります。

クレデンシャルスタッフィングは推測ではなく、漏えい済みの組み合わせを使うため、パスワードが複雑であっても「同じものを使っている」限り突破され得ます。

クレデンシャルスタッフィング攻撃による被害

被害は多岐にわたります。ユーザー被害と事業者被害を分けて捉えると、対策の優先順位が立てやすくなります。

• ユーザーアカウントの乗っ取り（プロフィール改ざん、連絡先変更など）
• 不正購入・不正送金（決済機能、ポイント、ギフト券などの悪用）
• 個人情報の漏えい（住所、連絡先、購入履歴、保存情報など）
• サービスへの信頼低下（問い合わせ増加、解約、ブランド毀損）
• 運用コストの増大（調査、補償、CS対応、再発防止、決済事業者対応）

特にECや会員制サービスでは、金銭的被害と信用の毀損が同時に発生します。さらに、攻撃者が「成功したアカウントだけを選別して売る」こともあるため、被害が断続的に続く形になりやすい点にも注意が必要です。

クレデンシャルスタッフィング攻撃への対策

対策は「ユーザー任せ」だけでも、「監視だけ」でも不十分になりがちです。認証の強化、試行の抑止、異常の検知、被害時の封じ込めを組み合わせ、攻撃のコストを上げることが現実的な方針になります。

多要素認証の導入

多要素認証（MFA）は、IDとパスワードが漏えいしても追加の要素が必要になるため、不正ログインの成功率を大きく下げます。特に、決済や個人情報参照などの重要操作に対しては、ログイン時に限らずステップアップ認証として要求する設計も有効です。

導入時は「強制範囲（全ユーザーか、重要ユーザーか）」「適用タイミング（ログイン時／重要操作時）」「復旧手段（端末紛失時）」まで含めて設計しないと、運用負担が増えて形骸化しやすくなります。

ログイン試行の制御

ログインの大量試行を成立させないための制御は基本対策です。代表的には次の手段があります。

• レート制限：一定時間あたりの試行回数に上限を設ける
• 段階的な制限：失敗回数に応じて待ち時間を増やす
• アカウント保護：条件付きで一時ロックや追加認証を要求する
• リスクベース制御：新規端末・異常IP・不自然な地域などで制限を強める

ただし、過度なロックは「攻撃者によるロック誘発（アカウントロックアウト攻撃）」で正規ユーザーを妨害する副作用もあります。固定の閾値だけでなく、状況に応じて段階的に強度を変える設計が現実的です。

異常検知と監視

短時間に大量のログイン試行が行われていないか、成功率が不自然に上がっていないか、特定の端末・IP帯で失敗が集中していないかなどを監視し、異常時に遮断・追加認証・調査につなげます。

監視で見るべき指標は、単純な「失敗回数」だけではありません。たとえば、失敗の分布（同一アカウント集中か、広範囲か）、成功率の変化、ログイン後の行動（住所変更、決済変更、連続購入など）まで含めると、検知の精度が上がります。

ユーザーへの啓発

利用者側の対策は「使い回しをやめる」に尽きますが、現実にはすぐには変わりません。そこで、サービス提供者としては次の支援策が有効です。

• パスワード使い回しを避ける案内（分かりやすい文言で継続的に）
• 安全なパスワード設計の提示（長さ重視、推測されやすい語の回避）
• パスワードマネージャ利用の推奨（運用上の現実解として）
• 不審ログイン通知（本人が気づいて止められる導線を用意）

啓発は「注意してください」で終わらせず、実行に落とし込める選択肢（MFA、マネージャ、通知）とセットにすることで効果が出やすくなります。

まとめ

クレデンシャルスタッフィング攻撃は、特別な脆弱性がなくても成立する現実的な脅威です。パスワードの使い回しと自動化を前提に、短時間で大量のログイン試行が行われ、成功後は不正購入や情報窃取などの被害に発展します。対策は、多要素認証による突破難度の引き上げ、ログイン試行の制御、異常検知・監視、ユーザー支援（啓発と仕組み）の組み合わせが重要です。単発の導入で終わらせず、ログと運用を前提に継続的に見直すことで、被害の発生確率と影響を下げられます。