SSHStalker O retorno do IRC na era dos botnets Linux

A cibersegurança às vezes parece um ciclo temporal: técnicas e protocolos que pareciam relegados ao passado voltam a reaparecer com novas vítimas. Esse é precisamente o caso do botnet recém documentado que os pesquisadores têm batizado como SSHStalker, uma infraestrutura maliciosa para Linux que repousa sobre um clássico da comunicação na Internet: IRC, o veterano Internet Relay Chat.

IRC nasceu no final dos anos oitenta e durante a década de 1990 foi a forma dominante de mensagens textuais para grupos e conversas privadas. Ainda hoje, comunidades técnicas valorizam sua simplicidade, interoperabilidade e baixo consumo de largura de banda —características que, paradoxalmente, o fazem atrativo também para operadores de malwares que buscam robustez e baixo custo em seus canais de controle. Para entender o protocolo na sua forma original, consultar o documento histórico RFC 1459 e uma visão geral Wikipédia.

As análises da equipe de inteligência em Flare mostram que o SSHStalker não pretende ser inovador em técnicas de sigilo; mais bem aposta pela escalabilidade e resistência. Em vez de frameworks modernos de C2, o malware exibe múltiplos bots escritos em C, apoia-se em servidores e canais IRC redundantes e emprega estratégias barulhentas como explorações massivas de SSH e tarefas agendadas a cada minuto para manter presença. Os detalhes do relatório estão disponíveis na análise publicada por Flare aqui.

A cadeia de infecção começa com um binário escrito em Go que se faz passar pela ferramenta de descoberta de rede nmap; essa suplantação facilita que a amostra passe desapercibida inicialmente em ambientes onde nmap é habitual. Após ganhar acesso por força bruta através de SSH, a equipe atacante usa os equipamentos comprometidos para continuar explorando e comprometendo outros servidores, um comportamento que lembra a dinâmica de um verme. Para quem quiser comparar, a página oficial do nmap serve como referência para a utilidade legítima: nmap.org.

Uma vez dentro, o SSHStalker descarrega ferramentas de compilação - em particular o GCC - para compilar seus binários diretamente no host infectado. Essa técnica proporciona portabilidade entre arquiteturas e pode ajudar a evitar algumas defesas baseadas em assinaturas. Os primeiros binários que mostram são bots IRC em C, com servidores e canais C2 codificados, e posteriormente força a descarga de pacotes adicionais (denominados no achado como GS e bootbou) que contêm variantes do bot para orquestração e execução de tarefas.

Para persistir nos sistemas comprometidos o botnet recurre a cron jobs que são executados a cada 60 segundos. Esse mecanismo atua como um vigilante: verifica que o processo principal está ativo e o relança se foi terminado. Paralelamente, o conjunto inclui exploit kits que aproveitam vulnerabilidades do kernel do Linux da época 2009–2010 para escalar privilégios quando a intrusão inicial só consegue acesso como usuário de baixa confiança. A base de dados do NIST (NVD) é um bom recurso para consultar detalhes sobre vulnerabilidades históricas: nvd.nist.gov.

Quanto à monetização e capacidades operacionais, Flare detectou harvest de credenciais e chaves da AWS, digitalização de sites e presença de kits de cripto-minaria - entre eles ferramentas conhecidas por seu desempenho no Ethereum - além de módulos para ataques DDoS. No entanto, os investigadores pontuam que até agora os bots se ligam ao C2 e entram num estado majoritariamente inactivo, sugerindo que os operadores poderiam estar testando infraestrutura ou acumulando acessos antes de colocá-los em uso malicioso.

Na telemetria examinada por Flare, destacam-se digitalizações voltadas majoritariamente para fornecedores de nuvem, com uma concentração visível em infraestrutura da Oracle Cloud. A equipe não atribuiu de forma conclusiva o trabalho a um actor concreto, embora observe semelhanças técnicas com ecossistemas de botnets prévios e alguns indicadores com possíveis vínculos geográficos.

Diante desta classe de ameaças, as recomendações práticas buscam elevar o custo da intrusão e reduzir a superfície explorável. As medidas recomendadas pelos especialistas incluem a desactivação da autenticação por senha no SSH e a utilização de chaves públicas, a remoção de compiladores e ferramentas de desenvolvimento de imagens de produção para impedir a compilação in situ, a filtragem do tráfego de saída para bloquear ligações C2 (incluindo padrões de tipo IRC) e a restrição da execução de espaços como /dev/shm. Além disso, convém estabelecer detecções que alertem sobre instalações ou execuções de compiladores em servidores produtivos e sobre cron jobs com cadências muito curtas criadas em rotas incomuns.

Guias práticas e oficiais para endurecer SSH podem ser consultados em recursos técnicos de referência e em manuais OpenSSH: OpenSSH Manual e artigos didáticos de provedores de infraestrutura que detalham como configurar autenticação por chave e outras medidas, por exemplo em DigitalOcean: How To Set Up SSH Keys. Para políticas de rede e filtragem de saída, as recomendações de controle de segurança costumam ser encontradas em organizações como o Center for Internet Security (CIS) e na documentação dos fornecedores cloud.

SSHStalker é um lembrete de que nem sempre ganha o que inova mais tecnologicamente, mas que otimiza uma receita comprovada: ferramentas simples, codificação leve, redundância e automação massiva. Para administradores e equipamentos de segurança, a lição é dupla: por um lado, cuidar da higiene básica dos acessos e das imagens de produção; por outro, instrumentar deteções que sinalizam padrões antigamente considerados “ruidosos” –cron cada minuto, compiladores aparecendo em servidores, conexões salientes para portos e padrões de IRC – porque esse ruído hoje pode ser o sinal de um botnet que está construindo seu exército.

Se você quer aprofundar os achados técnicos e as amostras analisadas, o relatório de Flare oferece uma desagregação detalhada com indicadores para detecção e resposta: Old school IRC, new victims — Flare.