Botnet invade 7.000 servidores Linux com ataques de força bruta a SSH
A botnet batizada de SSHStalker conseguiu comprometer cerca de 7.000 sistemas Linux ao explorar senhas fracas e mal configuradas no serviço SSH. A campanha foi detalhada em um relatório divulgado em 10 de fevereiro de 2026 pela empresa de segurança Flare, que vem monitorando a atividade do grupo por trás da ameaça.
Segundo o pesquisador de segurança da Flare, Eric Belzile, os operadores da botnet utilizam extensas listas de usuários e senhas — muitas vezes compostas por credenciais vazadas em incidentes anteriores ou combinações comuns — para realizar ataques de força bruta contra servidores expostos na internet. Quando encontram uma combinação válida, obtêm acesso inicial ao sistema e imediatamente instalam um bot responsável por manter a comunicação com a infraestrutura de comando e controle.
Após a infecção, o malware se conecta a um servidor de comando e controle (C2) baseado no protocolo IRC (Internet Relay Chat). Esse protocolo, originalmente criado para bate-papo em tempo real, é explorado pelos criminosos como um canal simples, leve e eficiente para coordenar grandes redes de máquinas comprometidas. Através de canais específicos de IRC, os operadores enviam instruções simultâneas para milhares de bots, disparando ações como ataques DDoS, download de novos malwares ou varreduras em busca de novas vítimas.
O relatório destaca que a SSHStalker realiza varreduras de rede para localizar outros servidores com portas SSH acessíveis. Uma vez identificados possíveis alvos, a botnet dispara novamente o mecanismo de força bruta, ampliando o alcance da campanha. Esse comportamento de autopropagação transforma cada servidor comprometido em uma plataforma para novos ataques, acelerando o crescimento da rede de dispositivos sequestrados.
Para dificultar a detecção, os operadores da botnet utilizam binários ELF ofuscados, desenvolvidos especificamente para ambientes Linux. A ofuscação torna o código mais difícil de ser analisado por especialistas e ferramentas automatizadas, atrapalhando a identificação de assinaturas e reduzindo a eficácia de soluções antivírus tradicionais. De acordo com Belzile, os bots se conectam a canais de IRC pré-configurados onde ficam escutando comandos, prontos para executar scripts arbitrários ou iniciar inundações de tráfego UDP e TCP contra alvos definidos pelo grupo criminoso.
Outro ponto crítico é o foco do malware em garantir persistência. O SSHStalker ajusta o ambiente comprometido para assegurar que o bot seja executado novamente após reinicializações do sistema, o que pode envolver modificações em scripts de inicialização, serviços do sistema ou agendamentos de tarefas. Assim, mesmo que o servidor passe por um reboot de rotina, ele tende a permanecer atrelado à botnet até que uma análise de segurança identifique e remova o componente malicioso.
Como funcionam os ataques de força bruta ao SSH
No centro da campanha está a exploração de configurações fracas de SSH. Em um ataque de força bruta, o invasor tenta inúmeras combinações de usuário e senha até encontrar uma que funcione. Muitas organizações ainda utilizam credenciais previsíveis, como “root” com senhas simples, ou reaproveitam a mesma senha em múltiplos servidores. Além disso, sistemas recém-instalados podem permanecer com contas padrão ativas, o que abre uma porta direta para ataques automatizados.
Bots como os da SSHStalker são programados para testar milhares de combinações em velocidade muito superior à de qualquer tentativa manual. Sem mecanismos de proteção, como limitação de tentativas ou bloqueio de IPs suspeitos, o servidor acaba se tornando um alvo fácil. Em ambientes com grande exposição na internet — como provedores de hospedagem, empresas de nuvem privada ou infraestruturas de TI descentralizadas — essa vulnerabilidade ganha escala rapidamente.
Riscos concretos para empresas e provedores
Uma vez dentro do servidor, o risco vai muito além da simples participação em ataques DDoS. Um sistema comprometido pode ser utilizado para:
– Exfiltrar dados sensíveis armazenados localmente
– Interceptar credenciais de outros serviços acessados a partir daquela máquina
– Desencadear movimentação lateral dentro da rede corporativa
– Hospedar ferramentas adicionais para campanhas de ransomware ou espionagem
– Servir como proxy para mascarar a origem de outras atividades criminosas
Para empresas que dependem de Linux em serviços críticos — como bancos de dados, aplicações de negócio, gateways de VPN ou sistemas de monitoramento — a presença silenciosa de um bot pode comprometer a confidencialidade, integridade e disponibilidade de todo o ambiente. Além disso, servidores usados como base para ataques DDoS podem gerar problemas de reputação de IP, bloqueios por parte de parceiros e até ações legais, dependendo da gravidade dos incidentes originados dali.
Medidas essenciais de proteção contra a SSHStalker
Belzile enfatiza que a defesa contra a SSHStalker passa, antes de tudo, pelo endurecimento (hardening) do serviço SSH. Entre as recomendações centrais estão:
– Substituir autenticação por senha por autenticação baseada em chaves criptográficas
– Exigir senhas fortes e exclusivas quando o uso de senha for inevitável
– Desativar logins diretos de root via SSH
– Restringir o acesso SSH apenas a usuários e grupos estritamente necessários
A Flare também recomenda o monitoramento constante de logs de autenticação, em busca de múltiplas tentativas falhas de login, picos de tentativas vindos de um mesmo IP ou padrões compatíveis com ataques automatizados. Em paralelo, é indicado observar o tráfego de saída em portas tradicionalmente associadas ao IRC, como a 6667, que podem indicar a presença de bots se comunicando com canais de C2.
Endurecimento avançado de SSH na prática
Para além das recomendações básicas, algumas práticas adicionais podem elevar significativamente o nível de segurança:
– Alterar a porta padrão do SSH (22) para reduzir ruídos de varreduras automatizadas
– Adotar soluções como fail2ban ou sistemas de detecção de intrusão que bloqueiam IPs após várias tentativas frustradas
– Implementar autenticação multifator (MFA) para acessos administrativos, sempre que possível
– Limitar o SSH a endereços IP específicos via firewall, principalmente para servidores de uso interno
– Utilizar bastion hosts (jump servers) como ponto único de acesso, em vez de expor múltiplos servidores diretamente à internet
Embora nenhuma dessas medidas seja isoladamente infalível, em conjunto elas elevam muito o custo e a dificuldade dos ataques de força bruta, levando os criminosos a procurar alvos mais fáceis.
Monitoramento, detecção e resposta a incidentes
Identificar a presença da SSHStalker em um ambiente exige atenção a diversos indicadores de comprometimento. Administradores devem ficar alertas para:
– Processos desconhecidos ou com nomes suspeitos rodando em background
– Conexões persistentes de saída para hosts e portas incomuns
– Aumento anormal de tráfego de rede, especialmente UDP e TCP, sem motivo operacional aparente
– Arquivos binários ELF recém-criados ou modificados em diretórios não usuais
– Alterações em scripts de inicialização ou tarefas agendadas sem registro de mudança planejada
Caso seja detectada contaminação, é fundamental isolar imediatamente o servidor da rede para interromper o uso do recurso pela botnet. A partir daí, recomenda-se realizar uma análise forense, identificar o vetor de acesso inicial (geralmente credenciais comprometidas), revogar senhas e chaves, reinstalar o sistema a partir de imagens confiáveis, aplicar atualizações e endurecer as configurações antes de recolocar o ativo em produção.
Segmentação de rede e redução da superfície de ataque
Outro pilar para mitigar o impacto de botnets como a SSHStalker é a segmentação de rede. Ao separar ambientes de produção, teste, desenvolvimento e administração, e ao restringir o tráfego entre segmentos, as organizações reduzem a capacidade de movimentação lateral caso um servidor seja comprometido.
Firewalls internos, listas de controle de acesso e políticas de zero trust ajudam a garantir que, mesmo se um atacante conquistar um servidor exposto à internet, o acesso a bancos de dados, aplicações críticas ou controladores de domínio continue bloqueado. Essa abordagem não impede a infecção inicial, mas limita drasticamente o dano potencial.
Cultura de segurança e governança de credenciais
A campanha da SSHStalker expõe uma fragilidade recorrente: a má gestão de credenciais. Senhas fracas, reaproveitadas e pouco monitoradas continuam sendo um dos caminhos mais simples para invasões bem-sucedidas. Investir em políticas claras de criação, rotação e armazenamento de senhas é tão essencial quanto instalar qualquer ferramenta de segurança.
Organizações podem se beneficiar de cofres de senhas corporativos, revisão periódica de contas ativas, desativação de usuários obsoletos e processos formais de provisionamento e desprovisionamento de acessos. Treinamentos regulares para equipes técnicas, reforçando boas práticas de SSH e de autenticação, ajudam a reduzir erros humanos que acabam abrindo portas para botnets.
Lições da SSHStalker para a segurança de Linux
O caso da SSHStalker reforça que ambientes Linux, muitas vezes vistos como mais seguros por padrão, não estão imunes a ameaças em larga escala. Configurações padrão, serviços expostos sem necessidade e falta de monitoramento criam um cenário em que ataques automatizados se tornam extremamente eficientes.
Ao combinar técnicas clássicas — como força bruta — com estruturas de comando e controle via IRC e ofuscação avançada de binários, os operadores da botnet demonstram que não é preciso inovação sofisticada para causar impacto, bastando explorar lacunas básicas de segurança operacional.
Fortalecer o SSH, monitorar ativamente o ambiente, segmentar redes e tratar senhas como ativos críticos são passos decisivos para impedir que servidores Linux entrem nas estatísticas de sistemas sequestrados por botnets. A SSHStalker é mais um alerta de que segurança não é um produto único, mas um conjunto contínuo de práticas, processos e controles técnicos que precisam ser revisados e aprimorados o tempo todo.