Botnet SSHStalker invade 7.000 servidores Linux com ataques de força bruta
Uma nova campanha de ataques direcionada a servidores Linux chamou a atenção de especialistas de segurança. A botnet batizada de SSHStalker conseguiu comprometer cerca de 7.000 sistemas ao explorar senhas fracas e mal configuradas no serviço SSH, segundo relatório divulgado em 10 de fevereiro de 2026 pela empresa de segurança Flare.
De acordo com o pesquisador Eric Belzile, da Flare, os operadores da botnet utilizam listas extensas de combinações de usuário e senha – muitas vezes compostas por credenciais vazadas em incidentes anteriores ou por padrões previsíveis – para tentar acesso remoto a servidores expostos na internet. Assim que uma combinação funciona, o atacante obtém controle inicial sobre a máquina e inicia a infecção.
Após a invasão bem-sucedida, um bot é instalado no servidor comprometido. Esse componente é responsável por se conectar à infraestrutura de comando e controle (C2) e preparar o ambiente para atividades maliciosas futuras. Entre essas ações estão o download de outros arquivos nocivos, a modificação de configurações do sistema e a criação de mecanismos para garantir que o malware sobreviva a reinicializações.
Um dos pontos que mais chama atenção na SSHStalker é a utilização do protocolo Internet Relay Chat (IRC) para gerenciar toda a rede de máquinas sequestradas. Em vez de recorrer a protocolos mais recentes ou infraestruturas complexas, os criminosos optaram por uma tecnologia antiga, mas extremamente simples e eficiente para seu propósito. Segundo a Flare, o IRC funciona como um “painel de controle” no qual os operadores emitem comandos em canais privados, e milhares de bots conectados respondem quase em tempo real.
Belzile explica que, a partir desses canais de IRC, os criminosos conseguem orquestrar ataques de negação de serviço distribuído (DDoS), acionar scripts personalizados e conduzir varreduras de rede em busca de novos alvos vulneráveis. A capacidade de escanear grandes blocos de endereços IP e testar credenciais em massa transforma a própria botnet em uma ferramenta de expansão contínua, alimentando o crescimento do número de máquinas infectadas.
Para dificultar a detecção, os operadores da SSHStalker utilizam binários ELF (formato executável típico do Linux) ofuscados. Essa ofuscação, de acordo com o relatório da Flare, serve para embaralhar o código, mascarar strings sensíveis e tornar mais complexo o trabalho de ferramentas antivírus e de análise estática. Em muitos casos, produtos de segurança tradicionais não identificam imediatamente o comportamento malicioso, especialmente se estiverem com assinaturas desatualizadas ou configuradas de forma permissiva.
Depois de instalados, os bots se conectam a canais de IRC específicos, onde permanecem em modo passivo até receberem instruções. A partir daí, podem iniciar inundações de tráfego UDP ou TCP contra um alvo definido pelos operadores, sobrecarregando serviços e derrubando sites ou aplicações. Em outros cenários, podem ser usados para baixar novos malwares, participar de campanhas de força bruta contra diferentes serviços ou servir como ponto de apoio para movimentação lateral dentro da rede interna da vítima.
A persistência é outro foco importante da SSHStalker. O malware tenta se firmar no sistema Linux modificando arquivos de inicialização, scripts de serviço ou agendando tarefas que garantam sua execução automática após cada reboot. Com isso, mesmo que o administrador reinicie o servidor na tentativa de solucionar problemas de desempenho ou disponibilidade, o bot continua ativo e conectado à botnet, pronto para obedecer a novos comandos.
Para reduzir o risco de comprometimento, Belzile enfatiza que é fundamental abandonar o uso de senhas fracas ou previsíveis no SSH. Ele reforça que o ideal é migrar para autenticação baseada em chaves criptográficas, que oferece um nível de segurança muito superior à simples combinação usuário/senha. Chaves privadas devidamente protegidas e com passphrase forte tornam ataques de força bruta praticamente inviáveis na prática.
O relatório da Flare também recomenda a vigilância constante dos logs do sistema. Padrões como múltiplas tentativas de login fracassadas em curto espaço de tempo, especialmente provenientes do mesmo endereço IP ou de faixas de IP suspeitas, são fortes indícios de ataques de força bruta em andamento. A detecção precoce desse comportamento permite que administradores bloqueiem endereços maliciosos, ajustem regras de firewall ou apliquem soluções automatizadas de bloqueio, como ferramentas de “banning” dinâmico com base em falhas de autenticação.
Outro ponto de atenção são as portas associadas ao IRC, como a 6667 e variações frequentemente utilizadas por operadores de botnet. Monitorar conexões de saída nessas portas, especialmente em servidores que não deveriam fazer uso legítimo desse tipo de protocolo, é uma prática essencial. Se um servidor de aplicação ou banco de dados começa, de repente, a estabelecer conexões IRC, isso é um forte indicador de comprometimento e merece investigação imediata.
Entre as medidas estruturais sugeridas para mitigar a propagação da SSHStalker estão a desativação de logins diretos de root via SSH e a adoção do princípio de privilégio mínimo. Isso significa que administradores devem acessar o sistema com contas não privilegiadas e elevar permissões apenas quando necessário, por meio de ferramentas como sudo. Essa abordagem reduz o impacto de uma eventual invasão, já que o atacante não obtém instantaneamente o controle total do sistema.
Firewalls configurados de forma restritiva também desempenham um papel central na defesa. Limitar o acesso ao SSH apenas a endereços IP específicos, redes corporativas confiáveis ou por meio de VPN reduz drasticamente a superfície de ataque exposta à internet. A segmentação de rede, isolando servidores críticos de ambientes menos confiáveis, complementa essa proteção ao dificultar a movimentação lateral de um invasor que consiga comprometer uma máquina.
Além das recomendações básicas, vale considerar soluções adicionais de endurecimento do SSH, como o uso de portas não padrão (embora isso não seja uma proteção por si só, dificulta ataques automatizados), limitação de tentativas de login por conexão, e aplicação de mecanismos de bloqueio temporário para IPs que excedam um número pré-definido de falhas de autenticação. Ferramentas específicas para isso conseguem reduzir de forma significativa o barulho de tentativas de força bruta no dia a dia.
Outra camada importante de proteção é a adoção de sistemas de detecção e resposta a intrusões, capazes de correlacionar eventos suspeitos, identificar comportamentos anômalos e acionar alertas em tempo quase real. Em um cenário em que botnets como a SSHStalker evoluem rápido e alteram táticas com frequência, depender apenas de assinaturas estáticas já não é suficiente. A combinação de análise comportamental, inteligência de ameaças e resposta automatizada ganha relevância.
Empresas que operam grande volume de servidores Linux em nuvem precisam considerar também políticas claras de hardening em escala: imagens padrão seguras, revisão periódica de configurações, rotação de chaves e senhas, além de inventário atualizado de todos os ativos expostos à internet. Ambientes em nuvem e SaaS muitas vezes são vistos como “intrinsecamente seguros”, mas, se o serviço SSH é publicado com credenciais fracas, o risco é tão alto quanto em qualquer data center físico.
Planos de resposta a incidentes específicos para botnets também devem ser estruturados. Isso inclui procedimentos para isolar rapidamente máquinas suspeitas da rede, coletar evidências para análise forense, remover o malware e reforçar configurações antes de recolocar o servidor em produção. Sem esse planejamento prévio, a organização tende a perder tempo precioso em meio ao caos de um ataque em andamento.
Por fim, a campanha da SSHStalker reforça uma mensagem recorrente na segurança da informação: a combinação de más práticas de autenticação, monitoramento deficiente e falta de segmentação de rede cria o cenário ideal para que botnets cresçam praticamente sem resistência. Ao mesmo tempo, medidas relativamente simples – como uso de chaves SSH, políticas de senha robustas, logs bem acompanhados e firewalls corretamente configurados – são suficientes para barrar boa parte dessas ameaças antes que alcancem o nível de 7.000 sistemas comprometidos.