Honeypot contra Abelhas: Análise Profunda de um Sistema de Monitoramento

Há algumas semanas, um vídeo cativante sobre a análise de eventos em um honeypot T-Pot chamou a atenção pela sua infografia elegante, relatórios analíticos e profundidade na análise de dados. Inspirado por essa demonstração de ciberconfronto, surgiu o desejo de realizar uma análise semelhante do mercado de varredura de rede, com uma condição crucial: o país hospedeiro deveria ser a Rússia. Inicialmente, a ideia era utilizar uma aplicação em Rust como MVP (Minimum Viable Product), mas essa abordagem foi rapidamente abandonada. A tarefa de reescrever um conjunto complexo de honeypots, com diferentes níveis de autonomia, utilizando apenas a capacidade de processamento de um modelo de linguagem, mostrou-se pouco atraente. Em resumo, o ciclo do projeto evoluiu de um observador de segurança em Rust, que coletava eventos e os exibia em um dashboard com gráficos interativos, para um conjunto combinado de armadilhas-sensores que não sobrecarregariam um VPS modesto. A estratégia passou a ser o carregamento gradual dos sensores no VPS, com verificações periódicas da capacidade restante após 24 horas de operação, e o desenvolvimento de um dashboard visualmente atraente. Embora a criação de um dashboard próprio seja uma opção, a configuração paralela de Elasticsearch e Kibana foi escolhida pela sua clareza, facilidade de implantação e conveniência na edição.

Por que não o T-Pot? Embora o T-Pot seja um produto pronto e de código aberto, excelente em muitos aspectos, ele apresenta uma desvantagem significativa: seus requisitos de sistema excedem as especificações dos servidores mais baratos disponíveis na RuVDS, tornando-o inadequado para o projeto. Assim, a primeira etapa foi a aquisição de um VPS na RuVDS, com um custo aproximado de 1700 Rublos. A segunda etapa envolveu a implantação dos sensores, com todas as ações sendo executadas sob a supervisão do autor, auxiliado pelo Codex GPT-5.5. O primeiro sensor a ser instalado foi o Cowrie, que imediatamente recebeu o tráfego na porta 22. A porta administrativa foi realocada para um segmento de gerenciamento privado separado, pois expor a única linha de comunicação e configurações do sensor à atividade maliciosa seria uma falha de segurança grave. Isso resultou em um fluxo imediato de logins, impressões digitais (fingerprints) e tentativas de escalonamento de privilégios, mas essas tentativas não ultrapassaram o próprio sensor, limitando o tempo de permanência dos bots na porta 22. Em seguida, foi adicionado o Dionaea, um componente crucial que expandiu o perfil do honeypot para incluir SMB, MSSQL e SIP, e, mais importante, permitiu o registro de amostras de malware enviadas pelos scanners. Foi necessário um esforço adicional para instruir o Codex sobre o processo detalhado de transporte seguro de amostras infectadas para um quarentena local no host. Posteriormente, foram integrados o Redis, o Conpot para a superfície ICS (com a hipótese de que a superfície industrial seria mais frequentemente atacada), uma isca web com uma legenda sintética e o Suricata como camada de Network Security Monitoring (NSM). Paralelamente, a camada analítica foi desenvolvida e hospedada separadamente. Inicialmente, um dashboard HTML simples foi suficiente, mas rapidamente se tornou longo e ilegível. Por isso, foram configurados Elasticsearch/Kibana locais para análise de práticas de escaneamento. O dashboard HTML permaneceu como um relatório rápido e legível, enquanto o Kibana serviu como um sistema de pesquisa aprofundada.

A arquitetura resultante consiste em um VPS com Cowrie, Dionaea, honeypot Redis, Conpot, Suricata e a isca web. O host abriga o pipeline de pull, normalização, GeoIP/ASN, verificação de hashes no VirusTotal (VT) e um quarentena para análise local (sem execução ou envio para serviços externos), juntamente com o dashboard HTML e Elasticsearch/Kibana. Essa abordagem resolve dois problemas principais: o VPS não se torna um sistema sobrecarregado como o T-Pot, e a lentidão na análise ou falhas no Kibana no host não afetam os sensores, permitindo que o VPS continue coletando eventos. No momento da atualização final, a vitrine local exibe 4.018.280 eventos do Suricata, 1.426.846 do Dionaea, 429.086 do Cowrie, 1.045 do honeypot Redis, 201 do Conpot, 9 da isca web e 315 artefatos. No Elasticsearch local, há 4.453.773 documentos no índice honeynet-events-local, 172 em honeynet-samples-local, 67 em honeynet-summary-local e 315 em honeynet-artifacts-local. É evidente que o Suricata gera o maior volume de dados, mas nem todos os 4 milhões de eventos são igualmente importantes. Uma parte significativa dos dados NSM consiste em tráfego de conexões, "anomalias de transporte" e eventos contextuais. Portanto, a análise separou o "ruído de transporte" dos "alertas significativos", com uma classificação mais detalhada, incluindo family_event, payload_pattern, network_context e attack_detail. A análise agregada revela que as anomalias de transporte do Suricata representam a maior parte dos eventos (3.197.305), seguidas por rajadas no MSSQL/1433 (2.673.234), SIP/SMB/DCERPC (937.331), alertas significativos do Suricata (820.882), sondagens de credenciais/sessão SSH (486.537), sondagens Redis (1.045), sondagens ICS (399) e sondagens de rota da isca web (9). Os portos mais visados são 1433/MSSQL (997.442 eventos), 22/SSH (486.537), 5060/SIP (116.343), 445/SMB (43.987), 3306/MySQL (15.081) e 6379/Redis (1.045). Uma análise mais detalhada do Suricata revelou diferentes cargas úteis dentro de eventos aparentemente idênticos, permitindo distinguir o ruído de transporte de ondas de protocolo específicas. O Cowrie registrou 90.562 logins bem-sucedidos no honeypot e 85.666 comandos executados, com ações típicas como verificação do sistema, tentativas de manipulação de .ssh, comandos de reconhecimento de CPU/RAM e preparação para movimentação lateral, indicando automação em massa. Duas campanhas de bot foram identificadas: uma campanha de exploração SSH no Cowrie, caracterizada por uma única fonte dominante e um comando recorrente "echo -e \x6F\x6B" (echo ok), possivelmente para verificar a persistência do shell, seguida por comandos de reconhecimento do sistema e tentativas de manipulação do ambiente SSH. As credenciais mais comuns incluíam "support/support", "admin/admin", "root/admin" e "root/root". A segunda campanha envolveu um cluster SMB/MSSQL/WannaCry-like, com domínio de tráfego 1433/MSSQL e SMB/DCERPC, anomalias de transporte/protocolo no Suricata e uploads de binários no Dionaea. O malware predominante era Win32 DLL, associado às CVEs 2017-0147 e 2017-0144, com famílias como trojan.wanna/wannacry. Isso sugere um ecossistema automatizado que ainda explora superfícies Windows/SMB com exploits antigos e ransomware.

A análise de amostras de malware é um dos aspectos mais valiosos do projeto. O objetivo não é apenas demonstrar a configuração de honeypots, mas realizar Threat Intelligence com base nos dados coletados para entender o cenário de ataques a serviços russos. A capacidade de um VPS leve capturar amostras reais de malware permitiu o desenvolvimento de um algoritmo seguro e reproduzível para lidar com o malware: o Dionaea registra os uploads, um pull local coleta o manifesto e o SHA256, as amostras são enviadas apenas para um quarentena local criptografada, apenas os SHA256 são enviados para serviços externos, e os resultados do VT são normalizados em um índice separado e exibidos no dashboard/Kibana. Até o momento, foram coletadas 172 SHA256 únicas, das quais 166 foram encontradas no VT e 163 apresentaram detecções maliciosas. A maioria das amostras (157) foi categorizada como trojan, seguida por ransomware (144). Os tipos de arquivo predominantes são Win32 DLL (150), com famílias como Wanna/WannaCry-like sendo as mais comuns, refletindo a campanha automatizada de 12 de junho. As tags incluem exploit, overlay e pedll, com 148 associadas a CVE-2017-0147 e 27 a CVE-2017-0144. A análise dos padrões de ataque sugere que o honeypot não foi um alvo específico, mas sim parte de uma varredura automatizada em busca de serviços Windows/SMB/MSSQL abertos, superfícies compatíveis com EternalBlue/WannaCry, credenciais SSH fracas, Redis desprotegido e, em menor grau, protocolos ICS. O corpus de malware indica uma infraestrutura automatizada e auto-propagável focada em servidores mal protegidos e serviços antigos e vulneráveis, em vez de um grupo direcionado. O honeypot se tornou um ponto de coleta para botnets e carregadores automatizados que visam servidores mal protegidos e serviços vulneráveis. Para o mapa de ataques, a visualização evoluiu de um mapa mundial com bolhas para um esquema de fluxo, onde os principais regiões são apresentadas em linhas fixas, com setas apontando para o sensor local. Essa abordagem, embora menos geográfica, é mais eficaz para visualização analítica, mostrando o ranking, volume e região. As regiões mais ativas incluem Europa/Ucrânia, América do Norte/EUA, Europa/Rússia, segmento privado/local, Ásia/Turquia, Europa/Andorra, Países Baixos e Alemanha. É importante notar que o GeoIP atribui a localização do ponto de saída da rede, não a do atacante, pois VPNs, proxies e máquinas comprometidas podem distorcer a imagem. A base de dados dbip-asn+city-lite.mmdb foi utilizada para a geolocalização, pois sem ela, aproximadamente 78% dos nós eram desconhecidos.

Existem algumas limitações importantes a serem consideradas. Primeiro, eventos não são sinônimos de ataques; um fluxo do Suricata e um login bem-sucedido no honeypot têm significados diferentes. Portanto, a comunicação se refere a "eventos registrados" em vez de "ataques". Segundo, o GeoIP é uma camada aproximada, útil para visualização, mas não prova a localização real do operador. Terceiro, a análise do VT é uma reputação de hash, não uma análise completa de malware, respondendo "o que já se sabe sobre este SHA256", mas não substituindo a análise estática e dinâmica. Em resumo, o projeto não tenta ser um "T-Pot pequeno", mas sim testar os limites de um VPS limitado, movendo a análise pesada para um host externo e adicionando sensores de forma controlada. A vantagem dessa abordagem é a gerenciabilidade, permitindo identificar a carga de cada sensor, o ruído e os dados relevantes para análise. A desvantagem é a necessidade de mais engenharia manual para construir o pipeline, corrigir visualizações e controlar a cópia de dados, geolocalização e integração com o VT/Kibana. Os resultados incluem a implantação de um contorno VPS multissensor (SSH, upload de malware, Redis, ICS, isca web, NSM), um contorno de análise local com dashboard HTML e Elasticsearch/Kibana, um algoritmo seguro para análise primária de malware (quarentena criptografada + referência VT SHA256), 172 SHA256 únicas coletadas (163 com detecções no VT), confirmação de interesse contínuo em MSSQL/1433, SSH/22, SIP, SMB/DCERPC e Redis, cenários de comando reais no Cowrie, contexto NSM amplo do Suricata com normalização detalhada, e um corpus de malware indicando infraestrutura automatizada em torno de amostras SMB/MSSQL/WannaCry-like. A principal conclusão é que mesmo um VPS barato, configurado como um conjunto de sensores cuidadosos com análise externa, pode se tornar um nó de observação valioso. O mais valioso é a combinação de uma ampla superfície de ataque, coleta segura de amostras, normalização, enriquecimento e visualização, utilizável para relatórios analíticos reproduzíveis. O autor agradece a leitura e oferece o código-fonte para quem desejar replicar o sistema.