Desde abril de 2025, o Gunra ransomware tem se destacado como uma das ameaças mais versáteis e preocupantes no cenário de segurança cibernética. Ao contrário de muitos ataques limitados a um sistema operacional, o Gunra foi projetado para funcionar tanto em ambientes Windows quanto Linux e com técnicas de criptografia diferentes para cada caso.
Essa capacidade de operar em múltiplas plataformas não é um detalhe técnico, mas um indicativo claro de maturidade operacional. Grupos como o Gunra estão mirando infraestruturas corporativas mistas, e essa abordagem multiplica o impacto potencial de suas campanhas, como já foi observado em ataques documentados na Coreia e em outros países.
Duas variantes, dois níveis de risco
A versão para Windows do Gunra chega em formato EXE, enquanto a variante Linux é entregue como um binário ELF. Ambas são executadas via linha de comando e exigem parâmetros específicos: número de threads para criptografia paralela, caminho de destino, extensões de arquivos a serem criptografadas, proporção de criptografia e caminho para a chave pública RSA.
No entanto, apesar da similaridade operacional, as implementações criptográficas revelam uma disparidade preocupante. A versão Linux possui uma falha crítica de segurança no processo de geração de chaves.
A criptografia usa o algoritmo ChaCha20, mas a geração dos valores de chave e nonce depende da função time() uma escolha frágil. Como o processo é rápido, múltiplas execuções acabam usando o mesmo seed. O resultado são chaves e nonces compostos por padrões de bytes repetidos. Isso abre a porta para ataques de força bruta extremamente simples: bastam 256 tentativas com diferentes valores de byte para quebrar a criptografia e recuperar os arquivos.
Pesquisadores de segurança já comprovaram que é possível descriptografar arquivos afetados por essa variante usando essa abordagem, conforme análise publicada recentemente. É uma falha grave que transforma um ransomware em um problema reversível pelo menos para vítimas que rodam Linux.
Já a variante Windows é mais robusta. Em vez de depender de funções fracas de aleatoriedade, ela usa o CryptGenRandom() uma API do serviço criptográfico da Microsoft, que gera valores com segurança suficiente para impedir ataques de força bruta viáveis.
Além disso, a versão Windows utiliza ChaCha8, o que demonstra acesso a bibliotecas mais sofisticadas e práticas de desenvolvimento mais avançadas, refletindo maior maturidade técnica por parte dos operadores.
A diferença entre criptografar e comprometer de verdade
Esse contraste entre as variantes torna o Gunra um exemplo claro de como a segurança cibernética não pode ser tratada como uma abordagem única para todos os sistemas. Uma organização que opera majoritariamente com Linux enfrenta um risco real de exposição pós-ataque os dados podem ser recuperados, sim, mas a violação já ocorreu, e o impacto operacional continua.
A variante Windows, por outro lado, apresenta uma ameaça mais alinhada ao que se espera de ransomwares avançados: forte criptografia, pouca margem para recuperação sem pagamento, e foco na durabilidade do dano causado.
Esse cenário assimétrico exige que as equipes de segurança adotem planos de resposta distintos por plataforma. Em ambientes Linux, o foco imediato deve ser o isolamento das máquinas e a tentativa de recuperação por meio das técnicas já publicadas de brute force. Já nos sistemas Windows, a estratégia deve considerar que a recuperação pode não ser possível e exigir atenção máxima na contenção da propagação.
Gunra mostra que ransomware está evoluindo e aprendendo com os erros
O modelo adotado pelo Gunra mostra um nível de engenharia modular que permite aos operadores customizar seus ataques com base na infraestrutura-alvo. A capacidade de adaptar o ataque de forma granular indica um padrão de evolução técnica que já vimos em outros grupos de ransomware sofisticados.
O que diferencia o Gunra, porém, é o contraste gritante entre as duas variantes. Enquanto o binário para Linux se apoia em práticas criptográficas frágeis e vulneráveis, a versão Windows demonstra competência técnica e uso de ferramentas maduras.
Essa lacuna pode ser explicada tanto por prioridades operacionais quanto por limitações técnicas dos desenvolvedores em ambientes Linux. Mas, independentemente da causa, o fato é que ela representa uma oportunidade para defensores ao menos por enquanto.
