Campanha TrapDoor distribui malware para roubo de credenciais via npm, PyPI e Crates[.]io

Pacotes maliciosos publicados em múltiplos ecossistemas usam hooks de instalação, execução em importação e scripts de compilação para atingir desenvolvedores de cripto, DeFi, Solana e IA.

Componente	Mais de 34 pacotes maliciosos, em mais de 384 versões, distribuídos pelos ecossistemas npm, PyPI e Crates.io sob a campanha TrapDoor.
Vetor	Execução acionada por hooks de pós-instalação no npm, execução durante importação em pacotes Python e scripts build.rs em crates Rust.
Impacto	Coleta de segredos de desenvolvedor, carteiras cripto, chaves SSH, credenciais de nuvem, dados de navegador e variáveis de ambiente, com validação de tokens AWS e GitHub em alguns fluxos.
Prioridade	Auditar dependências recentes, bloquear pacotes associados à campanha, revisar estáções de desenvolvedores e rotacionar credenciais expostas em ambientes de código, nuvem e CI/CD.
Artefatos	trap-core.js, build.rs, .cursorrules, CLAUDE.md, hooks Git, serviços systemd, tarefas cron e hooks de shell aparecem como pontos de execução ou persistência.
IoCs	Domínio GitHub Pages defangado ddjidd564.github[.]io foi associado ao carregamento de JavaScript remoto por pacotes Python.

Resumo técnico

A campanha TrapDoor representa um ataque coordenado de cadeia de suprimentos contra desenvolvedores que consomem dependências de npm, PyPI e Crates.io. A atividade começou em 22 de maio de 2026, às 20h20 UTC, e avançou em ondas de publicação a partir de um conjunto de contas que inseriram novos pacotes em rápida sucessão. O escopo informado inclui mais de 34 pacotes maliciosos e mais de 384 versões, o que indica tentativa de presença persistente nos registros e aumento da chance de instalação por projetos que aceitam atualizações frequentes.

O objetivo técnico da campanha é coletar materiais sensíveis de ambientes de desenvolvimento. Os pacotes foram descritos como voltados a comunidades de cripto, DeFi, Solana e IA, com nomes moldados para parecerem ferramentas de desenvolvimento, configuração local, segurança ou automação. A carga maliciosa procura segredos de desenvolvedor, carteiras cripto, chaves SSH, credenciais de nuvem, dados armazenados por navegadores e variáveis de ambiente. Em parte do fluxo npm, o payload compartilhado trap-core.js também valida credenciais por chamadas às APIs da AWS e do GitHub, o que aumenta o risco de uso posterior de tokens ainda válidos.

Fluxo técnico

A campanha usa mecanismos nativos de cada ecossistema para executar código no momento em que o desenvolvedor instala, importa ou compila a dependência. No npm, a execução ocorre por hooks de pós-instalação e por payloads JavaScript remotos. Esses hooks são particularmente sensíveis porque rodam dentro do contexto do usuário que instalou o pacote, geralmente em máquinas com acesso a repositórios, chaves SSH, tokens de API e variáveis de ambiente usadas por ferramentas de desenvolvimento. O payload trap-core.js varre o host em busca desses materiais, tenta validar credenciais AWS e GitHub e cria pontos de persistência por tarefas cron, serviços systemd, hooks Git, hooks de shell e arquivos usados por assistentes de desenvolvimento.

Nos crates Rust, o acionamento acontece por meio de scripts build.rs, executados durante a etapa de compilação. Esse caminho é perigoso para consumidores que tratam a compilação como uma operação confiável e não revisam scripts de build em dependências recém-adicionadas. Os crates associados à campanha procuram keystores locais, cifram os dados com uma chave XOR embutida e enviam o resultado para GitHub Gists. Nos pacotes Python, a execução ocorre durante a importação, com delegação para JavaScript remoto hospedado no domínio defangado ddjidd564.github[.]io; o material recebido é executado por uma invocação de Node.js com comando operacional omitido. Esse desenho permite alterar o comportamento do payload externo sem publicar uma nova versão no PyPI.

Superfície afetada

A superfície exposta concentra-se em estáções de trabalho, contêineres de desenvolvimento, agentes de build e ambientes de CI/CD que instalaram dependências recentes ligadas a nomes de pacotes da campanha. O risco é maior quando o ambiente mantém credenciais em variáveis, arquivos de configuração, diretórios de nuvem, chaves SSH reutilizadas ou sessões autenticadas de ferramentas como GitHub e AWS. Como os pacotes foram publicados em vários ecossistemas, equipes poliglotas que combinam JavaScript, Python e Rust precisam revisar manifests, lockfiles, caches de pacote e imagens de build, não apenas o repositório principal.

Um componente adicional envolve arquivos consumidos por assistentes de IA em projetos de desenvolvimento. A campanha implantou .cursorrules e CLAUDE.md com instruções ocultas voltadas a induzir assistentes a executar uma suposta verificação de segurança que resultaria em descoberta e exfiltração de segredos. Também houve abertura de pull requests em projetos populares de IA e desenvolvimento, incluindo browser-use/browser-use, langchain-ai/langchain e langflow-ai/langflow. Esse comportamento sugere teste de um caminho de ataque em que arquivos aparentemente administrativos entram no fluxo normal de contribuição e são interpretados por ferramentas automatizadas.

A campanha não deve ser confundida com outra operação chamada TrapDoor ligada a fraude publicitária em aplicativos Android. Neste caso, o nome se refere a uma atividade de cadeia de suprimentos de software voltada a registros de pacotes e ambientes de desenvolvimento.

• Projetos que instalaram pacotes recentes de npm, PyPI ou Crates.io relacionados a cripto, DeFi, Solana, IA, ambiente local ou segurança.
• Máquinas de desenvolvedores com chaves SSH, tokens GitHub, credenciais AWS, carteiras cripto, dados de navegador ou variáveis de ambiente sensíveis.
• Pipelines que executam hooks de instalação, importações Python ou compilação Rust sem isolamento rígido e sem revisão de scripts de dependência.
• Repositórios que receberam arquivos .cursorrules ou CLAUDE.md por contribuição externa e usam assistentes de IA no fluxo de desenvolvimento.

Hunting e telemetria

A investigação deve começar por manifests e lockfiles de projetos JavaScript, Python e Rust, correlacionando dependências adicionadas ou atualizadas desde 22 de maio de 2026. Em estáções de trabalho, procure execuções incomuns disparadas por gerenciadores de pacotes, processos Node.js iniciados durante importação Python, scripts de build Rust que acessam diretórios de credenciais e conexões de saída para GitHub Pages ou GitHub Gists logo após instalação ou compilação. Como a campanha usa mecanismos esperados dos ecossistemas, a detecção depende de contexto: processo pai, horário de instalação, nome do pacote, alterações de persistência e acesso a arquivos sensíveis.

Em endpoints Linux, eventos envolvendo criação ou modificação de tarefas cron, unidades systemd, hooks Git, perfis de shell e arquivos de configuração de assistentes de IA devem ser priorizados quando ocorrerem após operações de instalação de dependências. Em ambientes de nuvem e código, logs de validação ou uso anormal de tokens AWS e GitHub podem indicar que credenciais foram coletadas e testadas. A ausência de um alerta de malware tradicional não elimina o risco, porque parte do fluxo usa JavaScript remoto e scripts de ecossistema, que podem parecer atividade de desenvolvimento legítima quando analisados isoladamente.

• Instalações ou atualizações de pacotes npm, PyPI e Crates.io em ondas próximas a 22 de maio de 2026 ou depois dessa data.
• Execução de Node.js iniciada a partir de importação Python, com busca de JavaScript externo em domínio GitHub Pages defangado.
• Acesso a keystores locais durante compilação Rust por scripts build.rs.
• Criação de tarefas cron, serviços systemd, hooks Git ou hooks de shell após instalação de dependências.
• Chamadas incomuns a APIs da AWS ou do GitHub associadas a validação de tokens fora de fluxos normais de automação.

Mitigação

A resposta deve priorizar contenção de credenciais e limpeza de dependências. Remova pacotes suspeitos de manifests, lockfiles e caches, reconstrua ambientes a partir de bases confiáveis e revise imagens de CI/CD que possam ter executado hooks maliciosos. Em máquinas potencialmente afetadas, trate tokens de GitHub, chaves SSH, credenciais AWS, carteiras cripto e segredos em variáveis de ambiente como material possivelmente exposto quando houver evidência de instalação, importação ou compilação dos pacotes relacionados à campanha. A rotação deve ser acompanhada de invalidação de sessões, revisão de permissões e busca por uso posterior dos tokens.

Para reduzir recorrência, equipes devem isolar instalações de dependências em ambientes descartáveis, bloquear execução automática de scripts quando o fluxo permitir, revisar build.rs em crates novos e tratar arquivos de instrução para assistentes de IA como código que precisa de revisão. Pull requests externos que adicionem .cursorrules, CLAUDE.md, hooks ou arquivos de automação devem passar por análise explícita de segurança. A mitigação também exige governança de registros: permitir dependências por lista aprovada, monitorar typosquatting, fixar versões em lockfiles e exigir revisão humana para pacotes recém-publicados em áreas de alto risco.

• Auditar manifests, lockfiles, caches de pacotes e imagens de build que tenham consumido dependências recentes dos três ecossistemas afetados.
• Rotacionar tokens GitHub, credenciais AWS, chaves SSH e segredos de desenvolvimento quando houver indício de execução dos pacotes maliciosos.
• Remover persistências locais em cron, systemd, hooks Git e hooks de shell criadas após instalação ou compilação suspeita.
• Revisar arquivos .cursorrules e CLAUDE.md recebidos por pull requests, especialmente em projetos que usam assistentes de IA.
• Executar instalação e compilação de dependências em sandboxes sem acesso direto a segredos, carteiras, perfis de nuvem ou credenciais de produção.