Operação combina varredura SSH, componentes em Golang, C, shell, Perl e Python, limpeza de logs e exploração de vulnerabilidades Linux de 2009 a 2010 para manter acesso persistente em infraestrutura legada.
| Componente | Botnet SSHStalker, com bots controlados por IRC, scanner SSH em Golang, artefatos em C, shell, Perl e Python e módulos voltados a sistemas Linux legados. |
| Vetor | Varredura automatizada da porta 22 em servidores com SSH exposto, seguida por tentativa de cooptação de sistemas suscetíveis e uso de exploits antigos do núcleo Linux 2.6.x. |
| Impacto | Controle remoto via canais IRC, persistência com relançamento do processo principal em até 60 segundos, redução de visibilidade forense por adulteração de logs e capacidade de ataques de tráfego do tipo flood. |
| Prioridade | Inventariar Linux legados, eliminar SSH exposto sem controle, revisar evidências de manipulação em utmp, wtmp e lastlog, e atualizar ou isolar sistemas ainda compatíveis com falhas de 2009 e 2010. |
| Vulnerabilidades | O módulo de exploração inclui 16 falhas antigas do núcleo Linux, com exemplos como CVE-2009-2692, CVE-2009-2698, CVE-2010-3849, CVE-2010-1173, CVE-2009-2267, CVE-2009-2908, CVE-2009-3547, CVE-2010-2959 e CVE-2010-3437. |
| Artefatos | Foram descritos bot IRC, bot em Perl conectado a UnrealIRCd, limpadores de logs SSH, componente keep-alive, repositório de ferramentas ofensivas abertas, amostras antigas de malware, utilitário de coleta de segredos AWS expostos e EnergyMech. |
SSHStalker é uma operação de botnet voltada a sistemas Linux que combina mecânica clássica de comando e controle por IRC com automação de comprometimento em massa. O fluxo observado não depende de exploração inédita: o conjunto de ferramentas mantém um acervo de exploits antigos do núcleo Linux, principalmente de ambientes 2.6.x e de falhas publicadas entre 2009 e 2010. Essa escolha reduz a eficácia contra distribuições modernas e bem mantidas, mas preserva valor operacional contra servidores esquecidos, appliances antigos, instâncias sem ciclo de atualização e máquinas que continuam expostas por razões de compatibilidade.
A característica mais importante da campanha é a retenção de acesso. Embora o conjunto contenha bots capazes de receber comandos e executar ataques de tráfego do tipo flood, a atividade descrita não foi marcada por monetização imediata, mineração de criptomoedas, proxyjacking ou ataques distribuídos de negação de serviço como objetivo principal confirmado. O comportamento de espera sugere uso da infraestrutura comprometida como reserva operacional, ambiente de testes, ponto de preparação ou base de acesso futuro. Essa distinção importa para defesa: a ausência de ruído pós-exploração não deve ser interpretada como ausência de comprometimento.
O núcleo de propagação inclui um scanner escrito em Golang que procura servidores com SSH aberto na porta 22. Esse componente dá à operação comportamento semelhante a um worm, porque amplia a busca por novos alvos a partir de automação e varredura contínua. Sistemas identificados como suscetíveis podem receber payloads adicionais, entre eles variantes de bot controlado por IRC e um bot em Perl que se conecta a um servidor UnrealIRCd, entra em um canal de controle e permanece aguardando instruções. O controle por IRC é uma técnica antiga, mas ainda funcional em redes onde o tráfego de saída não é restrito ou onde conexões a servidores IRC não são monitoradas com rigor.
Após o comprometimento, a cadeia executa arquivos em C voltados à limpeza de rastros de conexão SSH e à adulteração de registros locais. Os alvos citados incluem utmp, wtmp e lastlog, arquivos usados para registrar sessões, logins e histórico de acesso em sistemas Unix-like. Essa etapa tem finalidade defensivamente relevante: ela diminui a visibilidade de investigações que dependem apenas de artefatos locais convencionais. A operação também inclui um componente de persistência do tipo keep-alive, capaz de relançar o processo principal em até 60 segundos caso uma ferramenta de segurança consiga encerrá-lo.
O módulo de exploração reúne 16 vulnerabilidades distintas do núcleo Linux, incluindo CVE-2009-2692, CVE-2009-2698, CVE-2010-3849, CVE-2010-1173, CVE-2009-2267, CVE-2009-2908, CVE-2009-3547, CVE-2010-2959 e CVE-2010-3437. O uso desse catálogo mostra foco em infraestrutura de cauda longa, não em desenvolvimento de zero-days ou rootkits inéditos. A operação também reutiliza ferramentas ofensivas abertas e amostras de malware já publicadas, com implementação distribuída entre C para componentes de baixo nível, shell para orquestração e persistência, e uso limitado de Python e Perl para automação auxiliar.
A exposição principal recai sobre servidores Linux com SSH acessível pela internet ou por segmentos internos amplos, especialmente quando combinados com versões antigas do núcleo, ausência de correções, senhas fracas, controles de acesso permissivos ou monitoramento incompleto de sessões. O risco aumenta em ambientes heterogêneos onde sistemas legados permanecem em produção por dependência de aplicação, falta de proprietário claro, appliances sem suporte, imagens antigas de nuvem ou máquinas migradas sem revalidação de endurecimento.
A campanha também toca superfície de nuvem e desenvolvimento quando inclui um script em Python descrito como executor de um binário de coleta de websites para localizar segredos AWS expostos em sites-alvo. O contexto não confirma exfiltração em massa nem uso posterior desses segredos, mas o artefato indica interesse por credenciais em páginas, repositórios publicados ou conteúdo web mal configurado. Para organizações com workloads em AWS, isso conecta a resposta de endpoint Linux com revisão de segredos, permissões IAM e histórico de uso de chaves.
- Servidores Linux com SSH aberto na porta 22 e sem restrição de origem.
- Sistemas baseados em núcleos Linux legados, incluindo famílias 2.6.x ainda presentes em infraestrutura esquecida.
- Hosts com registros locais adulteráveis e pouca centralização de logs de autenticação.
- Ambientes que permitem conexões de saída para IRC ou que não classificam esse tráfego como anômalo.
- Sites, aplicações ou artefatos publicados que possam conter segredos AWS expostos.
A investigação defensiva deve combinar telemetria de rede, endpoint, identidade e integridade de arquivos. Em rede, conexões de saída para servidores IRC, ingresso em canais de controle, tráfego persistente em padrões incomuns e atividade originada de servidores que não deveriam usar IRC são sinais fortes. No endpoint, processos desconhecidos escritos em C, Golang, Perl, Python ou shell, reinicialização rápida de binários após encerramento e arquivos temporários associados a bots merecem correlação com eventos de autenticação SSH.
A adulteração de utmp, wtmp e lastlog exige validação cruzada. Se os registros locais parecem limpos, mas há eventos no servidor SSH, no coletor centralizado, no EDR, no firewall, no bastion host ou no provedor de nuvem indicando acesso, a diferença é um indicador relevante. Também é importante verificar varredura de saída para a porta 22, porque um host comprometido pode passar a procurar novos sistemas. A presença de EnergyMech ou de artefatos compatíveis com bot IRC deve ser tratada como indício de controle remoto, mesmo sem execução posterior de ataques de tráfego.
- Conexões de saída para IRC a partir de servidores que não têm justificativa operacional para esse protocolo.
- Processos que reaparecem em curto intervalo após encerramento, especialmente dentro de uma janela próxima de 60 segundos.
- Divergência entre logs locais de login e registros centralizados de autenticação SSH.
- Varredura de saída para porta 22 partindo de servidores internos ou instâncias de nuvem.
- Alterações inesperadas em
utmp,wtmp,lastloge histórico de sessões. - Presença de bots IRC, scripts Perl, binários em Golang ou C sem procedência administrativa clara.
- Busca por strings, nomes de arquivos ou comportamentos associados a coleta de segredos AWS expostos em conteúdo web.
A resposta deve começar por inventário e contenção dos sistemas com SSH exposto. Servidores Linux antigos precisam ser identificados por versão do núcleo, função de negócio e caminho de atualização ou isolamento. Quando atualização não for viável de imediato, a exposição de SSH deve ser reduzida com listas de controle de acesso, VPN, bastion hosts, autenticação forte, desativação de login por senha quando aplicável e bloqueio de origens não autorizadas. Sistemas com sinais de botnet devem ser isolados antes de qualquer limpeza, porque o componente keep-alive pode recriar processos e mascarar a extensão do comprometimento.
A erradicação deve incluir remoção de artefatos, revisão de persistência em scripts de inicialização, tarefas agendadas, shells de usuário, diretórios temporários e binários fora do padrão. Como os logs locais podem ter sido adulterados, a linha do tempo precisa ser reconstruída com fontes externas: SIEM, EDR, firewall, proxy, logs de nuvem, histórico de bastion e registros de autenticação centralizados. Se houver qualquer indício de coleta de segredos AWS expostos, as chaves afetadas devem ser revogadas ou rotacionadas, as permissões revisadas pelo menor privilégio e o histórico de uso analisado para ações anômalas.
A prevenção de recorrência depende de retirar valor da cauda longa de infraestrutura. Falhas antigas do núcleo Linux permanecem exploráveis quando servidores sem dono, imagens antigas e appliances abandonados continuam roteáveis. A organização deve estabelecer datas de fim de suporte, alertas para núcleos fora de política, varredura interna de SSH, bloqueio de IRC não autorizado e testes periódicos de integridade dos registros de autenticação. A campanha mostra que um operador não precisa de exploração inédita para obter persistência quando encontra sistemas antigos, pouco monitorados e ainda conectados a redes produtivas.
- Atualizar ou substituir sistemas Linux vulneráveis a falhas antigas do núcleo, priorizando hosts expostos por SSH.
- Restringir SSH por origem, bastion, VPN e autenticação forte, removendo exposição direta desnecessária.
- Bloquear ou monitorar tráfego IRC de saída em servidores sem necessidade operacional desse protocolo.
- Centralizar logs de autenticação para reduzir dependência de arquivos locais adulteráveis.
- Isolar hosts com sinais de SSHStalker antes de remover processos, para preservar evidência e impedir nova propagação.
- Rotacionar segredos AWS quando houver suspeita de exposição em websites, artefatos publicados ou conteúdo acessível externamente.
- Revisar persistência, tarefas agendadas, scripts de inicialização e binários desconhecidos em C, Golang, Perl, Python e shell.
0 Comentários