TeamPCP ataca a cadeia de fornecimento de software: litellm comprometido para roubar credenciais e pivotar em Kubernetes

Uma nova onda na guerra pela cadeia de fornecimento de software volta a evidenciar o frágil que pode ser o ecossistema open source: o ator malicioso conhecido como TeamPCP conseguiu violar uma popular livraria de Python, litellm, e publicar versões com código malicioso que se propagou a ambientes de desenvolvimento e produção. Pesquisadores de segurança, entre eles Endor Labs e JFrog, documentaram como as versões 1.82.7 e 1.82.8, subidas em 24 de março de 2026, continham uma carga útil complexa desenhada para roubar credenciais, mover-se lateralmente dentro de clusters Kubernetes e estabelecer uma porta traseira persistente.

O vetor da intrusão parece estar relacionado com a integração de ferramentas de segurança nos pipelines de CI/CD: o repo público de litellm Mostra a utilização de Trivy nos seus fluxos, e essa dependência operacional teria sido explorada pelos atacantes para inserir a modificação maliciosa antes de serem publicadas as rodas (wheels) no PyPI, onde foi descarregada por projetos e ambientes de todo o tipo. As versões comprometidas já foram retiradas do repositório oficial, mas o potencial dano já estava em andamento.

Do ponto de vista técnico, a campanha emprega uma cadeia de três etapas que a torna especialmente perigosa. Primeiro, um coletor de credenciais rastreia chaves SSH, credenciais de nuvem, segredos de Kubernetes, carteiras de criptomoedas e arquivos .env. Essa informação é empacotada e enviada para um servidor de controlo e comando; de acordo com as análises, o ficheiro é chamado de "tpcp.tar.gz" e é enviado através de um pedido de HTTPS a models.litellm[.]cloud. Em paralelo, a carga inicial tenta escalar dentro de ambientes Kubernetes: se detectar um token de serviço, usa a API do cluster para enumerar nodos e implantar pods privilegiados que, por sua vez, fazem chroot no sistema de arquivos do host para instalar um dropper persistente como serviço de systemd. Finalmente, esse serviço persistente —registrado como ~/.config/sysmon/sysmon.py, o mesmo nome que apareceu em compromissos prévios relacionados com Trivy — consulta periodicamente checkmarx[.]zone/raw procurando instruções ou binários adicionais. Um detalhe curioso e frequente nestas campanhas é a presença de um "kill switch": se o URL recuperado contém o youtube[.]com, o código aborta a execução.

As duas versões maliciosas usaram técnicas distintas para maximizar seu alcance. Na 1.82.7, o código incrustou-se em litellm/proxy/proxy_server.py e foi concebido para ser executado ao importar esse módulo, pelo que qualquer processo que fizesse import de litellm.proxy.proxy_server ativava a carga sem interação do utilizador. Na seguinte iteração, 1.82.8, os atacantes foram mais agressivos: adicionaram um arquivo litellm_ init.pth na raiz da roda. Os arquivos .pth são processados automaticamente pelo site.py ao arrancar o intérprete de Python, por isso essa técnica permite executar código sempre que qualquer processo Python se inicia no ambiente, não apenas quando se importa litellm. Além disso, o .pth invoca um subprocesso em segundo plano empregando subprocess.Popen, o que facilita a execução desapercibida da carga maliciosa como processo filho.

Esse orquestrador descodificado desempaqueta o coletor de credenciais e o instalador de persistência. O mecanismo de movimento lateral em Kubernetes monta pods com privilégios que realizam um chroot para o sistema do host — uma técnica conhecida e descrita amplamente na literatura técnica ( chroot)— e exibem o serviço de systemd que atua como porta de entrada persistente para posteriores descargas de payloads. A estratégia de exfiltração, a persistência por systemd e o padrão de kill switch são consistentes com outras intrusões atribuídas a este ator.

Este episódio não é um caso isolado: TeamPCP demonstrou um padrão de escalada que parte de comprometer ferramentas em pipelines de CI/CD e termina atingindo ambientes de produção por meio de artefatos supostamente confiáveis. De acordo com a análise pública, a campanha afectou vários ecossistemas - GitHub Actions, Docker Hub, npm, Open VSX e agora PyPI - ampliando sua capacidade de acionar numa base de infra-estruturas e projetos muito diversa. Vários especialistas do setor alertaram sobre o efeito dominó: uma ferramenta comprometida pode dar chaves para vulnerar outras, em um ciclo que se retroalimenta. Organizações e equipamentos de desenvolvimento são assim obrigados a reagir a uma ameaça que ataca no coração da confiança na cadeia de suprimentos de software.

Os pesquisadores e fornecedores publicaram relatórios técnicos e recomendações que convém ler para entender alcance e mitigação. Relatórios como os de Endor Labs e JFrog oferecem detalhes do comportamento do malware e de como foi inserido, enquanto análises complementares em meios especializados resumem a cronologia do ataque e os sinais de comprometimento.

Se você administra ambientes que usam Python, contêineres ou pipelines automatizados, é prioritário rever se alguma das versões comprometidas do litellm foi obtida. Auditar instalações em ambientes virtuais e sistemas de produção, procurar arquivos suspeitos no site-packages (como litellm_init.pth), verificar processos Python em segundo plano e rever se existem serviços persistentes instalados sob ~/.config/sysmon são passos iniciais urgentes. Também há que inspeccionar clusters Kubernetes por pods não autorizados ou com privilégios elevados, e analisar registros de rede em busca de tráfego saliente para domínios relacionados ao operacional, em particular models.litellm[.]cloud e checkmarx[. ]zone. Não menos importante é auditar pipelines de CI/CD para detectar se ferramentas como Trivy ou KICS foram usadas na janela de compromisso e, se corresponder, rodar e revogar as credenciais que possam ter sido expostas.

A comunidade de segurança já reagiu e compartilha ferramentas e técnicas de detecção, mas os responsáveis por infra-estruturas devem agir rapidamente e cautela: isolar hosts comprometidos, eliminar mecanismos de persistência identificados, reconstruir artefatos críticos desde código-fonte limpo e rotar chaves e credenciais são medidas que, embora dispendiosas, limitam a capacidade do atacante para impulsionar novos objetivos. Em paralelo, é necessário repensar as políticas de confiança em artefatos externos e fortalecer os testes e o monitoramento nos pipelines.

A bronca pública do próprio grupo, difundida no seu canal Telegram, deixa claro que sua intenção é prolongar e ampliar a campanha; e vozes do setor, como a de Gal Nagli de Wiz, apontaram a natureza cíclica do problema: comprometer uma ferramenta de segurança pode desencadear múltiplos compromissos em cascata. Para aqueles que mantêm projetos e dependências, a lição é dolorosa, mas necessária: não assumir como inócuas as dependências de segurança e reforçar as barreiras de proteção ao redor dos processos que geram, empacotam e publicam software.

Para aprofundar os relatórios técnicos e a evolução deste incidente, recomendo ler as análises de Endor Labs, o relatório JFrog e as peças que resumem o caso em meios especializados, bem como seguir as atualizações nos canais oficiais onde foram publicadas evidências e IOCs. A segurança da cadeia de abastecimento é hoje um tema crítico e coletivo: proteger exige tanto melhores práticas técnicas como coordenação entre desenvolvedores, mantenedores de projetos e equipamentos de segurança.