HIBPに「6月のスティーラーログ」追加——5,627万のメールと1.24億のパスワードが出回る現実、次に来るのは“正規認証”を武器にした侵入です

今日の深掘りポイント

• 今回は単一サイトの侵害ではなく、情報窃取型マルウェア（Infostealer）が吸い上げた“生々しい認証情報”の寄せ集めです。すなわち、攻撃者はすぐに使える素材を大量に得た、ということです。
• ユニークなメールアドレスよりユニークなパスワードの方が多い構図は、パスワードの再利用・使い回し検証（Stuffing/Spraying/Permutation）の燃料が潤沢であることを示唆します。短期的に「正しい資格情報での侵入」が増える前提で構えるべきです。
• 企業側は、ドメインの検知・照会（HIBPのドメイン検索/API）と、ID基盤でのリスクベース制御・強制リセット・ボット/Stuffing対策を「同時に」回す運用が要点です。優先順位を付けて、数週間の“荒波”を乗り切る設計にすることが肝です。

はじめに

Have I Been Pwned（HIBP）が「2026年6月のスティーラーログ」として、5,627万件のユニークなメールアドレスと、1.24億件のユニークなパスワードを登録しました。出所は単一の被害サイトではなく、各種スティーラーが感染端末から抜き出したログの集合です。ユーザーは自分のメールのヒット有無を、組織はドメイン単位での影響を確認できます。問題の本質は、資格情報が“そのまま武器化されうる形”で広く流通することにあります。つまり、ゼロデイやフィッシングを介さずとも「正しいID/パスワード」で企業の外部サービスやSaaS、VPNに入られてしまう確率が一段と高まる、という現実です。

本件は、緊急性・実運用への落とし込みやすさ・情報の確度がいずれも高いタイプのイベントです。CISOやSOC、TIの現場は、警戒強度と対応コストのバランスを取りながら、少なくとも「数週間の急性期」を乗り切る運用モードに切り替える価値があります。

参考:

• HIBP「June 2026 Stealer Logs」ページ（件数・内容の一次情報）: https://haveibeenpwned.com/Breach/June2026StealerLogs
• HIBP ドメイン検索（組織向け照会）: https://haveibeenpwned.com/DomainSearch
• HIBP API v3 ドキュメント: https://haveibeenpwned.com/API/v3
• MITRE ATT&CK（後述のTTPマッピングの一次情報）
  • Valid Accounts (T1078): https://attack.mitre.org/techniques/T1078/
  • Credential Stuffing (T1110.004): https://attack.mitre.org/techniques/T1110/004/
  • Credentials in Web Browsers (T1555.003): https://attack.mitre.org/techniques/T1555/003/
  • Steal Web Session Cookie (T1539): https://attack.mitre.org/techniques/T1539/
  • External Remote Services (T1133): https://attack.mitre.org/techniques/T1133/

深掘り詳細

事実関係（何が起きたか）

• HIBPは「June 2026 Stealer Logs」として、5,627万7,397件のユニークなメールアドレスと、1.24億件のユニークなパスワードを登録しました。侵害データの種別はメールアドレスとパスワードです。出典はスティーラーログのコレクションで、単一サービスの漏えいではありません。一次情報
• 個人はメールアドレスを入力して照会でき、組織はドメイン所有証明を行うことで、対象ドメインに紐づくアドレスのヒットを確認できます。API経由での取り込みや自動化も可能です。ドメイン検索 / API v3

ここに登場する「スティーラーログ」とは、感染端末のブラウザやアプリから引き抜かれた資格情報群です。典型的には、メール/パスワード、場合によってはブラウザ保存の認証データやクッキーなどが含まれます（本件のHIBP登録では、少なくともメールとパスワードが対象です）。攻撃者視点では、フィッシングで1件ずつ釣るより速く、しかも“既に通る”資格情報が手に入るため、侵入コストが劇的に下がります。

インサイト（何が見えてくるか）

• メールよりもパスワードが大幅に多いという点は、攻撃側にとって「再利用・派生候補の探索空間」が広がったことを意味します。単純なリスト型攻撃に加え、よくある置換規則（年号、会社名、記号の付け替え）を組み合わせやすく、Stuffing/Sprayingに“効く”語彙が厚みを増す構図です。
• 今回は“汚染源が多数”という性質上、組織側にとっての判断は難しくなります。自社の直接的な漏えいではないケースでも、従業員が同一・派生パスワードを業務SaaSやVPNに使っていれば、結果的に企業リスクへ波及します。よって「直接起票のインシデント扱い」ではなくても、「資格情報露出起因の侵入リスク急上昇」という観点で運用レベルを上げるのが合理的です。
• さらに、攻撃者はドメイン名に基づく“名寄せ”でリストを調整し、外部リモートサービス（VPN/VDI/SaaS/メール）に的を絞るのが通例です。防御側は、アイデンティティ基盤（IdP/SSO/MFA）と境界（CDN/WAF/ボット対策）を“同時に”締めることで、認証成功後の動きを含めたトータルなハードルを作る必要があります。

脅威シナリオと影響

以下は、今回のデータ流通を起点に想定されるシナリオの仮説です。各ステップはMITRE ATT&CKのテクニックに対応づけています（該当TIDは参考リンク参照）。具体的な攻撃手順の解説ではなく、防御側の理解を助けるための戦術的マッピングです。

• シナリオ1：個人→企業へのスピルオーバー

  • 取得したメール/パスワードでSaaS（例：メール、ドキュメント、CRM）へログイン試行
    • Credential Stuffing（T1110.004）、Password Spraying（T1110.003）相当
  • 認証が通れば、正規アカウントの悪用
    • Valid Accounts（T1078）
  • 場合により、VPN/VDIなど外部公開のリモートサービスに横展開
    • External Remote Services（T1133）
  • 影響：メールボックス乗っ取りによるBEC/詐欺、SaaS上のデータ窃取、APIトークン奪取、サプライチェーン偽装など

• シナリオ2：MFA回避を狙う段階的アタック

  • 初回はパスワードのみでリスク判定を観察し、以降にMFA疲労や番号一致の社会工学で押し切りを画策（一般論としての仮説）
  • 成功すればセッション維持・横展開
    • Valid Accounts（T1078）
  • 影響：一時的にMFAを突破され、メールルール改ざんや権限申請など“音の小さい操作”で痕跡を薄められる

• シナリオ3：上流の窃取手口と二次利用の連鎖

  • スティーラーがブラウザ保存の認証を吸い上げる
    • Credentials in Web Browsers（T1555.003）
  • 併せてWebセッションクッキーの奪取・横流し（本件データに含まれるかは未確認の仮説）
    • Steal Web Session Cookie（T1539）
  • 影響：MFAを要求しないセッション再利用による“静かな乗っ取り”

• シナリオ4：ドメイン名で名寄せした標的化

  • “@example.co.jp”などで抽出し、当該組織の外部接続面（Office/Google、VPN、VDI、Git/CI/CD）に集中砲火
  • 影響：リストの精度が高いため、短時間で多くの認証成功が発生し、SOCの見逃し余地が増える

総じて、今回の追加登録は、攻撃が“弱いパスワード”を叩く局面から“正しいパスワード”を起点に始まる局面へ、リスクの重心を動かします。検知観点も、失敗の多いブルートフォースから、「最初から成功する少数のログインの後続挙動」へとシフトする必要があります。

セキュリティ担当者のアクション

実装コストと効果を秤にかけつつ、リリース直後の数週間を“急性期”と捉えた対応計画を推奨します。

• ドメイン影響の即時把握と自動化

  • HIBPのドメイン検索を用い、対象ドメインのヒットを取得。対象アドレスの棚卸しと優先度付けを行う（役職・権限・クリティカルSaaSの有無で重み付け）。DomainSearch
  • API連携で日次/週次の差分監視を走らせ、検知から「本人通知→強制リセット→監視強化」までを半自動化。API v3

• ID基盤のリスクガードを“重ね掛け”

  • リスクベース認証を高感度化（新規ASN/端末指紋/地理乖離/時間帯逸脱）。“最初の成功ログイン”の後続操作に対し、追加のステップアップ（再MFA/管理者承認）を要求する。
  • パスワード再利用の温床になりやすいSaaSを特定し、対象ユーザーに強制リセット＋MFA要件の強化を適用（管理者/特権/財務・人事は最優先）。
  • 管理者・非常用アカウントは条件付きアクセスでネットワーク/デバイス制約を強化し、パスワードのみで到達できない状態に固定。

• ボット/Stuffing耐性の底上げ

  • WAF/ボット対策でログインエンドポイントを保護し、行動異常（短時間の複数アカウント試行、フィンガープリント切替、ヘッダ異常）に基づくチャレンジ/ブロックを導入。
  • パスワードスプレーを受けやすい外部公開サービス（VPN/VDI/メール/Webメーラー/CI）のレート制御とMFA必須化を再点検。

• 検知とハンティングの観点転換

  • 失敗の多い攻撃検知に加えて、「成功した初回ログイン」の後続イベントを監視。具体例（一部）:
    • ログイン直後のメール転送ルール作成、OAuthアプリ承認、APIトークン作成、認証情報変更、権限申請、共有リンクの大量生成
    • これらを「新規端末/新規ASN×初回成功」のコンテキストで相関させ、優先度を底上げ
  • Impossible travel/ASNスイッチ/端末衛生不良（未管理/脆弱端末）との組み合わせで高リスクフラグを立てる。

• パスワード衛生の即効策と中期策

  • 影響者リストに対し、強制リセットを段階的に実施。業務影響を抑えるため、部門単位のウィンドウを切って実行し、サポート体制を厚めに。
  • パスワード禁止語彙（一般的・漏えい済み・社名/サービス名＋年号など）の適用範囲を拡大。変更時の“近接語彙”を拒否できる設定があれば有効化。
  • 中期的には、FIDO2/WebAuthnの比率を引き上げ、少なくとも管理者・財務決裁・人事・開発者アカウントで「パスワードレス優先」を既定路線に。

• ガバナンスとコミュニケーション

  • 「第三者由来の資格情報露出」を正式なリスクカテゴリとして定義し、意思決定（強制リセット、アクセス制御強化、一時的ブロック）の閾値と権限を明文化。
  • 従業員向けに、“個人アカウントでの再利用が企業リスクに直結する”ことを端的に説明。パスワードマネージャの利用と、個人・業務の分離徹底を社内標準に。

• CTI運用の勘所

  • HIBPのヒットは“氷山の一角”という前提で、Telegram/フォーラム等のスティーラーログ流通傾向（一般論）をウォッチし、ヒットのない要注意ペルソナにも予防措置を波及。
  • 攻撃者の収益化手口（BEC/不正送金/ギフトカード詐欺/広告アカウント乗っ取り等）に応じ、社内ワークフローの二重承認・金銭取引の検証プロセスを即時強化。

最後に、今回のような“資格情報の供給ショック”は、短期的な波と中期的な持続波の二層で現れます。前者に対しては抑止（リセット/制御強化）、後者に対しては耐性（FIDO化/検知転換/教育）の設計で臨むのが筋です。攻撃者は「正しい資格情報」を得たとき、初動の痕跡を極小化して静かに入ってきます。だからこそ、防御側は“成功後の不自然さ”に目を凝らしながら、アイデンティティを起点にした多層の足止めを重ねるべきです。

参考情報

• HIBP「June 2026 Stealer Logs」: https://haveibeenpwned.com/Breach/June2026StealerLogs
• HIBP ドメイン検索: https://haveibeenpwned.com/DomainSearch
• HIBP API v3: https://haveibeenpwned.com/API/v3
• MITRE ATT&CK T1078（Valid Accounts）: https://attack.mitre.org/techniques/T1078/
• MITRE ATT&CK T1110.004（Credential Stuffing）: https://attack.mitre.org/techniques/T1110/004/
• MITRE ATT&CK T1555.003（Credentials in Web Browsers）: https://attack.mitre.org/techniques/T1555/003/
• MITRE ATT&CK T1539（Steal Web Session Cookie）: https://attack.mitre.org/techniques/T1539/
• MITRE ATT&CK T1133（External Remote Services）: https://attack.mitre.org/techniques/T1133/