Nikkei: a Microsoft 365 account takeover sent about 9,000 phishing emails to staff and sources.

What Nikkei has confirmed

On 4 October 2026, Nikkei Inc., publisher of the Nikkei newspaper, announced that a Microsoft 365 account used by an employee had been attacked. Nikkei believes a third party signed in without authorisation and used the account to send about 9,000 impersonation emails. Nikkei notice (Japanese); Nikkei report (Japanese).

What was sent. On 30 September, emails leading to a malicious site went to people inside Nikkei and to outside contacts, including sources, who had corresponded with several employees.
What is believed leaked. Recipients' email addresses and names, and the content of some emails.
Regulator. Nikkei has reported the incident to Japan's Personal Information Protection Commission and is investigating the scope and the number of people affected.
Response stated. Nikkei changed the password and has confirmed no unauthorised sign-in since. It contacted recipients individually and asked them to delete the mail.
Warning. Nikkei expects more emails impersonating people at Nikkei and its group companies. It asks recipients of suspicious mail to report it through its contact form.

The notice does not publish the malicious URL, the sender addresses, the subject lines, the number of accounts involved or how the sign-in was obtained.

The same pattern, seven months earlier

On 7 May 2026, Nikkei disclosed a similar incident at its US subsidiary, Nikkei America in New York. An employee's Microsoft 365 account was accessed from outside. In early March, impersonation emails went to business partners the employee had corresponded with. Nikkei America learned of it when a partner got in touch. It changed the account password and confirmed no further unauthorised sign-in. Information on 291 people may have leaked, including names, company names and email addresses, along with some partner contacts stored in cloud files. Nikkei said none of it related to readers or reporting. Nikkei America notice (Japanese).

Editorial assessment: in seven months, two companies in the same group have reported a Microsoft 365 account takeover, mail sent to the employee's correspondents, and a password change as the stated response. That is not evidence of the same attacker, and Nikkei has attributed neither incident. It does mean the pattern repeated, and this time about 9,000 emails went out.

Why this mail gets through

Editorial assessment: most email defences, and most phishing training, ask one question: is the sender who they claim to be? Here the answer is yes.

Authentication passes. SPF, DKIM and DMARC check that a message came from servers allowed to send for the domain. Mail sent from the real mailbox through the organisation's own Microsoft 365 does, so they have nothing to reject.
Reputation is good. The sending domain and the mailbox have a long, clean history. Nikkei says the recipients were people who had corresponded with its employees, so many filters will see an established relationship rather than a first contact.
The lure can be real. An attacker who can read a mailbox can reuse real names, subjects and threads. Nikkei has not said whether that happened here, but it says some mail content leaked.
Recipients are the next senders. If the malicious site collected passwords or sessions, every recipient who entered them is the next account that can send trusted mail. For a newspaper, those recipients include sources.

Stage	ATT&CK technique	What Nikkei confirmed	What is not known
Initial access	T1078.004 Valid Accounts: Cloud Accounts	A third party is believed to have signed in	How the password or session was obtained; whether MFA was in place
Collection	T1114.002 Email Collection: Remote Email Collection	Names, addresses and some mail content believed leaked	Which mailboxes, over what period, and how much was read
Internal phishing	T1534 Internal Spearphishing	Mail sent to people inside Nikkei	How many internal recipients clicked
External phishing	T1566.002 Phishing: Spearphishing Link	About 9,000 emails on 30 September, also to sources and other contacts	What the site did: collect credentials, deliver malware, or both
Persistence	T1564.008 Hide Artifacts: Email Hiding Rules; T1098 Account Manipulation	Not mentioned	Whether inbox rules, app consents or added MFA methods were found and removed

A password change is not the whole recovery

Editorial assessment: both Nikkei notices describe the same response: the password was changed and no further unauthorised sign-in has been confirmed. Nikkei may have done more; the notices do not say. For any organisation responding to a mailbox takeover, a password change on its own leaves gaps:

Some tokens survive it. Under Microsoft's documented rules, a password the user changes themselves revokes password-based refresh tokens and session cookies. Tokens from non-password sign-ins and tokens held by confidential client applications stay alive. An access token already issued stays valid until it expires, by default after one hour. An administrator's Revoke sessions revokes every refresh token for the user. Microsoft: refresh token revocation; Microsoft: revoke user access.
Configuration survives it. A new password does not remove inbox rules that hide or forward mail, consent granted to an attacker's app, MFA methods the attacker registered, or mailbox delegations. Each needs its own check.
No new sign-in is not the same as no access. "No unauthorised sign-in since" covers sign-ins. It does not cover access through an app's token or a forwarding rule, which need no new sign-in.

The decisions, owners and evidence for this are in the account compromise playbook.

If you received mail from Nikkei around 30 September

Find the messages with the queries below. Do not rely on authentication results or sender reputation: both will look normal.
Treat a click as possible credential exposure. For anyone who clicked, review their sign-ins from the time of the click. If they entered a password, revoke sessions, reset the password and check their mailbox for new rules and app consents. The phishing response playbook walks through each step.
Remove remaining copies, as Nikkei asked, after you have kept a copy for the investigation.
Verify requests from Nikkei staff by another channel, such as a phone number you already hold. Nikkei expects further impersonation of its staff and group companies. Report suspicious Nikkei-branded mail through Nikkei's contact form.
Consider what your own people sent to Nikkei. Some mail content is believed leaked. Press releases under embargo, interview arrangements and comments sent to reporters may be in it.

Which teams should act

Team	Exposure to review	Next step	Evidence needed
Email Security	Mail from Nikkei addresses around 30 September, which passed authentication	Find and remove the messages; flag similar mail from other trusted senders	Message list with recipients, delivery location and click data
IT Operations (identity)	Accounts of recipients who clicked or entered credentials	Revoke sessions, reset passwords, check inbox rules, app consents and MFA methods	Sign-in logs after the click time; mailbox and app audit records
SIEM / SOC	One mailbox suddenly sending to hundreds of recipients	Add an alert on outbound volume per mailbox; it would also detect this happening to you	Baseline of normal outbound volume for your heaviest senders
Third-party Risk	Trusted senders whose accounts can be taken over	Agree on an out-of-band check for requests that involve links, payments or credentials	Contact list with verified phone numbers for key partners
Legal / Privacy	Your staff's names and addresses, and possibly mail they sent to Nikkei	Assess what your organisation sent by email to Nikkei; follow Nikkei's updates on scope	Nikkei's final scope statement; your own sent-mail records

IOCs and hunting

No indicators are published. Nikkei has not released the malicious URL, the sender addresses or the subject lines. The queries below find the mail by date and sender domain instead. Expect noise: Nikkei newsletters, subscription notices and normal correspondence will also match. Nikkei staff addresses in its notices use nex.nikkei.co.jp; group companies may use other domains, so extend the list as needed.

All queries are illustrative and were not run against live data. Table and column names were checked against Microsoft Learn and Splunk documentation on 4 October 2026. The mail window runs from 29 September 00:00 to 2 October 00:00 UTC, which covers all of 30 September in Japan time with a margin.

1. Who received the mail, and who clicked. Microsoft Defender XDR advanced hunting; needs Defender for Office 365 for EmailEvents and UrlClickEvents. Clicks are matched on the message and the recipient, because one message can have many recipients. That match assumes the user's UPN equals their email address; where it does not, map one to the other first. Advanced hunting keeps 30 days, so this window drops out in late October. After that, run the same logic where the tables are kept longer, for example Microsoft Sentinel, where Timestamp becomes 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

Rows with an empty ClickTime were delivered but not clicked through Safe Links. Clicks from devices or clients without Safe Links protection are not recorded. AuthenticationDetails will usually show a pass; that is expected here, not reassurance.

2. Would you see this happen to one of your own mailboxes? Microsoft Defender XDR advanced hunting. It finds internal senders who reached an unusually large number of recipients within one hour. Set the threshold above your heaviest legitimate senders and list known bulk senders, such as newsletter or system accounts, in BulkSenders. A hit is a lead: check that sender's sign-ins, inbox rules and recent app consents.

// 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. Who received the mail, in Splunk. Splunk Add-on for Microsoft Office 365, message trace input, sourcetype o365:reporting:messagetrace, with the fields SenderAddress, RecipientAddress, Subject, Status and FromIP. Replace the index. Splunk reads the absolute times in your user time zone; widen them if that is not UTC. The newer Graph-based input writes o365:graph:messagetrace, whose field names may differ, so check one event first. Message trace shows delivery, not clicks: pivot to proxy or DNS logs for the recipients it returns.

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

No result does not prove you were not sent the mail: logs may be missing or out of retention, Nikkei group companies may use other domains, and personal or unmanaged mailboxes are outside these searches. EmailEvents; UrlClickEvents; Splunk message trace data source.

What remains unknown

How access was gained. Phishing, a reused password, a stolen session and a relayed MFA prompt all fit "a third party signed in". Nikkei has not said which.
How many accounts. The Japanese notice does not state whether one account or several were involved.
How long the attacker had access before 30 September, and how much mail they read.
What the malicious site did, and whether any recipient's account was taken over in turn.
How many people are affected. Nikkei is still counting.
Whether the March and September incidents are connected. Nothing published links them.

Sources and updates

All sources were read on 4 October 2026. This article will be updated if Nikkei publishes the scope of the leak or further details. No corrections so far.

30-second briefing