Nikkei breach: hijacked Microsoft 365 account sent 9,000 phishing emails

Two incidents in one disclosure

Japanese media group Nikkei disclosed on October 4 that an unauthorised third party had gained access to an employee's Microsoft 365 account, as reported by BleepingComputer and summarised in a dev.to write-up. On September 30, the hijacked account was used to send roughly 9,000 emails containing links to malicious websites, targeting the company's own staff as well as interviewees and external contacts of several employees.

According to the company's statement, the data at risk in this incident includes recipients' names and email addresses, and in some cases the contents of their emails. Nikkei said it has since changed passwords, observed no further unauthorised logins, and contacted recipients one by one with a request that they remove the messages.

The same announcement covered a second, apparently separate intrusion. A different employee's Google Workspace account had been accessed without permission from late July, and Nikkei only learned of it in early August after a notification from Google. That case exposed the names and email addresses of 1,646 employees and business partners. Nikkei stated that no reader data or information about journalistic sources was caught in the Google Workspace intrusion.

The Cyber Express reports that the company has reported both incidents to Japan's Personal Information Protection Commission. Who the attackers are, and whether the two intrusions are linked, has not been established.

One message was enough

The most consequential detail comes from INTERNET Watch: Nikkei BP, a separate company within the group, disclosed its own breach on October 4. An employee there received one of the phishing emails sent from the genuine Nikkei address and entered their credentials on the attacker's page. The intruders obtained access, and 26 personal records — names and email addresses — may have leaked before the account was shut down.

That completes a documented chain: a compromised corporate mailbox, a phishing wave sent from a trusted domain, a victim who typed in credentials, and a second breach. Threadlinqs, which catalogued the disclosure, observes that recipients were especially likely to trust links arriving from a real Nikkei mailbox, since standard anti-phishing guidance tells people to verify the sender — and here the sender genuinely was Nikkei.

The dev.to analysis frames the problem from the other side: most phishing fails because the From address looks suspicious, but these 9,000 messages inherited a legitimate corporate identity, so the most common first-line check passed by default. Nikkei itself has told affected people to stay alert for further emails impersonating the company or its subsidiaries.

What remains unknown

Nikkei has not described how the attackers first broke into the employee accounts. Credential theft, infostealer malware, and some form of multifactor authentication bypass all remain possibilities. The recipient count is given only as "about 9,000", and the company has not published the sender addresses or the malicious URLs, which limits the hunting outside defenders can do. Any connection between the Microsoft 365 and Google Workspace incidents is also undetermined.

Why it matters

The breach shows where the most widely repeated piece of phishing advice breaks down. Checking the sender works only when the sender is spoofed; when the mailbox itself belongs to the organisation, the check passes and the message arrives with full institutional trust. People who correspond with journalists — sources, fixers, PR staff, freelancers — cannot rely on a real reporter's address as a signal of safety.

The Nikkei BP case also puts a number on the exposure: a single set of credentials entered, out of 9,000 sent messages, was enough to cause a further breach. Attackers holding both a working sending identity and contact lists of journalists and their correspondents are well placed for follow-up campaigns that reference the breach itself, such as fake security notices or requests to re-confirm contact details. Multifactor authentication, ideally with passkeys, remains the control that turns a stolen password into a dead end rather than a second incident.