AhsayCBS sob ataque: falhas críticas podem expor servidores de backup
Servidores que utilizam o AhsayCBS estão na mira de criminosos. A exploração encadeada de duas vulnerabilidades permite contornar a autenticação e executar comandos no sistema operacional. Em ataques identificados em outubro de 2026, os invasores instalaram ferramentas de mineração de criptomoedas, criaram mecanismos de persistência e deixaram portas abertas para manter o acesso às máquinas comprometidas.
A atividade é especialmente preocupante para provedores de serviços gerenciados e empresas que administram backups de vários clientes em uma única plataforma. Uma invasão ao servidor de backup pode comprometer não apenas os dados armazenados, mas também a capacidade de recuperação de diferentes organizações.
As falhas envolvidas são a CVE-2026-105133 e a CVE-2026-105134, divulgadas em 4 de outubro. A primeira afeta uma função da API do AhsayCBS e pode permitir o desvio de mecanismos de autenticação. A segunda está no componente Replication Receiver, usado em operações de replicação, e possibilita a injeção de comandos no sistema operacional.
A CVE-2026-105134 recebeu pontuação CVSS 4.0 de 9,3, classificada como crítica. Já a CVE-2026-105133 teve nota 5,5. Embora a segunda vulnerabilidade tenha uma avaliação mais alta, a falha de autenticação também é importante: os atacantes podem combiná-la com a vulnerabilidade de execução de comandos para avançar da exposição inicial ao controle do servidor.
As primeiras tentativas observadas em ambientes monitorados ocorreram na noite de 7 de outubro, no horário UTC. Até o dia seguinte, pelo menos cinco organizações haviam sido identificadas entre as possíveis vítimas. A sequência de ataque descrita começa com o contorno da autenticação e prossegue pela interface de replicação, permitindo executar comandos com privilégios elevados no Windows.
Em alguns casos, os criminosos gravaram uma webshell JSP na estrutura da aplicação. Esse tipo de arquivo pode oferecer uma forma de acesso remoto persistente, mesmo após a atividade inicial. Por isso, a verificação não deve se limitar a confirmar que os backups continuam sendo executados ou que o serviço parece funcionar normalmente.
Há ainda uma divergência relevante sobre a atualização corretiva. Informações inicialmente registradas indicavam que a versão 10.3.4 resolvia os problemas encontrados em versões anteriores, até a 10.3.2. No entanto, em 8 de outubro, após revisar sua análise, a Huntress informou que a versão 10.3.4 também permanecia vulnerável. A empresa comunicou a descoberta à Ahsay e recomendou limitar o acesso à interface de gerenciamento até que uma correção fosse validada. Portanto, a atualização para a versão 10.3.4, por si só, não deve ser tratada como garantia de proteção.
Depois de obter execução de comandos, os invasores recorreram a processos associados ao serviço `cbssvcX64.exe` para iniciar ferramentas do Windows e baixar arquivos. Parte dos componentes foi armazenada em diretórios temporários, onde pode passar despercebida em verificações operacionais de rotina. Um processo filho inesperado do serviço de backup não confirma sozinho uma invasão, mas, quando aparece junto a downloads desconhecidos ou alterações recentes, merece investigação.
Entre os arquivos identificados estava o XMRig, um programa legítimo de mineração de criptomoedas que pode ser usado de forma maliciosa para consumir os recursos de máquinas comprometidas. Na campanha, ele foi renomeado como `edge.exe`, numa tentativa de fazê-lo parecer relacionado ao Microsoft Edge. Outro arquivo, `msedge.exe`, correspondia a uma versão modificada do NSSM, ferramenta usada para manter programas em execução como serviços.
Os atacantes também criaram um serviço chamado `MicrosoftEdgeUpdateSvc`, nome semelhante ao de componentes legítimos de atualização. O objetivo era fazer o programa voltar a funcionar depois de interrupções ou reinicializações. Essa estratégia pode prolongar a presença do invasor mesmo quando o processo de mineração é encerrado manualmente.
Outro recurso de ocultação observado foi o script PowerShell `Taskgmr.ps1`. Ele monitorava a abertura do Gerenciador de Tarefas e interrompia temporariamente o serviço de mineração enquanto a ferramenta estivesse visível, retomando a atividade depois. Em determinadas situações, o script tentava fechar o próprio Gerenciador de Tarefas. Em um dos incidentes, também foi baixado o driver vulnerável `WinRing0x64.sys`, que pode facilitar o acesso a recursos de baixo nível do hardware.
Diante desse cenário, o primeiro passo é restringir o acesso ao console de administração do AhsayCBS. Sempre que possível, a interface deve ficar disponível apenas por meio de redes confiáveis, VPN ou endereços previamente autorizados. A exposição direta à internet aumenta a possibilidade de tentativas automatizadas e dificulta o controle sobre quem pode alcançar o serviço.
As equipes devem revisar os registros de autenticação e de atividade da API, além de procurar alterações recentes em serviços do Windows, tarefas agendadas e diretórios temporários. Arquivos JSP inesperados, executáveis com nomes parecidos com componentes conhecidos, conexões de saída incomuns e processos iniciados por `cbssvcX64.exe` são sinais que justificam uma análise aprofundada.
Se houver indícios de comprometimento, encerrar o minerador ou apagar um arquivo suspeito não é suficiente. É necessário isolar o servidor da rede, preservar registros e evidências para investigação e identificar todos os mecanismos de persistência instalados. Também convém verificar se credenciais administrativas ou de acesso a outros sistemas foram expostas e substituí-las a partir de um dispositivo confiável.
A recuperação deve incluir uma análise dos próprios backups. Um servidor comprometido pode ter sido usado para acessar, alterar ou apagar cópias de segurança, prejudicando a restauração após um incidente. As organizações precisam confirmar a integridade das cópias, testar a recuperação de arquivos e avaliar se existem versões offline ou isoladas da rede principal.
Por fim, administradores devem acompanhar os comunicados de segurança do fabricante e confirmar quais versões corrigem efetivamente as vulnerabilidades antes de considerar o risco resolvido. Até que uma correção seja validada, a combinação de acesso restrito, monitoramento reforçado e investigação de sinais de persistência é essencial para reduzir a possibilidade de uma nova invasão.