情報処理安全確保支援士
masazan (masazan)
情報処理安全確保支援士のmasazanと申します。
サイバーセキュリティ情報をわかりやすく発信します！
～～～セキュリティの基本を体系的に学べます～～～
先日、J:COMからメールアドレス漏えいの通知が届きました。
「メールアドレスの流出だけか、パスワードが漏れていないから大丈夫」と思うかもしれません。
しかし、メールアドレスの漏えいは自身が攻撃されるだけでなく、なりすましや他サービスへのログインIDとして悪用される可能性があります。
一方で、プロバイダ側で発生した情報漏えいを利用者本人が防ぐことは困難です。
つまり、利用者としてできる対策には玄関があります。
この記事では、前半で利用者目線のリスクを整理し、後半では一人情シス・メール管理者の視点から対策を考えます。
実際に届いたKDDI/J:COMの漏えい通知
今回、J:COMから「【重要】お客さまのメールアドレス漏えいに関するお詫びとお知らせ」という件名のメールが届きました。
通知メールでは、対象のJ:COM NETメールアドレスが第三者に取得されたことが説明されています。
私に届いた通知では、漏えいした情報は「メールアドレス」のみであり、氏名やパスワードなどのその他の個人情報は漏えいしていないと記載されていました。
ただし、KDDI関連の公表全体を見ると、対象サービスによってはメールアドレス以外の情報が漏えいした可能性にも触れられています。
参考：2026年6月23日 KDDI株式会社 ISP 事業者向けメールシステムに対する不正アクセスの発生について
今回私に届いた通知で対象となっていたのは、メールアドレスのみでした。
では、「メールアドレスだけ」であれば軽く見てよいのでしょうか？
「メールアドレスだけなら大丈夫」とは言い切れない
今回、私に届いたJ:COMの通知では、漏えいした情報にパスワードは含まれていませんでした。
パスワードを強固にしたりMFAを設定したりすれば、メールサービスへ不正ログインの危険性を低減できます。
そのため、「パスワードが漏れていないなら大丈夫」と考えたくなります。
しかし、メールアドレスが漏えいした影響は、自分のアカウントにログインされるかどうかだけではありません。
メールアドレスは攻撃者にとって価値がある
メールアドレスの漏えいには、少なくとも次のようなリスクが考えられます。
- フィッシングメールや迷惑メールが自身に届く可能性
- 他サービスへのログインIDとして使われる可能性
- フィッシングメールや迷惑メールが、自分のメールアドレスから発信されたように見せかけられる可能性
1つ目は、自分宛てに不審メールが届くリスクです。漏えいしたメールアドレスが送信先リストとして使われれば、フィッシングメールや迷惑メールが増える可能性があります。
この問題は、自身が注意してメールをチェックすることである程度の対処が可能です。
2つ目は、ログインIDとして利用されるリスクです。メールアドレスをIDにしているサービスでは、パスワードリスト攻撃や他の漏えい情報との組み合わせに使われるおそれがあります。
この問題も、パスワードを強固にしMFAやパスキーの設定などである程度の対処が可能です。
自分のメールアドレスが送信元のように見せかけられる可能性
もう1つ厄介なのが、3つ目の「自分のメールアドレスが送信元のように見せかけられる」ケースです。
これは、攻撃者が差出人を偽装し、自分のメールアドレスから送られたように見せかけるケースになります。
つまり、自分の知らないところで、自分のメールアドレスが他人をだます材料に使われる可能性もあるのです。
メールアドレス漏えいの問題は、自分だけでなく他者にも影響を与える問題でもあります。
通知が届く前に、不審メールが来ている可能性もある
私が使用しているサービスはJ:COM NETです。私にメールアドレス漏えいの連絡が来る前にまでにいくつか気になる点がありました。
ここではその気になる点を整理していきます。
今回気になった時系列
今回気になったのは、通知と不審メールの時系列です。
KDDIは2026年6月23日に、ISP向けメールシステムへの不正アクセスについて公表しています。
参考：2026年6月23日 KDDI株式会社 ISP 事業者向けメールシステムに対する不正アクセスの発生について
この時点で、KDDIが提供するISP向けメールシステムで不正アクセスがあったことはわかりました。
ただし、自分が利用しているJ:COM NETのメールアドレスが対象かどうかは、まだ不明です。
また、KDDIの後続報告では、2026年6月17日に不正アクセスを確認し、同日にシステム改修を実施したと説明されています。
参考：2026年7月6日 KDDI株式会社 ISP 事業者向けメールシステムに対する不正アクセスについての お詫びとご報告
さらに、一部ISP事業者では2026年5月16日から不正アクセスが発生していたとも説明されています。
一方で、J:COMから私宛てに漏えい通知が届いたのは2026年7月14日です。
そして、その前の2026年6月24日に、Amazonを装う不審メールを確認していました。
当時はBIGLOBEが送信元のメールが多いと言う感想を持っていました。（BIGLOBEもメールアドレス漏洩の対象）
これを発生した順に並べると以下のようになります。
| 日付 | 出来事 |
| 2026年5月16日 | 一部ISP事業者で不正アクセスが発生していたとKDDIが後続報告で説明 |
| 2026年6月17日 | KDDIが不正アクセスを確認し、同日にシステム改修を実施 |
| 2026年6月23日 | KDDIがISP向けメールシステムへの不正アクセスを公表 |
| 2026年6月24日 | Amazonを装う不審メールを確認 |
| 2026年7月14日 | J:COMからメールアドレス漏えい通知が届く |
少なくとも私の場合、7月14日に通知が届くまでは、自分のメールアドレスが対象だったとは把握できませんでした。
この不審メールが漏えい由来とは断定できない
もちろん、この不審メールが今回のKDDI/J:COMの漏えいに起因するとは断定できません。
メールアドレスは別の経路で漏れていた可能性もあります。
ただし、利用者目線で重要なのは、「正式な通知が届く前に、不審メールが届いていてもおかしくない」という点です。
漏えいの発生、事業者による確認、公表、個別通知には時間差があります。
攻撃者が先にメールアドレスを入手していれば、利用者が通知を受け取る前に不審メールが届いてもおかしくありません。
つまり、利用者が漏えいを知る前に、すでに攻撃が始まっている可能性もあるのです。
不審メールを受け取った時の基本対応
企業が漏えいを公表するには、影響範囲の確認や関係先との調整が必要です。
そのため、利用者への個別通知までにはどうしても時間差が生じます。
しかし、私たち一般ユーザにとって「漏えいした事実がわからない」状態で、フィッシングによる攻撃を受けるおそれがあります。
今回確認した不審メールでは、URLをVirusTotalで確認したところ、92ベンダー中2件が悪性として判定していました。
リンク先がフィッシングサイトの可能性があるため、安易にアクセスしない判断が必要です。
詳しいフィッシングメールの解析方法については、以前の記事でまとめています。よろしければご参照ください。
また、不審メールを受け取った側でできる対策としては以下のような対策が考えられます。
- メール本文のURLを押さない
- 公式アプリやブックマークから確認する
- パスワードを使い回している場合は変更する
- MFAを有効化する
不審なメールや詐欺サイトから身を守る基本的な考え方は、以下の記事で詳しく解説しています。よろしければご覧ください。
これらの対応を行っていなければ、うっかり不審メールのURLをクリックしてしまい、フィッシング被害にあうおそれがあります。
情シスが確認したい、なりすまし対策のポイント
ここまでは、漏えい通知や不審メールを受け取った側の視点で整理してきました。
しかし、メールアドレスが漏えいすることや、自分のメールアドレスが第三者へのなりすましに使われることを、受け取った側だけで完全に防ぐことはできません。
ここからは、情シス・メール管理者の視点で、組織としての対策を考えます。
なりすましは正規メールまで疑われる原因になる
なりすましメールの問題は、受信者がフィッシング被害に遭うことだけではありません。
自社名や自社ドメインを使った不審メールが出回ると、受信者は「この会社から怪しいメールが来た」と感じる可能性があります。
IPAも、メールを悪用した攻撃では「相手に対する信頼感を逆手に取り」ターゲットをだますソーシャルエンジニアリングの手法が使われると説明しています。
参考：独立行政法人 情報処理推進機構（IPA） 企業組織を狙うメールを悪用した攻撃の手口とその対策
自社ドメインを騙るメールが出回れば信頼感自体が損なわれ、受信者は「この会社は怪しいメールを送ってくる」という印象を持ちかねません。
そのため、本物の問い合わせ対応メールや請求メールまで「怪しいのでは」と身構えられたり、「本当に貴社から来たものか」と問い合わせが増えたりする実害につながります。
つまり、なりすましメールは「受信者がだまされる問題」であると同時に、「なりすまされた側の正規メールまで疑われる問題」でもあります。
だからこそ、利用者の注意喚起だけに頼るのではなく、自社ドメインを騙るメールを見抜きやすくする仕組みを整える必要があります。
メールのなりすましを低減する対策
こうしたメールが正規に送られたものかを検証する技術として使われるのが、SPF・DKIM・DMARCという仕組みです。
| 対策 | 何をする仕組みか |
| SPF | そのドメインからメールを送ってよいサーバーを示す仕組み |
| DKIM | メールに電子署名を付け、送信元ドメインや改ざん有無を確認する仕組み |
| DMARC | SPF・DKIMの結果とFromドメインの整合性を見て、認証失敗時の扱いを決める仕組み |
SPF・DKIM・DMARCは万能ではありませんが、自社ドメインを騙るメールを受信側で判定しやすくするための重要な仕組みです。
情シスがまず見るべきポイント
まずは、自社ドメインの状態を把握することが重要です。
確認したい項目は、たとえば次のようなものです。
- SPF・DKIM・DMARCが設定されているか
- 古い送信元や使っていない外部サービスが残っていないか
- 問い合わせフォームや配信サービスのメールが認証に通っているか
内閣官房国家サイバー統括室が公開している会議資料「安全基準等策定ガイドライン案の検討（総務省）」では、DMARCの設定について、通信事業者だけの対応では効果が限定的であり、メールサーバやドメインを運用する側も幅広く対応する必要があると説明されています。
出典：内閣官房 国家サイバー統括室「重要インフラサイバーセキュリティ対策推進会議 課長級会議（第6回）」資料7「安全基準等策定ガイドライン案の検討（総務省）」 P2
まずは「自社ドメインが今どうなっているか」を確認するところから始めればよいでしょう。
送信ドメイン認証は万能ではないが、やらない理由にはならない
メール認証対策を設定しても、次のようなフィッシング攻撃は残ります。
- 似たドメイン（microsoft の m に見えるように、r と n を並べた紛らわしいドメインを使う）を使う攻撃
- 表示名を偽装するメール
- IDとパスワードが盗まれ、正規サービスが乗っ取られるケース
- Google WorkspaceやMicrosoft 365など正規クラウドサービスを悪用するケース
※表示名を偽装するメールとは、以下の画像のように表示名とメールのドメインが合わない状態になります。
メール認証は「そのドメインから正しく送信されているか」を確認する仕組みです。
本文の内容が安全であることや、実在する企業からの正規メールであることまでは保証しません。
それでも、送信ドメイン認証の整備は、自社ドメインをそのまま騙るメールを減らし、正規メールを信頼してもらうためのベースになります。
万能ではありませんが、やらなくてよい理由にはなりません。
まとめ：「メールアドレスだけ漏えい」は軽く見ない
メールアドレスだけの漏えいは、パスワード漏えいと比べると軽く見られがちです。
しかし、メールアドレスはフィッシングメールの送信先にも、なりすましの材料にもなります。さらに、他サービスのログインIDとして使われる可能性もあります。
もちろん、受け取った側でできる対策はありますが、自分のメールアドレスが第三者へのなりすましに使われているかどうかを、個人が把握するのは困難です。
だからこそ、情シスやメール管理者はなりすましを見抜きやすい仕組みを整備する必要があります。
「メールアドレスだけだから軽微」と受け止めるのではなく、個人の注意喚起と組織側の仕組みづくりを分けて考えることが重要です。
※当ブログの一部画像はGoogle NotebookLMを利用しています。
コメント