Japanese media giant Nikkei has disclosed two separate incidents involving unauthorized access to employee cloud accounts, one on Microsoft 365 and another on Google Workspace. The more serious of the two incidents involved a compromised Microsoft 365 account that attackers used on September 30 to send approximately 9,000 phishing emails to people inside and outside the company. The messages directed recipients to malicious websites and reached individuals who had previously communicated with Nikkei employees, including journalistic contacts. Nikkei says the incident may also have exposed recipients’ names, email addresses and the contents of some messages. The company changed the compromised account’s password, has not observed further unauthorized logins, and has contacted recipients asking them to delete the malicious messages.
The second incident involved a different employee’s Google Workspace account, which Nikkei says had been accessed from outside since late July. Google alerted Nikkei in early August, after which the password was changed. The account contained personal information relating to 1,646 employees, business partners and others, including names and email addresses. Nikkei says that dataset did not include information concerning readers or journalistic sources and that it has not identified secondary misuse from that particular incident.
The two incidents should be treated separately unless further evidence connects them. Nikkei has not disclosed the original compromise method for either account and has not attributed the activity to a specific threat actor. It would therefore be premature to describe the Google and Microsoft compromises as part of one campaign, or to claim credential stuffing, MFA bypass, malware or session theft without supporting evidence.
The Microsoft 365 incident is particularly instructive because it demonstrates the danger of trust propagation through a compromised mailbox. Traditional phishing asks a victim to trust an unfamiliar sender, a misspelled domain or a convincing impersonation. Account takeover changes the equation completely. The email can come from the genuine address, through the genuine Microsoft 365 infrastructure, and from an identity with which the recipient may already have an established relationship.
That removes several of the cues users are normally trained to look for.
The domain is correct.
The sender is real.
The previous conversation history may be real.
Email authentication checks may pass.
The maliciousness lies not in who owns the mailbox, but in who currently controls it.
The incident became even more significant when Nikkei BP disclosed that one of its own employees was compromised after receiving a phishing email sent from a Nikkei employee’s legitimate address. The recipient’s credentials were stolen, leading to unauthorized access to the Nikkei BP mailbox and potential exposure of 26 names and email addresses. In other words, the compromise appears to have propagated from one trusted business identity to another.
That creates a straightforward attack sequence:
employee cloud account compromised → attacker sends phishing from legitimate Nikkei address → trusted contacts receive genuine-looking message → recipient follows malicious link → credentials stolen → second legitimate account compromised → attacker gains another trusted identity
This is why compromised business email is such powerful attack infrastructure. Each successfully hijacked account can provide a new set of relationships, conversation history and trusted recipients for the next wave.
The attacker is not merely stealing one identity.
They are inheriting that person’s trust graph.
A journalist’s mailbox can contain correspondence with executives, companies, sources, analysts, government officials and other journalists. A salesperson’s mailbox contains customers and prospects. A procurement employee’s mailbox contains vendors. An HR mailbox contains employees and candidates. Once the account is compromised, all of those existing relationships can become targeting data.
That makes media organizations particularly sensitive targets. A message arriving from a recognized Nikkei journalist or employee may receive more trust than a random external email because journalists routinely exchange documents, links, interview requests, drafts and background material with external contacts. Attackers can exploit exactly those expected behaviors.
There is also a confidentiality dimension beyond phishing. Nikkei says some email content associated with the Microsoft 365 account may have been exposed. Even limited mailbox access can reveal recent conversations, contact patterns, organizational relationships and contextual details that make future phishing significantly more convincing.
This is why cloud-email account compromise should rarely be treated as a simple password-reset event.
Changing the password is necessary, but defenders also need to determine what the attacker did while access was available. That includes reviewing sign-in history, active sessions, mailbox forwarding rules, inbox rules, OAuth grants, registered MFA methods, application passwords where supported, delegated access and suspicious sent-mail activity.
If the attacker stole or established a valid session, resetting the password alone may not always be sufficient unless active sessions are also revoked. Likewise, an attacker who added a malicious OAuth application or forwarding rule may retain a path to information even after the password changes.
A robust containment process should therefore look more like:
disable or restrict account → revoke sessions → reset credentials → verify MFA methods → inspect OAuth consent → inspect forwarding and inbox rules → review sent mail → examine cloud audit logs → determine data accessed → notify affected contacts
That sequence reflects the reality that a cloud identity is more than a password.
The Google Workspace incident reinforces the same principle from another angle. Google’s alert apparently helped Nikkei detect the unauthorized access in early August. This is a useful example of why identity-provider anomaly detection matters: suspicious access may not trigger endpoint malware alerts because the attacker is interacting with a cloud application using a legitimate account.
In cloud environments, identity telemetry increasingly becomes the equivalent of network perimeter telemetry.
Useful signals include:
new sign-in locations;
new devices;
impossible travel;
unusual user agents;
unexpected OAuth applications;
large mailbox searches;
mass downloads;
new forwarding configurations;
and sudden high-volume outbound mail.
No single signal proves compromise, but correlated deviations from the user’s normal behavior can expose account takeover much earlier.
The Microsoft incident provides an especially strong behavioral indicator: one employee account suddenly sent approximately 9,000 messages containing malicious links. That should be extremely unusual for most editorial or corporate identities. Outbound-mail analytics can therefore serve as a containment layer even after the initial account takeover has succeeded.
Organizations should consider thresholds or anomaly detection around sudden increases in:
recipient count;
external recipients;
new domains;
messages containing newly seen links;
and mass outbound communications from accounts that historically send far smaller volumes.
A journalist who normally sends dozens of emails suddenly sending thousands should not need a threat-intelligence report to become interesting.
This also demonstrates the limitation of security controls focused mainly on inbound email. Many organizations invest heavily in blocking malicious messages entering their environment while paying less attention to what leaves from their own trusted accounts. Once a mailbox is hijacked, the organization itself becomes part of the attacker’s delivery infrastructure.
Outbound phishing detection therefore matters both for protecting external parties and for limiting reputational damage.
This is particularly important for trusted brands such as media organizations, financial institutions, law firms, technology vendors and government agencies because messages from those domains may receive preferential treatment from recipients and automated email-security systems.
The Nikkei BP follow-on compromise illustrates this perfectly. A phishing message originating from an actual Nikkei employee address had enough credibility to convince another employee within the broader corporate ecosystem to provide credentials.
This is effectively business email compromise as a worm-like trust mechanism.
The propagation is not automated in the malware sense, but trust provides the equivalent of lateral movement between organizations.
One compromised identity reaches a trusted recipient.
The recipient becomes compromised.
That identity can then target its own contacts.
The technical mechanism remains phishing, but the social structure gives it scale.
The incidents also highlight why email-security advice that focuses only on checking sender addresses is no longer sufficient. Telling users to “verify the sender domain” is useful against ordinary spoofing, but it fails when the genuine sender account itself is compromised.
Users need an additional rule:
a legitimate sender can still send a malicious message if their account has been taken over.
Unexpected requests to authenticate, review documents or follow links should therefore be verified based on context and behavior, not simply sender identity.
If a known contact suddenly sends an unusual login link, requests authentication on an unfamiliar domain, or changes the normal workflow, recipients should confirm the request through another channel.
That is inconvenient, naturally. Security has an unfortunate habit of asking humans not to behave like humans.
But for high-value communications, independent verification remains one of the strongest controls against compromised-account phishing.
Phishing-resistant MFA can also substantially reduce downstream damage. If the attacker obtains a username and password from a malicious site but the account uses FIDO2 security keys or properly implemented passkeys, the stolen password alone is insufficient to authenticate to the legitimate service. Traditional OTP-based MFA offers less protection when attackers use real-time phishing proxies capable of capturing credentials and session tokens.
Nikkei has not disclosed whether MFA was enabled on the compromised accounts or how the attackers obtained access, so it would be inappropriate to suggest that MFA specifically failed here. The broader defensive lesson is simply that cloud accounts belonging to employees with extensive external relationships deserve strong phishing-resistant authentication.
Organizations should also pay particular attention to mailbox content and relationship data during breach assessment. An attacker who gains access to a mailbox may not need to download thousands of attachments to extract value. The contact history itself can identify:
who the user communicates with;
which relationships are active;
which conversations are sensitive;
and which recipients are likely to trust a follow-up message.
This is especially relevant in journalism, where correspondence may reveal confidential or sensitive professional relationships even when the content itself is mundane.
Nikkei has specifically said that the Google Workspace exposure did not include reader or interviewee information, which is a useful limitation. The Microsoft 365 incident, however, did involve phishing emails being sent to interviewees and other contacts, and some email content may have been exposed. Those two data scopes should not be conflated.
The distinction is important because the risk to journalistic contacts is potentially different from ordinary employee contact-data exposure. Even a list of relationships can sometimes be sensitive in media environments. That does not mean confidential sources were definitely exposed; Nikkei has not said that. It means investigators need to treat mailbox metadata and communication patterns as potentially valuable information.
The incidents also come after Nikkei disclosed a separate compromise in November 2025, when credentials stolen by infostealer malware from an employee’s personal computer were used to access the company’s Slack environment, potentially exposing data associated with more than 17,000 employees and business partners. That earlier incident is separate and should not be treated as part of the current email-account compromises, but it demonstrates the repeated value attackers find in cloud identities connected to communication platforms.
Across Slack, Microsoft 365 and Google Workspace, the recurring security object is not the application.
It is the identity.
Once a valid user identity is compromised, the attacker may inherit access to years of communication and relationships without needing to exploit the SaaS platform itself.
That is why modern enterprise security increasingly needs to treat cloud identities as high-value assets comparable to privileged endpoints.
Organizations should know which users have access to particularly sensitive correspondence, large external contact networks, administrative cloud privileges or critical business relationships. Those identities should receive tighter conditional access, phishing-resistant MFA, shorter session lifetimes where practical and more aggressive anomaly detection.
The attack chain seen across the Nikkei incidents can be summarized as:
employee cloud identity compromised → attacker gains legitimate mailbox access → contacts and message context become available → malicious emails sent from trusted address → recipients directed to malicious site → credentials potentially harvested → trusted relationship enables additional account compromise
That chain is much more difficult to stop than simple sender spoofing because several security signals remain valid.
The SMTP infrastructure is legitimate.
The domain is legitimate.
The account is legitimate.
The relationship is legitimate.
Only the person behind the keyboard has changed.
That is why identity compromise increasingly defeats simplistic notions of “trusted sender.”
Trust cannot stop at:
“Did this message really come from this account?”
It also needs to ask:
“Is the person currently controlling this account behaving like its legitimate owner?”
For cloud email, that behavioral question may be the difference between detecting one compromised mailbox and watching it send the next 9,000 phishing messages.
Over the weekend, Japanese publishing giant Nikkei disclosed that unknown attackers recently breached two employee email accounts and used one to send thousands of phishing emails. [...]
Source: Nikkei discloses breaches of employees’ Microsoft, Google email accounts via Bleeping Computer — published 06 Oct 2026.
Was this article helpful?
Your feedback helps us improve the knowledge base.