Botnet Carbonato compromete servidores Docker e Kubernetes para minerar Monero
Uma botnet identificada como Carbonato está explorando servidores Docker e ambientes Kubernetes expostos à internet para instalar programas de mineração de criptomoedas. O objetivo é usar, sem autorização, a capacidade computacional de máquinas Linux para produzir Monero (XMR) e gerar ganhos para os responsáveis pela operação.
A campanha se aproveita principalmente de configurações inadequadas e serviços administrativos acessíveis externamente. Entre os alvos estão APIs do Docker sem autenticação suficiente e clusters Kubernetes com controles de acesso frágeis. Nessas condições, os invasores podem obter acesso aos recursos de containerização e executar atividades maliciosas.
No caso do Docker, uma API exposta pode permitir que os criminosos criem containers com conteúdo nocivo e executem comandos no sistema hospedeiro. Em vez de depender necessariamente de uma falha específica no software, a abordagem abusa de funcionalidades legítimas da plataforma que ficaram acessíveis a pessoas não autorizadas.
Após invadir o ambiente, os operadores utilizam scripts para preparar o servidor e instalar os componentes necessários. Um dos principais é o minerador de Monero, que consome processador para realizar cálculos associados à mineração. Como a atividade ocorre sem o conhecimento do proprietário, o custo aparece na forma de uso excessivo de recursos, lentidão e possível aumento das despesas de infraestrutura.
A Carbonato não se limita a explorar uma máquina isolada. Os equipamentos comprometidos também podem ser usados para localizar outros servidores Docker e Kubernetes expostos. Dessa maneira, a botnet amplia sua presença e incorpora novos sistemas à rede controlada pelos invasores.
Em ambientes Kubernetes, o ataque depende de configurações que permitam acesso indevido ao cluster ou a seus recursos. Se conseguirem permissões suficientes, os criminosos podem criar workloads maliciosos e aproveitar a capacidade computacional disponível para mineração. Um cluster comprometido pode afetar mais do que um único servidor, especialmente quando reúne diversos serviços e cargas de trabalho.
Os operadores também recorrem a medidas para manter a atividade e dificultar sua interrupção. Entre as ações descritas estão alterações em processos e componentes do Linux e tentativas de preservar os workloads instalados. Por isso, remover apenas o minerador aparente pode não ser suficiente: é importante investigar como ocorreu a invasão e verificar se outros mecanismos de persistência continuam ativos.
O impacto vai além da queda de desempenho causada pela mineração. Um invasor com acesso ao host ou ao cluster pode alcançar aplicações, credenciais, segredos e outros recursos disponíveis naquele ambiente. A extensão do risco depende das permissões concedidas e da separação entre os serviços, mas uma configuração insegura pode abrir caminho para consequências mais amplas do que o consumo clandestino de CPU.
Como reduzir o risco de comprometimento
A primeira medida é impedir que APIs do Docker e interfaces administrativas do Kubernetes fiquem abertas ao público. Quando o acesso remoto for necessário, ele deve ser limitado a redes e endereços confiáveis, com autenticação adequada e controles que reduzam a possibilidade de uso por terceiros.
Também é importante revisar as permissões atribuídas a usuários, serviços e workloads. O princípio do menor privilégio ajuda a evitar que uma credencial ou componente comprometido tenha liberdade para criar containers, alterar configurações ou acessar recursos que não são necessários para sua função.
Administradores devem acompanhar mudanças inesperadas no ambiente, como a criação de containers ou workloads desconhecidos, processos com consumo elevado de CPU e atividade incomum nos servidores. A observação contínua desses sinais pode ajudar a identificar uma invasão antes que ela se espalhe para outros sistemas.
Em caso de suspeita, a resposta deve incluir a análise do host e do cluster, a identificação dos componentes instalados e a revisão das credenciais que poderiam ter sido expostas. Depois de conter a atividade, é necessário corrigir as configurações que permitiram o acesso e avaliar se aplicações, segredos ou outros recursos também foram afetados.
A campanha Carbonato evidencia que Docker e Kubernetes, embora sejam ferramentas legítimas e amplamente usadas em ambientes corporativos, podem se tornar uma porta de entrada quando são implantados sem controles apropriados. Restringir o acesso, revisar permissões e monitorar alterações são medidas essenciais para evitar que a infraestrutura de uma organização seja incorporada a uma botnet.
