Credenciais roubadas em ambientes de CI/CD foram usadas para adulterar fluxos confiáveis, coletar segredos de runners e publicar extensões trojanizadas no Open VSX.
| Componente | GitHub Actions mantidas pela Checkmarx, extensões Open VSX ast-results 2.53.0 e cx-dev-assist 1.7.0, além de runners de CI/CD com segredos acessíveis em memória ou no ambiente. |
| Vetor | Uso de credenciais de CI roubadas, força de atualização de tags para commits maliciosos e ativação de extensões trojanizadas baixadas do Open VSX em 23 de março de 2026 entre 02:53 UTC e 15:41 UTC. |
| Impacto | Coleta e exfiltração de chaves SSH, tokens GitHub, credenciais de nuvem, segredos Kubernetes, Docker, bancos de dados, arquivos .env, webhooks e configurações de CI/CD para infraestrutura controlada pelo operador. |
| Prioridade | Rotacionar todos os segredos acessíveis aos runners no período afetado, auditar execuções do GitHub Actions, procurar repositórios de exfiltração tpcp-docs ou docs-tpcp e fixar ações por SHA completo. |
| Artefatos | Payload setup.sh, arquivo de coleta tpcp.tar.gz, domínio C2 defangado checkmarx[.]zone, IP defangado 83.142.209[.]11 na porta 443 e uso de repositório docs-tpcp como fallback. |
| Versões | As versões do VS Code Marketplace não são descritas como afetadas; o impacto informado envolve artefatos Open VSX baixados e executados na janela indicada. |
A operação atribuída ao TeamPCP avançou de um comprometimento anterior envolvendo ações associadas ao Trivy para fluxos mantidos pela Checkmarx, usando credenciais de CI roubadas para introduzir um coletor de segredos em componentes confiáveis da cadeia de desenvolvimento. O ponto central do incidente não é uma exploração isolada de aplicação, mas a capacidade de transformar confiança de automação em vetor de propagação: uma ação adulterada é executada por projetos consumidores, acessa variáveis, tokens e credenciais presentes no runner, e esses segredos podem ser reutilizados para comprometer outros repositórios ou publicar artefatos maliciosos em canais de desenvolvimento.
O coletor identificado como TeamPCP Cloud stealer foi projetado para buscar credenciais de Git, SSH, AWS, Google Cloud, Microsoft Azure, Kubernetes, Docker, bancos de dados, VPNs, arquivos .env, configurações de CI/CD, carteiras de criptomoedas e webhooks de Slack e Discord. O material coletado é empacotado como tpcp.tar.gz, criptografado e enviado para o domínio defangado checkmarx[.]zone; quando a exfiltração direta falha, a nova versão tenta criar um repositório docs-tpcp usando GITHUB_TOKEN da vítima para armazenar os dados como rota alternativa.
A cadeia observada depende da adulteração de tags em ações do GitHub. Em vez de depender de uma mudança evidente em um arquivo de workflow do consumidor, o operador força a tag de uma ação confiável para apontar para um commit com o payload setup.sh. Projetos que referenciam a ação por tag, e não por SHA completo, podem executar o conteúdo adulterado sem alteração explícita no próprio repositório consumidor. Esse modelo reduz a visibilidade em revisões de código convencionais, porque o ponto de execução confiável passa a entregar código diferente do esperado.
O mesmo padrão também apareceu em extensões Open VSX associadas à Checkmarx. As versões ast-results 2.53.0 e cx-dev-assist 1.7.0 foram publicadas de forma trojanizada após comprometimento da conta de serviço cx-plugins-releases. Após a ativação, a extensão verifica se o sistema possui credenciais de pelo menos um provedor ou serviço, incluindo GitHub, AWS, Google Cloud ou Microsoft Azure. Quando encontra credenciais, busca um estágio adicional no domínio defangado checkmarx[.]zone e executa a lógica de coleta por meio de gerenciadores de pacotes JavaScript, descritos aqui apenas pelo efeito defensivo, sem comandos reproduzíveis.
Em sistemas que não são CI, o malware instala persistência por serviço de usuário do systemd e consulta periodicamente um caminho remoto para obter cargas adicionais. O comportamento inclui uma condição de parada baseada em conteúdo de resposta contendo a palavra youtube, e o endpoint citado estava redirecionando para conteúdo musical público no momento descrito. Esse detalhe é útil para investigação porque combina tráfego periódico, persistência no espaço do usuário e contato com o mesmo domínio usado na campanha.
A exposição se concentra em organizações que executaram ações comprometidas com segredos disponíveis no runner, especialmente quando tokens GitHub possuíam permissão de escrita em repositórios que também consumiam ações da Checkmarx. Esse encadeamento permite que um segredo coletado em uma execução de CI/CD seja usado para modificar outra ação ou outro repositório, criando um comprometimento em cascata. O risco é maior em ambientes que usam runners compartilhados, variáveis de organização amplas, tokens persistentes, permissões excessivas em GITHUB_TOKEN e ações referenciadas por tags móveis.
No caso das extensões, a janela de impacto informada envolve organizações que baixaram artefatos do Open VSX em 23 de março de 2026, entre 02:53 UTC e 15:41 UTC, e efetivamente os executaram. O texto também delimita que a Checkmarx não tinha conhecimento de impacto em dados de clientes ou ambientes de produção, e que novas versões dos artefatos impactados foram liberadas. Essa distinção importa para resposta: a prioridade deve ser validar ambientes de desenvolvimento, estáções de trabalho e pipelines, sem presumir comprometimento de produção onde não há evidência no contexto.
- Fluxos do GitHub Actions que consumiam ações afetadas por tags em vez de SHAs completos.
- Runners com chaves SSH, tokens GitHub, credenciais de nuvem, segredos Kubernetes, Docker, bancos de dados, VPNs ou arquivos
.env. - Instalações Open VSX de
ast-results2.53.0 ecx-dev-assist1.7.0 baixadas e executadas na janela informada. - Repositórios onde
GITHUB_TOKENtinha permissão suficiente para criar repositórios, gravar commits ou alterar referências.
A investigação deve partir dos logs de execução de CI/CD, porque a cadeia usa runners como ponto de coleta. Procure referências a tpcp.tar.gz, setup.sh, checkmarx[.]zone, scan.aquasecurity[.]org e ao IP defangado 83.142.209[.]11 na porta 443. A presença de tráfego para domínios com aparência próxima ao fornecedor é uma técnica de disfarce relevante: o objetivo é fazer uma conexão de exfiltração parecer parte normal da ação executada.
Também é necessário revisar eventos de GitHub ligados a força de atualização de tags, criação inesperada de repositórios e uso incomum de tokens em janelas próximas às execuções dos workflows. A criação de repositórios tpcp-docs ou docs-tpcp dentro de organizações ou contas de serviço é um sinal forte de exfiltração por fallback. Em endpoints de desenvolvedores, a telemetria deve incluir ativações de extensões Open VSX, criação de serviço de usuário no systemd, downloads de estágio adicional e processos de gerenciadores JavaScript iniciados por extensões.
- Execuções do GitHub Actions com saída de rede para
checkmarx[.]zoneou IP defangado83.142.209[.]11na porta 443. - Criação de repositórios
docs-tpcpoutpcp-docspor contas de automação ou tokens normalmente usados em CI. - Referências a
tpcp.tar.gzem logs de runner, diretórios temporários, artefatos de build ou histórico de processos. - Atualizações forçadas de tags em ações consumidas por workflows internos.
- Serviços de usuário
systemdrecém-criados em estáções de desenvolvimento após instalação das extensões afetadas.
A contenção deve tratar os segredos presentes nos runners como potencialmente expostos durante a janela afetada. Isso inclui tokens GitHub, chaves SSH, credenciais AWS, Google Cloud e Microsoft Azure, kubeconfigs, segredos Docker, credenciais de banco de dados, VPNs, webhooks e variáveis .env. A rotação precisa ser acompanhada de invalidação de sessões, revisão de escopo e redução de permissões, porque a simples troca de segredo mantém o mesmo risco estrutural se o token novo continuar com escrita ampla sobre repositórios sensíveis.
A correção estrutural envolve fixar GitHub Actions por SHA completo, restringir permissões padrão de GITHUB_TOKEN, separar segredos por ambiente, reduzir acesso de runners a metadados de instância e validar extensões instaladas em ambientes de desenvolvimento. Para workloads em nuvem, runners em contêineres devem ter acesso controlado ao Instance Metadata Service e preferir IMDSv2 quando aplicável. Após a contenção, equipes devem reexecutar varreduras de integridade em repositórios, tags, releases, extensões e imagens publicadas durante a janela de exposição.
- Rotacionar todos os segredos acessíveis aos runners que executaram ações afetadas ou extensões trojanizadas.
- Fixar ações por SHA completo e revisar dependências que ainda referenciam tags móveis.
- Reduzir permissões de
GITHUB_TOKENao mínimo necessário por workflow e bloquear escrita por padrão quando não for exigida. - Auditar organizações GitHub em busca de tags alteradas, commits inesperados, repositórios
docs-tpcpoutpcp-docse uso anormal de contas de serviço. - Remover versões Open VSX afetadas, instalar versões corrigidas e verificar persistência de usuário no
systemdem máquinas que executaram os artefatos. - Monitorar e bloquear tráfego de CI/CD para domínios defangados associados à campanha e revisar políticas de egress dos runners.
0 Comentários