日本経済新聞社のSlackへの不正ログイン（社員PCのウイルス感染で認証情報が流出、社員・取引先など17,368人分の情報流出のおそれ）
公表日
日本経済新聞社が業務で使うビジネスチャット「Slack」に不正ログインがあり、社員や取引先など17,368人分の氏名・メールアドレス・チャットの履歴が流出したおそれがあります。
対象者は？
日経のSlackに登録されていた社員と、取引先などの社外の関係者です。最大17,368人で、流出は「おそれ」の段階であり、流出が確定した件数は公表されていません。対象の情報は氏名、メールアドレス、チャットの履歴です。会社は、取材先や取材に関する情報の漏えいは確認されていないと説明しています。
社員と取引先の内訳や、対象者への個別の連絡の有無は公表されていません。仕事で日経とSlackを使ってやり取りしていた方は、公式のお知らせで内容を確認してください。
いますぐできること
- 日経の担当者を名乗るメールで、添付ファイルを開かせたりログインさせたりしようとするものに注意する。やり取りの内容を知っているような文面でも、電話など別の方法で本人に確かめる
- 仕事で使うチャットやメールのアカウントに、二段階認証（多要素認証）を設定する
何が起きたのか
2025年9月、日本経済新聞社が一部の業務で使っているビジネスチャット「Slack」に、外部から不正なログインがあったことが分かりました。不正にログインされたのは社員のアカウントです。Slackに登録されていた17,368人分の氏名、メールアドレス、チャットの履歴が流出した可能性があります。会社は2025年11月4日に日本語と英語で公表しました。
なぜ起きたのか・なぜ広がったのか
会社の説明では、社員の個人のパソコンがウイルスに感染し、Slackにログインするための情報が漏れました。その情報を使って、社員のアカウントに不正にログインされたとみられています。どんなウイルスだったのか、Slackに二段階認証などが設定されていたのか、いつ侵入されたのかは、まだ公表されていません。
いまの状況2025-11-04 時点
会社はパスワードの変更などの対策を行いました。報道目的の個人情報は法律上の報告義務の対象外ですが、個人情報保護委員会に自主的に報告しています。ウイルスの種類、二段階認証の有無、侵入の日時、社員と取引先の内訳は、まだ発表されていません。
企業として考えたいこと
社員が私物のパソコンやスマートフォンから、仕事のチャットやメールにログインできる状態になっていないでしょうか。ログイン情報が盗まれても入られないよう、二段階認証や端末の制限が設定されているか確認しましょう。
技術的な要約
日本経済新聞社が一部業務で利用するビジネスチャット「Slack」に外部から不正ログインがあり、2025年9月に判明した。同社の公表によれば、社員の個人のPC（報道では私物PC）がウイルスに感染してSlackの認証情報が漏えいし、それを使って社員のアカウントに不正ログインされたとみられる。Slackに登録されていた社員・取引先など17,368人分の氏名、メールアドレス、チャット履歴が流出した可能性がある（おそれであり確定ではない）。同社はパスワード変更などの対策を実施し、取材先・取材に関する情報の漏えいは確認されていないと説明、報道目的の個人情報は法定報告の対象外としつつ個人情報保護委員会に任意で報告した。2025年11月4日の公表以降、続報は確認できず、マルウェアの種類・MFAの有無・侵入日時は非公表のまま。同社は2026年10月にもGoogle Workspace・Microsoft 365をめぐる別の不正ログイン事案（2026-nikkei-workspace）を公表している。
公開情報が限られている点について
攻撃の分類
- 侵入口
- 認証情報窃取・流用公表で確認公式（英語版）: "An employee's personal computer was infected with a virus, leading to the leakage of Slack authentication credentials." その認証情報を使って社員のアカウントに不正ログインされたと同社はみている。@ITは日本語版の表現を『私物PC』として伝え、組織の管理が及ばない端末からの流出と整理している。マルウェアの名称・種別（インフォスティーラーか否か）、窃取されたのがID/パスワードのみかセッショントークン（Cookie）を含むか、SlackへのMFA/SSO適用の有無はいずれも非公表。@ITは『ユーザー名、パスワード、場合によってはセッショントークン』が奪われる典型的な流れとして説明しているが、これは記者の推定であり確定情報ではない。
- 脆弱性
- CVE 非公表不明Slack（認証設定）／社員の個人PCソフトウェア脆弱性の悪用は公表されていない。侵入は正規の認証情報による不正ログインで、弱点はSlack側の認証強度（MFA・SSO・端末制限・セッション有効期間）と管理外端末からの業務SaaS利用にあったと考えられるが、同社はMFA等の設定状況を公表していない。
- 攻撃者
- 特定・主張なし
- ATT&CK
影響
- 業務停止
- なし Slackや新聞発行・デジタル配信の停止は公表されていない。対応はパスワード変更等にとどまる。
- データ
- おそれ上限 17,368確定 —人氏名メール業務データ従業員情報取引先情報公表はSlackに登録されていた17,368人分の『氏名、メールアドレス、チャット履歴』が流出した可能性（おそれ）。社員と取引先等の内訳、閲覧・取得が確定した件数、チャット履歴の対象チャンネル（公開/非公開/DM/Slackコネクトの共有チャンネル）は非公表。取材先・取材に関する情報の漏えいは『確認されていない』とされる（漏えいがないことの確認ではない）。
- 波及先
- —
- Slackに登録されていた取引先等の社外関係者（人数内訳は非公表）
- 金銭影響
- —
- サプライチェーン
- SaaS（Slack）自体の侵害ではなく、日経社員の認証情報が悪用された事案。取引先等の情報も流出のおそれがあるが、他組織のシステムへの波及は公表されていない。
時系列
- 2025-09
- 2025-09パスワード変更などの対策を実施（公表は『判明後に実施』のみで日付不明）1
- 2025-11-04
- 2025-11-04CyberInsiderが報道（社員の個人PCのマルウェア感染が起点）5
- 2025-11-05Dark Readingが報道。2019年の米国子会社のBEC被害（約2,900万ドル）や2022年のシンガポール子会社のランサムウェア被害にも言及4
- 2025-11-05 10:25innovatopiaが報道（SNS上で公表の遅れを指摘する反応を紹介）
- 2025-11-06安全内参（SecRSS、中国語）が報道7
- 2025-11-10 08:00@ITが解説記事を掲載（私物PC→認証情報窃取→正規ログイン再現の流れ、EA・Uber・Slack社の類似事例、セッショントークン窃取とMFA疲労攻撃によるMFAの限界を解説）3
- 2026-02-12Acronisが脅威リサーチユニットによる解説を更新（マルウェア種別と攻撃者の踏み込み範囲は公式に未公開と整理）6
- 2026-10-04日本経済新聞社が別事案としてGoogle Workspaceアカウントへの不正ログインとMicrosoft 365でのなりすましメール送信を公表（2026-nikkei-workspace）9
技術解説
攻撃の構造：端末1台の感染からSaaS全体のチャット履歴へ 事実
公表された事実は、(1)社員の個人のPCがウイルスに感染、(2)Slackの認証情報が漏えい、(3)その認証情報で社員アカウントに外部から不正ログイン、(4)Slackに登録されていた17,368人分の氏名・メールアドレス・チャット履歴が流出したおそれ、の4点である。日経の全社的な基盤（AD、メール、CMS等）への侵入やソフトウェア脆弱性の悪用は公表されておらず、攻撃は『正規ユーザーとしてのログイン』で完結している。1アカウント（または少数アカウント）の侵害で万単位の登録者情報が対象になったのは、Slackではワークスペースのメンバー一覧（氏名・メール）が一般ユーザー権限で参照でき、参加チャンネルの履歴も検索・閲覧できるためである。侵害アカウントの数、アクセスされたチャンネルの範囲、判明の契機、ログイン元は公表されていない。
インフォスティーラーとMFAの関係（推測） 解釈
公表はマルウェア名を示していないが、『個人PCの感染→SaaSの認証情報流出→外部からのログイン』という流れは、ブラウザ保存パスワードやセッションCookieを抜き取って売買・悪用するインフォスティーラー（RedLine、Lumma、Vidar等）の典型パターンと一致する。もしパスワードのみが盗まれたのであれば、MFAが有効なら不正ログインは成立しにくい。逆にMFAが有効でもログイン済みのSlackセッションCookie（d cookie等）が盗まれれば、MFAを通過済みのセッションとして再利用され得る。つまり本件は『MFAが未適用だった』か『セッショントークンが盗まれた』かのどちらかである可能性が高いが、日経はいずれも公表していない。講義では、この二択のどちらかで必要な対策（MFA強制か、セッション短縮・端末バインドか）が変わる点を示すとよい。
管理外端末（BYOD）という盲点 解釈
英語版は"An employee's personal computer"、日本語版を引用した@ITは『私物PC』と表現している。私物端末はEDR・資産管理・パッチ管理の対象外であることが多く、感染しても組織側では検知できない。一方でSlackのようなSaaSはインターネット上のどこからでも同じIDでログインできるため、端末管理の境界とSaaSの認証境界がずれている。私物PCでブラウザにSlackのパスワードを保存したり、ログイン状態を保持したりしていた場合、そこから窃取された情報は会社の端末対策をすべて迂回する。報道機関は社外での取材活動が多く、私物端末で業務ツールを使う誘因が大きい業態でもある。なお日経が私物端末からのSlack利用を許可していたのか、規程外の利用だったのかは公表されていない。
被害の重さ：チャット履歴は『文脈つき』の個人情報 解釈
公表された流出項目は氏名・メールアドレス・チャット履歴だが、チャット履歴には業務上のやり取り、取引条件、社内外の人間関係、場合によっては取材に関わる情報が自由記述で含まれ得る。日経は取材先・取材に関する情報の漏えいは『確認されていない』と説明しているが、これは漏えいがないことを確認したという意味ではない。また、氏名・所属・過去のやり取りがそろうと、攻撃者は実在の会話の続きを装ったスピアフィッシングやBEC（日経グループは2019年に米国子会社で約2,900万ドルのBEC被害を受けたと報じられている）を仕掛けやすくなる。17,368人には取引先等の社外の人も含まれるため、二次被害は日経の外でも起こり得る。
公表の評価と、翌年の再発 解釈
判明（9月）から公表（11月4日）まで約1〜2カ月を要し、続報は出ていない。マルウェア種別、MFA有無、侵害アカウント数、不正ログイン期間といったエンジニアが再発防止を判断するための情報はほぼ公表されなかった。一方で、報道目的の個人情報は個人情報保護法の報告義務の対象外であるにもかかわらず個人情報保護委員会へ任意報告した点は、透明性の観点で評価されている（Acronis等）。同社は約11カ月後の2026年10月4日に、Google Workspaceアカウントへの不正ログイン（1,646人分）とMicrosoft 365でのなりすましメール約9,000件という、再び業務SaaS・ID基盤を狙われた事案を公表している（2026-nikkei-workspace）。両事案の侵入経路の関連は公表されていないが、Slack事案の再発防止策がどの範囲（Slackのみか、全SaaSか）に及んだのかが問われる。
対応
- 封じ込め
- 2025年9月の判明後、パスワード変更などの対策を実施（公表）。CyberInsiderはアクセスの見直しも行ったと報道。Slackのセッション失効、MFA/SSOの導入・強制、私物端末からのアクセス制限など具体的な技術的措置は公表されていない。
- 公表の仕方
- 2025年11月4日に日本語・英語のお知らせ各1本で公表。流出項目と人数（17,368人）、感染→認証情報漏えい→不正ログインという経緯、取材情報の漏えいが確認されていないこと、個人情報保護委員会への任意報告を記載。マルウェア種別・MFA有無・侵入日時・侵害アカウント数は非公表で、続報なし。判明から公表まで1カ月以上空いた。
- 当局対応
- 個人情報保護委員会：報道・著述目的の個人情報は個人情報保護法の漏えい等報告義務の対象外としつつ、透明性確保のため任意で報告（日経公表）
教訓と対策
| 教訓 | 具体的な対策 |
|---|---|
| 管理外の個人PCで業務SaaSの認証情報が扱われ、感染してもSaaS側で防げなかった | IdP（Entra ID／Google／Okta）のSSOをSlackに強制し、条件付きアクセスで準拠端末（MDM登録・EDR稼働）以外からのログインを拒否する。Slack Enterprise GridならSSO必須化と承認済みデバイスの制限、Business+ならSSO＋IdP側のデバイス条件で代替する |
| パスワードのみ、または長期間有効なセッションで外部ログインが成立した可能性 | フィッシング耐性MFA（FIDO2/パスキー）を全員に強制し、Slackのセッション有効期間を短縮（例: 12〜24時間）。漏えい疑いの際はパスワード変更だけでなく管理APIで全セッションを失効（Admin APIの admin.users.session.reset 等）させる手順をランブックに入れる |
| インフォスティーラー由来の認証情報流出を自社で早期に把握する仕組みがない | 自社ドメインのメールアドレス・SaaSのURLを対象にスティーラーログ／ダークウェブ監視サービスを契約し、ヒット時は該当ユーザーのセッション失効とパスワードリセットを自動化。ブラウザへの業務パスワード保存をポリシーで禁止し、パスワードマネージャを配布する |
| 1アカウントの侵害でワークスペース全体の登録者情報と多数チャンネルの履歴が対象になった | Slackの監査ログ（Audit Logs API）をSIEMに取り込み、新規IP/ASN/国からのログイン、短時間の大量検索・ファイルダウンロード・メンバー一覧取得をアラート化する。機微な議論はプライベートチャンネルに限定し、メッセージ・ファイルの保持期間を設定して履歴の母数を減らす |
| 同一組織で1年以内に別の業務SaaS（Google Workspace／Microsoft 365）でも不正ログインが発生 | 事案対応の再発防止を侵害されたSaaSだけで閉じず、全SaaSを棚卸しして同じ認証基準（SSO統合・MFA・端末条件・セッション期限・監査ログ連携）を一括で適用する。SSPMツールで各SaaSの設定逸脱を継続監視する |
自組織などでの確認項目
- あなたの会社のSlack（またはTeams/Chatwork）に、私物PCのブラウザからID・パスワードだけでログインできるか。できる場合、そのPCがインフォスティーラーに感染していたら何が盗まれ、どれだけの期間使われ得るか。
- 社員1人のアカウントが乗っ取られたとき、攻撃者が閲覧できる社内外の人数とチャンネル数を即答できるか。Slackコネクト等で取引先とつながっている場合、相手先への通知は誰がどう判断するか。
- パスワードを変更すれば攻撃者は締め出せるか。既存のセッショントークンやアプリトークンを失効させる手順と権限が、インシデント時に確実に実行できる状態になっているか。
- チャット履歴に流れている情報（顧客情報・認証情報・契約条件など）のうち、漏えいすると最も困るものは何か。それはチャットに置き続ける必要があるか。
未解明点
- 感染したマルウェアの名称・種別（インフォスティーラーか）と、私物PCからSlackを利用することが社内規程で許可されていたか
- 窃取されたのがID/パスワードのみか、セッショントークン（Cookie）を含むか。SlackへのMFA/SSO適用状況
- 不正ログインの期間・回数・侵害アカウント数・ログイン元、アクセスされたチャンネルとダウンロードされたデータの範囲
- 17,368人の内訳（社員・取引先・その他）と取引先等への個別通知の有無
- 判明の契機（Slackのアラート、外部からの通報、社内監視など）と、判明から公表まで約1〜2カ月を要した理由
- 本件の再発防止策の範囲と、2026年に公表されたGoogle Workspace／Microsoft 365事案（2026-nikkei-workspace）との関連の有無
出典
- 1Nikkei Inc.2025-11-04公式本文確認済
- 2日本経済新聞社2025-11-04公式未確認
- 3@IT（アイティメディア）2025-11-10報道本文確認済
- 4Dark Reading2025-11-05報道本文確認済
- 5CyberInsider2025-11-04報道本文確認済
- 6Acronis（脅威リサーチユニット）2026-02-12研究者本文確認済
- 7安全内参（SecRSS）2025-11-06報道本文確認済
- 8
- 9日本経済新聞社2026-10-04公式未確認