Indra usou wipers Meteor, Stardust e Comet em ataques contra Irã e Síria

A campanha combinou tarefas agendadas via Active Directory, scripts em camadas, bloqueio de estáção e destruição configurável de arquivos contra redes ferroviárias iranianas e empresas sírias.

Componente	Wipers Meteor, Stardust e Comet, com execução por scripts Batch ou VBS, arquivos compactados em camadas, configuração criptografada e componentes auxiliares de bloqueio de estáção Windows.
Vetor	Implantação interna em ambiente Windows, incluindo tarefa agendada distribuída por Active Directory via política de grupo e cadeias de scripts que extraíam arquivos, executavam payloads e acionavam o wiper final.
Impacto	Bloqueio de interação local, remoção de máquinas do domínio, corrupção de configuração de inicialização, alteração de senhas locais, substituição de tela e destruição de arquivos definidos na configuração.
Prioridade	Investigar distribuição de tarefas agendadas suspeitas por GPO, artefatos msapp.exe, msconf.conf e mssetup.exe, execução anômala de scripts em diretórios do Windows e sinais de limpeza de cópias de sombra.
Artefatos	A cadeia iraniana usou Microsoft\Windows\Power Efficiency Diagnostics\AnalyzeAll, msapp.exe, msconf.conf, mssetup.exe e logs criptografados com mensagens internas associadas ao nome Meteor.
Alvos	Infraestrutura ferroviária iraniana e sites do Ministério de Estradas e Urbanização do Irã em julho de 2021; amostras anteriores foram associadas a incidentes contra Katerji Group, Arfada Petroleum e Alfadelex na Síria.

Resumo técnico

Indra é o nome usado por um operador que assumiu publicamente ataques destrutivos contra organizações ligadas ao Irã e a entidades sírias. Em julho de 2021, a infraestrutura ferroviária iraniana sofreu uma interrupção em que painéis de informação de estáções exibiram mensagens sobre atrasos e cancelamentos de trens. No dia seguinte, sites do Ministério de Estradas e Urbanização do Irã ficaram indisponíveis após outra disrupção cibernética. A análise dos artefatos ligados a esses eventos mostrou uma cadeia orientada a destruição, não a extorsão: o objetivo técnico era retirar estáções Windows de operação, dificultar recuperação remota e apagar arquivos locais definidos por configuração.

O principal payload observado na operação contra o Irã foi msapp.exe, associado internamente ao nome Meteor. Ele dependia de um arquivo de configuração criptografado, msconf.conf, passado como argumento de linha de comando. Essa dependência é relevante para defesa porque indica que o binário não era apenas um destruidor genérico: a execução podia ser ajustada por vítima, por caminho de arquivo, por componente auxiliar e por parâmetros de persistência ou registro. A presença de campos não usados na configuração iraniana também mostra reaproveitamento de uma base de código mais antiga, com capacidades preservadas ou parcialmente inativas.

A mesma família de ferramentas apareceu em operações anteriores contra empresas sírias entre 2019 e 2020. Nessas amostras, os nomes internos Stardust e Comet aparecem em strings de depuração e em diferenças funcionais. Comet é a variante mais antiga citada no contexto, compilada em setembro de 2019, e incluía uma lógica de interrupção condicionada por comunicação com servidor. Stardust manteve parte do fluxo destrutivo e adicionou telemetria remota de execução. A evolução até Meteor preservou o propósito de impacto operacional, mas alterou a forma de distribuição e alguns componentes de bloqueio e sabotagem de inicialização.

Fluxo técnico

Na operação iraniana, a execução começava com a criação e distribuição de uma tarefa agendada a partir do Active Directory para máquinas do domínio por política de grupo. O nome Microsoft\Windows\Power Efficiency Diagnostics\AnalyzeAll imitava uma nomenclatura legítima ligada a diagnósticos de eficiência de energia do Windows, o que reduzia a chance de triagem visual imediata por administradores. A partir dessa tarefa, uma sequência de arquivos Batch e arquivos compactados conduzia a execução até o payload principal. Essa arquitetura em camadas é típica de operações que já têm algum acesso administrativo ou domínio comprometido, pois depende de mecanismos internos de distribuição para alcançar múltiplos endpoints.

Depois de iniciado, Meteor ocultava a janela de console do executável para reduzir exposição ao usuário local. Em seguida, validava e interpretava a configuração criptografada. Quando a configuração era aceita, o programa registrava eventos em um arquivo de log também criptografado, incluindo mensagens internas que indicavam o início e a continuidade do wiper. Essa telemetria local, embora útil ao operador durante testes ou execução, também cria artefatos forenses importantes: mesmo quando o conteúdo precisa ser decodificado por análise especializada, a existência de logs criptografados próximos ao binário e à configuração ajuda a reconstruir a sequência temporal.

A fase de impedimento de recuperação começava com a retirada da máquina do domínio por chamadas WinAPI ou WMI. Esse passo tem impacto operacional direto, pois reduz a capacidade de administradores empurrarem correções, scripts de contenção ou novas políticas a partir do Active Directory. Em seguida, o malware atacava a configuração de inicialização: em versões anteriores ao Windows 7, substituía o arquivo c:\boot.ini; em Windows 7 e posteriores, apagava entradas BCD. O fluxo também alterava senhas de usuários locais usando um padrão controlado pelo operador, desligava recursos visuais como protetor de tela, substituía papel de parede e tela de bloqueio e encerrava sessões ativas.

A etapa de bloqueio usava mssetup.exe, recuperado da configuração como componente auxiliar. Esse programa impedia interação com teclado e mouse, enquanto o wiper preparava persistência por tarefa agendada para reiniciar seu efeito quando o sistema fosse ligado. A destruição de dados era direcionada por listas de caminhos e regras de prefixos e sufixos. O conteúdo dos arquivos correspondentes era sobrescrito com bytes nulos e depois removido, um comportamento mais alinhado a sabotagem do que a ransomware. Ao final, a cadeia tentava remover cópias de sombra do Windows por utilitários administrativos nativos, o que reduzia opções simples de restauração local sem exigir criptografia ou negociação com vítima.

Superfície afetada

A superfície principal é composta por estáções e servidores Windows que possam receber tarefas agendadas por política de grupo, executar scripts administrativos e acessar caminhos definidos na configuração do wiper. O caso iraniano demonstra dependência de Active Directory e de compartilhamentos internos, incluindo artefatos que continham nomes de computadores e objetos internos da rede ferroviária. Isso sugere que a fase destrutiva ocorreu depois de reconhecimento ou acesso prévio ao ambiente, e não como simples infecção oportunista a partir da internet.

As operações sírias mostram outra forma de encadeamento. Em vez de Batch nas primeiras etapas, Stardust usava scripts VBS, incluindo resolve.vbs, que extraía arquivos RAR protegidos por senha para C:\Program Files\Windows NT\Accessories\ e executava outros scripts em sequência. Durante a execução, os scripts faziam requisições HTTP para registrar etapas de progresso. Campos como paths_to_wipe, process_to_kill, log_server_ip e log_server_port apareciam com mais uso nas configurações sírias do que na configuração iraniana, indicando que as versões anteriores expunham mais capacidades operacionais por configuração.

Comet, a variante mais antiga, tinha diferenças importantes. Ela continha uma lógica de kill switch baseada em parâmetros de servidor, porta, caminho de URL e número de requisições. Caso a comunicação não retornasse status HTTP esperado, a execução era abortada. Comet também podia criar um usuário administrador por APIs locais, usar o nome INDRA como usuário, ajustar telas de primeiro logon e configurar auto logon com base em caminho definido na configuração. Stardust e Comet ainda usavam o software Lock My PC 4 para restringir uso da estáção, removiam um valor de registro relacionado à senha de bloqueio e apagavam o desinstalador para dificultar recuperação manual.

Os alvos citados incluem infraestrutura ferroviária no Irã, sites governamentais iranianos e empresas sírias como Katerji Group, Arfada Petroleum e Alfadelex. A presença de nomes de empresas, usuários e administradores de domínio dentro de scripts e configurações reforça que a destruição foi preparada com conhecimento específico dos ambientes. A atribuição a Indra é sustentada por assinatura visual, strings internas em amostras e presença pública do grupo em redes sociais, mas vínculos externos a hacktivismo ou crime organizado permanecem condicionados ao que foi indicado por fontes iranianas citadas no material técnico.

• Ambientes Windows ligados a Active Directory e política de grupo ficam no centro da distribuição observada.
• Estáções com execução de scripts VBS ou Batch em diretórios do Windows podem preservar artefatos da cadeia.
• Caminhos definidos em configuração determinam quais arquivos e diretórios são destruídos, portanto o impacto varia por vítima.
• A presença de nomes internos de domínio, usuários e compartilhamentos em scripts indica reconhecimento prévio ou acesso operacional antes da etapa final.

Hunting e telemetria

A caça deve começar por alterações em tarefas agendadas distribuídas por GPO, principalmente tarefas que imitem nomes de componentes legítimos do Windows e apareçam de forma simultânea em muitos hosts. O identificador Microsoft\Windows\Power Efficiency Diagnostics\AnalyzeAll é um pivô concreto para o caso iraniano. A análise deve correlacionar criação da tarefa, origem da política, conta administrativa usada, escopo de máquinas afetadas e comandos ou scripts chamados pela tarefa. Em ambientes grandes, esse tipo de evento pode se perder em ruído de administração legítima, por isso a combinação de nome incomum, execução em massa e proximidade com scripts recém-gravados é mais forte do que qualquer sinal isolado.

No endpoint, procure por execução e presença de msapp.exe, msconf.conf, mssetup.exe, arquivos Batch em cadeia, arquivos compactados extraídos em sequência e logs criptografados gerados no mesmo fluxo. Para as variantes sírias, a presença de resolve.vbs, extração para C:\Program Files\Windows NT\Accessories\ e uso de VBS para abrir arquivos RAR protegidos por senha são sinais relevantes. Também é importante revisar eventos de WMI e chamadas administrativas que removam máquinas do domínio, mudanças abruptas em senhas de contas locais, encerramento de sessões, alteração de papel de parede e alteração de tela de bloqueio em massa.

Em rede, as variantes Stardust faziam requisições HTTP de acompanhamento de execução e podiam enviar log codificado em Base64 por HTTP POST para um recurso chamado data.html. Como o contexto não fornece endereços de IP concretos, a defesa deve buscar padrões comportamentais: hosts internos fazendo requisições HTTP incomuns durante a fase de script, sequência temporal entre extração local e tráfego externo, e envio de conteúdo codificado após etapas de bloqueio ou destruição. Em proxy, EDR ou NDR, esses sinais devem ser analisados junto com criação de processos de script e alterações em arquivos de inicialização.

Eventos de sabotagem de recuperação são especialmente importantes para detecção precoce. Tentativas de remover cópias de sombra, exclusão de entradas BCD, modificação de boot.ini em sistemas legados, criação de persistência por tarefa agendada e sobrescrita seguida de exclusão de arquivos devem gerar alertas de alta prioridade quando ocorrerem fora de janelas de manutenção. A sequência completa é mais importante que o binário isolado: retirar domínio, bloquear usuário, alterar senha, impedir inicialização normal e remover cópias de restauração compõem uma cadeia destrutiva clara.

• Criação ou alteração de tarefa agendada Microsoft\Windows\Power Efficiency Diagnostics\AnalyzeAll em múltiplos hosts.
• Execução de msapp.exe com caminho para msconf.conf como parâmetro e presença de log criptografado associado.
• Remoção de máquina do domínio por WMI ou WinAPI pouco antes de falhas em massa de acesso administrativo.
• Alterações em BCD, boot.ini, senhas locais, papel de parede, tela de bloqueio e encerramento de sessões em sequência curta.
• Execução de VBS a partir de C:\Program Files\Windows NT\Accessories\ com extração de arquivos RAR protegidos por senha.
• Tráfego HTTP de acompanhamento ou envio de log codificado para recurso data.html, quando combinado com execução local suspeita.

Mitigação

A resposta deve priorizar contenção de distribuição antes de limpeza de endpoints. Em um cenário semelhante, a equipe deve isolar controladores de domínio e estáções administrativas potencialmente usadas para empurrar GPOs, revisar políticas recém-criadas ou alteradas e suspender tarefas agendadas suspeitas no escopo do domínio. Como Meteor remove máquinas do domínio e altera senhas locais, depender apenas de administração remota tradicional pode falhar. A organização precisa preparar canais de resposta fora do domínio afetado, como console de virtualização, EDR com canal independente, mídia de recuperação controlada e contas de emergência protegidas por processo formal.

Nos hosts preservados, a contenção deve impedir execução de scripts não autorizados, bloquear binários e componentes conhecidos por hash apenas como medida auxiliar e coletar artefatos antes de reconstrução. A coleta deve incluir diretórios usados pela cadeia, tarefas agendadas, configurações criptografadas, logs, eventos de criação de processos, histórico de GPO, alterações de registro, eventos de WMI e telemetria de proxy. Em hosts já destruídos, restauração deve partir de imagens confiáveis e backups offline validados, porque a sobrescrita de conteúdo com bytes nulos e a exclusão de cópias de sombra tornam recuperação local incompleta ou inviável.

A mitigação estrutural envolve reduzir o poder de uma única conta ou política de grupo para executar scripts em massa sem validação. GPOs que criam tarefas agendadas devem passar por controle de mudança, revisão por pares, registro centralizado e alerta quando alteradas fora de janela aprovada. Estáções administrativas devem usar segregação, acesso privilegiado just-in-time, proteção contra roubo de credenciais e bloqueio de navegação ou execução de ferramentas não administrativas. Em paralelo, políticas de App Control devem limitar execução de Batch, VBS e binários não assinados em caminhos sensíveis, com exceções documentadas e monitoradas.

Para ambientes com risco de wiper, backup precisa ser tratado como controle operacional, não apenas como rotina de TI. Cópias offline ou imutáveis, testes periódicos de restauração, inventário de dependências críticas e planos de reconstrução de domínio reduzem o impacto de destruição coordenada. Também é necessário simular cenários em que controladores de domínio, compartilhamentos e estáções administrativas ficam indisponíveis, porque a cadeia Meteor foi desenhada para dificultar justamente a resposta centralizada após a infecção.

• Revisar imediatamente GPOs e tarefas agendadas criadas ou modificadas perto do incidente, com foco em distribuição para muitos hosts.
• Isolar contas administrativas usadas para alterar políticas de grupo e rotacionar credenciais associadas a administração de domínio.
• Bloquear execução não autorizada de VBS, Batch e binários desconhecidos em diretórios do Windows e caminhos de usuário sensíveis.
• Coletar msapp.exe, msconf.conf, mssetup.exe, scripts, arquivos compactados e logs criptografados antes de reimagem, quando a preservação for possível.
• Restaurar sistemas afetados a partir de backups offline ou imutáveis e validar integridade de BCD, contas locais, associação ao domínio e políticas aplicadas.
• Criar alertas para remoção de cópias de sombra, alterações de inicialização e desligamento de interação de usuário quando combinados com execução de scripts administrativos.