AhsayCBS já foi invadido — aplicar o hotfix não encerra a limpeza

Servidores AhsayCBS sofreram acessos não autorizados, e instalar o hotfix não basta para recuperar um host já comprometido. Na atualização de 13 de outubro de 2026, a Ahsay informou que recebeu relatos de parceiros desde 9 de outubro, lançou o hotfix 10.3.4.45 para a linha 10 no dia 10 e o 9.15.2.70 para a linha 9 no dia 12, e orientou a reconstrução completa dos servidores invadidos. Quem ainda opera as linhas 7 ou 8 precisa migrar para a versão 9.15.0.0 antes de aplicar o hotfix correspondente.

O alerta tem base em invasões observadas, não apenas em uma falha teórica. A investigação da Huntress registrou exploração desde 7 de outubro e cinco organizações visadas até o dia 8: invasores combinaram CVE-2026-105133 e CVE-2026-105134, instalaram webshells JSP e, em alguns casos, o minerador XMRig disfarçado de Microsoft Edge. Para cada instalação, as perguntas são distintas: a versão e a exposição da interface indicam risco de entrada; contas, arquivos e processos suspeitos indicam se já houve comprometimento.

Por que a atualização não limpa o servidor

A primeira falha permite contornar a autenticação; a segunda, no componente Replication Receiver, permite executar comandos no sistema. Na cadeia observada, o invasor configura um receptor malicioso e grava um webshell no diretório servido pela aplicação. O arquivo oferece uma forma de voltar a executar comandos depois que a entrada original é corrigida. Por isso, confirmar a instalação do hotfix responde à pergunta sobre vulnerabilidade atual, mas não à pergunta sobre o estado do host antes da correção.

O número completo da versão importa. As versões 10.3.4.0 e 9.15.2.59, apresentadas anteriormente como correções, não resolveram integralmente as falhas; quem as instalou ainda precisa do hotfix posterior e de uma reinicialização do servidor. A interface de administração acessível pela internet ou por outra rede não confiável amplia a exposição. Restringir esse acesso a endereços confiáveis ou a uma VPN reduz as oportunidades de exploração enquanto a atualização é feita, mas não apaga uma alteração já executada no sistema.

Onde procurar sinais de invasão

Os indicadores mais diretos aparecem na aplicação e na estrutura de arquivos. Pastas inesperadas na raiz dos discos, como ahsay_ts ou ahsay_t8, arquivos JSP de nomes aleatórios em %CBS%\webapps, receptores RPS não autorizados e contas AhsayCBS criadas com privilégio de administrador são motivos para tratar o servidor como comprometido. O horário de criação desses itens ajuda a estabelecer o início provável da invasão e a escolher uma configuração anterior para a recuperação.

Uma busca limitada a nomes conhecidos pode deixar passar outras formas de persistência. Em três investigações publicadas pela Bitdefender em 15 de outubro, a cadeia inicial era a mesma, mas os arquivos e as ferramentas variavam; em uma delas, os invasores tentaram configurar o serviço de acesso remoto OpenSSH. A verificação deve incluir processos de comando ou PowerShell iniciados pelo serviço AhsayCBS, novos serviços e tarefas agendadas, mudanças de privilégios e conexões externas inesperadas. Nos incidentes examinados pela empresa, não houve observação de criptografia nem de exfiltração; essa constatação vale apenas para aqueles casos.

Uma decisão por instalação, não por frota

Um provedor pode ter servidores com versões, regras de rede e históricos diferentes. Em cada host, registre a versão instalada, verifique se o serviço de administração era alcançável por redes não confiáveis e determine desde quando houve essa exposição. Um servidor atualizado agora pode ter sido invadido antes; a ausência de um webshell com nome já divulgado tampouco encerra a investigação.

1. Versão vulnerável e interface exposta: restrinja o acesso de administração, instale o hotfix adequado e examine a atividade anterior à correção. Priorize os registros de acesso, alterações de contas e processos filhos do serviço de backup.
2. Hotfix presente após um período de exposição: mantenha a busca por indicadores de comprometimento. Compare o momento da instalação com a criação de receptores RPS, arquivos, serviços e contas; o pacote instalado não permite concluir que o host esteja limpo.
3. Qualquer vestígio de invasão: isole o servidor para conter novas ações e preserve registros, alertas e demais evidências antes de reinstalá-lo. Essa linha do tempo orienta a escolha de uma configuração confiável e a avaliação dos acessos que precisam ser revogados.

Como recuperar um AhsayCBS comprometido

A recuperação indicada para um host comprometido começa pela reinstalação do Windows ou Linux, seguida de uma instalação limpa do AhsayCBS e da aplicação do hotfix apropriado. A configuração deve ser restaurada de um Auto Save anterior ao comprometimento; a orientação do fornecedor é escolher, por prudência, uma cópia de pelo menos um dia antes do horário dos arquivos ou diretórios suspeitos. Recuperar uma configuração já modificada pode devolver ao servidor contas ou parâmetros deixados pelo invasor.

Também é necessário revisar as credenciais armazenadas no host ou acessíveis a partir dele: administradores do AhsayCBS, contas de serviço, credenciais de domínio usadas ali e destinos de armazenamento dos backups. Se houver sinal de comprometimento, a troca dessas credenciais deve acompanhar a reconstrução, pois reinstalar o sistema não invalida senhas obtidas antes. Sem essa revisão, uma senha exposta antes da reinstalação ainda pode dar acesso aos destinos de backup.

Leia também:

• Falha no Cisco SD-WAN já dá acesso de administrador — não há atalho
• WhatsApp troca PIN por senha — e ela não expulsa quem já invadiu a conta
• Dify ou Flowise: o projeto encerrado transforma leveza em risco