Azov usa infecção polimórfica de executáveis e atua como wiper no Windows

A amostra analisada destrói arquivos, trojaniza binários de 64 bits e usa ofuscação em assembly para dificultar engenharia reversa e detecção estática.

Componente	Azov, malware para Windows distribuído inicialmente como carga do botnet SmokeLoader e observado em executáveis portáteis de 64 bits.
Vetor	A infecção foi associada a ambientes que receberam SmokeLoader, comum em falsos softwares pirateados e sites de cracks; após execução, o malware modifica executáveis de 64 bits no sistema.
Impacto	Destruição intermitente de arquivos, alteração de extensão para .azov, persistência por binário trojanizado e propagação local por executáveis modificados.
Prioridade	Isolar máquinas afetadas, bloquear execução de binários trojanizados, preservar amostras para análise forense e restaurar dados somente a partir de backups verificados.
Artefatos	Mutex Local\\azov, mutex por unidade Local\\Kasimir_%c, arquivo persistente rdpclient.exe, chave de execução automática SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Run e extensão .azov.
Amostra	A amostra principal citada é um executável portátil de 64 bits com SHA-256 650f0d694c0928d88aeeed649cf629fc8a7bec604563bca716b1688227e0cc7e.

Resumo técnico

Azov foi tratado inicialmente como ransomware, mas a análise técnica mostra um comportamento mais próximo de wiper: a rotina principal destrói conteúdo de arquivos e não apresenta, pelo material analisado, um fluxo confiável de recuperação. A nota exibida às vítimas não deve ser interpretada como prova de extorsão funcional. O ponto central é que o malware combina destruição de dados com infecção polimórfica de executáveis Windows de 64 bits, criando múltiplos artefatos modificados no ambiente comprometido e aumentando a dificuldade de resposta.

A ameaça apareceu como carga associada ao SmokeLoader, um botnet frequentemente encontrado em falsos instaladores, softwares pirateados e páginas de cracks. Depois de executado, Azov desempacota shellcode em memória, inicia rotinas separadas para limpeza destrutiva de arquivos e trojanização de executáveis, cria mecanismos de persistência e usa técnicas de ofuscação que dificultam análise estática. Em novembro de 2022, a grande quantidade de amostras relacionadas ao Azov submetidas ao VirusTotal já passava de 17 mil, incluindo arquivos originais e binários infectados.

Fluxo técnico

A amostra analisada é um executável portátil de 64 bits montado com FASM, com uma única seção .code marcada como leitura e execução, sem tabela normal de importações. A seção concentra três blocos visíveis pela entropia: shellcode cifrado, rotina de desempacotamento e strings usadas na construção da nota. O desempacotamento aloca memória, decifra o conteúdo e transfere execução para o próximo estágio. A cifra descrita usa uma combinação simples de xor e rotação, com chave constante, mas o código ao redor foi escrito para parecer mais complexo e consumir tempo de engenharia reversa.

Após o desempacotamento, a execução se divide em duas responsabilidades principais. A primeira é a rotina destrutiva, que cria o mutex Local\\azov para evitar concorrência entre instâncias, prepara persistência e aguarda um horário de disparo. Na amostra mencionada no material técnico, esse gatilho estava configurado para 27 de outubro de 2022 às 10:14:30 UTC. Quando a condição temporal é satisfeita, o malware percorre diretórios da máquina, ignora caminhos e extensões codificados internamente e sobrescreve blocos alternados de 666 bytes com conteúdo derivado de memória de pilha não inicializada. O processo continua até um limite de 4 GB por arquivo; depois disso, o restante do arquivo permanece intocado, mas o conteúdo já fica corrompido o suficiente para impedir uso normal em muitos formatos.

A segunda responsabilidade é a trojanização polimórfica de executáveis .exe de 64 bits que passam por verificações internas. Antes de modificar um arquivo, o malware cria um mutex por unidade no padrão Local\\Kasimir_%c, onde o caractere final representa a letra do volume processado. Em seguida, identifica a seção de código original, normalmente .text, altera posições aleatórias, injeta um bloco de shellcode, muda constantes internas e recifra o shellcode com o mesmo algoritmo usado no carregamento inicial. Ao final, o binário modificado recebe estruturas codificadas anexadas, incluindo recursos usados pelo próprio malware, como dados relacionados à nota. Esse desenho faz com que cada executável contaminado possa diferir em bytes, reduzindo a efetividade de assinaturas estáticas ingênuas.

A persistência é criada por meio da trojanização de binários do sistema Windows, com destaque para msiexec.exe ou perfmon.exe, que são salvos como rdpclient.exe. O caminho desse arquivo é então registrado em SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Run, permitindo execução automática em inicializações posteriores do usuário ou do sistema, conforme o contexto da chave. A ameaça também incorpora técnicas anti-análise: cópia de trechos já decifrados para novas regiões de memória, uso de constantes opacas, saltos condicionais que se comportam como desvios incondicionais, instruções sintaticamente confusas, bytes sem função útil e uma estrutura dinâmica semelhante a uma tabela de importações, usada para resolver chamadas da API do Windows sem imports convencionais.

Superfície afetada

A superfície imediata é composta por estáções Windows que executaram a carga Azov, especialmente quando a infecção veio depois de uma cadeia de distribuição do SmokeLoader. O risco não se limita aos arquivos diretamente destruídos: executáveis legítimos de 64 bits no host podem ser modificados para carregar código do malware, confundindo inventário, reputação por hash e análises que dependem apenas da origem aparente do arquivo. Ambientes com compartilhamentos locais, diretórios de usuários com muitos executáveis e controles fracos contra software pirateado ficam mais expostos ao acúmulo de binários contaminados.

O comportamento de wiper torna a resposta mais sensível a tempo. A lógica de disparo baseada em horário permite que a infecção exista antes da destruição visível, e a persistência por rdpclient.exe aumenta a chance de reexecução após reinicialização. Como a limpeza sobrescreve blocos alternados e renomeia arquivos com .azov, a presença de arquivos parcialmente legíveis não deve ser confundida com integridade. A restauração a partir de cópias locais no mesmo host também é arriscada se esses dados estiverem no escopo percorrido pelo malware.

• Hosts Windows de 64 bits com execução prévia de Azov ou de carga entregue por SmokeLoader.
• Executáveis .exe de 64 bits modificados localmente, inclusive binários que parecem legítimos pelo nome ou diretório.
• Arquivos renomeados com extensão .azov após corrupção parcial por blocos alternados.
• Persistência em chave Run apontando para rdpclient.exe criado a partir de binário trojanizado.

Hunting e telemetria

A investigação deve combinar endpoint, registro do Windows, inventário de arquivos e análise de memória. No endpoint, são relevantes eventos de criação ou alteração de grande volume de executáveis .exe, especialmente quando a gravação parte de um processo recém-executado sem histórico corporativo. Também é importante procurar arquivos de usuário ou aplicação que receberam .azov, além de padrões de corrupção parcial que alternam blocos sobrescritos e blocos intactos. Esse padrão não comprova sozinho a família, mas ajuda a diferenciar destruição intermitente de criptografia tradicional de ransomware.

Na telemetria de persistência, a chave SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Run deve ser revisada para entradas que apontem para rdpclient.exe fora de um caminho esperado ou recém-criado após a infecção. A criação dos mutexes Local\\azov e Local\\Kasimir_%c é um sinal forte quando disponível em EDR ou captura de comportamento. Em análise estática, a ausência de imports, a seção única .code, a presença de shellcode cifrado, estruturas anexadas ao fim de executáveis e variações polimórficas entre amostras relacionadas devem orientar regras comportamentais em vez de dependência exclusiva de hash.

Como o vetor citado envolve SmokeLoader em falsos softwares pirateados e cracks, a caça também precisa voltar para o início da cadeia. Procure execução recente de instaladores não autorizados, artefatos de download em navegadores, diretórios temporários com nomes aleatórios, processos que geraram múltiplas gravações em disco e mudanças simultâneas em arquivos de dados e executáveis. Em redes corporativas, a resposta deve correlacionar usuários que baixaram software não homologado com hosts onde apareceram arquivos .azov ou executáveis alterados no mesmo intervalo.

• Criação do mutex Local\\azov ou mutexes por volume no padrão Local\\Kasimir_%c.
• Entrada de execução automática em SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Run apontando para rdpclient.exe suspeito.
• Aumento anormal de gravações em executáveis .exe de 64 bits por um único processo.
• Arquivos de dados corrompidos em blocos alternados e renomeados com extensão .azov.
• Executáveis sem imports usuais, com seção .code única e dados codificados anexados ao fim do arquivo.

Mitigação

A prioridade é interromper execução e propagação local antes de restaurar dados. Máquinas com indícios de Azov devem ser isoladas da rede, preservando disco e memória quando a política forense permitir. Como executáveis legítimos podem ter sido trojanizados, não é suficiente remover apenas o arquivo inicialmente identificado. A varredura deve abranger binários .exe de 64 bits criados ou modificados no período da infecção, entradas de inicialização automática, artefatos do SmokeLoader e arquivos com extensão .azov. Sistemas afetados devem ser reconstruídos a partir de mídia confiável quando houver dúvida sobre a integridade de binários locais.

A recuperação de dados deve partir de backups offline ou imutáveis validados antes da restauração. Backups montados no mesmo host durante a execução do wiper podem ter sido alcançados pela rotina de varredura e não devem ser assumidos como íntegros. Em paralelo, controles preventivos devem bloquear execução de cracks, falsos instaladores e software não autorizado, aplicar reputação e controle de aplicação para executáveis recém-baixados, monitorar alterações de chave Run e reduzir permissões de escrita em diretórios compartilhados. Para detecção contínua, regras devem priorizar comportamento: criação de persistência suspeita, alteração em massa de executáveis, execução de binários sem cadeia de confiança e surgimento de arquivos .azov.

A análise de impacto precisa separar três conjuntos: arquivos destruídos, executáveis contaminados e artefatos de persistência. Arquivos destruídos indicam perda operacional; executáveis contaminados indicam risco de reexecução; persistência indica possibilidade de retorno após reinicialização. Cada conjunto exige validação própria. Encerrar processos e apagar uma nota não encerra o incidente se binários trojanizados permanecerem no disco. Depois da contenção, a organização deve revisar a origem da carga, reforçar bloqueios contra software pirateado, auditar usuários e estáções envolvidos e confirmar que novas amostras não continuam aparecendo por sincronização de arquivos, compartilhamentos ou restauração inadequada.

• Isolar hosts afetados e preservar artefatos antes de limpeza quando houver necessidade de investigação.
• Remover persistência em Run somente após coletar evidências e identificar o rdpclient.exe associado.
• Inventariar executáveis .exe de 64 bits modificados no período do incidente e substituir por cópias confiáveis.
• Restaurar dados apenas de backups validados e não expostos ao host comprometido.
• Bloquear execução de software não autorizado, cracks e instaladores sem origem confiável em estáções corporativas.