Pesquisa da Universidade Técnica Checa em Praga revelou que 99,23% das sessões SSH autenticadas em honeypots são não-interativas: o atacante entra, executa um único comando em menos de um segundo e desconecta. Apenas 0,10% abrem um shell de verdade. A imagem do hacker digitando comandos em um terminal não existe mais — a esmagadora maioria é automática, invisível e impossível de capturar com ferramentas que medem engajamento.
Resumo e pontos-chave
- 99,23% dos 177.622 ataques SSH analisados foram não-interativos (um comando por sessão, abaixo de 1 segundo).
- Apenas 0,10% abriram um shell interativo — o cenário que honeypots tradicionais foram projetados para estudar.
- Padrão dominante desde 2018: em outubro de 2024, a fatia não-interativa saltou para 97,4% em um único mês.
- Atacantes testam se o servidor é honeypot e extraem informações de reconhecimento antes de prosseguir.
- Defesas baseadas em sessão longa ou contagem de comandos perdem 99% da atividade real.
A realidade dos ataques SSH
Quem administra um servidor com SSH exposto à internet vê o mesmo padrão nos logs, todos os dias: uma corrente constante de scanners automatizados tentando login, hora após hora, a partir de endereços espalhados pelo mundo. A imagem comum do que vem depois — um invasor caindo em um shell, explorando o sistema, digitando comandos — não resiste aos dados. A realidade registrada em onze honeypots de pesquisa parece quase nada com isso.
O estudo, conduzido por pesquisadores da Universidade Técnica Checa em Praga e publicado no arXiv em 26 de junho de 2026 sob o título “Ghost Without Shell: Measuring Non-Interactive SSH Attacks on Honeypots”, revela um comportamento que derruba premissas fundamentais sobre como ataques SSH funcionam na prática.
Como os honeypots capturaram tudo
Onze honeypots SSH rodaram em servidores na nuvem em Frankfurt, Alemanha, durante quinze dias no final de maio e início de junho de 2026. Juntos, registraram 177.622 sessões autenticadas — todas de atacantes que conseguiram passar pelo login. A ferramenta usada foi uma versão modificada do AdvancedShelLM, um honeypot de código aberto que utiliza modelos de linguagem (LLM) para gerar respostas de shell realistas.
Para validar os resultados além do próprio ambiente, os pesquisadores compararam os dados com um conjunto independente da CZ.NIC, operadora de um serviço de honeypot baseado em milhares de sensores Cowrie. Esse conjunto continha mais de 250 mil sessões autenticadas na mesma janela temporal. Entre as sessões que carregavam pelo menos um comando, 92,67% carregavam exatamente um. O padrão se confirmou em hardware operado por uma entidade diferente.
O que os atacantes executam
Uma sessão não-interativa funciona de maneira específica: o cliente autentica, envia um único comando através de uma requisição SSH exec, o servidor fecha o canal sem alocar um terminal, e a troca inteira termina em menos de um segundo — mais rápido do que uma pessoa consegue digitar. São scanners e scripts de exploração rodando em velocidade de máquina, entrando para confirmar um fato sobre o host e seguindo em frente.
Os dez comandos não-interativos mais comuns cobriram 41,59% de todo o tráfego, e a maioria deles coleta informações básicas sobre a máquina. Variantes de uname, que reportam o sistema operacional e o kernel, lideraram a lista. Outros perguntaram pelo número de processadores, usuário logado, hardware gráfico e tempo de atividade do sistema. Esses comandos coletam informações que dizem a uma campanha automatizada se a máquina merece uma segunda olhada.
| Tipo de sessão SSH | Porcentagem do total | Característica |
|---|---|---|
| Não-interativa (1 comando) | 99,23% | Login, comando único, desconexão em < 1s |
| Shell interativo | 0,10% | Terminal alocado, múltiplos comandos |
| Transferência de arquivos | 0,67% | SCP/SFTP após autenticação |
Atacantes testam se você é armadilha
Um grupo menor de comandos tinha um trabalho diferente: testar se a coisa que responde executa comandos de verdade. A equipe registrou 2.178 sessões desse tipo. Uma campanha enviou uma string codificada em Base64 e a decodificou — uma operação que retorna uma resposta conhecida em um sistema funcional. Outras pediram aritmética simples, despejaram o conteúdo de um binário, ou gravaram um arquivo e o leram de volta.
Isso pesa contra a classe mais nova de honeypots construídos com modelos de linguagem. Um modelo pode produzir uma saída de shell que parece plausível e está errada. Um scanner que confere a matemática, decodifica a string ou confirma que um arquivo persiste pega a diferença em um único comando. O sucesso desses honeypots depende de sobreviver a essa verificação.
O reverso também apareceu. Algumas sessões procuraram sinais de honeypots conhecidos — listando processos por Cowrie ou kippo e testando se arquivos de sistema eram graváveis. Os números foram pequenos, e os autores tratam esses dados com cautela, mas a tendência é clara: atacantes automatizados já incluem detecção de armadilhas em seu repertório padrão.
A virada que ninguém notou
O registro histórico aponta para um comportamento consolidado. O arquivo da CZ.NIC remonta a 2017 e contém mais de 400 milhões de sessões. O tráfego não-interativo é majoritário desde cerca de 2018. Um salto abrupto ocorreu em outubro de 2024, quando a fatia não-interativa subiu para 97,4% em um único mês — um aumento de mais de dezessete pontos, acompanhado por um pico no volume total.
Isso significa que, durante anos, ferramentas de segurança que avaliam ameaças SSH com base em tempo de sessão e número de comandos estiveram medindo uma fração minúscula da atividade real. Um honeypot que só oferece shell interativo e recusa requisições não-interativas registra uma versão do comportamento do atacante que o próprio honeypot criou — não a realidade.
Como proteger seus servidores
As tentativas de login que enchem seus logs são majoritariamente triagem. Um cliente automatizado confirma que o host é real, arquiva para depois e sai. O valor real está em reconhecer esse padrão e agrupar o ruído em campanhas, para que mil toques de um segundo se resolvam nas poucas operações por trás deles. Para administradores brasileiros, a pesquisa traz implicações concretas:
- Desative login por senha: com 177 mil sessões automatizadas em quinze dias, senhas fracas caem em minutos. Use chaves SSH exclusivamente.
- Monitore sessões não-interativas: sua ferramenta de detecção precisa registrar comandos exec isolados, não apenas shells persistentes.
- Implemente rate limiting: ataques não-interativos dependem de velocidade. Limite conexões por IP e por minuto.
- Agrupe campanhas, não incidentes: mil sessões de um segundo podem ser uma única operação de reconhecimento. Ferramentas como um SOC bem configurado devem correlacionar padrões, não contar alertas individuais.
- Reavalie seus honeypots: se sua armadilha só mede sessões longas, você está perdendo 99% do tráfego autenticado. Considere honeypots que servem ambos os tipos de sessão.
A pesquisa também trouxe um alívio temporário: os pesquisadores filtraram todas as sessões em busca de strings de prompt injection e menções a nomes de modelos de IA, e não encontraram nenhuma. A preocupação com atacantes convencendo modelos de linguagem a revelar informações por engano não tem suporte nestes dados — pelo menos por enquanto.
Para quem acompanha nossa análise sobre como responder a incidentes nas primeiras horas após um ataque, a lição da pesquisa é clara: a ameaça SSH não é um invasor paciente explorando seu servidor — é um exército de bots de um segundo cada, mapeando infraestruturas inteiras antes que qualquer alarme dispare. Sua defesa precisa ser tão rápida quanto eles.
Referências
- arXiv — Ghost Without Shell: Measuring Non-Interactive SSH Attacks on Honeypots (Valeros, Sladić, Garcia — Universidade Técnica Checa em Praga)
- Help Net Security — Non-interactive SSH attacks dominate after login
- CyberSec Research — AdvancedShelLM e publicações de segurança (listing de papers)
- MITRE ATT&CK — Lateral Movement (TA0008): Técnicas de SSH em movimento lateral