日経の不正アクセスとなりすましメール約9,000件｜M365・Google Workspace乗っ取りの調査手順

日本経済新聞社は2026年10月4日、社員が業務で使っていたMicrosoft 365とGoogle Workspaceのアカウントに第三者が不正にログインしていたと公表しました。Microsoft 365からは9月30日に社内や取材先へなりすましメール約9,000件が送られ、Google Workspaceでは社員や取引先など1,646人分の氏名とメールアドレスが漏えいした可能性があります。同じ日に公表されたのは、日経社員のアドレスから届いたフィッシングメールで認証情報を取られたという日経BPの事案です。本記事では三つの公表を事案ごとに整理したうえで、業務SaaSのアカウントを乗っ取られた組織の管理者が回す封じ込めと調査の手順を、Exchange Online PowerShellとGoogleのReports APIの実行例で示します。なりすましメールを受け取った側の確認と、再発防止にどこまで投資するかの判断も扱います。

まとめ：日経の不正アクセスで公表された事実と管理者・受信者が今日やること

公表で確定しているのは、Microsoft 365とGoogle Workspaceという別々のクラウドで、それぞれ社員アカウントへの不正ログインがあったことです。Microsoft 365の件は9月30日のなりすましメール約9,000件、Google Workspaceの件は7月下旬以降の不正ログインで8月上旬にGoogleの通知で判明しました。どちらもパスワード変更後の不正ログインは確認されていないとしています。一方、日経の2件の侵入経路は公表文に書かれていません。

管理者の打ち手は、アカウントを止める、セッションを失効させる、転送ルールと登録済みMFAとアプリ同意を洗う、送信履歴とログイン履歴を遡る、の順です。パスワードの変更だけでは、攻撃者が仕込んだ転送設定やアプリの権限が残ります。受信した側は、9月30日前後に日経関係者名義で届いたメールのリンクを開いていないかを確かめ、開いて認証情報を入れていれば自社のアカウントを同じ手順で点検します。

Microsoft 365・Google Workspace・日経BPの公表事案

Microsoft 365の9月30日のなりすましメール約9,000件と送信先

日本経済新聞社の「サイバー攻撃による情報漏洩、不審メールの送信について」（2026年10月4日）によると、社員が使っていたMicrosoft 365のアカウントに第三者が不正にログインしたとみられ、9月30日に悪性サイトへ誘導するメール約9,000件が送られました。送信先は社内と、複数の社員とやりとりがあった取材先などです。

漏えいのおそれがあるのは、送信先のメールアドレスと氏名、一部のメールの内容です。同社は個人情報保護委員会へ報告し、侵害の範囲と件数を調べています。送信先には個別に連絡してメールの削除を依頼し、同社やグループ会社の関係者を名乗るメールが増える可能性があるとして注意を呼びかけています。

Google Workspaceの7月下旬の不正ログインと8月上旬のGoogle通知

もう一件は「不正ログインによる情報漏洩について」で公表されました。社員が業務で使っていたGoogle Workspaceのアカウントに7月下旬以降、外部から不正ログインされ、8月上旬にGoogleからの通知で判明しています。同社はすぐにパスワードを変更し、それ以降の不正ログインは確認されていません。

漏えいの可能性があるのは社員や取引先などのメールアドレスと氏名1,646人分で、読者や取材先の情報は含まれないとしています。二次被害も確認されていません。注目すべきは時間の幅です。侵入は自社の監視ではなくGoogleの通知で見つかり、判明から公表までおよそ二か月かかっています。

日経BPの26件が示す取引先経由の連鎖と公表文から書けないこと

日経BPの「メール不正アクセスによる個人情報の漏えいについて」では、9月30日に従業員のメールアカウントへの不正アクセスが判明しました。原因は「日本経済新聞社社員のメールアドレスで届いたフィッシングメールから、認証情報を入手されました」と書かれています。漏えいのおそれは個人名とメールアドレスの26件です。

一つの組織で乗っ取られたアカウントが、取引のある別の組織の認証情報を取る道具に使われた構図です。ただし、日経のMicrosoft 365、Google Workspace、日経BPの3件が同じ攻撃者によるものかは公表されていません。日経の2件がどのような手口で始まったかも不明です。本記事では、そこを推測で埋めずに進めます。

業務SaaSアカウントの乗っ取りで攻撃者が得るもの｜送信元の信用・メール本文・取引先名簿

正規アカウントから送られるなりすましメールがSPF・DMARCを通過する理由

今回のメールは、偽のドメインからではなく社員本人のMicrosoft 365アカウントから送られています。送信サーバーも署名も正規のものなので、SPF・DKIM・DMARCの検証はすべて成功します。送信ドメイン認証は「そのドメインの正規のサーバーから送られたか」を確かめる仕組みで、「本人が書いたか」は判定できません。仕組みの詳細はDMARCの仕組みとnone・quarantine・rejectの差で整理しています。

受信者から見ると、過去にやりとりした記者から届いた、認証にも通ったメールです。受信側のフィルタも疑う材料を持ちません。乗っ取りの被害が自社の中で終わらず、取引先へ広がりやすいのはこのためです。

パスワード変更だけでは止まらない転送ルール・アプリ同意・登録済みMFA

Microsoftの侵害されたメールアカウントへの対応手順は、侵害の兆候として、外部アドレスへの自動転送ルール、メッセージを迷惑メールやRSSフォルダーへ移すルール、送信済みアイテムの不審なメール、最近追加された外部転送を挙げています。攻撃者は返信や警告を本人に見せないよう、受信トレイルールを仕込むことが多いからです。

こうした設定はパスワードを変えても消えません。攻撃者が自分の端末をMFAの方法として登録していた場合や、悪意あるアプリに権限を同意させていた場合も同じです。同じ文書はアプリパスワードもパスワード再設定では自動で失効しないと明記しています。封じ込めは、パスワードの外側に残った足場まで消して初めて終わります。

Microsoft 365の乗っ取り調査と封じ込め｜PowerShellの確認手順

封じ込めの順番｜アカウント無効化・セッション失効・MFA方法とアプリ同意の見直し

Microsoftの手順は六段階です。調査中はアカウントを無効化し、無効化できなければパスワードを再設定します。次にセッションを失効させ、登録済みのMFAの方法、ユーザーが同意したアプリ、割り当てられた管理者ロール、メールの転送設定を順に確認します。

1. Update-MgUserでアカウントを無効化する（無理ならパスワード再設定。新しいパスワードはメールで送らない）
2. Revoke-MgUserSignInSessionで全セッションとリフレッシュトークンを失効させる
3. 見覚えのないMFAの方法と端末を削除する
4. 同意済みアプリのうち不要なものの権限を取り消す
5. 管理者ロールの付与を確認する
6. 転送設定と非表示を含む受信トレイルールを確認する

大量送信に使われたアカウントは、Microsoft 365側で送信を止められていることがあります。その場合にDefenderポータルの「制限付きエンティティ」から解除するのは、アカウントの調査が完了した後です。解除を急いで再び送信されると、送信先への被害が積み上がります。

転送設定・隠しルール・90日分の送信履歴を点検するPowerShellの実行例

手順6の転送設定・受信トレイルールと送信履歴の確認は、管理画面よりExchange Online PowerShellのほうが漏れなく取れます。次のスクリプトは、対象アカウントの転送設定、非表示を含む受信トレイルールのうち転送・削除・移動を伴うもの、過去90日の送信履歴を出力します。ExchangeOnlineManagementモジュールと、メッセージ追跡を実行できる権限が前提です。

# 使い方: .\Invoke-M365Triage.ps1 -Upn (Read-Host "対象のUPN")
param([Parameter(Mandatory)][string]$Upn)

Connect-ExchangeOnline -ShowBanner:$false

# 1) メールボックスの転送設定（外部転送はForwardingSmtpAddressに出る）
Get-Mailbox -Identity $Upn |
  Format-List ForwardingAddress,ForwardingSmtpAddress,DeliverToMailboxAndForward

# 2) 非表示を含む受信トレイルールのうち、転送・削除・移動を伴うもの
Get-InboxRule -Mailbox $Upn -IncludeHidden |
  Where-Object { $_.ForwardTo -or $_.ForwardAsAttachmentTo -or $_.RedirectTo -or $_.DeleteMessage -or $_.MoveToFolder } |
  Format-List Name,Enabled,ForwardTo,ForwardAsAttachmentTo,RedirectTo,DeleteMessage,MoveToFolder,Identity

# 3) 過去90日の送信履歴（1回の問い合わせは10日分まで）を9回に分けて取得
$end = Get-Date
$sent = @()
for ($i = 0; $i -lt 9; $i++) {
  $start = $end.AddDays(-10)
  $sent += Get-MessageTraceV2 -SenderAddress $Upn -StartDate $start -EndDate $end -ResultSize 5000
  $end = $start
}
"送信件数: " + $sent.Count
$sent | Export-Csv -Path .\sent_90days.csv -NoTypeInformation -Encoding UTF8

Get-MessageTraceV2の公式リファレンスによると、遡れるのは過去90日、1回の問い合わせで取れるのは10日分、件数は既定1,000件・最大5,000件です。スクリプトが10日ずつ9回に分けているのはこの制約に合わせるためです。出力の時刻はUTCなので、日本時間の9月30日を見るときは9時間ずらして読みます。

一日に数千通を送られたアカウントでは、10日の窓でも5,000件の上限に当たります。その場合は該当日だけ期間を数時間単位に狭めるか、最後の結果の受信者アドレスと受信時刻をStartingRecipientAddressとEndDateに渡して続きを取ります。宛先が1,000を超える一斉送信の追跡にはMessageTraceIdの指定が必要です。CSVの宛先を見れば、削除依頼と注意喚起を送る相手の名簿がそのまま作れます。

セッション失効後もアクセストークンが最大1時間残る場合の対応手順

Revoke-MgUserSignInSessionはセッションとリフレッシュトークンを失効させますが、発行済みのアクセストークンまでは即座に止めません。Microsoftの緊急時のアクセス取り消しの解説によると、Entra IDが発行するアクセストークンの有効期間は既定で1時間です。アクセストークンを使うアプリでは、その期限が切れるまで利用者はアクセスを失いません。

この1時間の隙間を詰めるのが継続的アクセス評価（CAE）で、対応アプリではアクセストークンとセッショントークンの失効をほぼリアルタイムで反映できます。実務上は、無効化と失効を先に済ませ、送信履歴とルールの調査はその1時間の間に並行して進める段取りにします。攻撃者が新しいトークンを取れない状態を先に作るのが優先です。

Google Workspaceの不正ログイン調査｜監査ログとReports API

管理コンソールで一時停止・サインインCookie・OAuthトークンを無効化する流れ

Googleの侵害されたアカウントの特定と保護は、最初に対象ユーザーを一時停止するよう案内しています。一時停止するとサインインCookieとOAuthトークンがリセットされ、攻撃者の既存のセッションも切れます。パスワードの変更だけで対応を終えた場合、ブラウザに残ったログイン状態まで失効したとは限りません。

そのうえで、管理者アカウントなら管理監査ログで最近の設定変更を確かめ、ユーザーのログイベント、メールログ、OAuth・ドライブ・カレンダーのログを調べます。アクセスを戻す前に済ませる作業は、パスワードの再設定、OAuthトークンの取り消し、アプリパスワードの削除です。再開後はフィルタと転送設定、回復用の連絡先をユーザーと一緒に確認します。

Reports APIのloginイベントで不審なログインを遡るリクエスト例

管理コンソールのユーザーログイベントでは、Web上のログインの成功と失敗を最大6か月分確認できます。7月下旬の侵入であれば、まだ遡れる範囲です。件数が多いときや複数アカウントを横断して見るときは、Reports APIのログイン監査イベントを直接引くほうが速く済みます。

# 事前に admin.reports.audit.readonly スコープのアクセストークンを取得しておく
TOKEN="取得したアクセストークン"
START="2026-07-15T00:00:00Z"

# 1) ドメイン全体で、ブロックされた不審なログインを取得
curl -s -H "Authorization: Bearer ${TOKEN}" \
  "https://admin.googleapis.com/admin/reports/v1/activity/users/all/applications/login?eventName=suspicious_login&startTime=${START}&maxResults=1000"

# 2) 特定ユーザーの成功ログインを時刻とIPアドレスで一覧にする
USER_KEY="対象ユーザーのメールアドレス"
curl -s -H "Authorization: Bearer ${TOKEN}" \
  "https://admin.googleapis.com/admin/reports/v1/activity/users/${USER_KEY}/applications/login?eventName=login_success&startTime=${START}" \
  | jq -r '.items[] | [.id.time, .ipAddress, .events[0].name] | @tsv'

1本目は、Googleがブロックした不審なログインをドメイン全体で拾います。2本目は、対象ユーザーの成功したログインを時刻とIPアドレスの組で並べるもので、業務で使わない国や回線からのログインがあれば侵入の起点の候補です。ほかに確認したいイベントは、email_forwarding_out_of_domain（ドメイン外への転送の有効化）、2sv_disable（2段階認証の無効化）、account_disabled_hijacked（乗っ取りの疑いによる停止）です。

検知から公表まで二か月かかる構図を縮めるアラートとログの保管

日経のGoogle Workspaceの件は、7月下旬の侵入をGoogleの通知で知ったのが8月上旬でした。外部の通知を待つ体制では、検知までの時間は自社で決められません。Googleの手順も、不審なログインや管理者による設定変更を知らせるアクティビティアラートの有効化を追加の対策に挙げています。

もう一つはログの保管期間です。Microsoft 365のメッセージ追跡は90日、Google Workspaceのログイン履歴は6か月で、侵入から数か月後に気づくと最初の痕跡が消えている可能性があります。発覚が遅れた場合にも侵入当初まで遡れるようにする方法は、ログを自社のストレージやSIEMへ定期的に書き出して保管することです。痕跡の読み方は不正アクセスのログ確認・解析方法が参考になります。

なりすましメールを受け取った取引先・取材先側の確認｜開いた場合と入力した場合

9月30日前後に日経関係者名義で届いたメールを見分けて削除する基準

日経は送信先に個別に連絡していますが、受け取った側が自分で探すほうが早い場合もあります。社内のメールゲートウェイやMicrosoft 365のメッセージ追跡で、9月30日前後に日経関係者のアドレスから届き、本文にリンクやファイルを含むメールを抽出します。認証に通っているため、送信元のドメインで機械的に弾くことはできません。

判断の目安は、やりとりの流れと関係なく届いたか、ファイル共有やログインを求めるリンクがあるか、の二つです。どちらかに当てはまれば開かずに削除し、組織内で同じメールを受け取った人がいないかを確認します。日経は不審なメールを受け取った場合、同社のお問い合わせフォームから連絡するよう求めています。

リンクを開いて認証情報を入力した場合に自社の管理者へ依頼する点検の順番

リンク先でIDとパスワードを入力していた場合、日経BPと同じ立場にあると考えて動きます。入力したアカウントのパスワードを変えるだけでなく、管理者に連絡し、本記事の前半と同じ手順で、セッション失効、MFAの方法、転送ルール、送信履歴を確かめてもらってください。リンクを開いただけで入力していなければ、端末のウイルス対策ソフトでのスキャンと、ブラウザに保存した認証情報の確認から始めます。

フィッシング起点で社内アカウントが乗っ取られ、取引先へ連鎖した事例として講談社の個人情報流出3,812件も比較の材料になります。そちらは侵害後の調査範囲の切り方、本記事はMicrosoft 365とGoogle Workspaceの操作手順に重心を置いています。

再発を防ぐ設計の判断｜耐フィッシングMFAと条件付きアクセスを入れる条件と見送る場面

パスワードとSMS認証の組み合わせが中間者型フィッシングで破られる理由

日経の2件の手口は公表されていませんが、業務SaaSの乗っ取りでよく使われるのは、本物のログイン画面を中継する中間者型のフィッシングです。利用者が偽サイトでパスワードとワンタイムコードを入力すると、攻撃者は同時に本物のサイトへログインし、発行されたセッションCookieを持ち帰ります。SMSや認証アプリのコードは、利用者が自分で入力する以上、中継されれば防げません。

これを防げるのは、ログイン先のドメインと結び付いた認証方式です。パスキーやFIDO2セキュリティキーは、偽ドメインでは署名を返さないため中継が成立しません。各方式の違いは多要素認証（MFA）とはでコードとあわせて解説しています。

耐フィッシングMFAを全社員に広げるか管理者と外部窓口から始めるかの判断基準

Microsoftは管理者に耐フィッシングMFAを求める条件付きアクセスのポリシーを用意しています。最初に入れるのは管理者ロールの保有者で、ここは規模を問わず採用すべきです。管理者アカウントを取られると、転送設定やアプリ同意を組織全体へ広げられるからです。

次の対象は、社外と大量にやりとりする職種です。記者、営業、購買、採用担当のように取引先の名簿をメールボックスに抱える人は、乗っ取られたときの被害が今回の約9,000件のように社外へ広がります。逆に、社外とのやりとりがほぼなく、会社支給の端末からしか使わない部署まで一度にセキュリティキーを配るのは過剰です。その層は、条件付きアクセスで会社管理の端末と国内からのログインに絞るだけでも攻撃面を大きく減らせます。Microsoft 365の権限設計の起点はMicrosoft 365 管理センターの初期設定にまとめています。

外部転送の既定での禁止、条件付きアクセス、耐フィッシングMFAの段階導入をテナントの実情に合わせて組みたい場合は、Microsoft 365・Copilot導入支援でEntra IDの設定見直しから相談できます。

個人情報保護委員会への報告要否と漏えい範囲に応じた社外周知の段取り

日経は3件とも個人情報保護委員会へ報告しています。不正の目的をもって行われたおそれのある漏えい等は、本人の数が少なくても報告の対象になる類型です。期限は速報が発覚から3〜5日以内、確報が30日以内で、不正目的によるものは60日以内とされています。

アカウントの乗っ取りでは、メールボックスにある宛先と本文がすべて漏えいのおそれの範囲に入ります。報告の順序は、範囲の確定を待たずに速報で現時点の見込みを出し、続いて送信履歴の調査結果をもとに確報を固める流れです。4類型と期限の実務は個人情報保護委員会への報告義務で詳しく扱っています。

よくある質問

日経の不正アクセスについて、受信者と管理者から出やすい質問をまとめました。

日経の購読者や読者の情報は漏えいしたのですか？

Google Workspaceの件について、日経は読者や取材先に関する情報は含まれないとしています。漏えいの可能性があるのは社員や取引先などの氏名とメールアドレス1,646人分です。Microsoft 365の件で漏えいのおそれがあるのは、なりすましメールの送信先のアドレスと氏名、一部のメール内容です。購読サービスの会員情報の漏えいは、10月4日の公表には含まれていません。

日経の社員から届いたメールのリンクを開いてしまいました。何をすればよいですか？

リンク先でIDやパスワードを入力したかどうかで分かれます。入力した場合は、そのアカウントのパスワードを変え、社内の管理者に連絡してセッションの失効と転送ルール・MFAの確認を依頼してください。入力していなければ、端末のウイルススキャンと、同じメールを受け取った同僚への周知から始めます。メール自体は削除して構いません。

なりすましメールはなぜ迷惑メールフィルタで止まらなかったのですか？

社員本人のMicrosoft 365アカウントから送られたため、送信サーバーも署名も正規のものだったからです。SPF・DKIM・DMARCは送信元のドメインが正しいかを確かめる仕組みで、送信者本人が書いたかは判定できません。過去にやりとりのある相手から届くため、受信者も疑いにくい形になります。

パスワードを変えれば乗っ取られたアカウントは安全になりますか？

パスワード変更だけでは足りません。攻撃者が仕込んだ外部転送や受信トレイルール、登録したMFAの方法、同意させたOAuthアプリ、アプリパスワードは残ります。Microsoft 365ではRevoke-MgUserSignInSessionでのセッション失効、Google Workspaceでは一時停止によるサインインCookieとOAuthトークンのリセットを組み合わせ、残った設定を一つずつ消してください。

自社のMicrosoft 365で同じ被害が起きていないか、何から確かめればよいですか？

最初に、全メールボックスの外部転送設定と非表示を含む受信トレイルールを洗い出します。次に確認するのは、Entra IDのサインインログに記録された、業務で使わない国や回線からの成功ログインの有無です。最後に、送信件数が急に増えたアカウントがないかをメッセージ追跡で見ます。メッセージ追跡は90日までしか遡れないため、気になる点があれば早めに書き出しておいてください。

関連記事

• 講談社の個人情報流出3,812件｜フィッシング起点のアカウント侵害の技術解説：フィッシング起点のアカウント侵害を調査範囲の切り方から見る事例
• DMARCの仕組みとnone・quarantine・rejectが分けるなりすまし防御の差：正規アカウント発のメールがDMARCを通る理由の前提
• 多要素認証（MFA）とは？3要素と実装方式・耐フィッシングMFAをコード付きで解説：耐フィッシングMFAの方式選びに
• 個人情報保護委員会への報告義務｜対象4類型・速報3〜5日と確報30日の実務：乗っ取り発覚後の報告の段取りに
• Gyazoの不正アクセスと2,362万件の流出｜利用者の点検手順とアップロード基盤の見直し：同じ時期に公表された事業者側の侵害との比較に
• ジャパンタイムズのランサムウェア被害とグループ会社サーバー｜Eclipseの犯行声明と被害を分けたインフラ設計：同時期の報道機関の事案（グループ会社サーバー）と被害を分ける設計の比較に