Nikkei: quatro incidentes em um ano, fontes jornalísticas expostas ao phishing
A Nikkei confirmou dois acessos não autorizados simultâneos — um ao Microsoft 365 (usado para disparar ~9.000 e-mails de phishing a fontes jornalísticas) e outro ao Google Workspace (expondo dados de 1.646 pessoas) — ambos divulgados em 4 de outubro de 2026. Nenhum ator foi identificado, a conexão entre os dois incidentes não foi esclarecida, e a empresa não confirmou nem negou exposição de fontes no caso do M365, ao contrário do que o título original sugere.
Analytic judgments
Every assessment carries its confidence level explicitly, following intelligence practice (ICD 203 / FIRST). High confidence is not certainty; low confidence is not a guess — it’s the weight the available evidence supports.
O incidente do Microsoft 365 foi um ATO (Account Takeover) com uso do acesso para lançar campanha de phishing de segundo estágio — o objetivo provável era coleta de credenciais, não exfiltração direta de dados, dado que a subsidiária Nikkei BP confirmou que um funcionário perdeu credenciais ao clicar em um dos 9.000 e-mails disparados.
A Nikkei descartou exposição de fontes jornalísticas apenas no incidente do Google Workspace; para o caso do Microsoft 365, onde os destinatários incluíam fontes, nenhuma declaração equivalente foi emitida — lacuna que pode ser intencional ou resultado de investigação ainda em curso.
O padrão recorrente de comprometimento de contas SaaS (Slack em nov/2025, Nikkei America M365 em mar/2026, M365 e Google Workspace em set-out/2026) indica falha sistêmica de controles de identidade no grupo Nikkei — MFA ausente ou contornável, ausência de detecção de sessão anômala, ou políticas de acesso condicional insuficientes.
Os dois incidentes de outubro podem ser tecnicamente independentes (dois funcionários distintos, plataformas distintas, períodos distintos), mas a divulgação simultânea em 4 de outubro sugere que a investigação interna as tratou em conjunto, possivelmente após identificar relação de causa ou actor comum — o que a empresa não confirmou nem negou.
O veículo de origem (The Record) intitulou a reportagem como 'targeting journalistic sources', mas a Nikkei não confirmou que fontes tiveram dados exfiltrados — apenas que fontes estavam entre os destinatários dos e-mails de phishing. A manchete original amplifica o risco além do que a evidência sustenta.
A ausência de menção a revogação de sessões ativas — apenas troca de senha — na divulgação da Nikkei representa uma lacuna de contenção relevante: sessões OAuth abertas podem permanecer válidas mesmo após reset de senha dependendo da configuração do tenant M365.
Analysis
A divulgação da Nikkei em 4 de outubro de 2026 cobre dois incidentes distintos, comunicados no mesmo comunicado, o que contribuiu para confusão narrativa tanto na imprensa quanto no nosso próprio registro inicial. Vale separar com precisão o que a empresa disse de cada caso.
No incidente do Microsoft 365: um funcionário teve a conta comprometida por terceiro desconhecido, que a utilizou em 30 de setembro para disparar aproximadamente 9.000 e-mails com links para sites maliciosos. Os destinatários incluíam funcionários internos e fontes jornalísticas com quem múltiplos funcionários tinham comunicação prévia. A Nikkei afirma que nomes, endereços de e-mail e o conteúdo de alguns e-mails podem ter vazado. A empresa não descartou exposição de informações de fontes neste caso — apenas disse que ainda está investigando. O título original da notícia ('targeting journalistic sources') é impreciso: as fontes eram destinatárias do phishing, não necessariamente vítimas de exfiltração de dados sobre elas.
No incidente do Google Workspace: acesso não autorizado a partir do final de julho, descoberto em agosto após alerta do Google. Dados de 1.646 pessoas (funcionários e parceiros de negócios) potencialmente expostos — nomes e e-mails. A Nikkei afirmou explicitamente que este incidente não incluiu informações de leitores ou fontes jornalísticas. A nota de confiança desta afirmação é A2: a própria empresa declarou (fonte A), e não há contradição externa (informação 2).
O detalhe mais revelador do conjunto é o que aconteceu na Nikkei BP: um funcionário da subsidiária perdeu suas credenciais ao clicar em um dos 9.000 e-mails enviados da conta Nikkei comprometida, resultando em vazamento potencial de 26 nomes e e-mails. Isso confirma que a campanha de phishing foi de segundo estágio — credencial harvesting — e não apenas spam de baixo impacto. É o único elo confirmado entre os dois incidentes (o e-mail de spoofing gerou uma nova vítima), mas não prova que os dois comprometimentos de conta (M365 e Google Workspace) tenham o mesmo ator.
O contexto histórico é o elemento mais preocupante: este é o quarto incidente divulgado pelo grupo Nikkei em menos de 12 meses. Em novembro de 2025, infostealer comprometeu Slack (17.368 pessoas). Em março de 2026, Nikkei America perdeu uma conta M365 (291 pessoas). Agora, em outubro de 2026, M365 e Google Workspace foram comprometidos simultaneamente. O padrão — endpoint comprometido ou credencial roubada → acesso a SaaS → uso da conta legítima para novo ataque — é consistente com o modelo de infostealer + BEC (Business Email Compromise), mas a Nikkei não confirmou o vetor de comprometimento inicial para nenhum dos dois incidentes de outubro. A causa-raiz permanece oficialmente desconhecida.
Um analista técnico independente apontou com precisão que 'a nuvem foi atacada' e 'uma conta na nuvem foi comprometida' são afirmações com implicações muito diferentes. Não há evidência de brecha na infraestrutura da Microsoft ou do Google — o alvo foram credenciais de usuário final. Isso é relevante para atribuição de responsabilidade e para as recomendações técnicas.
A Nikkei voluntariamente notificou a Comissão de Proteção de Informações Pessoais do Japão em ambos os casos, o que é consistente com boas práticas e com o regime japonês de proteção de dados — embora a empresa tenha ressaltado que os dados envolvidos no incidente do Slack de 2025 não eram tecnicamente cobertos pelas leis de proteção de informação pessoal do Japão. Para este incidente de outubro, a investigação do escopo total ainda estava em curso na data de publicação deste relatório.
Timeline
- 04 Nov 2025Nikkei divulga comprometimento do Slack via infostealer em PC de funcionário — dados de 17.368 pessoas potencialmente expostos (nomes, e-mails, histórico de chat). Incidente identificado internamente em setembro/2025.
- 01 Mar 2026Nikkei America sofre comprometimento de conta M365; e-mails de spoofing enviados a parceiros comerciais; 291 pessoas potencialmente afetadas. Descoberto após aviso de terceiro.
- 07 May 2026Nikkei America divulga formalmente o incidente de março ao público.
- 01 Jul 2026Início do acesso não autorizado à conta Google Workspace de funcionário da Nikkei (data aproximada — 'final de julho' segundo a empresa).
- 01 Aug 2026Nikkei recebe alerta do Google sobre acesso anômalo à conta Workspace e muda a senha. Nenhum login não autorizado subsequente detectado.
- 30 Sep 2026Conta Microsoft 365 de funcionário da Nikkei usada para disparar ~9.000 e-mails contendo links para sites maliciosos, direcionados a funcionários internos e fontes jornalísticas externas.
- 04 Oct 2026Nikkei divulga publicamente os dois incidentes (M365 e Google Workspace) e reporta ambos à Comissão de Proteção de Informações Pessoais do Japão. Nikkei BP divulga separadamente que um funcionário perdeu credenciais ao clicar em um dos e-mails disparados da conta Nikkei comprometida, expondo 26 nomes e endereços de e-mail.
- 06 Oct 2026Bleeping Computer e The Record publicam análises com base nas divulgações oficiais. Investigação do escopo total do incidente M365 ainda em andamento segundo a empresa.
Data involved
Impact
Impacto direto confirmado: (1) ~9.000 destinatários — funcionários da Nikkei e fontes jornalísticas externas — receberam e-mails de phishing a partir de conta legítima da Nikkei, com links para sites maliciosos; alguns tiveram nomes, endereços de e-mail e conteúdo de mensagens expostos. (2) 1.646 funcionários e parceiros de negócios tiveram dados potencialmente expostos via Google Workspace (nomes e e-mails). (3) A Nikkei BP confirmou que um funcionário perdeu credenciais ao clicar em um dos e-mails de phishing, expondo 26 registros adicionais. O risco residual mais grave é o uso das identidades de fontes jornalísticas expostas como insumo para campanhas de spear phishing futuras — o ator obteve uma lista de quem conversa com jornalistas do maior grupo de mídia econômica do Japão, dono do Financial Times.
Technical links
Recommendations
- Revogar imediatamente todas as sessões OAuth ativas das contas comprometidas no M365 e no Google Workspace — não apenas redefinir senhas. No M365: 'Revoke-AzureADUserAllRefreshToken' ou equivalente no portal Entra ID. No Google Workspace: encerrar todas as sessões ativas no Admin Console. Troca de senha sem revogação de token deixa sessões persistentes abertas.
- Auditar o status de MFA em todas as contas de e-mail corporativas — especialmente contas de jornalistas que se comunicam com fontes externas. Priorizar implementação de chave de segurança física (FIDO2/passkey) para contas com alto perfil de risco jornalístico, que são resistentes a ataques AiTM diferentemente de OTP por SMS ou app.
- Implementar políticas de acesso condicional que bloqueiem login de IPs ou ASNs fora do padrão histórico do usuário, exigindo step-up authentication para acesso a partir de localização nova. No M365: Conditional Access com Named Locations. No Google Workspace: Context-Aware Access.
- Fontes jornalísticas e parceiros que receberam os ~9.000 e-mails de phishing devem ser alertados explicitamente sobre o risco de campanha de spear phishing subsequente usando as identidades e contextos comunicacionais expostos — não apenas sobre o e-mail original. O aviso genérico emitido pela Nikkei ('pode haver aumento de e-mails de impersonação') é insuficiente para este perfil de risco.
- Conduzir varredura de infostealer em todos os endpoints de funcionários que usam as contas comprometidas, e expandir para endpoints de funcionários com acesso a sistemas SaaS críticos. O incidente do Slack de 2025 foi causado por infostealer — se o vetor atual for semelhante, a infecção pode estar ativa em outros dispositivos não identificados.
Intelligence gaps
What we still don’t know. A report that doesn’t declare its holes is selling, not analyzing.
Vetor de comprometimento inicial das contas M365 e Google Workspace: a Nikkei não divulgou como os atacantes obtiveram as credenciais — phishing, infostealer, password spray ou outro método. Divulgação do laudo técnico interno ou do relatório de forense resolveria.
Se os dois incidentes (M365 e Google Workspace) têm o mesmo ator: a empresa disse explicitamente que não sabe — ou não disse que sabe. Análise de logs de acesso (IPs, ASNs, user agents) poderia estabelecer ou descartar relação.
Se MFA estava habilitado nas contas comprometidas: a Nikkei não mencionou MFA em nenhum dos comunicados, apenas troca de senha. Essa omissão é ela mesma informação — ou as contas não tinham MFA, ou o MFA foi contornado (AiTM, session hijacking), ou a empresa preferiu não abordar o ponto.
Escopo real do incidente M365: a investigação do número de pessoas afetadas e do conteúdo exfiltrado estava em curso na data de divulgação. Atualização oficial da empresa à Comissão de Proteção de Informações Pessoais do Japão resolveria.
Se sessões OAuth ativas foram revogadas além da troca de senha: os comunicados mencionam apenas reset de senha — não revogação de tokens. Se sessões persistentes não foram encerradas, o acesso pode ter continuado após o anúncio.
Relação com o incidente de 2025 (Slack/infostealer): o Slack de novembro de 2025 foi causado por infostealer em PC de funcionário. Se a mesma técnica foi usada agora, há um problema de higiene de endpoint não resolvido. A Nikkei não conectou os casos.
Sources and rating
Admiralty rating (NATO standard, used by CERT-EU and OpenCTI): the letter rates SOURCE reliability (A completely reliable to F not rated); the number rates INFORMATION credibility (1 confirmed to 6 cannot be judged). Both dimensions are assessed independently — a good source does not make weak information reliable.