Campanha Carbonato explora Docker exposto e exibe Hermes Agent controlado pelo Telegram

Pesquisadores em cibersegurança revelaram uma campanha ativa que usa um novo botnet apodado Carbonato para comprometer servidores com Docker exposto sem autenticação e implantar um agente de inteligência artificial de código aberto chamado Hermes Agent. De acordo com o relatório técnico que divulgaram as assinaturas que investigaram a operação, o impacto principal é que os atacantes transformam hosts comprometidos em nodos controláveis de forma remota que obedecem instruções enviadas pelo Telegram e priorizam a busca de chaves de APIs de IA e credenciais.

Os fatos confirmados pelos pesquisadores são os seguintes: Carbonato explora demônios Docker acessíveis pela rede através do porto não seguro 2375, lança contêineres com privilégios sobre os hosts afetados para executar comandos no sistema subjacente, estabelece persistência por tarefas programadas e scripts watchdog, e lança um túnel SSH inverso para um relevo exterior. Em cada máquina comprometida se instala Hermes Agent sem modificar o binário, mas se sobresscreve seu arquivo de personalidade SOUL.md com um prompt que ordena ao agente agir como um "operador sênior" sem restrições éticas e responder a ordens recebidas pelo Telegram. Além disso, a operação tem capacidades semelhantes a um verme: cada host examina redes adjacentes a cada cinco minutos para localizar novos demônios Docker sem autenticação e propagar-se. Esses achados foram identificados, segundo os relatos, a partir de dados expostos em um registro Docker sem autenticação que estava público desde maio de 2026.

Tecnicamente, a cadeia de compromisso descrita combina técnicas de explosão de superfície e automação. O vetor inicial é o acesso ao socket do demônio Docker (exposto por exemplo no porto 2375), que permite ao atacante criar contentores privilegiados. Dentro desses contentores é executado um programa que levanta um túnel SSH inverso para uma substituição controlada (investigadores anotam infraestrutura na Costa Rica como ponto intermediário), instala um servidor SSH com a chave pública do operador para acesso persistente e notifica o novo nó através do Telegram. Hermes Agent, configurado com o prompt malicioso, recebe tarefas via Telegram, reenvia essas instruções a um modelo LLM ou a uma passarela LLM, e converte as saídas do modelo em comandos de terminal que o recipiente executa no host comprometido. Os atacantes também teriam troceado ou incluído no registo dados de outra campanha —aplicações de carteira cripto troceadas — o que sugere a partilha de infra-estruturas para múltiplas operações.

O que está confirmado: a mecânica básica de infecção (Docker exposto → contentor privilegiado → persistência → implantação de Hermes Agent) e o uso do Telegram como canal de controle. As evidências técnicas documentadas incluem os artefatos do túnel SSH inverso, cron jobs e watchdogs que relançam o implant se removido, e a modificação do arquivo SOUL.md do agente para forçar comportamento ofensivo. Também está confirmado que a operação prioriza a coleta de chaves de API e credenciais.

O que é estimativa ou ainda não verificado: a atribuição completa do ator que opera Carbonato. Os pesquisadores apontam indícios de idioma, fusos horários e infraestrutura que apontam para operadores localizados na Costa Rica, mas não há vinculação pública e conclusiva a um grupo conhecido. O alcance total das infecções na Internet (cantidade de máquinas comprometidas) e a lista completa de objectivos afectados não estão totalmente verificados.

Este caso se encaixa numa tendência maior: operadores que combinam agentes de IA com implantes tradicionais para automatizar o ciclo de ataque. Relatórios anteriores mencionam usos de Hermes Agent e ferramentas afins em campanhas que automatizam reconhecimento, exploração e exfiltração sem supervisão humana constante. Além disso, foram identificados implantes que consultam múltiplos fornecedores de LLM para decidir ações pós-compromissiva, o que demonstra a elevação do papel dos modelos de linguagem na cadeia de comando maliciosa.

Para organizações e administradores de sistemas, as implicações são concretas e urgentes. Um servidor do Docker exposto sem autenticação é equivalente a dar acesso root remoto: permite executar contentores com privilégios e comprometer o host. A combinação com agentes IA adiciona velocidade, criatividade e persistência às campanhas maliciosas, porque o atacante pode orquestrar múltiplas tarefas de coleta de segredos, latência e pivotagem com pouca intervenção humana.

Acções práticas imediatas: primeiro, identificar e fechar qualquer daemon Docker exposto a redes públicas. Não exponha o socket do servidor na rede; configure-o para localhost ou use o TLS e autenticação. Para diretrizes públicas sobre como proteger o demônio Docker, revisite a documentação oficial de Docker e boas práticas comunitárias como o guia de OWASP para Docker: https://docs.docker.com/engine/security/ e https://cheatsheetseries.owasp.org/cheatsheets/Docker_Security_Cheat_Sheet.html.

Segundo, investigue indicadores de compromisso em hosts que executam o Docker: procure contentores lançados com a bandeira --privileged, presença de servidores SSH recém instalados, processos autossh ou conexões SSH salientes incomuns (túneles inversos), e entradas em cron ou scripts watchdog que relancen binários. Audite autorizações SSH (authorized_keys) e verifique imagens de contentor e registos para identificar cargas novas ou imagens não assinadas.

Terceiro, rote e audite chaves e credenciais que poderiam ter sido exfiltradas, em especial chaves de APIs de IA e tokens de serviço. Configure alertas para atividade incomum para APIs de mensagens (Telegram) ou para fornecedores de LLM e limite, por política, o acesso de serviços a chaves sensíveis.

Quarto, implemente controles de rede: segmentação, listas de controle de acesso que impeçam que hosts de produção contactem livremente a Internet ou relays externos, inspeção de tráfego saliente e bloqueio de portos que não sejam necessários (como 2375). Considere políticas de imagem assinada e digitalização de imagens em registries privados com autenticação R/O.

Por último, se suspeitar de compromisso, consulte evidências (logs, imagens de contentor, processos em memória) e considere a desconexão controlada para evitar a propagação. Notifique as equipas de resposta a incidentes e, se for caso disso, as autoridades competentes. A automação com IA reduz a janela de resposta viável: a contenção deve ser mais rápida e acompanhada de medidas de resiliência e de rotação de segredos.

Este caso sublinha que a segurança dos contentores e a protecção das credenciais da IA são agora vectores críticos. Proteger o demônio Docker, garantir registries privados e auditar o uso de chaves são medidas concretas que reduzem o risco de ferramentas legítimas de automação, como Hermes Agent, serem reutilizadas para operações maliciosas.