O maior fabricante de eletrônicos do mundo foi atingido por ransomware. Mas o que torna este caso singular não é o tamanho da vítima — é o bug no encryptor que transforma extorsão em destruição pura. Segundo a análise da Coveware, o criptografador (encryptor) ESXi da Nitrogen corrompe a própria chave pública durante a criptografia. O resultado: a descriptografia é matematicamente impossível, independente de pagamento. Nem os atacantes conseguem recuperar os arquivos. Na Tech86, vemos este caso como a demonstração inequívoca de que pagar resgate nunca foi garantia de recuperação — e agora, em cenários específicos, é garantia matemática de fracasso.
O ataque à Foxconn: timeline e impacto
Segundo o site de vazamento da Nitrogen, a Foxconn foi listada em 11 de maio de 2026. A Foxconn confirmou o ataque em 12 de maio, após inicialmente classificar o incidente como "problema técnico" em declaração à imprensa. A fábrica de Mount Pleasant, em Wisconsin, parou: segundo relato de um funcionário verificado pelo DysruptionHub, Wi-Fi indisponível às 7h, funcionários liberados às 11h, folhas de ponto registradas em papel.
A Nitrogen alega ter roubado aproximadamente 8 TB e 11 milhões de arquivos — afirmação do grupo, não verificação independente. As amostras no leak site incluem documentos de engenharia da Foxconn e, segundo a AppleInsider, esquemas de servidores Apple referentes a infraestrutura de data center, não projetos de produtos consumidores. A Foxconn não confirmou que dados de clientes foram acessados. Os nomes dos clientes — Apple, Nvidia, Intel — são tática de extorsão: maximizar pressão independente do conteúdo real dos arquivos.
Contexto: esta é a 4ª vez que a Foxconn é atingida por ransomware. Segundo registros públicos, DoppelPaymer em 2020, LockBit em 2022, LockBit em 2024 na subsidiária Foxsemicon, e agora Nitrogen em 2026. A planta de Wisconsin foi recentemente expandida com investimento de US$ 569 milhões e parceria com a OpenAI para projeto e fabricação de hardware de infraestrutura de IA.
O bug: quando a criptografia se autodestrói
O detalhe técnico que diferencia este ataque é a análise que a Coveware fez do encryptor ESXi da Nitrogen, publicada em 2 de fevereiro de 2026. A engenharia reversa revelou um bug crítico na gestão de memória do encryptor.
A chave pública é armazenada como variável de stack em rsp+0x20. Outra variável QWORD em rsp+0x1c sobrescreve 4 bytes da chave pública com zeros. A chave corrompida é então usada na troca de chaves Curve25519 para criptografar cada arquivo. Como a chave corrompida nunca foi derivada de uma chave privada válida, não existe chave privada correspondente. Nem os atacantes têm. A descriptografia é matematicamente impossível.
Este bug afeta apenas a variante ESXi. A variante Windows funciona corretamente. Organizações precisam identificar qual variante criptografou seus arquivos antes de assumir que a recuperação é impossível.
A janela de aproximadamente 3 meses: disclosure sem correção
A Coveware publicou essa análise em 2 de fevereiro de 2026. O ataque à Foxconn começou em maio. Aproximadamente 3 meses se passaram entre a disclosure pública do bug e o ataque. A Nitrogen ou não corrigiu o bug, ou não se importa. Para vítimas com criptografia ESXi, pagar o resgate não resolve nada — o dinheiro vai e os arquivos ficam inacessíveis.
Isso revela algo fundamental sobre o modelo de negócio do ransomware como serviço: os operadores não necessariamente se importam com a funcionalidade do produto. O encryptor é um meio de pressão, não uma ferramenta de engenharia confiável. Quando o bug impede a descriptografia, o atacante ainda pode extorquir com a ameaça de vazamento — mas a promessa de descriptografia é falsa.
O vetor: malvertising como porta de entrada
O vetor de acesso inicial não foi confirmado pela Foxconn. A Nitrogen é conhecida por malvertising (anúncios maliciosos): anúncios maliciosos no Google e Bing para instaladores trojanizados de ferramentas de TI como AnyDesk, WinSCP, PuTTY, FileZilla e Cisco AnyConnect. É o modus operandi documentado do grupo, mas não confirmado neste ataque específico.
O que importa operacionalmente: equipes de TI que buscam ferramentas legítimas em mecanismos de busca são o vetor. Não é phishing sofisticado — é exploração de confiança em canais de distribuição de software. EDR com detecção comportamental identifica a execução de cargas anômalas mesmo quando o vetor inicial parece legítimo.
A lição operacional: pagar não é estratégia
Se o encryptor tem bug, pagar não adianta. Se o atacante não corrige o bug aproximadamente 3 meses após disclosure pública, o modelo de negócio da extorsão quebra. E a vítima fica sem arquivos e sem dinheiro.
A Foxconn é um caso extremo por escala, mas o padrão se aplica a qualquer organização. A decisão de pagar resgate historicamente dependeu da boa-fé do atacante — de que o decryptor funciona, de que os dados não vazam depois, de que a chave é entregue. Quando o próprio encryptor é defeituoso por design ou por negligência, essa dependência se revela pelo que é: uma aposta.
Na Tech86, defendemos que a resposta a ransomware começa antes do ataque: inventário de ativos, backups offline testados, EDR com detecção comportamental e monitoramento contínuo. Quando o encryptor falha, essas são as únicas coisas que funcionam.
