CanisterWorm do TeamPCP: destruição seletiva e persistência em ambientes Kubernetes

Há dias, pesquisadores de segurança revelaram uma campanha que mistura técnicas de movimento lateral em ambientes cloud-native com uma carga útil deliberadamente destrutiva orientada para sistemas iranianos. O achado, documentado pela assinatura Aikido, atribui a operação ao grupo conhecido como TeamPCP e a relaciona com atividades prévias que comprometeram ferramentas de código aberto e pacotes NPM sob o nome informal "CanisterWorm".

A ameaça combina duas faces: Em ambientes Kubernetes se aproveita de mecanismos nativos para se espalhar e persistir; fora de Kubernetes, ativa um mecanismo de remoção maciça que pode deixar máquinas inserviáveis se detectar certas pistas do sistema.

Segundo a análise técnica, o malware primeiro tenta determinar se a equipe corresponde ao Irã revisando a configuração de fuso horário e regional. Se detectar esses sinais e existir Kubernetes na máquina, ele exibe um DaemonSet dentro do espaço de sistema que monta o sistema de arquivos do host e arranca contêineres privilegiados. Cada um desses contentores executa uma imagem mínima (Alpine) com um binário que apaga as entradas principais do disco do host e força um reinício, uma manobra que, na prática, pode deixar nodos e aplicações irreparáveis.

Em contrapartida, quando o sistema não se identifica como iraniano, mas tem Kubernetes, a mesma infra-estrutura de propagação é reutilizada para instalar um componente persistente: um backdoor escrito em Python que se deixa no sistema de ficheiros e se registra como um serviço systemd para sobreviver a reinícios. Esta dupla estratégia — aborrar onde se considera “objectivo” e estabelecer porta traseira onde não – confirma o caráter seletivo e orientado da campanha.

O ator não se limita a Kubernetes: Aikido também documenta variantes que prescindem do movimento lateral baseado em DaemonSets e recorrem a mecanismos mais tradicionais de propagação por SSH. Nesses casos, o malware examina registros de autenticação em busca de credenciais válidas, reutiliza chaves privadas comprometidas e estabelece conexões SSH salientes com opções que evitam verificações de impressão do host (por exemplo, usando StrictHostKeyChecking=no). Outro canal de expansão identificado é o uso de APIs do Docker expostas (normalmente o porto 2375 sem TLS), que permitem arrancar contêineres privilegiados e montar o host como volume, o que reproduz o efeito destrutivo fora do ecossistema Kubernetes.

Há indicadores concretos que convém vigiar: entre eles, atividade na rede saliente para a infraestrutura de comando e controle já associada a CanisterWorm, o aparecimento de DaemonSets com nomes suspeitos como "Host-provisioner-iran" ou "host-provisioner-std" no namespace kube-system, contêineres Alpine marcados como "kamikaze", arquivos temporários deixados em rotas tipo /tmp/pglog e conexões a APIs Docker no porto 2375 a hosts da subred local. Aikido também aponta para um canister específico usado como C2; seu relatório oferece mais detalhes técnicos e artefatos IOCs para equipes de resposta: Aikido.

Para contextualizar o que aproveita esta campanha, convém lembrar como funcionam alguns elementos chave de Kubernetes e Docker. Os DaemonSets são objetos de Kubernetes que garantem que um pod seja executado em cada nó, pelo que, nas mãos de um atacante com privilégios, são uma forma eficaz de executar código em todos os hosts de um cluster; a documentação oficial explica seu desenho e riscos: DaemonSets na documentação de Kubernetes. Por outro lado, o uso de volumes hostPath para montar o sistema de arquivos do host em um recipiente permite ao processo dentro do recipiente manipular diretamente arquivos do sistema: hostPath em Kubernetes.

Do lado de contêineres e runtimes, expor a API do Docker sem autenticação (habitualmente através do porto 2375) é uma prática conhecida e perigosa: essa API permite gerenciar contêineres e montar o host da rede se não estiver protegida. Os guias oficiais do Docker incluem recomendações de segurança para mitigar esses cenários: segurança do motor Docker.

O que podem fazer equipes e administradores agora mesmo? Em primeiro lugar, auditar permissões e acessos a nível de cluster: revisar quem pode criar DaemonSets ou modificar o namespace kube-system, e aplicar controles RBAC rigorosos para evitar que processos não autorizados criem objetos com privilégios elevados. É fundamental bloquear o acesso não autenticado à API do runtime de contêineres e segmentar a rede para que um host comprometido não possa invocar APIs administrativas na subred. Monitorizar a criação de recursos invulgares (nomes, imagens Alpine executadas com privilégios, mounts de /) e estabelecer alertas sobre conexões SSH salientes com opções que desactivam verificações de impressão são contramedidas práticas e de alto impacto.

Além disso, as práticas básicas de higiene permanecem essenciais: rotatividade e proteção de chaves privadas, desativação do sudo sem senha, aplicação de atualizações e adesivos às ferramentas da cadeia de abastecimento que são usadas (se o ator já demonstrou interesse em projetos de código aberto, proteger esses fluxos é crítico) e armazenar registros de auditoria fora do alcance de nós individuais para facilitar a pesquisa pós-compromissível.

Esta campanha é um lembrete de que a segurança em ambientes cloud-native já não é apenas uma questão de aplicar adesivos: é necessário projetar defesas que tenham em conta mecanismos de orquestração, a exposição de APIs de runtime e a possibilidade de um adversário combinar técnicas de persistência e destruição. Para quem quiser aprofundar a análise técnica e os indicadores, o relatório de Aikido oferece uma desagregação detalhada: ler o relatório do Aikido.

Se você gerencia infraestrutura crítica ou clusters Kubernetes, atua com prioridade: revisa as regras RBAC, fecha e certifique-se de que as APIs do Docker não estão acessíveis sem proteção, vigia logs e alertas por comportamento anormais, e prepara um plano de resposta que contemple a possibilidade de remoção maciça de dados. A combinação de intenção política e técnicas automatizadas que mostra esta campanha eleva o risco e exige uma resposta coordenada entre administradores, equipamentos de segurança e prestadores de serviços.