本文へスキップ
JAENES

EXPLAINERS

盗まれたパスワードは、どう使われるのか — 漏えいから乗っ取り、パスキーまで

漏えい事件で流出したのは「どこかのサイトの」メールアドレスとパスワードの組です。しかしその組は、使い回しをしていた別のサイトへの入り口として使われます。この記事では、クレデンシャルスタッフィングと呼ばれる攻撃がどうアカウントを破るのか、多要素認証(MFA)のどこに抜け道があるのか、パスキーがなぜ偽サイトに効くのかを、スクロールに連動する図と一緒に追います。

公開: 2026年10月30日 ・ 出典は2026年10月30日時点で確認済み

253件

発生件数(令和8年上半期・インターネットバンキングに係る不正送金事犯)

約20.7億円

被害総額(前年同期比 51% 減)

警察庁の集計による。同資料は、被害の防止にはメール認証や多要素認証などの技術的な対策だけでは十分ではなく、日常的な意識の向上が重要だと述べています。[2]

01いま起きていること

漏えいのニュースを見て「自分のアカウントは大丈夫か」と確認して終わりにしていませんか。問題はその後にあります。盗まれた組は、漏えいしたサイトとは別のサイトでのログインに使われます。まず、その流れを図で追います。

図は模式図です。実際の割合・規模を示すものではありません。

STEP 1

漏えい・フィッシングで組が盗まれる

攻撃者は、データベースの漏えい、フィッシング、パスワードダンプなどから「メールアドレス(ユーザー名)+パスワード」の組を入手します。[3]

多くの人が同じ組み合わせを使い回すため、これらの組は他の数十〜数百のサイトでも試される価値を持ちます。[3]

STEP 2

リスト化され、売買される

入手された組はリスト化され、闇市場などでやり取りされます。盗まれたデータがどう流通するかは、世界のセキュリティ事情のダークウェブの章で図解しています。

クレデンシャルスタッフィングは、アカウント乗っ取りで最も一般的な手法の一つとされます。[3]

STEP 3

自動ツールで大量投入される

盗んだ組は、自動ツールで多数のサイトのログインフォームへ大量に投入されます。ブルートフォース(総当たり攻撃)の一種ですが、推測ではなく「流出済みの本物の組」を使う点が異なります。[3]

試行が成功すれば、その組が有効な認証情報であることが攻撃者に分かります。[3]

STEP 4

使い回していたサイトだけが破られる

パスワードを使い回していなかったサイトではログインは失敗します。破られるのは、同じ組がそのまま通じてしまったサイトだけです。

乗っ取られたアカウントは、保存された価値の抜き取りや購入、クレジットカード番号や個人情報の閲覧、フィッシングやスパムの踏み台、有効な認証情報の他の攻撃者への販売に使われます。[3]

数字の位置づけ

Verizon の DBIR 2026(2025年11月までのデータ、確認済み侵害 2.2 万件超・145か国)では、初期侵入経路として「認証情報の悪用」は 13%(n=19,905)でした。従来首位だったこの経路は、今回は 31% で首位となった「脆弱性の悪用」に順位を譲しています。[1]

ただし、この 13% は「判明している初期侵入経路」に占める割合で、侵害の全過程で認証情報が使われた割合ではありません。[1]

また、第三者のクラウドアカウントについて、MFA の欠落・不備を完全に是正した組織は 23% にとどまります。対策の未着手が侵入を許す構図は変わっていません。[1]

OWASP は、クレデンシャルスタッフィングの主要な対策として多要素認証を挙げます。[3]では、その多要素認証のどこに抜け道があるのか — 次の章で見ます。

02なぜ効くのか

「パスワードを使い回さなければ大丈夫」「MFA を付けているから大丈夫」— 後半は崩れます。MFA には、偽サイトが入力を中継する手口と、承認を押させる手口という抜け道があります。パスワードとワンタイムコードがどう盗まれ、パスキーがなぜ止まるのかを図で見ます。

PASSWORD + CODE

偽サイトでパスワードと6桁コードを入力する

典型的なフィッシングの手口は、本物そっくりのログイン画面を用意し、ユーザー名とパスワードに加えて、認証アプリの6桁のワンタイムコードまで入力させるものです。[4]

RELAY

偽サイトが本物へ中継し、ログインが成立する

入力された情報は偽サイトから本物のサイトへ即座に転送されます。本人が正しいコードを入力しているためログインは成立し、攻撃者がそのセッションに入ります。利用者は本物のサイトにログインしたつもりでも、通信は偽サイトを経由しています。[4]

PUSH FLOOD

承認を押させる「プッシュ爆撃」

プッシュ通知型の MFA には「プッシュ爆撃(プッシュ疲れ)」という攻撃があります。ユーザーが「承認」を押すまで通知を送り続け、疲れや誤操作で承認させて侵入します。[4]

PASSKEY

パスキーは偽サイトでは使えない

パスキー(公開鍵クレデンシャル)は、そのサービス(Relying Party)のオリジンからしかアクセスできません。この範囲の強制はブラウザと認証器が共同で行うため、偽サイトのドメインでは本物のサイト用のパスキーは使えず、中継もできません。[6]

MFA の強さの4段階[4]

  • フィッシング耐性 MFA(FIDO / WebAuthn、PKI)ゴールドスタンダード

    弱い相手: プッシュ爆撃・SS7・SIM スワップは該当しない

  • アプリ認証(ワンタイムコード、番号一致付きプッシュ)

    弱い相手: フィッシング(偽サイトでの中継)には弱い

  • 番号一致なしのプッシュ通知

    弱い相手: プッシュ爆撃・ユーザーの誤操作に弱い

  • SMS / 音声

    弱い相手: フィッシング・SS7・SIM スワップに弱い「最後の手段」

棒の長さは強さの順位の目安(模式)であり、測定値ではありません。

CISA はフィッシング耐性 MFA(FIDO/WebAuthn や PKI)を「ゴールドスタンダード」と呼びます。フィッシング耐性のある MFA へ移行できない場合の追加対策が、番号一致です。[4]

プッシュ爆撃はこう見える

自分がログインしていないのに承認要求が連続して届く — それが不正のサインです。CISA は、番号一致なしのプッシュ通知がプッシュ爆撃やユーザーの誤操作に弱いことを挙げています。[4]

番号一致(number matching)では、画面に表示された番号の入力が求められるため、通知を押し切るだけでは承認できません。フィッシング耐性 MFA へ移行できない場合の追加対策とされます。[4]

連続して届く承認要求の例(模式)

番号一致なら:表示された番号の入力が求められ、承認だけでは通らない

03どう防ぐか

優先順に並べました。今日できるものから順に進めてください。

メール・金融・通信/ID の主要アカウントから、使い回しをなくす

パスワードマネージャーを使い、サイトごとに別々のパスワードを設定します(特定の製品名は挙げません)。

NIST SP 800-63B-4 は、パスワードを単独で使う場合は最低15文字(多要素の一部として使う場合は最低8文字)を求め、文字種などの組成ルールや定期的な変更を求めない方針を示しています。漏えいしたパスワードやよく使われるパスワードのブロックリストとの照合も必須としています。[5]

パスキーを有効にする

  1. 1.各サービスの「セキュリティ」設定を開く
  2. 2.「パスキーを作成」を選ぶ
  3. 3.端末の生体認証・画面ロックで確認する
  4. 4.次のログインから、偽サイトでは求められない(使えない)ことを意識する

パスキー未対応のサービスでは、認証アプリ式の MFA を使います。SMS は「最後の手段」です。[4]

警察庁も、パスワードに代わって生体認証等で簡単かつ安全にログインできる認証方法(パスキー)の普及促進に向けて、事業者等への働き掛けを行っています。[2]

プッシュ通知の承認は、自分が操作していない時は絶対に押さない

連続して届く通知は不正のサインです。番号一致が選べるサービスでは、番号一致を選びます。[4]

メールのリンクからログインしない

警察庁は、メール認証や多要素認証などの技術的な対策だけでは十分ではなく、「メール等に記載のリンクを安易にクリックしない」「公式サイトや公式アプリからアクセスする」など、日常的な意識の向上が重要としています。[2]

流出が分かったら

そのサービスと、同じパスワードを使っていたすべてのサービスでパスワードを変更し、MFA またはパスキーを有効化します。

被害に遭ったときの相談窓口は、「被害に遭ったら」にまとめています。流出事案の検索は、漏洩ウォッチと事案一覧でできます。

関連するページ

出典

  1. [1]Verizon 2026 Data Breach Investigations Report(Executive Summary)
  2. [2]警察庁「令和8年上半期におけるサイバー空間をめぐる脅威の情勢等について」
  3. [3]OWASP — Credential stuffing
  4. [4]CISA — Implementing Phishing-Resistant MFA(2022)
  5. [5]NIST SP 800-63B-4 — Authentication and Authenticator Management
  6. [6]W3C — Web Authentication (WebAuthn) Level 3

出典は2026年10月30日時点で確認済み。本記事は一般的な情報の提供を目的としており、個別の状況に応じて、各サービスの公式案内をご確認ください。

LIVE