TeamPCP lança campanha com malware destrutivo focado em sistemas iranianos
Pesquisadores de segurança da Aikido identificaram uma nova operação do grupo TeamPCP direcionada especificamente a clusters Kubernetes, mas com um diferencial alarmante: um script malicioso capaz de literalmente inutilizar máquinas configuradas para operar no Irã. A mesma quadrilha já havia ganhado notoriedade recentemente por ataques à cadeia de suprimentos envolvendo o scanner Trivy e por uma campanha maliciosa baseada em pacotes npm, batizada de CanisterWorm, iniciada em 20 de março.
Nesta nova onda, os criminosos reaproveitam elementos já vistos em incidentes anteriores – como o mesmo canister ICP, a infraestrutura de comando e controle (C2) e o código de backdoor -, mas adicionam um payload explicitamente destrutivo, desenhado para afetar apenas sistemas associados ao Irã. Essa característica reforça a hipótese de motivações políticas ou geopolíticas por trás da campanha, já que o foco não é apenas roubo de dados, mas a destruição total de ativos.
Como o malware identifica e destrói sistemas iranianos
O código malicioso foi programado para verificar dois parâmetros principais: fuso horário e localidade. Sempre que uma máquina corresponde ao fuso horário e à região do Irã, o malware ativa uma rotina destrutiva, mesmo que o ambiente não esteja rodando Kubernetes. Ou seja, qualquer sistema que atenda a essas duas condições torna-se um alvo potencial de “destruição total”.
Em ambientes Kubernetes iranianos, o script cria um DaemonSet chamado “Host-provisioner-iran” dentro do namespace “kube-system”. Esse DaemonSet utiliza contêineres privilegiados que montam o sistema de arquivos raiz do host, o que dá ao atacante controle completo sobre o sistema operacional subjacente. Cada pod executa um contêiner Alpine batizado de “kamikaze”, cuja função é apagar todos os diretórios de nível superior do filesystem e, em seguida, forçar a reinicialização da máquina. Na prática, isso deixa o sistema inutilizável e exige, muitas vezes, reinstalação completa.
Backdoor em vez de destruição em outros países
Quando o malware encontra um ambiente Kubernetes que não se enquadra na configuração de fuso horário e localidade do Irã, o comportamento é diferente. Em vez de destruir os dados, o código instala um backdoor para manter o acesso persistente ao ambiente comprometido.
Nesses casos, o DaemonSet criado recebe o nome de “host-provisioner-std” e também é composto por contêineres privilegiados. Cada pod escreve um backdoor em Python diretamente no sistema de arquivos do host e o registra como um serviço systemd. A partir daí, o atacante garante persistência mesmo após reinicializações, consolidando o controle sobre todos os nós do cluster. Isso transforma os servidores comprometidos em pontos de apoio para futuras ações, como exfiltração de dados, movimentação lateral ou uso em novas campanhas.
Ataques a sistemas iranianos sem Kubernetes
O caráter destrutivo da campanha não se restringe a clusters Kubernetes. Em máquinas iranianas que não executam Kubernetes, o malware parte para uma abordagem ainda mais direta: a execução do comando `rm -rf /` com a flag `–no-preserve-root`. Esse comando força a exclusão recursiva de todos os arquivos do sistema, incluindo componentes críticos do próprio sistema operacional, sem a proteção padrão que normalmente impediria a remoção do diretório raiz.
O resultado é um colapso completo da máquina atacada, exigindo, na maioria dos casos, reinstalação do sistema e restauração de dados a partir de backups – se existirem. Em ambientes empresariais sem uma estratégia robusta de backup e recuperação, esse tipo de ataque pode resultar em perda definitiva de informações e paralisação de serviços essenciais.
Evolução da campanha: de Kubernetes para propagação via SSH
A Aikido observou ainda que versões mais recentes do malware passaram por uma evolução significativa. Em vez de depender exclusivamente da movimentação lateral baseada em Kubernetes, o TeamPCP passou a investir em propagação via SSH. Os operadores analisam logs de autenticação em busca de credenciais válidas e também reutilizam chaves privadas roubadas, ampliando rapidamente o alcance da infecção.
Uma vez em posse de credenciais ou chaves, o malware tenta conexões SSH de saída a partir dos hosts comprometidos, muitas vezes com a opção `StrictHostKeyChecking no`. Esse parâmetro desativa a verificação de integridade da chave do host remoto, facilitando conexões automatizadas e reduzindo a chance de o processo ser bloqueado por advertências de segurança locais. Essa mudança de estratégia demonstra o esforço do grupo em tornar a campanha mais furtiva e resiliente frente a melhorias de segurança em clusters Kubernetes.
Indicadores de comprometimento e sinais de alerta
Os pesquisadores destacaram alguns sinais que podem indicar a presença desse malware em um ambiente:
– Conexões SSH de saída com a opção `StrictHostKeyChecking no` partindo de servidores que normalmente não realizam esse tipo de conexão automatizada.
– Tráfego de saída para a API do Docker na porta 2375, principalmente quando exposta sem criptografia ou autenticação.
– Execução de contêineres Alpine privilegiados via API do Docker não autenticada, especialmente com nomes fora do padrão operacional da organização.
– Criação inesperada de DaemonSets com nomes como “Host-provisioner-iran” ou “host-provisioner-std” dentro do namespace “kube-system”.
A detecção precoce desses indicadores pode ser decisiva para interromper a campanha, conter a propagação e reduzir o impacto, principalmente em ambientes críticos.
Riscos específicos para infraestruturas em nuvem e Kubernetes
Ataques que exploram Kubernetes e APIs de contêineres expostas revelam uma fragilidade recorrente em organizações que adotaram nuvem e containers sem um desenho de segurança adequado. A exposição da API do Docker na porta 2375 sem autenticação, por exemplo, ainda é um problema frequente em ambientes de desenvolvimento e teste que acabam se conectando à rede corporativa ou à internet.
Além disso, o uso de DaemonSets com contêineres privilegiados é uma poderosa arma para atacantes. Ao ter acesso ao filesystem do host, um contêiner deixa de ser isolado e passa a funcionar quase como um root shell remoto no servidor físico ou virtual. Essa combinação torna ataques como o do TeamPCP especialmente perigosos para empresas que dependem de clusters Kubernetes para sustentar serviços de missão crítica.
Motivação destrutiva e contexto geopolítico
O fato de o payload destrutivo estar explicitamente limitado a sistemas que correspondem ao fuso horário e à localidade do Irã sugere uma intenção clara de dano direcionado. Diferentemente de campanhas de ransomware que buscam lucro financeiro, essa operação revela um componente de sabotagem, possivelmente conectado a disputas geopolíticas, espionagem ou conflitos regionais.
Para além do Irã, porém, a campanha demonstra a capacidade do grupo de manter acesso prolongado a outros ambientes que não entram na regra de destruição, graças à instalação de backdoors. Isso significa que organizações em outros países podem estar sendo usadas como infraestrutura auxiliar: pontos de comando, plataformas para novos ataques ou canais de exfiltração de dados sensíveis.
Boas práticas de defesa e mitigação
Diante de um cenário em que o adversário consegue tanto destruir máquinas quanto se manter de forma furtiva em ambientes não-alvos, algumas medidas se tornam fundamentais:
1. Revisão de exposição de APIs de contêineres
– Garantir que a API do Docker não esteja exposta sem autenticação.
– Utilizar TLS e mecanismos de controle de acesso rigorosos.
2. Endurecimento de clusters Kubernetes
– Restringir o uso de contêineres privilegiados ao mínimo indispensável.
– Monitorar continuamente a criação de DaemonSets e alterações em namespaces sensíveis como o “kube-system”.
– Implantar políticas de admission control que bloqueiem implantações suspeitas.
3. Gestão de credenciais e chaves SSH
– Rotacionar regularmente chaves e senhas.
– Analisar logs de autenticação em busca de padrões anômalos.
– Desabilitar o uso de `StrictHostKeyChecking no` em scripts e automações de produção.
4. Monitoramento e resposta a incidentes
– Implementar soluções de detecção de ameaças focadas em ambientes cloud-native.
– Criar playbooks específicos para incidentes em Kubernetes e Docker.
– Testar cenários de destruição de dados para validar tempos de recuperação.
Importância de backup e recuperação de desastres
Ataques com foco em destruição total, como o comandado pelo TeamPCP contra sistemas iranianos, reforçam um ponto frequentemente negligenciado: na nuvem e em ambientes SaaS, backups não são garantidos por padrão. Muitas organizações assumem que, por estarem em um provedor de nuvem ou usando serviços gerenciados, estarão automaticamente protegidas contra perda total de dados – o que não é verdade.
É essencial implementar políticas próprias de backup, com cópias imutáveis, testes recorrentes de restauração e segregação lógica entre os ambientes de produção e armazenamento de cópias. Sem essa camada, um ataque destrutivo pode não apenas derrubar sistemas, mas apagar registros de negócio, históricos operacionais e evidências necessárias para investigações posteriores.
O que as empresas devem fazer agora
Mesmo que a organização não opere no Irã, essa campanha é um alerta sobre o nível de sofisticação e agressividade que grupos como o TeamPCP já atingiram. Empresas que utilizam Kubernetes, Docker ou infraestrutura em nuvem devem:
– Revisar imediatamente configurações de exposição de serviços e APIs.
– Verificar a presença de DaemonSets estranhos e contêineres privilegiados fora do padrão.
– Auditar o uso de chaves SSH e credenciais reutilizadas entre servidores.
– Reforçar a visibilidade sobre logs e eventos em nível de containers, nós e rede.
Ao mesmo tempo, é crucial que equipes de segurança se mantenham atualizadas sobre novas variantes desse malware e sobre táticas emergentes do grupo. A combinação de payload destrutivo, ataque à cadeia de suprimentos e uso inteligente de infraestrutura cloud-native mostra que o TeamPCP está disposto a explorar todas as brechas possíveis – tanto técnicas quanto organizacionais – para alcançar seus objetivos.
Em síntese, a campanha contra sistemas iranianos não é apenas um episódio localizado, mas um sinal de que operações cibernéticas com motivação destrutiva e recorte geopolítico tendem a se tornar mais frequentes. Preparar-se agora, endurecendo ambientes e revisando processos, é a forma mais efetiva de reduzir o impacto de ataques que, como este, misturam destruição, backdoors persistentes e rápida capacidade de propagação.