TeamPCP lança campanha com malware destrutivo mirando sistemas iranianos
Pesquisadores da Aikido identificaram uma nova campanha do grupo de ameaça TeamPCP direcionada a clusters Kubernetes e a servidores Linux, com um diferencial alarmante: um payload explicitamente desenhado para destruir máquinas configuradas para o Irã. A mesma operação também instala backdoors em ambientes de outros países, ampliando o alcance da ameaça e criando uma infraestrutura persistente de ataque.
O grupo não é desconhecido no ecossistema de segurança. Ele é apontado como o responsável pelo recente ataque à cadeia de suprimentos envolvendo o scanner de vulnerabilidades Trivy, além da campanha baseada em pacotes npm conhecida como CanisterWorm, iniciada em 20 de março. A investigação atual mostra que, embora a infraestrutura de comando e controle e partes do código de backdoor sejam reaproveitadas, a nova onda de ataques introduz um componente claramente destrutivo contra alvos iranianos.
Como funciona o ataque
O malware realiza uma checagem inicial de configuração de sistema para identificar se a máquina comprometida corresponde ao fuso horário e à localidade do Irã. Essa validação é suficiente para acionar o comportamento destrutivo, independentemente de o host rodar ou não Kubernetes. Ou seja, qualquer servidor configurado como iraniano entra na mira do componente “kamikaze” do código.
Em ambientes Kubernetes identificados como iranianos, o script malicioso cria um DaemonSet chamado `Host-provisioner-iran` dentro do namespace `kube-system`. Esse DaemonSet utiliza contêineres privilegiados com acesso ao sistema de arquivos raiz do host. Cada pod executa um contêiner Alpine batizado de “kamikaze”, cuja função é apagar todos os diretórios de nível superior do sistema de arquivos e, em seguida, forçar a reinicialização da máquina. Na prática, isso causa uma destruição quase total do sistema operacional e dos dados armazenados.
Já em clusters Kubernetes que não são classificados como iranianos, a lógica muda. Nesse cenário, o malware implanta um DaemonSet denominado `host-provisioner-std`, também com contêineres privilegiados, mas sem o módulo de destruição de dados. Em vez disso, cada pod grava um backdoor em Python diretamente no sistema de arquivos do host e o registra como um serviço systemd. Com isso, o TeamPCP garante persistência em todos os nós do cluster, criando um canal permanente para futuras operações maliciosas, espionagem, movimentação lateral ou instalação de novos payloads.
Em sistemas iranianos que não executam Kubernetes, o malware adota um método clássico e brutal: a execução do comando `rm -rf /` com a flag `–no-preserve-root`. Essa opção remove a proteção padrão do comando contra a exclusão do diretório raiz, permitindo que todos os arquivos do sistema sejam apagados, incluindo componentes críticos do sistema operacional e dados de usuários ou aplicações.
Evolução da campanha: da exploração de Kubernetes à propagação por SSH
A Aikido observou que uma versão mais recente do malware abandonou parcialmente o foco na movimentação lateral baseada exclusivamente em Kubernetes e passou a adotar um mecanismo mais amplo de propagação por SSH. O código malicioso passa a analisar logs de autenticação para identificar credenciais válidas e também tenta se aproveitar de chaves privadas roubadas em sistemas comprometidos.
Com esse recurso, o TeamPCP aumenta a capacidade de se espalhar para outros servidores dentro da mesma rede ou até mesmo para ambientes remotos, caso consiga acessar hosts expostos com SSH habilitado. Isso torna o incidente mais complexo de conter, pois o ataque deixa de depender apenas de clusters Kubernetes vulneráveis e passa a explorar a superfície de ataque tradicional de servidores Linux gerenciados via SSH.
Indicadores de comprometimento observados
Os pesquisadores destacam alguns sinais que podem indicar a presença ou a atividade do malware:
– Conexões SSH de saída partindo de hosts comprometidos, configuradas com a opção `StrictHostKeyChecking no`, o que evita a verificação de chaves de host e facilita conexões automatizadas a novos alvos.
– Conexões de saída para a API do Docker na porta 2375, especialmente quando essa API está exposta sem autenticação.
– Execução de contêineres Alpine privilegiados, disparados por meio de uma API do Docker não autenticada, com acesso direto ao sistema de arquivos do host.
A combinação desses fatores – sobretudo o uso de contêineres privilegiados, API de Docker exposta e DaemonSets suspeitos em `kube-system` – é um forte indicativo de que o ambiente pode ter sido alvo da campanha do TeamPCP.
Alvo geográfico e motivação provável
O fato de o payload destrutivo ser ativado apenas em sistemas configurados como iranianos e a opção de manter backdoors em outros países aponta para um viés geopolítico ou estratégico. Em termos práticos, o grupo parece usar a mesma campanha para dois objetivos distintos:
1. Destruir de forma direta a infraestrutura de determinadas vítimas, quando estas correspondem ao perfil de localização do Irã.
2. Construir uma base extensa de máquinas comprometidas em outros territórios, com foco em persistência, espionagem ou criação de botnets para ataques futuros.
Ainda que a pesquisa não atribua oficialmente o grupo a um Estado específico, o recorte geográfico do payload destrutivo sugere motivações que vão além do mero crime financeiro tradicional.
Riscos para ambientes em nuvem e clusters Kubernetes
A campanha expõe uma fragilidade recorrente em ambientes modernos: a combinação de Kubernetes mal configurado com APIs de Docker expostas e credenciais SSH mal gerenciadas. Em muitos casos, clusters são implantados com contêineres privilegiados por conveniência operacional, o que abre espaço para que um atacante com acesso a um único pod obtenha controle total do host.
Além disso, a falsa sensação de segurança em torno de serviços em nuvem e SaaS – muitas vezes tratados como “autoprotetivos” – pode fazer com que organizações negligenciem backups independentes e estratégias de recuperação de desastres. Num cenário em que comandos como `rm -rf / –no-preserve-root` são executados de forma automatizada, ter cópias recentes e isoladas dos dados passa a ser a diferença entre recuperar o ambiente em horas ou perder sistemas essenciais por completo.
Estratégias de mitigação e boas práticas
Para reduzir o risco de ser afetado por campanhas semelhantes, algumas medidas técnicas são fortemente recomendadas:
– Restringir o uso de contêineres privilegiados: permitir privilégios apenas quando estritamente necessário, usando políticas de segurança de pod, admission controllers e ferramentas de compliance.
– Proteger a API do Docker: nunca expor a API na porta 2375 sem autenticação; quando possível, desabilitar acesso remoto ou protegê-lo com TLS, autenticação e listas de controle de acesso.
– Endurecer o SSH: desativar autenticação por senha sempre que possível, restringir o uso de chaves, utilizar listas de hosts confiáveis, registrar e monitorar tentativas de login e uso de chaves suspeitas.
– Monitorar namespaces sensíveis: auditar o namespace `kube-system` e outros críticos em busca de DaemonSets ou deployments não autorizados, especialmente com nomes genéricos ou relacionados a “provisionamento”.
– Implementar backups independentes: garantir que os dados sejam copiados para ambientes isolados do cluster de produção, com testes regulares de restauração.
– Adotar observabilidade e resposta rápida: integrar logs de Kubernetes, Docker e sistema operacional em uma plataforma de detecção e resposta, capaz de correlacionar eventos como criação suspeita de DaemonSets, conexões SSH de saída anômalas e uso de APIs sem autenticação.
Impacto para provedores e empresas que usam serviços gerenciados
Organizações que delegam a operação de suas infraestruturas para provedores de serviços gerenciados também precisam reavaliar o modelo de responsabilidade compartilhada. Pesquisas recentes apontam que falhas de configuração em serviços gerenciados podem abrir brechas semelhantes às exploradas pelo TeamPCP, mesmo quando a empresa acredita estar “protegida por padrão”.
É essencial exigir transparência sobre como o provedor gerencia contêineres privilegiados, controla acesso à API do Docker, trata logs de SSH e aplica políticas de segurança em clusters Kubernetes. Sem essa visibilidade, a empresa corre o risco de herdar vulnerabilidades sistêmicas, tornando-se um alvo indireto de campanhas avançadas como essa.
Consequências para o ecossistema de software e supply chain
A participação do TeamPCP em incidentes anteriores ligados a supply chain, como o ataque ao scanner Trivy e a campanha CanisterWorm via npm, mostra um padrão de atuação que vai além da simples exploração de vulnerabilidades técnicas. O grupo demonstra conhecimento profundo de como desenvolvedores e equipes de DevOps consomem ferramentas de código aberto, contêineres e bibliotecas de terceiros.
Isso reforça a necessidade de:
– Auditar dependências e pacotes utilizados em pipelines de CI/CD.
– Verificar a integridade de imagens de contêiner.
– Monitorar alterações suspeitas em componentes amplamente utilizados em ambientes de nuvem.
Quando um atacante consegue inserir código malicioso em ferramentas ou bibliotecas populares, o alcance da campanha cresce de forma exponencial, afetando desde pequenas startups até grandes operadores de infraestrutura crítica.
O que esperar dos próximos movimentos de grupos como o TeamPCP
A tendência observada na campanha atual indica que grupos avançados continuarão combinando elementos de destruição seletiva com instalação de backdoors em larga escala. De um lado, ataques claramente destrutivos, ativados apenas em alvos específicos; de outro, a criação silenciosa de redes de máquinas comprometidas em múltiplos países.
Para as equipes de segurança, isso significa que:
– Focar apenas em bloquear ransomware tradicional ou ataques de criptomineradores não é suficiente.
– É preciso assumir que backdoors silenciosos possam estar sendo instalados em segundo plano, mesmo em ambientes sem sinais óbvios de dano.
– A detecção de atividades sutis – como a criação de DaemonSets suspeitos, alteração de serviços systemd e conexões SSH atípicas – ganha importância equivalente à de bloquear cargas úteis mais vistosas.
Conclusão: destruição seletiva e backdoor global
A campanha do TeamPCP descrita pelos pesquisadores da Aikido combina três elementos que a tornam especialmente preocupante: um payload destrutivo direcionado a sistemas associados ao Irã, a instalação sistemática de backdoors em outros países e a capacidade de se propagar tanto via Kubernetes quanto por SSH tradicional.
Esse tipo de operação reforça a urgência de fortalecer configurações de Kubernetes, proteger APIs de containers, endurecer o uso de SSH e tratar backup e recuperação como pilares centrais da estratégia de cibersegurança. Em um cenário em que um único script pode tanto apagar completamente um servidor quanto transformá-lo em um nó silencioso de uma infraestrutura maliciosa global, a postura de defesa precisa ser contínua, estruturada e orientada por inteligência de ameaças atualizada.