リスト型攻撃事例から見る被害と対策の判断軸

リスト型攻撃（パスワードリスト攻撃）について、最近の不正アクセス・情報漏えい事案を受けて「自社でも同様の不正ログインが起きるのか」「起きた場合にどこまで被害が広がるのか」を、経営・法務・運用の観点で整理したい場面が増えています。放置すると、ポイント不正利用や登録情報変更などの不正操作だけでなく、個人情報保護委員会への報告要否が問題となる類型（本人の数が1,000人を超える個人データの漏えい等）に該当し得る局面で、初動判断が遅れて事業影響が拡大しかねません。以下では、被害の典型パターンとリスク評価の観点、実務での対策・初動の判断材料として押さえるべき点を示します。

リスト型攻撃の基本

リスト型攻撃の仕組み

リスト型攻撃（パスワードリスト攻撃）は、攻撃者が他サービスから漏えい・窃取されたID（メールアドレス等）とパスワードの組み合わせを入手し、標的サービスのログイン画面へ自動投入して不正ログインを狙う手法です。標的側から見ると「自社から認証情報が漏れていない」場合でも、利用者が他サービスと使い回しをしていれば成立します。

攻撃は、一般に次の流れで進みます。

総当たり（ランダムな文字列を片端から試す）と異なり、最初から「実在する可能性が高い認証情報」を投入するため、試行が効率化しやすい点が特徴です。また攻撃者は、送信元を分散して試行することで、単純なIP制限や監視をすり抜けることがあります。

他の認証攻撃との違い

リスト型攻撃の本質的な違いは、推測ではなく、漏えい等で得た認証情報を流用する点にあります。推測型の攻撃は、対策が「複雑なパスワード」「試行回数制限」で効きやすい一方、リスト型攻撃は使い回しがある限り突破され得ます。

参照されやすい認証攻撃は、次のとおりです。

実務上は、これらが単独で行われるとは限らず、リスト型攻撃と推測型攻撃が併用されることもあります。そのため「推測されにくいパスワード」だけで安心せず、後段の多要素認証や検知・遮断まで含めた防御設計が重要です。

リスト型攻撃が起きる原因

情報漏えいと使い回し

リスト型攻撃が成立する最大要因は、利用者が複数サービスで同一または類似のパスワードを使い回すことです。使い回しがあると、漏えいが起きたのが他社であっても、自社側のアカウント侵害につながります。

また、攻撃者は「標的型（特定企業を狙う）」だけでなく、手当たり次第に試すランダム型で効率よく当たりを探す傾向があります。規模の大小にかかわらず、偶発的に攻撃の網にかかる可能性があるため、自社の知名度だけでリスクを判断しないことが重要です。

システム側の弱点

リスト型攻撃は「認証情報さえ一致すれば正規利用者として扱われる」という性質を突くため、システム側の設計・運用の弱さがあると被害が拡大します。特に、知識情報（パスワード等）だけの認証に依存していると、認証情報が漏れた時点で防御が崩れます。

認証情報が窃取された場合に備え、可能な限り多要素認証を取り入れることが示されています。多要素認証は、知識情報（パスワード等）に加えて、所持情報（SMSやワンタイムパスワード）や生体情報（指紋・顔等）を組み合わせ、2つ以上で認証する考え方です。

また、ログを取得していても「確認する術がない」「解析されず放置される」状態が多い点も実務上の落とし穴です。アクセス数やCPU・メモリ・トラフィック等の異常値を検知するため、閾値（しきいち）を設定し、アラートを自動通知する仕組みの整備が有効です。

自社が狙われやすいかを見極める判断基準──会員数・保有情報・決済機能の有無で見る優先度

自社が標的になりやすいかは、「攻撃者が得る利益」と「当たりやすさ（試行の効率）」で概ね決まります。会員数が多いほど命中が出やすく、保有情報が濃いほど二次被害や換金性が上がります。

また、漏えいの「確証」がない段階でも、個人情報保護法のガイドライン（通則編）でいう「おそれ」は、当時点で判明している事実関係から漏えい等が疑われるが確証がない場合を含む、と整理されています。リスト型攻撃は「侵入痕跡はあるが、閲覧・取得の確証が取りにくい」局面があるため、この「おそれ」判断を前提に、初動・報告の体制設計が必要です。

リスト型攻撃の被害事例

国内事例に共通する流れ

国内の不正アクセス事案では、攻撃→不正操作→発覚という流れが繰り返し見られます。の事例でも、犯人がIDとパスワードを入力してWebサーバを作動させ、アクセス制御を回避して不正アクセスした上で、利用者の承諾なく商品購入に至った旨が記載されています。

実務では、攻撃者が「手当たり次第（ランダム型）」で試すため、特定業界・大企業に限らず発生し得ます。したがって、発覚契機が利用者申告に偏る状態（監視が弱い状態）を前提にせず、ログ監視・アラートで早期に検知できる設計が重要です。

個人情報と金銭被害

リスト型攻撃は、不正ログインにより「閲覧され得る情報」と「実行され得る操作」が増えるほど被害が大きくなります。個人情報面では、氏名・住所・電話番号・メールアドレス等の流出が二次被害（詐欺、なりすまし等）につながります。

財産的被害の観点では、個人情報保護委員会の整理として「不正に利用されることにより財産的被害が生じるおそれがある個人データ」の例にクレジットカード番号の漏えい等が挙げられています。この種の情報を扱うサービスでは、不正ログインは単なるアカウント侵害にとどまらず、法令対応（報告・本人通知）と補償・返金が同時に発生し得ます。

被害が大きくなりやすい会社の共通点──ログイン後に住所変更・ポイント利用・登録情報更新ができる場合

被害が拡大しやすいのは、「ログインできたこと」をもって、その後の重要操作まで一括して許可してしまう設計・運用です。の事例でも、不正ログイン後に利用者の承諾なく商品購入が行われています。

実務の対策設計では、「ログイン後の重要操作」に対し、追加認証（多要素認証、再ログイン、確認コード等）や、操作前後の通知・保留（一定時間の猶予）といった制御を入れるかを、被害の換金性に応じて決める必要があります。

狙われやすいアカウント

標的になりやすいWebサービス

標的になりやすいのは、攻撃者が「当たり」を取りやすく、かつ不正利用後に利益化しやすいサービスです。EC、ポイント、サブスクリプション、会員制サービスは典型で、会員数が多いほど試行の効率が上がります。

また、攻撃は認証画面だけでなく、侵入経路としてVPN機器の脆弱性や、公開されたリモートデスクトップ（RDP）、SSH等を手当たり次第に試す動きも指摘されています。リスト型攻撃の主戦場はWebログインであっても、実務上は「周辺の入口」が弱いと、認証情報窃取や運用アカウント侵害を経由して最終的に会員基盤へ波及するため、入口の棚卸が必要です。

休眠アカウントと認証運用

休眠アカウントは、本人が気づきにくく、攻撃者が不正利用しても発覚が遅れがちです。さらに、過去の弱いパスワードポリシーのまま残っていると、推測型攻撃とも組み合わさりやすくなります。

リソース種別（コンピューター、ネットワーク機器、クラウドサービス等）を問わず、アカウント共通の対応として次が挙げられています。

休眠アカウントの管理は、単に「放置しない」では足りず、失効・無効化・再有効化時の本人確認、監視強化など、ライフサイクルとして運用設計する必要があります。

BtoC会員向けと管理者アカウントで対策を分けるべき理由──侵害時の事業影響が違う

会員アカウントは被害が「個別顧客単位」に留まる場合がある一方、管理者アカウント（特権ID）が侵害されると、被害は「全社・全顧客」に拡大します。Enterprise Admins や Domain Admins など高権限グループについて、許可すべきでないユーザーや不適切なアカウントがないか確認し、見つかった場合はまず無効にする旨、また削除する場合はレプリケーションメタデータを含む保全が望ましい旨が示されています。

企業が取るべき対策

不正アクセス検知とログ監視

リスト型攻撃の現実的な防御は、「完全に防ぐ」だけでなく、早く気づいて止める設計が重要です。ハッカーが侵入した段階やファイルを盗み出そうとした段階で早期発見できれば、被害を最小化できた可能性があるとして、一定条件でアラートを発する仕組みの検討が示されています。

ログは「取っている」だけでは足りず、アラート運用（誰が、何分以内に、どの判断で遮断するか）まで含めて統制しないと、利用者申告まで発覚が遅れるリスクが残ります。

認証強化とログイン試行制限

認証情報が窃取される前提で考えると、知識情報だけの認証から脱却し、多要素認証を適用することが柱になります。パッチ適用で脆弱性を塞いでいても認証情報が窃取されれば侵入され得るため、認証方法に可能な限り多要素認証を取り入れるべき、とされています。

多要素認証は、次の要素のうち2つ以上を組み合わせます。

また、リスト型攻撃は自動化されやすいため、試行制限（レート制限、ロックアウト）は「推測型攻撃だけの対策」ではなく、運用妨害や当たり探索の効率を落とす意味で重要です。にあるとおり、アカウントロックは一定回数ログインに失敗したときにロックをかける設定であり、総当たり系への対策として位置付けられます。

社内で誰が何を決めるか──情シス・開発・CS・法務で事前合意しておく運用項目

インシデント対応は、発生後に協議を始めると遅れます。事前に「止める判断」「連絡する判断」「保全する判断」を合意しておくことが、事業影響と法的リスクを同時に抑える前提になります。

クラウドサービスの初動対応として、窃取された認証情報がクラウドサービスの認証情報である場合の対応例として、全アカウントの認証情報のリセットと多要素認証の導入が挙げられています。会員サービスでも、SaaS（問い合わせ管理、MA、決済管理等）と連携している場合は、同様に「連携先も含めて」意思決定できる体制が必要です。

被害時の初動と法務対応

初動対応の優先順位

初動は「被害拡大の防止」と「後で説明できる記録の確保」を同時に行います。被害者が利用者Aからの報告を端緒に管理部門が調査を開始し、特定時間帯の不正ログイン痕跡がアクセスログに保存されていることを発見した旨が記載されています。すなわち、ログ等の証跡が残っていることが、事実認定と外部説明の基盤になります。

加えて、管理者権限の侵害が疑われる場合は、にあるとおり「意図しないログオン元機器がある場合は侵害可能性を考慮し、機器を隔離・保全する」発想で、会員基盤だけでなく管理系端末・踏み台化も含めて初動を組み立てます。

報告公表と個人情報保護法

個人情報保護法では、個人情報保護委員会への報告対象となる事態が整理されています。報告対象として次の類型が挙げられています（実務での切り分けに直結します）。

また「おそれ」の解釈について、個人情報保護法ガイドライン（通則編）では、当時点で判明している事実関係から漏えい等が疑われるが確証がない場合も含む、とされています。リスト型攻撃では、侵入の痕跡がある一方で取得の確証が難しい局面があるため、法務・情シスがこの定義を共有しておくことが重要です。

なお、本文中にある「速報を3〜5日」「確報を60日以内」といった期限・日数は、に明示の根拠がないため、本稿では断定的な運用期限としては置かず、社内では個人情報保護委員会の公表資料・ガイドラインに基づき確認する前提で整理してください。

不正アクセス禁止法と個人情報保護法をどう切り分けるか──法務確認で外しやすい論点

不正アクセス事案では、「攻撃者を処罰する枠組み」と「事業者の管理責任の枠組み」を混同しやすい点が落とし穴です。

• 不正アクセス禁止法は、ID・パスワード等を用いた不正なアクセス行為などを規制し、攻撃者側の責任を問う枠組みです。
• 個人情報保護法は、個人データを取り扱う事業者に対し、安全管理措置や、漏えい等が起きた場合の報告・通知等を含む対応を求める枠組みです（個人情報保護法）。

にも、盗み取ったID・パスワードでログインする行為は不正アクセス罪に該当し得る旨、また警察への届け出を行うべき旨が示されています。一方で、個人情報保護法の側では、サイバー攻撃による漏えい等は「不正の目的をもって行われたおそれのある漏えい等」に該当し得るため、被害者として捜査協力を進めながら、管理者としての法令対応（報告・本人通知等）を同時並行で進める必要があります。

よくある質問

リスト型攻撃とパスワードリスト攻撃は同じ意味ですか？

はい、実務上は同義で扱われます。いずれも、他サービス等から入手したID（メールアドレス等）とパスワードの組み合わせを用いて、別サービスへ不正ログインを試みる攻撃です。

また、呼称が違っても対策の要点は共通で、でもアカウント共通対応としてアカウントロックの設定、パスワードリセット、多要素認証の導入が挙げられています。名称に引きずられず、被害シナリオ（不正ログイン→重要操作）に沿って対策を設計してください。

自社で被害の有無を確認するにはログのどこを見ればよいですか？

被害確認は「認証ログ」と「ログイン後の重要操作ログ」を突合して行います。アクセスログから不正ログインの痕跡を発見した旨が示されており、ログが事実認定の中心になります。

中小企業でも導入しやすい多要素認証には何がありますか？

多要素認証は、知識情報に追加して、所持情報または生体情報を組み合わせる考え方です。実現手段としてSMS送信やワンタイムパスワード、指紋・顔認証・静脈認証などが挙げられています。

中小企業では「全ユーザー一律で強制」か「高リスク操作のみ追加認証」かの設計が重要で、特に決済・ポイント・連絡先変更などから優先的に適用範囲を決めると、負荷と効果のバランスを取りやすいです。

情報漏えいが疑われる場合はいつ報告や公表を行うべきですか？

個人情報保護法では、個人情報保護委員会への報告対象となる類型として、にあるとおり、要配慮個人情報、財産的被害のおそれ、不正目的による漏えい等、1,000人超、そしてこれらの「おそれ」が示されています。

したがって、リスト型攻撃が疑われ、上記類型に該当する可能性がある場合は、確証が揃うまで待つのではなく、まずは事実関係の整理と並行して、報告・本人通知・公表の要否を法務が判断できるよう情報を集約することが実務上の出発点になります。特に「おそれ」は、当時点で判明している事実関係から疑われるが確証がない場合も含むため、情シスと法務が同じ定義で判断できるよう、ログ・操作履歴・影響データ項目を早期に取りまとめることが重要です。

リスト型攻撃への対応で次にすべきこと

リスト型攻撃は、他社起点の漏えいと利用者の使い回しを前提に成立するため、「自社から漏れていない」だけではリスク評価にならず、ログ監視・検知と重要操作の追加認証まで含めた設計が必要です。被害事例の典型は、不正ログインの試行増加から始まり、住所変更やポイント利用、購入といった不正操作を経て、利用者申告で発覚する流れであり、早期に気づける運用が事業影響を左右します。法務面では、個人情報保護委員会への報告対象に「本人の数が1,000人を超える個人データの漏えい等」や各類型の「おそれ」が含まれるため、確証の有無だけで判断を先送りしない整理が重要です。次のアクションとして、情シス・開発・CS・法務で、アラート閾値、遮断判断、証跡保全、本人通知・公表の判断材料を事前合意し、必要に応じて外部専門家にも相談できる体制を整えてください。個別の事案では事実関係と適用法令の整理が前提になるため、最終判断は専門家の助言も踏まえて進めるのが安全です。

Baseconnect株式会社
サイト運営会社

本メディアは、「企業が経営リスクを正しく知り、素早く動けるように」という想いから、Baseconnect株式会社が運営しています。

当社は、日本最大級の法人データベース「Musubu」において国内1200万件超の企業情報を掲げ、企業の変化の兆しを捉える情報基盤を整備しています。

加えて、与信管理・コンプライアンスチェック・法人確認を支援する「Riskdog」では、年間20億件のリスク情報をAI処理、日々4000以上のニュース媒体を自動取得、1.8億件のデータベース等を活用し、取引先の倒産・不正等の兆候の早期把握を支援しています。

運営会社情報ページへ