日経が公表した内容
日本経済新聞社は2026年10月4日、社員が使っていた業務ソフト「マイクロソフト365」のアカウントがサイバー攻撃を受けたと発表しました。第三者が不正にログインしたとみられ、そのアカウントからなりすましメール約9000件が送信されました。日経のお知らせ、日経の記事。
- 送信されたもの。 9月30日、悪性サイトに誘導する内容のメールが、社内のほか、複数の社員とやりとりがあった取材先などに送信されました。
- 漏洩したとみられる情報。 送信先のメールアドレスと氏名、一部メールの内容。
- 報告。 日経は個人情報保護委員会に報告し、侵害を受けた範囲と漏洩した個人情報の件数を調査しています。
- 公表された対応。 パスワードを変更し、それ以降の不正ログインは確認されていません。送信先には個別に連絡し、メールの削除を依頼しました。
- 注意喚起。 日経やグループ会社の関係者になりすましたメールが増える可能性があるとして、不審なメールを受信した場合はお問い合わせフォームから連絡するよう求めています。
お知らせには、悪性サイトのURL、送信元アドレス、件名、関係したアカウントの数、不正ログインに至った経緯は記載されていません。
7カ月前にも同じ型
日経は2026年5月7日、米国子会社の日経アメリカ社（ニューヨーク市）でも同様の事案を公表しています。社員が業務で使用していたマイクロソフト365に外部から不正なログインがあり、3月上旬に、その社員とやりとりのあった取引先へなりすましメールが送信されました。取引先からの連絡で被害を把握し、パスワードを変更した後、不正ログインは確認されていません。流出した可能性がある情報は氏名、会社名、メールアドレスなど291人分で、クラウド上のファイルに保存されていた一部取引先の連絡先も含まれますが、読者や取材に関するものは含まれていないとしています。日経アメリカ社に関するお知らせ。
当サイトの分析： 同じグループの2社が、7カ月の間に、マイクロソフト365アカウントの乗っ取り、社員のやりとり相手へのメール送信、公表された対応としてのパスワード変更、という同じ流れを報告しています。同一の攻撃者による証拠ではなく、日経もどちらの事案も攻撃者を特定していません。ただ、同じ型が繰り返され、今回は約9000件のメールが送られたということです。
このメールが届いてしまう理由
当サイトの分析： 多くのメール防御やフィッシング訓練は、「送信者は名乗っているとおりの相手か」を問います。今回、その答えは「はい」です。
- 送信ドメイン認証は通る。 SPF・DKIM・DMARCは、そのドメインの送信を許可されたサーバーから届いたかを確認します。組織自身のマイクロソフト365から本物のメールボックスで送られたメールは条件を満たすため、拒否する理由がありません。
- 評判が良い。 送信ドメインとメールボックスには長く問題のない履歴があります。送信先は日経の社員とやりとりがあった相手なので、多くのフィルターは初めての相手ではなく、既存の関係と判断します。
- 文面が本物になり得る。 メールボックスを読める攻撃者は、実在の名前、件名、スレッドを再利用できます。今回そうしたかは公表されていませんが、一部メールの内容が漏洩したとみられています。
- 受信者が次の送信者になる。 悪性サイトがパスワードやセッションを収集するものだった場合、それを入力した受信者のアカウントが、次に信頼されるメールを送れるアカウントになります。新聞社の場合、その受信者には取材先が含まれます。
| 段階 | ATT&CKの手法 | 日経が公表したこと | 分かっていないこと |
|---|---|---|---|
| 初期アクセス | T1078.004 Valid Accounts: Cloud Accounts | 第三者が不正にログインしたとみられる | パスワードやセッションの入手経路、多要素認証の有無 |
| 収集 | T1114.002 Email Collection: Remote Email Collection | 氏名、メールアドレス、一部メールの内容が漏洩したとみられる | どのメールボックスを、どの期間、どれだけ読まれたか |
| 社内へのフィッシング | T1534 Internal Spearphishing | 社内にもメールが送信された | 社内の受信者のうち何人がクリックしたか |
| 社外へのフィッシング | T1566.002 Phishing: Spearphishing Link | 9月30日、取材先などにも約9000件 | 悪性サイトの目的（認証情報の収集、マルウェア配布、またはその両方） |
| 永続化 | T1564.008 Hide Artifacts: Email Hiding Rules、T1098 Account Manipulation | 言及なし | 受信トレイルール、アプリへの同意、追加された多要素認証の方法が見つかり、削除されたか |
パスワード変更だけでは復旧は終わらない
当サイトの分析： 日経の2件のお知らせは、どちらも同じ対応を記載しています。パスワードを変更し、それ以降の不正ログインは確認されていない、というものです。日経がそれ以上の対応をした可能性はありますが、お知らせには書かれていません。メールボックスの乗っ取りに対応するどの組織にとっても、パスワード変更だけでは次の隙間が残ります。
- 一部のトークンは残る。 マイクロソフトの公開資料では、利用者自身がパスワードを変更すると、パスワードに基づくリフレッシュトークンとセッションCookieは無効になります。一方、パスワード以外の方法によるサインインのトークンや、機密クライアントアプリが持つトークンは残ります。発行済みのアクセストークンは期限まで有効で、既定では1時間です。管理者の「セッションの取り消し」は、その利用者のリフレッシュトークンをすべて無効にします。Microsoft：リフレッシュトークンの失効、Microsoft：ユーザーアクセスの取り消し。
- 設定は残る。 新しいパスワードでは、メールを隠したり転送したりする受信トレイルール、攻撃者のアプリへの同意、攻撃者が登録した多要素認証の方法、メールボックスの代理アクセス権は消えません。それぞれ個別の確認が必要です。
- 新たなサインインがないことは、アクセスがないことではない。 「それ以降の不正ログインは確認されていない」はサインインについての説明です。アプリのトークンや転送ルールによるアクセスには、新たなサインインは必要ありません。
判断の分岐、担当、必要な証拠はアカウント侵害対応プレイブックにまとめています。
9月30日前後に日経からメールを受け取った組織へ
- 下記のクエリでメールを特定する。 認証結果や送信者の評判には頼りません。どちらも正常に見えます。
- クリックは認証情報の露出の可能性として扱う。 クリックした人について、クリック時刻以降のサインインを確認します。パスワードを入力していた場合は、セッションを取り消してパスワードを再設定し、メールボックスの新しいルールとアプリへの同意を確認します。手順はフィッシング対応プレイブックにあります。
- 残っているメールを削除する。 日経の依頼どおりに削除しますが、その前に調査用の写しを保全します。
- 日経社員からの依頼は別の経路で確認する。 すでに把握している電話番号などで確認します。日経は、社員やグループ会社をかたるメールがさらに届く可能性があるとしています。日経を名乗る不審なメールは、日経のお問い合わせフォームに報告できます。
- 自社から日経に送った内容を振り返る。 一部メールの内容が漏洩したとみられています。解禁前の報道資料、取材の調整、記者へのコメントが含まれている可能性があります。
どのチームが確認するか
| チーム | 確認対象 | 次の対応 | 必要な証拠 |
|---|---|---|---|
| メールセキュリティ | 9月30日前後に届いた日経のアドレスからのメール（送信ドメイン認証は成功） | メールを特定して削除し、他の信頼済み送信者からの類似メールにも目を配る | 受信者、配信場所、クリック情報を含むメールの一覧 |
| IT運用（ID管理） | クリックした、または認証情報を入力した受信者のアカウント | セッションの取り消し、パスワード再設定、受信トレイルール・アプリへの同意・多要素認証の方法の確認 | クリック時刻以降のサインインログ、メールボックスとアプリの監査記録 |
| SIEM / SOC | 1つのメールボックスが突然数百人に送信する事象 | メールボックスごとの送信量にアラートを設定する。自社で同じことが起きた場合の検知にもなる | 送信量の多い正規の送信者の平常時の基準値 |
| 委託先リスク | アカウントが乗っ取られ得る信頼済みの送信者 | リンク、支払い、認証情報が関わる依頼は、別経路で確認する手順を取り決める | 主要な取引先の、確認済み電話番号を含む連絡先一覧 |
| 法務・プライバシー | 自社社員の氏名とメールアドレス、日経に送ったメール | 自社が日経にメールで送った内容を把握し、日経の範囲に関する続報を確認する | 日経による最終的な範囲の公表、自社の送信記録 |
IOCとハンティング
公開されたIOCはありません。 日経は悪性サイトのURL、送信元アドレス、件名を公表していません。以下のクエリは、日付と送信元ドメインでメールを探します。日経のニュースレター、購読関連の通知、通常のやりとりもヒットするため、ノイズを前提にしてください。日経のお知らせに記載された社員の連絡先はnex.nikkei.co.jpを使っています。グループ会社は別のドメインを使っている可能性があるため、必要に応じてリストを追加してください。
いずれのクエリも参考例であり、実環境では実行していません。テーブル名と列名は2026年10月4日にMicrosoft LearnとSplunkの資料で確認しました。メールの検索範囲はUTCの9月29日0時から10月2日0時までで、日本時間の9月30日全体を余裕をもって含みます。
1. メールを受信した人と、クリックした人。 Microsoft Defender XDRの高度なハンティングです。EmailEventsとUrlClickEventsにはDefender for Office 365が必要です。1通のメールに複数の受信者がいるため、クリックはメールと受信者の両方で照合します。この照合は、利用者のUPNがメールアドレスと同じであることを前提にしています。異なる場合は、先に対応付けてください。高度なハンティングの保持期間は30日なので、この期間は10月下旬に検索できなくなります。その後は、Microsoft Sentinelなど、テーブルを長く保持している環境で同じロジックを実行します（TimestampはTimeGeneratedになります）。
// Illustrative; not run against live data. Microsoft Defender XDR advanced hunting.
// Inbound mail from Nikkei addresses around 30 Sep 2026 (JST), with any Safe Links clicks.
let SenderDomains = dynamic(["nex.nikkei.co.jp", "nikkei.co.jp", "nikkei.com"]);
let MailStart = datetime(2026-09-29T00:00:00Z); // 30 Sep JST begins 29 Sep 15:00 UTC
let MailEnd = datetime(2026-10-02T00:00:00Z);
EmailEvents
| where Timestamp between (MailStart .. MailEnd)
| where EmailDirection == "Inbound"
| where SenderFromDomain in~ (SenderDomains) or SenderMailFromDomain in~ (SenderDomains)
| where UrlCount > 0
| extend Recipient = tolower(RecipientEmailAddress)
| project MailTime = Timestamp, NetworkMessageId, Recipient, SenderFromAddress,
Subject, DeliveryAction, LatestDeliveryLocation, AuthenticationDetails
| join kind=leftouter (
UrlClickEvents
| where Timestamp > MailStart
| extend Recipient = tolower(AccountUpn)
| project ClickTime = Timestamp, NetworkMessageId, Recipient, Url,
ClickAction = ActionType, IsClickedThrough
) on NetworkMessageId, Recipient
| project MailTime, Recipient, SenderFromAddress, Subject, DeliveryAction,
LatestDeliveryLocation, AuthenticationDetails, ClickTime, Url,
ClickAction, IsClickedThrough
| order by MailTime asc
| take 500
ClickTimeが空の行は、配信されたものの、セーフリンク経由ではクリックされていないメールです。セーフリンクで保護されていない端末やクライアントからのクリックは記録されません。AuthenticationDetailsは通常「成功」を示します。今回はそれが想定どおりで、安心材料にはなりません。
2. 自社のメールボックスで同じことが起きたら気付けるか。 Microsoft Defender XDRの高度なハンティングです。1時間のうちに異常に多くの受信者に送信した社内の送信者を探します。しきい値は正規の送信量が最も多い送信者より上に設定し、ニュースレターやシステム用アカウントなど既知の大量送信者をBulkSendersに登録します。ヒットは調査の手がかりです。その送信者のサインイン、受信トレイルール、最近のアプリへの同意を確認します。
// Illustrative; not run against live data. Microsoft Defender XDR advanced hunting.
// Internal mailboxes that reached an unusually large number of recipients in one hour.
let Lookback = 7d;
let Threshold = 300; // set above your heaviest legitimate senders
let BulkSenders = dynamic(["REPLACE_WITH_KNOWN_BULK_SENDER"]);
EmailEvents
| where Timestamp > ago(Lookback)
| where EmailDirection in ("Outbound", "Intra-org")
| where SenderFromAddress !in~ (BulkSenders)
| summarize Recipients = dcount(RecipientEmailAddress),
ExternalDomains = dcountif(RecipientDomain, EmailDirection == "Outbound"),
Messages = dcount(NetworkMessageId), WithLinks = countif(UrlCount > 0),
Subjects = make_set(Subject, 5)
by SenderFromAddress, Hour = bin(Timestamp, 1h)
| where Recipients >= Threshold
| order by Recipients desc
| take 200
3. Splunkでメールを受信した人を探す。 Splunk Add-on for Microsoft Office 365のメッセージ追跡入力（sourcetype o365:reporting:messagetrace）を使い、SenderAddress、RecipientAddress、Subject、Status、FromIPの各フィールドを前提にします。インデックス名を置き換えてください。Splunkは絶対時刻を利用者のタイムゾーンで解釈するため、UTCでない場合は範囲を広げます。新しいGraphベースの入力はo365:graph:messagetraceに書き込み、フィールド名が異なる可能性があるため、先に1件確認してください。メッセージ追跡で分かるのは配信までで、クリックは分かりません。該当した受信者について、プロキシやDNSのログを確認します。
index="REPLACE_WITH_O365_INDEX" sourcetype="o365:reporting:messagetrace" earliest="09/29/2026:00:00:00" latest="10/02/2026:00:00:00"
| eval sender_domain=lower(mvindex(split(SenderAddress, "@"), 1))
| search sender_domain IN ("nex.nikkei.co.jp", "nikkei.co.jp", "nikkei.com")
| table _time SenderAddress RecipientAddress Subject Status FromIP
| sort 0 _time
| head 500
該当なしでも、メールが届かなかったとは言えません。ログの欠落や保持期間切れ、グループ会社の別ドメイン、個人や管理外のメールボックスは、これらの検索の範囲外です。EmailEvents、UrlClickEvents、Splunkのメッセージ追跡データソース。
分かっていないこと
- 侵入の経路。 フィッシング、パスワードの使い回し、セッションの窃取、多要素認証の中継は、いずれも「第三者が不正にログインした」に当てはまります。日経はどれかを明らかにしていません。
- アカウントの数。 お知らせは、1つのアカウントか複数かを明記していません。
- 9月30日より前に攻撃者がアクセスできた期間と、読まれたメールの量。
- 悪性サイトが何をするものだったか、また受信者のアカウントがさらに乗っ取られたか。
- 影響を受けた人数。 日経が調査中です。
- 3月の事案と9月の事案の関係。 両者を結び付ける公表情報はありません。
出典と更新履歴
- 日本経済新聞社：サイバー攻撃による情報漏洩、不審メールの送信について（2026年10月4日）
- 日本経済新聞：日経にサイバー攻撃 情報漏洩、不審メール9000件送信（2026年10月4日15時）
- 日本経済新聞社：米国子会社での不正ログインについて（2026年5月7日）
- Microsoft Learn：リフレッシュトークンの失効
- Microsoft Learn：Microsoft Entra IDでのユーザーアクセスの取り消し
すべての出典は2026年10月4日に確認しました。日経が漏洩の範囲などを公表した場合、この記事を更新します。現時点で訂正はありません。