Um ataque sofisticado contra uma das tecnologias fundamentais de roteamento da internet conseguiu transformar o sistema legítimo de atualização do Virtualizor em um canal para instalação de malware com privilégios máximos em servidores de hospedagem.
O incidente ocorreu entre 28 e 30 de agosto de 2026 e explorou o BGP — Border Gateway Protocol, protocolo utilizado para determinar os caminhos percorridos pelo tráfego entre as diferentes redes que formam a internet.
A informação apresentada na imagem está correta, mas existe uma ressalva importante: os cinco servidores comprometidos pertencem a um único provedor que verificou 34 hypervisors, e não representam cinco máquinas afetadas em todo o mundo. A dimensão total do incidente permanece desconhecida.
A própria Virtualizor reconhece que não consegue produzir uma relação definitiva dos servidores que receberam o pacote adulterado.
Criminosos atacaram a rota, não o servidor de atualização
O aspecto mais interessante do ataque é que os invasores não precisaram necessariamente comprometer diretamente a infraestrutura original responsável pelas atualizações.
Em vez disso, manipularam o caminho utilizado para chegar até ela.
O incidente atingiu o bloco de endereços IP 162.55.80.0/24, utilizado por serviços da Softaculous em infraestrutura hospedada na Hetzner.
Uma rota BGP não autorizada começou a ser propagada aproximadamente às 20h57 UTC de 28 de agosto.
Quando essa rota estava ativa, parte do tráfego destinado aos sistemas legítimos da Softaculous era direcionada para uma máquina controlada pelos invasores.
Na prática, o usuário acreditava estar se comunicando com o servidor correto, mas a internet havia sido convencida a entregar seus pacotes em outro lugar.
Até o HTTPS parecia legítimo
Normalmente, uma tentativa de interceptar uma atualização HTTPS deveria gerar alertas relacionados ao certificado digital.
Neste caso, isso não aconteceu.
Durante o sequestro das rotas, os criminosos conseguiram obter um certificado TLS tecnicamente válido da Let’s Encrypt para os domínios envolvidos.
Isso significava que as conexões desviadas podiam continuar aparecendo como seguras para os sistemas.
O cadeado do HTTPS, portanto, não era suficiente para revelar o ataque.
A Softaculous posteriormente comunicou o certificado para revogação.
Falta de assinatura criptográfica abriu a segunda porta
O ataque ainda precisava superar outra barreira: provar que o pacote de atualização era realmente produzido pelo desenvolvedor.
E foi justamente aí que apareceu uma fragilidade decisiva.
Os clientes de atualização do Virtualizor não realizavam verificação criptográfica da assinatura dos pacotes.
Assim, uma instalação que consultasse os servidores durante um período em que sua conexão estivesse sendo desviada poderia receber o pacote adulterado e aceitá-lo como uma atualização legítima.
A combinação foi poderosa:
BGP sequestrado + certificado TLS válido + pacote sem verificação criptográfica.
O resultado transformou uma atualização confiável em uma cadeia de comprometimento.
Malware conquistava privilégios de root
Uma vez instalada, a atualização maliciosa modificava arquivos legítimos do Virtualizor.
Como componentes do sistema são executados com privilégios elevados para administrar os hypervisors, o código injetado conseguia executar comandos como root, o nível máximo de privilégio em sistemas Linux.
O malware adicionava uma chave SSH controlada pelo invasor à conta root e instalava o Java 17 quando necessário.
Depois, baixava e executava uma carga adicional em Java.
A persistência era estabelecida por meio de um serviço do systemd chamado:
java-jre-update.service
A presença desse serviço tornou-se um dos principais indicadores de comprometimento divulgados após o ataque.
Conta clandestina também foi criada
As investigações encontraram ainda uma conta não autorizada chamada proxyuser.
Em pelo menos um dos ambientes analisados, registros mostraram uma autenticação SSH bem-sucedida nessa conta a partir de um endereço IP associado à atividade maliciosa.
Isso demonstra que o ataque não terminou na simples instalação automatizada do malware.
Os criminosos chegaram a possuir uma forma persistente de retornar às máquinas comprometidas.
Para um servidor de hospedagem, esse cenário é particularmente grave.
Cinco de 34 hypervisors estavam comprometidos
A confirmação mais concreta veio da AlbaHost, provedora de hospedagem que analisou sua infraestrutura após a divulgação do incidente.
Dos 34 hypervisors Virtualizor verificados pela empresa, cinco apresentavam as mesmas modificações maliciosas.
Isso corresponde a quase 15% daquele conjunto específico.
O número, entretanto, não pode ser extrapolado para toda a base mundial do Virtualizor.
Cada servidor precisava realizar uma consulta de atualização justamente durante um dos intervalos em que sua rota estivesse sendo desviada.
Como o ataque BGP apresentou períodos de instabilidade e interrupção, diferentes redes tiveram níveis diferentes de exposição.
Sequestradores chegaram a desviar grande parte das rotas observadas
A reconstrução do incidente utilizando informações públicas do RIPE mostrou que o sequestro teve alcance significativo.
Durante os picos, a rota maliciosa apareceu para aproximadamente 72% do conjunto total de peers monitorados utilizado na análise.
Foram identificadas duas grandes ondas de atividade: uma iniciada na noite de 28 de agosto e outra entre 29 e 30 de agosto.
Entre elas houve um intervalo de aproximadamente 11 horas com níveis mínimos de desvio.
Essa característica ajuda a explicar por que algumas instalações receberam o pacote adulterado e outras não.
Virtualizor manda todos os administradores verificarem seus servidores
Existe um problema operacional particularmente complicado: a empresa não possui uma lista completa dos equipamentos que receberam a atualização maliciosa.
Como as respostas adulteradas eram entregues pelo servidor dos criminosos, essas solicitações não chegaram aos registros normais da Softaculous.
Por isso, não existe uma versão específica que possa simplesmente ser considerada vulnerável ou segura.
A recomendação é tratar todas as instalações Virtualizor como potencialmente expostas até que sejam verificadas.
A companhia disponibilizou a versão 3.2.9.9, acompanhada de um Security Analyzer e ferramentas para ajudar na identificação dos sinais conhecidos do ataque.
Também informou que pretende implementar assinatura criptográfica nos pacotes.
Administradores precisam trocar credenciais
A orientação não se limita à atualização do software.
Operadores devem verificar a existência do serviço java-jre-update.service, procurar contas desconhecidas, analisar chaves SSH adicionadas ao sistema, revisar tarefas cron e procurar conexões de saída suspeitas.
Também é recomendada a rotação das chaves da API do Virtualizor e a restrição de acesso da API apenas a endereços confiáveis.
Se existirem evidências de comprometimento, simplesmente apagar o arquivo malicioso não garante que o invasor tenha sido removido.
A obtenção de root permite alterar praticamente qualquer componente do sistema.
Um hypervisor comprometido multiplica o risco
O alvo torna o incidente ainda mais grave.
Virtualizor é utilizado para administrar ambientes de virtualização em provedores de hospedagem e infraestrutura VPS.
Um único hypervisor pode hospedar diversas máquinas virtuais pertencentes a clientes diferentes.
Ter acesso root ao host significa ocupar uma posição extremamente privilegiada dentro dessa infraestrutura.
Isso pode, dependendo da arquitetura e das ações realizadas pelo invasor, abrir caminho para acessar discos, configurações, credenciais, redes virtuais e outros recursos associados às máquinas hospedadas.
A AlbaHost afirmou que, no ambiente analisado, não encontrou confirmação de alterações nas VPS de clientes nem confirmou exportação de bancos de dados.
Isso é importante: o acesso root existiu, mas não há evidência pública de que todos os possíveis impactos tenham efetivamente ocorrido.
Área de clientes também esteve potencialmente exposta
O bloco de IP sequestrado não hospedava apenas componentes de atualização.
Serviços relacionados à área de clientes e faturamento da Softaculous também estavam na infraestrutura afetada.
Por isso, pessoas que fizeram login ou inseriram informações de pagamento durante o período do incidente podem ter tido suas conexões desviadas.
A empresa recomendou a troca das senhas da área de clientes e regeneração das chaves de API.
Até o momento, entretanto, não há confirmação pública de roubo de dados de pagamento.
Ataque expõe fragilidade estrutural da internet
O caso Virtualizor é particularmente relevante porque combina três camadas diferentes de confiança.
A primeira é o BGP, que determina para onde o tráfego da internet deve viajar.
A segunda é o TLS, utilizado para verificar a identidade de um serviço e criptografar a comunicação.
A terceira é a integridade do próprio software baixado.
Os invasores conseguiram manipular a primeira camada, obter uma condição válida na segunda e aproveitar a ausência de uma proteção adequada na terceira.
É justamente a assinatura criptográfica independente do pacote que poderia oferecer uma última barreira.
Mesmo que um atacante controlasse temporariamente a rota e apresentasse uma conexão HTTPS aparentemente legítima, o pacote modificado não teria a assinatura privada correta do desenvolvedor e poderia ser rejeitado.
Ataques à cadeia de confiança ganham nova dimensão
Incidentes de supply chain normalmente são associados à invasão de desenvolvedores, repositórios ou sistemas de compilação.
O caso Virtualizor demonstra uma alternativa muito mais incomum: atacar a estrada utilizada pela atualização em vez da fábrica que produz o software.
O servidor legítimo não precisa necessariamente entregar malware.
Basta convencer parte da internet de que o caminho até ele passa pela infraestrutura do criminoso.
Para provedores de hospedagem, cloud e telecomunicações, o episódio deixa um alerta importante sobre a necessidade de combinar segurança de roteamento, monitoramento BGP e validação criptográfica independente de atualizações.
O ataque conseguiu transformar um procedimento rotineiro e normalmente confiável — atualizar um software — em um mecanismo para conquistar o nível máximo de privilégio em servidores de produção.
