Invasores alteraram repetidamente os arquivos que o AOMEI Backupper baixa dos servidores de atualização do próprio fabricante, em janelas de cinco a dez minutos por vez, entre maio e julho de 2026. Assim, qualquer cópia do programa de backup para Windows que buscasse atualização durante uma dessas janelas baixava e executava um backdoor (porta dos fundos, um acesso secreto ao sistema).
Google Threat Intelligence Group, Mandiant e o Laboratório de Análise de Ameaças da ManageEngine, que revelaram a campanha nesta semana, afirmam que a AOMEI informou ter corrigido seus servidores. Essa correção, porém, não remove o backdoor das máquinas que já haviam sido atingidas.
O AOMEI Backupper é um software de backup e clonagem de discos para Windows, desenvolvido pela AOMEI Technology, empresa registrada em Hong Kong. Assim como o AnyViewer, ferramenta de acesso remoto da mesma companhia, ele executa serviços em segundo plano que consultam regularmente os servidores da AOMEI por HTTPS (protocolo de comunicação seguro na internet) em busca de atualizações de software e de pop-ups promocionais.
Dois arquivos controlam essa verificação. O primeiro, down_html.ini, indica o pacote de atualização a ser baixado e a soma de verificação (checksum) que o programa usa para validá-lo. O segundo, Notifycfg.ini, define o que o serviço de pop-up exibe e o que ele executa.
O programa não verifica criptograficamente nenhum dos dois arquivos. Além disso, a soma de verificação que deveria comprovar que o download é genuíno está dentro do mesmo arquivo não assinado que indica o download.
Nenhuma falha de software foi explorada. Não houve vulnerabilidade, e nenhuma ação do usuário foi necessária além de ter o programa instalado e em execução, segundo o laboratório da ManageEngine. O invasor precisou apenas alterar dois arquivos de texto no servidor, por alguns minutos.
Uma cópia do Backupper que consultou o servidor durante uma dessas janelas baixou o pacote do invasor para sua própria pasta, e o arquivo de notificação then o fez executar. O pacote rodou com os privilégios do processo da AOMEI que o iniciou.
Nas máquinas analisadas pelo laboratório, isso bastou para instalar softwares em todo o sistema, embora a ManageEngine tenha afirmado que a elevação de privilégios dependia da forma como o serviço da AOMEI estava sendo executado.
Três janelas para Windows, onze países
O GTIG e a Mandiant confirmaram três janelas de adulteração e afirmaram que outras provavelmente ocorreram sem que fossem detectadas:
- 28 de maio de 2026: janela de 10 minutos, das 05h40 às 05h50 (UTC)
- 16 de julho de 2026: janela de 6 minutos, das 08h33 às 08h39 (UTC)
- 20 de julho de 2026: janela de 5 minutos, das 10h35 às 10h40 (UTC)
Apenas as cópias que buscaram atualização durante uma janela foram afetadas. Uma cópia que consultou o servidor antes ou depois recebeu arquivos limpos e genuínos, o que torna o ataque difícil de detectar. O GTIG descreveu a escolha dos alvos como oportunista, atingindo qualquer sistema que consultasse o servidor naqueles minutos.
A partir da própria telemetria, o GTIG identificou organizações afetadas nos setores de serviços de TI, telecomunicações e ensino superior em 11 países: Austrália, Brasil, Índia, Paquistão, Portugal, Singapura, África do Sul, Espanha, Suíça, Turquia e Estados Unidos. O grupo não divulgou um total e afirmou que o número real provavelmente é maior.
O GTIG citou o AnyViewer, ferramenta de acesso remoto da AOMEI, como usando o mesmo fluxo de atualização, mas as detecções descritas pelo grupo envolvem o Backupper. Nenhum dos dois relatórios informa quais versões do Backupper são afetadas, e o laboratório analisou a versão 8.3.0.
O GTIG acompanha o grupo por trás da campanha como UNC7017 e não indica país nem ator conhecido. O grupo afirmou que esta é a primeira comprometimento da cadeia de suprimentos que encontrou, construído sobre Windows, com uma janela tão curta, “evadindo efetivamente a triagem tradicional pontual e a varredura automatizada de arquivos”.
O que foi instalado na máquina
Em uma máquina que baixou o pacote, um downloader que o GTIG chama de CROSSROAD descompactou um conjunto de arquivos em uma pasta local do Radmin, criou uma tarefa agendada para ser executada a cada três horas e, em seguida, apagou a si mesmo do disco.
O conjunto incluía uma cópia genuína e assinada do Radmin, ferramenta comercial de administração remota. O laboratório da ManageEngine constatou que ela foi preparada, mas nunca ativada, sem listener, sem configuração e sem nova conta. O controle remoto veio de um implante separado, que se conectava ao invasor.
A tarefa agendada executa o programa Radmin assinado, que carrega uma DLL (biblioteca de vínculo dinâmico) criada pelo invasor e colocada ao lado dele. Essa DLL, por sua vez, carrega o implante SHINYROAD. O implante oferece um shell remoto e pode baixar e executar novos códigos por comando. Ele se comunica com um único endereço fixo, sem alternativa de backup, de modo que bloquear esse endereço corta o controle do invasor.
O CROSSROAD só é executado em alguns lugares. Ele verifica a localização da máquina e para se estiver na China. A ManageEngine acrescentou que ele também para se encontrar determinados agentes de segurança no sistema. Em máquinas que passaram por essas verificações, o GTIG observou depois uma segunda ferramenta enviada sobre o SHINYROAD: o framework de C2 (comando e controle) de código aberto Adaptix, disfarçado de software Nitro PDF.
Uma mudança de 20 de julho que não precisava de código para funcionar
A janela de 20 de julho incluiu um segundo artifício que não exigia a execução de nenhum programa. O GTIG descobriu que o arquivo de notificação fora alterado para abrir um pop-up invisível de um pixel, apontando para um arquivo no servidor do invasor via WebDAV, um meio de acessar um arquivo remoto como se estivesse no disco local.
A renderização desse pop-up pode levar o Windows a enviar ao endereço do invasor a resposta de autenticação NetNTLMv2 do usuário logado, um token que pode ser quebrado offline ou reutilizado, sem que o usuário veja nada. Como nenhum programa precisava ser executado, uma máquina com o backdoor bloqueado ainda poderia ter vazado esse token.
O que foi informado à AOMEI, e quando
O laboratório da ManageEngine afirmou que seu software de endpoint detectou a atividade pela primeira vez em 28 de maio, quando registrou o AOMEI Backupper instalando o Radmin em dois clientes sem relação entre si, em países diferentes. Um cliente levantou o caso em 7 de junho, e o laboratório notificou a AOMEI no mesmo dia. A primeira explicação da empresa foi que o conteúdo havia sido interceptado e alterado em trânsito.
O laboratório afirmou que as evidências não sustentavam essa explicação. As duas máquinas haviam baixado os arquivos por HTTPS dos próprios servidores da AOMEI, em países e redes diferentes, e o programa obteve o pacote pelas etapas normais de atualização. Em meados de julho, os monitores da própria ManageEngine capturaram uma das janelas enquanto ela ocorria, o que confirmou que a alteração estava sendo servida a partir do lado da AOMEI.
A Mandiant notificou a AOMEI em 17 de julho e compartilhou indicadores de comprometimento. Em 29 de julho, a AOMEI informou à Mandiant que havia tomado medidas corretivas para proteger seus servidores. O laboratório da ManageEngine afirmou que, até a publicação, não havia confirmado de forma independente que o comprometimento tinha sido contido.
Nenhum dos relatórios diz como o invasor obteve a capacidade de alterar arquivos nos servidores da AOMEI. O registro de alterações (changelog) publicado pela AOMEI para o Backupper, consultado pelo The Hacker News em 16 de outubro, não lista nenhuma mudança na forma como o programa verifica as atualizações até a versão atual, 8.5.0, lançada em 9 de outubro. Nenhum dos relatórios aponta uma versão que feche a brecha.
O que verificar agora
Um servidor corrigido não limpa uma máquina que foi atingida. O downloader criou sua tarefa agendada e, em seguida, restaurou o arquivo local de atualização ao conteúdo genuíno. Assim, uma máquina infectada pode parecer normal, enquanto a página de download do fabricante também parece limpa. O GTIG e a ManageEngine recomendam que as organizações que usam softwares da AOMEI investiguem todo o período de abril a julho.
“Organizações que usam softwares da AOMEI não podem presumir que estão protegidas apenas porque o fabricante tomou medidas corretivas no lado do servidor”, afirmaram o GTIG e a Mandiant.
Não avalie um alerta conferindo agora a página de download do fabricante. Como os arquivos voltavam ao normal em minutos, essa página exibe conteúdo genuíno quase sempre, o que levou analistas a descartar detecções reais como falsos alarmes. Preserve os arquivos armazenados em cache nas pastas do próprio programa e verifique os registros de rede para saber o que foi servido exatamente no momento em que o alerta disparou.
No endpoint, procure:
- Tarefa agendada: RadminComponentRuntime, ou NitroRuntime para a ferramenta secundária
- Arquivo: um upgrade-now.exe sem assinatura que traz os dados de editor da AOMEI, ou qualquer programa executado a partir da pasta de pop-up html do Backupper
- Pasta: arquivos do invasor preparados na pasta de dados de aplicativos locais do Radmin
Na rede, bloqueie a infraestrutura do invasor citada nos dois relatórios e bloqueie o SMB (TCP 445) de saída e o WebDAV para endereços externos, para interromper o artifício de credenciais:
- Domínios: storage-data[.]com, promotion.storage-data[.]com, aomei.storage-data[.]com
- IPs: 8.210.84[.]56, 8.218.65[.]184, 47.239.60[.]117
O GTIG e a ManageEngine publicaram, cada um, regras de detecção junto com os relatórios: regras YARA (linguagem para identificação de malware) do GTIG e regras Sigma (formato genérico para regras de detecção em registros) do laboratório. Os dois conjuntos são de autoria dos pesquisadores e não foram testados pelo The Hacker News.
