Malware `fast16` adulterava simulações de armas nucleares antes do `Stuxnet`

Ferramenta em Lua interferia em cálculos de detonação e compressão de urânio em LS-DYNA e AUTODYN, com regras condicionais para alterar resultados de simulações específicas.

Componente	Malware fast16, escrito em Lua, com mecanismo de hooks voltado a programas de engenharia e simulação, principalmente LS-DYNA e AUTODYN.
Vetor	Execução em estáções usadas para simulações de explosivos e detonações; o malware se propaga automaticamente para outros endpoints na mesma rede e aciona adulteração apenas em execuções que atendem a condições físicas específicas.
Impacto	Corrupção silenciosa de cálculos em simulações de compressão de urânio e detonação de alto explosivo, com potencial de produzir resultados técnicos falsos em pesquisa de armas nucleares.
Prioridade	Identificar ambientes históricos ou isolados que executem LS-DYNA ou AUTODYN, revisar integridade de binários e resultados de simulação, e tratar qualquer propagação lateral em rede como incidente de sabotagem industrial.
Versões	Foram observados 101 conjuntos de regras agrupáveis em aproximadamente 9 a 10 grupos de hooks, cobrindo diferentes compilações de LS-DYNA e AUTODYN; análise anterior também apontou candidatos prováveis como LS-DYNA versão 970, PKPM e MOHID.
Artefatos	Regras de adulteração matemática, motor de hooks, checagem de densidade acima de 30 g/cm³ e lógica de evasão que evita infecção em computadores com determinados produtos de segurança instalados.

Resumo técnico

O fast16 é um malware de sabotagem industrial escrito em Lua e construído para interferir em simulações técnicas, não para roubo genérico de dados ou indisponibilidade ampla. A análise disponível indica que a ferramenta antecede o Stuxnet e já poderia ter componentes em desenvolvimento por volta de 2005. O alvo operacional não era um equipamento de controle industrial em tempo real, mas o ambiente de engenharia usado para modelar fenômenos físicos críticos. A lógica maliciosa se concentrava em programas de simulação capazes de representar detonações, resposta de materiais e compressão sob choque, com foco confirmado em LS-DYNA e AUTODYN. Essa escolha desloca o impacto da sabotagem para a fase de projeto: em vez de alterar um processo físico já implantado, o código manipula a confiança nos resultados que orientam decisões de pesquisa, validação e desenho.

A característica mais relevante é a seletividade. O mecanismo de hooks não adulterava qualquer cálculo executado pelos programas visados. Ele avaliava propriedades da simulação e só agia quando o cenário envolvia condições compatíveis com detonações de alto explosivo e compressão de material em densidade acima de 30 g/cm³, patamar associado ao urânio quando submetido à compressão por choque em um dispositivo de implosão. Essa condição reduz ruído operacional, diminui a chance de descoberta em simulações comuns e direciona a sabotagem para execuções de alto valor técnico. Para defesa, isso significa que a ausência de falhas óbvias no uso cotidiano de ferramentas de engenharia não elimina risco: o comportamento malicioso pode aparecer apenas em cargas de trabalho muito específicas e difíceis de reproduzir fora do domínio físico correto.

Fluxo técnico

O fluxo de execução combina três elementos: implantação no endpoint de engenharia, instalação de hooks dentro do programa de simulação e adulteração condicional de cálculos matemáticos. O conjunto identificado possui 101 regras voltadas a alterar operações internas realizadas por softwares de engenharia. Essas regras podem ser agrupadas em aproximadamente 9 a 10 famílias, cada uma relacionada a diferentes compilações de LS-DYNA ou AUTODYN. A distribuição por versões indica acompanhamento contínuo dos alvos: quando o usuário atualizava ou retrocedia para uma versão diferente do software, outro grupo de hooks poderia manter a interferência. Essa adaptação é típica de uma operação que depende de conhecimento detalhado do ambiente da vítima, incluindo versões em uso, convenções de chamada produzidas por compiladores e pontos de cálculo com relevância física.

A adulteração era ativada apenas em execuções de detonação e explosão transitória em escala completa. O motor do fast16 analisava a classe da simulação e propriedades do material antes de modificar resultados. A checagem de densidade acima de 30 g/cm³ é um filtro técnico importante porque separa simulações industriais comuns, como impacto automotivo ou modelagem de materiais convencionais, de cenários compatíveis com compressão extrema. Ao alterar cálculos nesse ponto, o malware poderia provocar divergências nos resultados de pressão, densidade, resposta do material ou comportamento hidrodinâmico, sem necessariamente interromper o programa ou produzir erro visível. Para o operador da simulação, a saída poderia parecer válida, mas conter distorções incorporadas ao modelo numérico.

O fast16 também incluía lógica para evitar a infecção de computadores com determinados produtos de segurança instalados. Essa restrição funciona como controle de exposição: reduz a chance de captura por ambientes monitorados e preserva a operação contra análise prematura. Além disso, a ferramenta se propagava automaticamente para outros endpoints na mesma rede. Em um laboratório ou rede de engenharia, esse comportamento é crítico porque uma simulação pode ser preparada em uma estáção, validada em outra e executada em máquinas diferentes. Ao tentar alcançar múltiplos endpoints, o malware aumenta a probabilidade de que qualquer computador usado para rodar LS-DYNA ou AUTODYN gere saídas adulteradas de forma consistente.

Superfície afetada

A superfície exposta é composta por estáções de trabalho e servidores usados para simulações técnicas com LS-DYNA e AUTODYN, especialmente ambientes de pesquisa que executam modelos de alto explosivo, detonação, resposta de materiais e compressão extrema. Embora aplicações como LS-DYNA e AUTODYN também sejam usadas em áreas legítimas e civis, como colisões automotivas, modelagem estrutural e estudos de materiais, a lógica do fast16 restringia a ação maliciosa a cenários com características muito específicas. Essa seletividade limita a detecção por testes funcionais simples: abrir o software, executar um modelo comum ou validar uma simulação fora das condições de disparo pode não revelar a adulteração.

A presença de grupos de hooks para múltiplas compilações amplia o risco em ambientes que mantêm versões antigas por compatibilidade, repetibilidade científica ou dependência de projetos históricos. A análise também indicou candidatos prováveis em investigação anterior, como LS-DYNA versão 970, PKPM e MOHID, mas a confirmação mais recente concentra o alvo em LS-DYNA e AUTODYN. Como o malware evita certos produtos de segurança e se movimenta pela rede, a superfície defensiva não deve se limitar ao host em que a simulação foi executada. É necessário considerar compartilhamentos, servidores de arquivos, estáções de preparação de modelos, máquinas de pós-processamento e nós que recebam artefatos de simulação.

• Estáções com LS-DYNA ou AUTODYN usadas para simulações de detonação, explosão transitória e compressão de materiais.
• Ambientes com versões antigas ou múltiplas compilações dos simuladores, inclusive instalações mantidas para compatibilidade com projetos anteriores.
• Redes de engenharia em que modelos, resultados e binários circulam entre várias máquinas antes, durante ou depois da execução.
• Hosts sem determinados produtos de segurança instalados, pois a lógica de evasão do fast16 podia selecionar onde a infecção ocorreria.

Hunting e telemetria

A investigação defensiva deve priorizar correlação entre execução de simuladores, alterações de integridade e movimentação lateral. Como não há hashes, endereços de comando e controle ou nomes de arquivo confirmados neste conjunto de informações, a caça deve ser comportamental. Um caminho prático é comparar binários de LS-DYNA e AUTODYN com mídia original, checksums internos de fornecedores, backups confiáveis e imagens antigas preservadas. Diferenças em trechos executáveis, bibliotecas carregadas, scripts Lua inesperados ou mecanismos de interceptação de chamadas devem ser tratados como evidência de adulteração. A revisão também deve cobrir diretórios de instalação, plugins, componentes auxiliares e qualquer camada que possa injetar lógica entre o simulador e suas rotinas matemáticas.

A telemetria de endpoint deve buscar execuções anômalas associadas aos simuladores, criação de arquivos não documentados em diretórios de engenharia, carregamento incomum de módulos, alteração de permissões e conexões laterais entre estáções que normalmente não atuam como origem de propagação. Em rede, o foco é identificar comunicação entre hosts de simulação fora dos fluxos administrativos esperados, acessos repetidos a compartilhamentos contendo modelos e resultados, e cópia de artefatos executáveis entre máquinas. Em logs de identidade, eventos relevantes incluem uso de contas técnicas fora do horário normal, autenticações cruzadas entre estáções de pesquisa e tentativas de acesso a múltiplos endpoints em sequência.

A validação dos resultados científicos também faz parte da resposta. Como o impacto central é a corrupção silenciosa de cálculos, a defesa deve selecionar simulações históricas críticas e reexecutá-las em ambiente limpo, com binários verificados e cadeia de ferramentas reconstruída. Divergências persistentes em cenários que envolvam alto explosivo, detonação transitória e densidade extrema devem ser analisadas como possível efeito de sabotagem, não apenas como variação numérica. A comparação deve registrar versão do simulador, compilação, sistema operacional, bibliotecas, parâmetros do modelo e arquivos de entrada, porque o fast16 parece depender de combinações precisas para acionar sua lógica.

• Diferenças de integridade em binários, bibliotecas, scripts ou componentes auxiliares de LS-DYNA e AUTODYN.
• Execução de código Lua não documentado ou presença de mecanismos de hooks associados a programas de simulação.
• Propagação entre estáções de engenharia, cópia lateral de executáveis ou acessos incomuns a compartilhamentos de modelos e resultados.
• Divergências em reexecuções limpas de simulações de detonação, explosão transitória ou compressão com densidade acima de 30 g/cm³.

Mitigação

A resposta deve começar pela preservação forense dos sistemas de simulação e pela interrupção controlada da propagação lateral. Isolar estáções suspeitas, coletar memória quando viável, preservar imagens de disco e exportar logs antes de reinstalações evita perda de evidência. Em seguida, os defensores devem reconstruir a cadeia de confiança dos simuladores: validar instaladores, binários, bibliotecas, arquivos de configuração, permissões e dependências usadas em LS-DYNA e AUTODYN. Como o malware pode alterar cálculos sem quebrar a execução, reinstalar o software sem revisar resultados anteriores não é suficiente. Projetos críticos precisam de reprocessamento em ambiente limpo, com registro reproduzível de versão, parâmetros e artefatos de entrada.

A contenção de rede deve tratar estáções de engenharia como ativos de alto valor. Segmentar ambientes de simulação, reduzir compartilhamentos amplos, remover credenciais persistentes entre hosts e aplicar listas de permissão para execução de binários diminui a chance de reinfecção. Em endpoints, controles úteis incluem monitoramento de integridade de arquivos, bloqueio de scripts não autorizados, auditoria de carregamento de módulos e política de execução restrita para diretórios de instalação. Como o fast16 evita certos produtos de segurança, a defesa não deve depender apenas da presença do agente de proteção; é necessário combinar verificação offline, comparação criptográfica e análise de comportamento.

A mitigação também envolve governança técnica sobre versões de software científico. Ambientes que mantêm compilações antigas por compatibilidade devem inventariar cada versão, associá-la a projetos específicos e registrar checksums aprovados. Quando um usuário retrocede para uma versão anterior por causa de anomalia nos resultados, esse evento deve gerar investigação, porque o conjunto de hooks do fast16 sugere adaptação a múltiplas versões usadas ao longo do tempo. A revisão de simulações históricas deve priorizar saídas que tenham orientado decisões de projeto, validações de materiais ou conclusões sobre detonação e compressão extrema.

• Isolar hosts suspeitos, preservar evidências e impedir comunicação lateral entre estáções de engenharia antes de reinstalar sistemas.
• Revalidar LS-DYNA, AUTODYN, bibliotecas e componentes auxiliares a partir de fontes confiáveis e checksums conhecidos.
• Reexecutar simulações críticas em ambiente limpo, registrando versão, compilação, parâmetros e artefatos de entrada para comparação técnica.
• Segmentar redes de pesquisa, restringir compartilhamentos, aplicar controle de execução e monitorar alterações em diretórios dos simuladores.
• Inventariar versões antigas e investigar retornos incomuns para compilações anteriores quando associados a divergências de resultado.