NotPetya: o ciberataque mais caro de sempre

25 de fevereiro de 2026 • 12 min read

No final de junho de 2017, começa na Ucrânia algo que, à primeira vista, parece “ransomware como sempre”: máquinas a reiniciar, ficheiros de repente indisponíveis e um pedido de resgate no ecrã.

Poucas horas depois, é claro: isto não é um incidente local. É um incêndio.

O nome que ficou é NotPetya. Até hoje, é um símbolo de como uma suposta “vaga simples de malware” se pode transformar num evento que paralisa empresas no mundo inteiro e causa danos na ordem dos milhares de milhões.

Neste artigo quero ligar duas coisas:

A história por trás do NotPetya: o que aconteceu e porque foi tão caro?
A perspetiva prática: o que é que isto significa para empresas “normais” hoje — não só para Fortune 500?

O lado desconfortável do NotPetya não é que fosse “demasiado complexo”. O lado desconfortável é: é assustadoramente realista.

Porque escrevo isto em 2026? Porque hoje falamos de phishing com deepfakes alimentados por IA, mas em crise continuamos a falhar nas mesmas coisas básicas que em 2017: falta de segmentação e backups ligados ao mesmo “soro” que a produção.

NotPetya em 5 minutos: o que aconteceu?

Para contextualizar, temos de pôr os acontecimentos em ordem.

No dia 27 de junho de 2017, o NotPetya apareceu primeiro na Ucrânia e depois espalhou-se globalmente a grande velocidade. Um ponto central foi uma atualização comprometida de um software de contabilidade muito usado na Ucrânia (M.E.Doc). Ou seja: não entrou por “um clique estúpido”, mas por um mecanismo que as empresas usam todos os dias — atualizações.

E isto é algo que muita gente subestima em retrospectiva: no fundo, foi um ataque à supply chain (cadeia de fornecimento). O M.E.Doc não foi um acaso; foi a alavanca perfeita, porque as updates são confiadas por design.

A lição para hoje é desconfortável, mas importante: podes fazer muita coisa bem dentro de casa; se o software do teu contabilista, de um fornecedor, um conector de ERP ou uma ferramenta de terceiros for comprometida, continuas a estar no raio de explosão. Risco de supply chain não é “um problema cloud” — é, muito concretamente, um problema de updates.

Uma vez dentro da rede, deixou de ser sobre endpoints isolados e passou a ser Lateral Movement (movimento lateral):

Via SMB e vulnerabilidades conhecidas (incluindo EternalBlue / MS17-010, um exploit que saiu de um leak do toolkit da NSA), o NotPetya conseguia propagar-se para outros sistemas Windows sem interação do utilizador.
Em paralelo, usava credential dumping (Mimikatz/LSASS) para tirar passwords/hashes da RAM e avançar com credenciais reais de admin.
Para a execução remota, usava ferramentas “normais” de administração (por exemplo, PsExec/WMI). Esta mistura é perigosa porque, nos logs, pode parecer “operação normal” no início.

Esta foi a “receita secreta”: exploit para saltar rapidamente para novas máquinas, credenciais extraídas da memória para obter privilégios reais e, depois, escalar com ferramentas nativas.

O ponto importante: só aplicar patches não teria chegado. Mesmo que uma máquina estivesse patchada contra o EternalBlue, podia cair na mesma assim que o malware tivesse apanhado credenciais/hashes admin válidos algures na rede.

O NotPetya também jogava com o tempo: incorporava um atraso e não forçava o “grande estrondo” (reboot/wipe) logo de imediato, mas apenas passado algum tempo. Isto é péssimo para a deteção e, de passagem, um clássico contra sandboxing: o malware não “detona” imediatamente, enquanto por trás já está a escalar.

O resultado é exatamente o que se vê sempre nestas situações:

Primeiro, alguns sistemas ficam “estranhos”.
Depois, de repente, um site inteiro cai.
E se não reagires muito depressa (desligar redes, bloquear contas, fechar fronteiras de segmentação), o incidente pode tornar-se multi-site.

Porque “ransomware” era só camuflagem

O NotPetya foi percebido como ransomware porque mostrava um pedido de resgate. Mas tecnicamente e na prática era outra coisa.

O ponto essencial: o NotPetya era, na realidade, um wiper. Malware cujo objetivo não é “ganhar dinheiro”, mas destruir sistemas e travar operações.

Isto pode soar a semântica. Em incident response, muda tudo:

Com ransomware clássico, há (às vezes) uma hipótese de recuperar dados via chaves ou negociação.
Com um wiper, o objetivo é “estragar”. Pagar em Bitcoin não te salva.

No NotPetya há um detalhe técnico que reforça brutalmente o caráter de wiper: sobrescrevia o MBR (Master Boot Record) e cifrava a MFT (Master File Table). E até a mecânica “ransomware” estava mal implementada: o ID de instalação apresentado era gerado aleatoriamente e não estava devidamente ligado a uma chave de desencriptação utilizável. Ou seja: na prática, não havia caminho de volta.

É por isso que o NotPetya foi tão perverso: empurrou muitas empresas para o playbook errado no início. Pensa-se “playbook de ransomware”, mas o que se precisa é “playbook de disaster recovery”.

O facto de o ataque ser mais destruição do que dinheiro também encaixa com a atribuição posterior: vários governos atribuíram publicamente o NotPetya a atores estatais russos.

10 mil milhões de dólares: porque foi tão caro?

Se olhares apenas para o rótulo “ransomware”, o dano parece difícil de explicar. “Então é só restaurar do backup, certo?”

Na prática, o NotPetya foi tão caro sobretudo porque acertou numa área onde muita gente investe pouco: disponibilidade.

O maior bloco de custos não foi o malware em si, mas a paragem.

Linhas de produção param.
A logística volta ao papel.
Identidades e domínios têm de ser reconstruídos.
Aplicações, integrações e dependências caem em cascata.
E isto não acontece num único sistema, mas em muitos ao mesmo tempo.

É por isso que o NotPetya é muitas vezes descrito como “o ciberataque mais caro de sempre”. Em relatórios, os danos totais são estimados em cerca de 10 mil milhões de dólares.

E dá para ver isso em números de empresas individuais: Merck, FedEx (incluindo TNT Express) e Mondelez descreveram nos seus relatórios que isto não foi “um tema de IT”, mas um tema de negócio com impacto real em receita, custos e capacidade de entrega.

O NotPetya também teve um enorme pós-efeito jurídico: empresas entraram em disputa com as seguradoras. Algumas seguradoras tentaram não pagar, classificando o NotPetya como “Act of War” (ou seja, um ataque dirigido por um Estado). Um exemplo famoso foi o conflito da Mondelez com a sua seguradora. Para empresas, isto continua a ser uma lição dura: o meu seguro ciber cobre ataques estatais — ou uma war exclusion entra em ação quando mais importa?

Update para leitores pro: o caso da Mondelez ficou resolvido em 2023. Depois disso (e, em geral, após o NotPetya), o mercado apertou a linguagem em muitos contratos: em muitas apólices, ataques “state-motivated” são hoje definidos de forma mais estreita ou explicitamente excluídos. Isso transforma o seguro ciber num risco financeiro muito real se não compreenderes as cláusulas a sério.

E há outra coisa importante: mesmo que “só” estejas a restaurar IT, na realidade estás a lutar contra dependências.

Um exemplo que aparece em muitos retrospectivos é a Maersk: não se tratou de alguns ficheiros cifrados, mas da reconstrução de sistemas core, identidades e IT operacional para que portos e logística pudessem voltar a arrancar.

A história é lendária porque mostra como identidades e backups podem ser frágeis: a Maersk perdeu praticamente todo o Active Directory — exceto um Domain Controller (controlador de domínio) no Gana que, devido a uma falha de energia, estava offline no momento do ataque. Esse “Lucky Punch” acabou por ser um backup offline acidental: com esse único servidor físico, conseguiram reconstruir o AD global e acelerar a recuperação.

No fim, isto não afeta só “IT”, mas o negócio diretamente:

Numa empresa alimentar: produção, planeamento e supply chain param.
Numa empresa de transporte marítimo: contentores ficam parados.
Numa farmacêutica: fabrico, processos de qualidade e capacidade de entrega ficam sob pressão.

É por isso que o número é tão alto: o ecrã do resgate é só o sintoma. O dano real é a paragem.

Cenário prático: o ataque que eu esperaria numa empresa “normal”

Quero descrever de propósito um caso que não parece Hollywood. Não “state actor vs big tech”, mas um cenário plausível para uma empresa média.

Imagina uma empresa de média dimensão:

Um site principal e um segundo site pequeno.
Um setup Windows clássico: AD, file servers, algumas VMs, um ERP.
Mais alguns sistemas que quase ninguém quer mexer: controladores de máquinas, software antigo, um “Windows Server 2008 qualquer coisa”, porque o fornecedor nunca atualizou.
Backups existem: diário para um NAS, semanal também para um segundo sistema.

E aqui vem o ponto que muita gente subestima:

Esta empresa não tem “pouca segurança” porque toda a gente é incompetente. É porque operação e tempo ganham sempre.

O patching é adiado porque o planeamento da produção está apertado. A segmentação fica para “mais tarde” porque VLANs dão trabalho. Passwords de admin local cresceram historicamente. E o NAS está, claro, online, porque os restores seriam demasiado incómodos caso contrário.

A linha temporal (realista, não dramática)

Numa manhã de terça-feira chega uma atualização. Pode ser um fornecedor, uma ferramenta de prestador, um conector — qualquer coisa que atualiza automaticamente. Ou é um sistema comprometido num parceiro com acesso via VPN.

08:10: os primeiros clientes ficam instáveis. Um reboot aqui, um erro estranho ali.
08:25: o primeiro file server fica lento. Os tickets do helpdesk aumentam.
08:40: de repente, “o domínio está estranho”. O login demora, as GPOs falham.
09:00: um admin faz login “só para ver”. Muitas vezes é aí que o lateral movement ganha velocidade.
09:20: um site inteiro está, na prática, offline.

E agora vem a parte que só se compreende bem depois:

Se nesse momento não cortares de forma dura, o dano não escala linearmente — escala exponencialmente.

E, claro, vem a pergunta que vem sempre:

“Temos de pagar?”

No NotPetya, a resposta amarga era: mesmo que quisesses, provavelmente não era solução. Psicologicamente, isso muda tudo, porque tens de mudar logo para “reconstrução”, não “desencriptação”.

Quanto mais esperas, mais sistemas tens de refazer. Quanto mais sistemas tens de refazer, mais tempo ficas em modo de emergência. E quanto mais tempo ficas em modo de emergência, mais caro fica.

O que dói mesmo

Passadas algumas horas, fica claro: isto não é “restauramos alguns ficheiros”. Isto é “reconstruímos Active Directory e sistemas core”.

E então percebes:

Os backups estavam online e foram apanhados.
A documentação não está atualizada.
Tens poucas “golden images” para reimaging rápido.
Credenciais de admin estavam por todo o lado.
Ninguém praticou como segmentar um site de forma limpa em 30 minutos.

É aí que um incidente de IT se torna uma crise empresarial.

O que um SOC faz diferente hoje (e o que a IA tem a ver com isso)

Num grande Security Operations Center (SOC), entram por dia milhares de milhões de eventos vindos de muitas fontes. Isto já não é “um admin a olhar para o log da firewall”, mas um processo industrializado de telemetria, correlação, automação e análise humana.

O que acho interessante é a divisão de papéis:

IA/automação como primeira linha: organiza, correlaciona, deteta padrões e filtra o óbvio.
Humanos como segunda/terceira linha: quando o caso é crítico ou ambíguo, analistas assumem, decidem medidas e coordenam a resposta.

Isto soa a “só para grandes”, mas a aprendizagem serve para empresas pequenas também:

Não precisas de construir um SOC. Mas precisas da mesma mentalidade:

Recolhe sinais (EDR, firewall, logs de autenticação).
Define o que é “normal”.
E tem um processo que reage em minutos, não em dias.

O NotPetya em 2017 já era tão rápido que nenhum humano conseguiria “reagir depressa o suficiente” quando a propagação estava a acontecer. O ponto da IA é menos “ainda mais rápido” e mais: ajudar-te a encontrar mais cedo a anomalia no ruído (por exemplo, às 03:00, de repente 500 máquinas a querer falar SMB entre si). Esses minutos decidem: ver mais cedo, limitar mais cedo, isolar mais cedo.

E depois há a mentalidade que cada vez mais vejo como default:

Assume breach.

Planeia como se o atacante já estivesse dentro. Não por paranoia, mas por pragmatismo.

O mínimo que quero ver hoje (sem orçamento enterprise)

Se há uma coisa para levares do NotPetya, é esta:

O NotPetya não foi “uma falha”. Foi uma cadeia de fraquezas a reforçarem-se mutuamente.

A boa notícia: exatamente por isso, alguns básicos tiram imenso risco.

1) Patching e exposure management (a sério)

Updates críticos de Windows (sobretudo em torno de SMB) não podem ser “um dia”.
Tudo o que é acessível do exterior tem prioridade.
E se tens legacy: pelo menos segmentado, com regras claras.

2) Tornar o lateral movement difícil

Separar contas admin (dia a dia vs admin).
Passwords de admin local únicas por máquina (LAPS).
Não deixar ferramentas de admin remota (WMI, PsExec) abertas por todo o lado.
Restringir SMB onde não é mesmo necessário.

3) Segmentação, mas pragmática

Não tens de fazer Zero Trust “perfeito” amanhã. Mas:

Clientes, servidores, backups e OT/produção não devem estar numa rede plana.
Domain Controllers são tier 0 e têm de ser protegidos como tal.
Tráfego leste-oeste merece tanta atenção como tráfego para a internet.

4) Backups: offline, imutáveis, testados

Digo isto como vejo em projetos:

Um backup sempre online e sempre gravável muitas vezes não é backup no momento crítico.

3-2-1 é um bom começo.
Storage imutável (ou media offline) muda o jogo.
Testes de restore são obrigatórios. Não “temos backups”, mas “praticámos restores”.

5) Runbooks e um “kill switch” para sites

Não precisas de um manual de 80 páginas. Mas precisas de clareza:

Quem decide que um site é isolado?
Como bloqueias contas rapidamente?
Que sistemas têm de voltar primeiro (AD, DNS, DHCP, VPN, ERP)?

E sim: isto tem de ser treinado, senão não te ajuda em crise.

Reality-check: no NotPetya, em muitos casos a medida mais eficaz não foi “mais uma ferramenta”, mas separação física. Há relatos de que, na Maersk, pessoas literalmente correram por escritórios e puxaram cabos (rede/energia) de switches para travar a propagação. Parece básico, mas às vezes é a melhor high-tech security quando cada segundo conta.

Conclusão

Para mim, o NotPetya continua a ser um dos melhores exemplos de porque segurança não se resolve com “temos antivírus”.

Não foi devastador por ser mágico. Foi devastador porque explorou pontos fracos muito comuns:

confiança em updates
demasiado lateral movement
pouca segmentação
backups demasiado colados à produção

E é exatamente por isso que é tão relevante para empresas “normais”.

Se investes hoje, não invistas só em ferramentas: investe em resiliência (visibilidade, resposta rápida e capacidade de restaurar sistemas de forma limpa). É a diferença entre “um dia horrível” e “um trimestre que nunca recuperas”.

Fontes e leituras adicionais

Até à próxima, Joe