`Lotus Wiper` mira energia e utilidades na Venezuela com destruição de sistemas Windows

O wiper usa scripts em lote para preparar hosts Windows, enfraquecer mecanismos locais de recuperação e acionar apagamento destrutivo de volumes sem indício de extorsão financeira.

Componente	Lotus Wiper, scripts em lote do Windows, compartilhamento NETLOGON, serviço UI0Detect e utilitários nativos como diskpart, robocopy e fsutil.
Vetor	Execução de uma cadeia em múltiplos estágios em ambiente Windows possivelmente associado a domínio Active Directory, com verificação de arquivo remoto em NETLOGON e diretórios locais como C:\lotus ou %SystemDrive%\lotus.
Impacto	Remoção de mecanismos de recuperação, sobrescrita de setores físicos com zeros, limpeza de diário USN, preenchimento de espaço livre e exclusão sistemática de arquivos em volumes montados, deixando sistemas inoperantes.
Prioridade	Monitorar alterações em NETLOGON, uso destrutivo de utilitários nativos do Windows, desativação de interfaces de rede, logoff forçado de sessões e sinais prévios de comprometimento de domínio.
Artefatos	Amostra compilada no fim de setembro de 2025 e enviada a uma plataforma pública em meados de dezembro de 2025 a partir de uma máquina na Venezuela.
Escopo	Campanha direcionada contra o setor de energia e utilidades na Venezuela no fim de 2025 e no início de 2026, sem instruções de pagamento ou extorsão embutidas no artefato.

Resumo técnico

Lotus Wiper é um malware destrutivo previamente não documentado usado contra sistemas do setor de energia e utilidades na Venezuela. A cadeia observada não se comporta como ransomware: não há instruções de pagamento, rotina de negociação ou artefato voltado a extorsão. O objetivo técnico sustentado pelo contexto é indisponibilizar máquinas Windows por meio de preparação do ambiente, enfraquecimento de defesas locais e execução de um payload final capaz de apagar caminhos de recuperação, sobrescrever conteúdo de unidades físicas e remover arquivos em volumes afetados. Esse conjunto de ações aponta para sabotagem operacional, não para monetização direta.

A operação combina scripts em lote com ferramentas nativas do Windows para ampliar o dano antes da execução final do wiper. O primeiro estágio coordena verificações de ambiente, tenta interagir com recursos de domínio e aciona um segundo script. O segundo estágio reduz a capacidade de uso e recuperação do host ao enumerar contas locais, desabilitar logins em cache, encerrar sessões ativas, desativar interfaces de rede e usar recursos administrativos do sistema para limpar unidades, sobrescrever conteúdo de diretórios e ocupar espaço livre. Em seguida, o Lotus Wiper remove pontos de restauração, zera setores físicos, limpa registros do diário USN e apaga arquivos dos volumes montados.

A linha do tempo também reforça o caráter direcionado. A amostra foi compilada no fim de setembro de 2025 e carregada em uma plataforma pública em meados de dezembro de 2025 a partir de uma máquina localizada na Venezuela. A atividade descrita ocorreu no fim de 2025 e no início de 2026, em período no qual havia relatos públicos de malware contra o mesmo setor e a mesma região. O contexto não confirma relação causal com eventos externos mencionados na mesma janela temporal, portanto essa associação deve ser tratada apenas como coincidência temporal não comprovada. Para defesa, o ponto central é que a cadeia parece ter sido adaptada a um ambiente Windows específico, inclusive com referência a UI0Detect, recurso ausente em versões modernas do Windows a partir da remoção ocorrida no Windows 10 versão 1803.

Fluxo técnico

A cadeia começa com um script em lote que inicia uma sequência de múltiplos estágios. Uma das primeiras ações é tentar parar o serviço UI0Detect, associado à detecção de serviços interativos em versões antigas do Windows. Esse detalhe importa porque o recurso foi removido de versões modernas, o que sugere que a lógica foi escrita considerando hosts legados ou uma base instalada com sistemas anteriores ao Windows 10 versão 1803. A presença desse alvo não prova, por si só, que todos os sistemas afetados eram antigos, mas indica conhecimento operacional suficiente para incluir uma etapa compatível com ambientes Windows específicos.

O script também verifica a presença de um compartilhamento NETLOGON e tenta acessar um arquivo XML remoto. Em seguida, procura um arquivo correspondente em diretórios locais definidos previamente, como C:\lotus ou %SystemDrive%\lotus. Mesmo quando o arquivo local não está presente, a sequência continua para um segundo script, desde que a verificação remota seja satisfeita. Quando o NETLOGON não está imediatamente acessível, a lógica introduz atraso aleatório de até 20 minutos antes de repetir a checagem, comportamento que pode reduzir simultaneidade visível e acomodar instabilidade de rede ou disponibilidade variável de controladores de domínio.

O segundo script prepara o host para a fase destrutiva. Ele enumera contas locais, altera a disponibilidade de autenticação em cache, força encerramento de sessões, desativa interfaces de rede e usa utilitários administrativos legítimos para causar dano. O uso de diskpart é descrito como limpeza completa de unidades lógicas identificadas. O uso de robocopy aparece associado à sobrescrita ou remoção recursiva de conteúdo por espelhamento de diretórios. Já fsutil é usado para criar um arquivo capaz de consumir o espaço livre disponível, reduzindo a chance de recuperação e prejudicando a operação normal do sistema. Essas ações não dependem de exploração de uma vulnerabilidade específica no material analisado; elas dependem de execução com permissões suficientes no ambiente comprometido.

Depois da preparação, o payload Lotus Wiper executa as rotinas finais. Ele remove pontos de restauração, sobrescreve setores físicos escrevendo zeros, limpa os números de sequência de atualização do diário USN dos volumes e apaga arquivos em cada volume montado. A limpeza do diário USN afeta uma fonte importante de rastreamento de alterações em volumes NTFS, dificultando reconstrução de atividade após o incidente. A sobrescrita de setores e o preenchimento de espaço livre reduzem oportunidades de recuperação forense tradicional, especialmente quando backups locais, snapshots e pontos de restauração foram removidos antes da limpeza principal.

Superfície afetada

A superfície descrita é composta por hosts Windows em uma rede corporativa com sinais de integração a Active Directory. O uso de NETLOGON indica interesse em recursos distribuídos por domínio, e a checagem de arquivos remotos sugere coordenação centralizada ou validação de pertencimento ao domínio antes da fase destrutiva. A cadeia não descreve exploração inicial, phishing, abuso de credenciais ou movimentação lateral de forma detalhada; por isso, a análise defensiva deve separar o que está confirmado do que precisa ser investigado. O fato confirmado é a execução de scripts e payload destrutivo em sistemas Windows; o vetor inicial de comprometimento permanece não especificado.

A presença de lógica para UI0Detect amplia a preocupação com ambientes que mantêm versões antigas do Windows por dependência operacional, compatibilidade industrial ou ciclos longos de atualização. Em energia e utilidades, sistemas de suporte, estáções de engenharia, servidores auxiliares e hosts administrativos podem permanecer conectados a domínios corporativos mesmo quando atendem processos críticos. O contexto não identifica sistemas industriais específicos, controladores, protocolos OT ou fornecedores de automação, então não é correto afirmar impacto direto em ICS. O risco confirmado está na indisponibilidade de sistemas Windows alcançados pela cadeia destrutiva.

Como o malware não inclui extorsão, a preparação de resposta deve priorizar continuidade operacional e recuperação confiável, não negociação. Backups offline, imagens douradas verificadas, inventário de dependências de domínio e restauração de serviços essenciais ganham importância maior do que rotinas tradicionais focadas apenas em criptografia de arquivos. O dano descrito atinge recuperação local, espaço livre, registros de alteração e conteúdo de volumes, de modo que restauração a partir do próprio host afetado tende a ser frágil.

• Hosts Windows com acesso a recursos de domínio e ao compartilhamento NETLOGON.
• Ambientes que ainda mantêm versões anteriores ao Windows 10 versão 1803 ou compatibilidade com componentes legados como UI0Detect.
• Diretórios locais usados pela cadeia, incluindo C:\lotus e %SystemDrive%\lotus, quando presentes nos endpoints analisados.
• Volumes montados e unidades lógicas identificadas durante a fase de limpeza destrutiva.

Hunting e telemetria

A busca deve começar pela sequência de preparação, porque ela oferece sinais anteriores ao apagamento final. Eventos de execução de scripts em lote, consultas a NETLOGON, tentativas de acesso a arquivo XML remoto e criação ou uso de diretórios com o nome lotus são pontos de pivô relevantes. Em controladores de domínio, mudanças inesperadas em NETLOGON, criação de arquivos incomuns e acessos simultâneos por múltiplos hosts devem ser correlacionados com logs de autenticação, inventário de máquinas e horário de início de degradação operacional.

No endpoint, o foco deve ser comportamento, não apenas assinatura. O uso de diskpart, robocopy e fsutil por contas administrativas ou processos de script precisa ser analisado no contexto de janela de manutenção, origem do processo pai, host acionador e volume de operações. Essas ferramentas são legítimas e comuns em administração, mas a combinação de limpeza de unidades, espelhamento recursivo destrutivo, preenchimento de disco, logoff de usuários e desativação de interfaces de rede forma uma cadeia anômala. A remoção de pontos de restauração e a limpeza do diário USN também são sinais de tentativa de prejudicar recuperação e investigação.

Como a rotina pode introduzir atraso aleatório antes de repetir acesso remoto, janelas de hunting não devem se limitar ao minuto exato em que a indisponibilidade foi percebida. É importante analisar períodos anteriores, especialmente quando há evidência de upload ou compilação antiga do artefato. A amostra compilada meses antes do uso observado sugere que preparação, teste ou posicionamento podem ter antecedido a fase destrutiva. O contexto também recomenda atenção a sinais de dumping de credenciais ou escalonamento de privilégio, mas não fornece técnica específica; por isso, a investigação deve procurar anomalias de identidade sem atribuir uma técnica única não confirmada.

• Execução de arquivos .bat com processos filhos relacionados a utilitários administrativos do Windows.
• Acessos anormais ao compartilhamento NETLOGON e tentativa de leitura de arquivo XML remoto por múltiplos hosts.
• Tentativas de parada ou interação com o serviço UI0Detect em sistemas onde esse serviço ainda existe.
• Uso de diskpart, robocopy e fsutil em sequência próxima, especialmente quando iniciado por script.
• Eventos de logoff em massa, desativação de interfaces de rede e falhas súbitas de acesso a volumes.
• Remoção de pontos de restauração, alterações no diário USN e rápida ocupação de espaço livre em disco.

Mitigação

A resposta deve isolar rapidamente os hosts com sinais de preparação destrutiva, preservando o máximo possível de evidência antes que a sobrescrita avance. Como a cadeia pode desativar interfaces de rede, o isolamento precisa considerar tanto controles de EDR quanto segmentação de rede e ações em switches ou controladores de acesso. Em paralelo, controladores de domínio e compartilhamentos NETLOGON devem ser revisados para identificar arquivos, scripts ou alterações não autorizadas. Se a organização encontrar diretórios ou arquivos associados à cadeia, a coleta deve registrar caminho, timestamps, usuário, hash interno e processo de origem, sem executar artefatos para validação manual.

A recuperação deve partir de backups offline ou repositórios que não dependam dos volumes atingidos. Pontos de restauração locais não devem ser considerados suficientes, porque o próprio wiper tenta removê-los. Antes de recolocar sistemas em produção, é necessário validar a integridade da imagem restaurada, revisar contas administrativas, sessões persistentes, tarefas agendadas, políticas de domínio e artefatos em compartilhamentos usados para distribuição. A investigação deve determinar como os scripts chegaram aos hosts e quais credenciais ou permissões permitiram execução com capacidade de limpar unidades e alterar estado de rede.

A redução de risco envolve endurecimento de permissões administrativas, controle de execução de scripts, monitoramento de ferramentas nativas usadas de forma destrutiva e revisão de sistemas Windows legados. Ambientes que ainda dependem de versões antigas devem ter compensações explícitas: segmentação, restrição de acesso administrativo, bloqueio de execução não autorizada por política, logging centralizado e testes de restauração. Para setores de energia e utilidades, a prioridade operacional é impedir que uma cadeia de domínio corporativo alcance hosts essenciais sem barreiras, mesmo quando o vetor inicial ainda não é conhecido.

• Revisar NETLOGON e remover artefatos não autorizados após coleta forense adequada.
• Restringir execução de scripts em lote a caminhos, assinaturas e grupos administrativos aprovados.
• Criar detecções comportamentais para a combinação de limpeza de volumes, preenchimento de disco, remoção de restauração e logoff forçado.
• Validar backups offline e testar restauração completa de hosts críticos antes de depender deles em crise.
• Revisar contas privilegiadas, permissões de domínio e sinais de dumping de credenciais ou escalonamento de privilégio.
• Mapear sistemas Windows legados e aplicar segmentação e controles compensatórios quando atualização imediata não for viável.