Ataque a SAP CAP em npm expõe tokens e credenciais mediante roubo de memória de runners por TeamPCP

Um conjunto de pacotes oficiais do SAP publicados no registro npm foi comprometido e, segundo análise de vários equipamentos de pesquisa, a intrusão coincide com a assinatura tático-operativa do grupo conhecido como TeamPCP. As versões afetadas que foram publicadas com código malicioso e já foram deprecadas em npm incluem @cap-js/sqlite v2.2.2, @cap-js/postgres v2.2.2, @cap-js/db-service v2.10.1 e mbt v1.2.48, componentes ligados ao modelo Cloud Application Programming (CAP) e Cloud MTA utilizados em desenvolvimentos empresariais.

Os pesquisadores de Aikido e Socket documentaram que o pacote comprometido adiciona um programa de pré-instalação que lança um loader chamado setup.mjs, que por sua vez descarrega o runtime Bun desde o GitHub e executa um payload ofuscado chamado execution.js. Esse payload atua como um ladrão de informação projetado para extrair tokens de npm e GitHub, chaves SSH, credenciais de provedores cloud (AWS, Azure, GCP), configurações e segredos de Kubernetes e variáveis de ambientes de CI/CD, além de tentar ler memória do runners da CI para evitar o mascaramento de segredos.

O mecanismo de ex-filtração documentado inclui a cifra da informação roubada e sua subida a repositórios públicos do GitHub criados sob contas de vítimas, usando descrições com a cadeia "A Mini Shai-Hulud has Appeared". Além disso, o malware emprega uma técnica de "dead‐drop" por commit messages no GitHub com a forma "OhNoWhatsGoingOnWithGitHub:" para recuperar Tokens, o que permite ampliar o alcance e persistência do atacante. Estes detalhes estão coletados nos relatórios de Aikido e Socket: Aikido — Mini Shai-Hulud e Socket — análise do ataque à SAP CAP.

A capacidade do malware para ler /proc/ pid/maps e /proc/ pid/mem no runners Linux reproduz táticas vistas em compromissos prévios atribuídos ao TeamPCP contra fornecedores como Bitwarden e Checkmarx: se extraem segredos diretamente da memória do processo do runner para evitar qualquer mascarado de logs do fornecedor CI. Com credenciais roubadas, o ator tenta se espalhar automaticamente modificando outros pacotes e repositórios para inserir a mesma cadeia maliciosa.

Sobre o vetor inicial, não há confirmação pública do SAP ao fechamento dos relatórios, mas pesquisadores apontam para a possibilidade de que um token npm fica exposto por uma configuração errônea de um job de CircleCI, o que concorda com padrões anteriores nos quais credenciais de CI serviam como pivote de publicação maliciosa. Enquanto a SAP investiga, as organizações que usam CAP ou as livrarias afetadas devem assumir risco de comprometimento em suas cadeias de desenvolvimento.

As ações imediatas recomendadas incluem rotar e revogar qualquer token e credencial que pudesse ter estado presente em máquinas ou em CI: regenerar tokens de npm e GitHub, rodar chaves SSH, renovar credenciais de nuvem e regenerar secrets de CI. É imprescindível inspecionar os repositórios e contas no GitHub em busca de novos repos criados com a descrição indicada e rever o histórico de commits por padrões suspeitos como "OhNoWhatsGoingOnWithGitHub:". Também convém revogar os runners comprometidos e reconstruí-los a partir de imagens limpas para remover qualquer backdoor em memória ou no sistema de ficheiros.

Num segundo plano, as práticas de desenvolvimento e implantação devem ser endurecidas: activar a autenticação multifator e o uso de tokens com o menor privilégio possível, migrar para mecanismos de autenticação federada ou OIDC para a CI onde seja viável, ativar o digitalizado de segredos e a proteção avançada de repositórios (por exemplo, GitHub Advanced Security), e definir versões de dependência através de lockfiles e políticas de aprovação de mudanças na pipeline. As ferramentas de digitalização de software de terceiros (SCA) e a monitoração de integridade de pacotes ajudam a detectar modificações não autorizadas em artefatos publicados.

Do ponto de vista operacional, é crítico auditar logs de acessos a repositórios e APIs cloud por atividade incomum, bloquear exfiltração não autorizada com controles de egress e revisar a configuração de CI para evitar que variáveis sensíveis fiquem embebidas em builds ou expostas em jobs públicos. Considerar o uso de tokens efêmeros, rotação automática e separação estrita de credenciais de publicação frente às de execução Reduz a janela de exposição a um compromisso futuro.

Este incidente sublinha que as cadeias de fornecimento de software são um objetivo de alto valor e que um único token ou pipeline mal configurado pode dar acesso a ambientes corporativos completos. A defesa requer tanto controles técnicos (hardening de CI, rotatividade de segredos, leiast privilege) como governança: políticas claras sobre publicação de pacotes, revisões humanas e respostas rápidas ante sinais de compromisso. Para guias práticas sobre manejo de tokens e credenciais podem ser consultadas as recomendações do GitHub sobre tokens pessoais e de acesso: GitHub — Personal Access Tokens, e documentação de npm sobre segurança e tokens: npm — Access Tokens.

Se a sua organização usar a SAP CAP ou as livrarias afetadas, atua agora: avalia exposição, assume compromisso até demonstrar o contrário, executa rotações e reconstruções, e aproveita este incidente para elevar as defesas da cadeia de abastecimento e a higiene de segredos a nível corporativo.