Dez pacotes publicados no repositório Python abusavam de rotinas de instalação para baixar código, acionar webhooks e coletar senhas, chaves AWS, tokens de API e variáveis de ambiente.
| Componente | Pacotes Python maliciosos publicados no PyPI, incluindo Ascii2text, Pyg-utils, Pymocks, PyProto2, Test-async, Free-net-vpn, Free-net-vpn2, zlibsrc e Browserdiv. |
| Vetor | Execução de código durante a instalação de pacotes, principalmente por scripts setup.py e importação de código em __init__.py. |
| Impacto | Coleta e envio não autorizado de senhas locais, credenciais pessoais, chaves AWS, tokens de API e variáveis de ambiente do sistema do instalador. |
| Prioridade | Remover dependências afetadas, auditar instalações recentes, revisar segredos presentes em ambiente de desenvolvimento e rotacionar credenciais expostas. |
| Artefatos | Uso de webhooks do Discord, domínios defangados pygrata[.]com e pymocks[.]com, download de código remoto e publicação de segredos em site associado a DNS dinâmico. |
| Mitigação | Os pacotes foram reportados ao PyPI e removidos; ambientes que os instalaram ainda exigem investigação local e rotação de segredos. |
Uma campanha de supply chain no ecossistema Python envolveu dez pacotes maliciosos distribuídos pelo PyPI, repositório amplamente usado por desenvolvedores para instalar bibliotecas de terceiros. A técnica central não depende de exploração de uma vulnerabilidade no PyPI, mas do abuso do fluxo normal de instalação de pacotes. Quando um desenvolvedor instala uma dependência, o processo pode executar lógica definida pelo mantenedor do pacote, inclusive scripts de preparação e inicialização. Os pacotes identificados usavam esse ponto de execução para acionar código malicioso no host do instalador, em vez de entregar apenas a funcionalidade declarada na descrição pública.
O objetivo observado foi a coleta de informações sensíveis presentes em estáções de desenvolvimento e ambientes onde pacotes Python são instalados. O material descreve acesso a senhas locais, credenciais pessoais, chaves AWS, tokens de API e variáveis de ambiente. Também foram observados webhooks do Discord como canal de notificação ou recebimento, domínios usados por campanhas relacionadas e download de código remoto durante a instalação. Após a identificação e comunicação ao repositório, os pacotes foram removidos do PyPI, mas a remoção do índice não elimina o risco em máquinas, caches, imagens de contêiner, ambientes de CI/CD ou lockfiles que tenham consumido essas dependências enquanto estavam disponíveis.
O padrão de execução mais importante está no uso de setup.py e, em alguns casos, na importação de arquivos internos como __init__.py durante a instalação. Esse comportamento é relevante porque a instalação de uma biblioteca Python pode executar código antes de o pacote ser usado pela aplicação. Em Ascii2text, o pacote imitava nome e descrição de um projeto popular associado a arte ASCII. A parte maliciosa ficava em __init__.py, importado pelo script de instalação, e era responsável por baixar e executar outro script. Esse script procurava senhas locais e enviava os dados por meio de um webhook do Discord.
Pyg-utils foi associado a uma campanha anterior voltada à coleta de credenciais AWS. Durante a instalação, o pacote conectava-se ao domínio defangado pygrata[.]com, descrito como infraestrutura possivelmente usada em um ataque de phishing. Pymocks e PyProto2 tinham código quase idêntico, mas direcionado ao domínio defangado pymocks[.]com. As datas de publicação reforçam a relação operacional entre esses pacotes: Pyg-utils foi lançado em 15 de junho, enquanto Pymocks e PyProto2 apareceram em 24 de junho e 4 de julho. O domínio pymocks[.]com também foi criado em 24 de junho, o que sustenta a hipótese de reaproveitamento de técnica e infraestrutura por um mesmo operador ou grupo com acesso ao mesmo fluxo de campanha.
Test-async apresentava uma descrição informal de pacote de teste, mas seu script de instalação baixava e executava código da web. Antes do download, o pacote notificava um canal do Discord sobre uma nova execução, o que cria telemetria operacional para o atacante acompanhar instalações bem-sucedidas. Free-net-vpn e Free-net-vpn2 miravam variáveis de ambiente, com código descrito como limpo e documentado para coletar credenciais do usuário e publicá-las em um site resolvido por serviço de DNS dinâmico. zlibsrc tentava se beneficiar da familiaridade com zlib, biblioteca conhecida no ecossistema Python, e também baixava e executava arquivo malicioso durante a instalação.
Browserdiv coletava credenciais do instalador e as enviava a um webhook do Discord. O nome sugeria relação com desenvolvimento web, enquanto a descrição pública mencionava uso de selfbots no Discord, mostrando desalinhamento entre aparência, descrição e comportamento real. Um décimo pacote, descrito publicamente como ferramenta para explorar uma vulnerabilidade de Windows RPC, foi caracterizado como coletor de credenciais durante a instalação. Esse detalhe é importante para triagem: a descrição declarada do pacote não deve ser tratada como prova de funcionalidade legítima nem como indicador confiável do impacto técnico.
A superfície de risco inclui estáções de desenvolvedores, ambientes de build, máquinas usadas para testes locais, imagens de contêiner criadas com dependências baixadas do PyPI e pipelines que instalam pacotes dinamicamente. O ponto comum é a execução de instalação com permissão suficiente para ler variáveis de ambiente, arquivos de configuração, caches de credenciais ou segredos injetados no processo. Em ambientes de desenvolvimento, esses dados podem incluir tokens pessoais, chaves de nuvem, credenciais de serviços internos, senhas salvas em arquivos locais e variáveis exportadas para testes de integração.
A campanha também explora confiança por semelhança. Ascii2text imitava nome e descrição de outro projeto; zlibsrc se apoiava em proximidade nominal com zlib; outros pacotes usavam descrições genéricas ou enganosas. Esse modelo é típico de ataques de dependência em que o instalador confia no nome do pacote, na aparência do README ou em comandos copiados de documentação sem validar mantenedor, histórico, data de publicação e comportamento de instalação. Como os pacotes foram removidos do PyPI, novas instalações diretas tendem a falhar, mas artefatos internos podem preservar a dependência em caches corporativos, proxies de pacotes, espelhos privados, ambientes congelados e registros de build.
- Desenvolvedores que instalaram os pacotes maliciosos enquanto estavam disponíveis no PyPI.
- Pipelines de CI/CD que executaram instalação de dependências com segredos em variáveis de ambiente.
- Ambientes com chaves AWS, tokens de API, senhas locais ou credenciais pessoais acessíveis ao processo de instalação.
- Caches, lockfiles, imagens de contêiner e espelhos internos que possam registrar ou reter versões afetadas.
A investigação deve começar por inventário de dependências e histórico de instalação. Registros de shell, logs de CI/CD, metadados de ambientes virtuais Python, arquivos de lock e relatórios de build podem indicar se algum dos pacotes foi baixado ou instalado. Como o vetor ocorre no momento de instalação, a ausência de importação do pacote pela aplicação não elimina o risco. Se o script de instalação foi executado, a máquina pode ter realizado conexões de saída, baixado código adicional, notificado canais externos ou enviado segredos antes mesmo de qualquer uso funcional da biblioteca.
Em endpoint, a telemetria relevante inclui criação de processos Python durante instalação, execução de código remoto, conexões HTTP ou HTTPS para domínios defangados associados, contato com webhooks do Discord e leitura anormal de variáveis de ambiente ou arquivos de credenciais. Em rede, a defesa deve procurar conexões de saída a pygrata[.]com, pymocks[.]com, endpoints de webhook do Discord e domínios resolvidos por DNS dinâmico usados logo após instalações Python. Em nuvem, a prioridade é correlacionar instalações suspeitas com uso subsequente de chaves AWS, principalmente chamadas realizadas a partir de origem incomum, horário inesperado, região não habitual ou agente de usuário inconsistente com automações conhecidas.
- Presença dos pacotes
Ascii2text,Pyg-utils,Pymocks,PyProto2,Test-async,Free-net-vpn,Free-net-vpn2,zlibsrcouBrowserdivem logs de instalação. - Execução de
setup.pyseguida de conexão de saída para Discord,pygrata[.]com,pymocks[.]comou domínio associado a DNS dinâmico. - Downloads de código remoto iniciados por processo Python durante criação de ambiente virtual, build de pacote ou execução de pipeline.
- Acesso ou leitura de variáveis de ambiente contendo chaves de nuvem, tokens de API ou credenciais de serviços internos.
- Uso incomum de credenciais AWS após a instalação, especialmente quando a chave estava disponível no host ou no pipeline afetado.
A primeira medida é confirmar exposição real. Equipes devem pesquisar os nomes dos pacotes em repositórios, manifests, lockfiles, caches de build, imagens de contêiner, ambientes virtuais e logs de CI/CD. Onde houver instalação confirmada, a resposta deve tratar o host ou pipeline como ambiente com segredos potencialmente acessados. Isso exige remover os pacotes, reconstruir ambientes a partir de dependências verificadas, invalidar caches afetados e revisar qualquer artefato produzido enquanto a dependência estava presente. Como a remoção no PyPI apenas interrompe novas instalações pelo índice público, a resposta local precisa considerar cópias internas e artefatos já gerados.
A rotação de credenciais deve ser guiada pelo escopo do ambiente. Se a instalação ocorreu em estáção de desenvolvedor, devem ser revisados tokens pessoais, credenciais de nuvem, chaves de API e senhas presentes em arquivos ou variáveis de ambiente. Se ocorreu em pipeline, a rotação deve incluir segredos disponíveis ao job, credenciais usadas por runners, tokens de publicação, chaves de acesso a registries e permissões associadas. Para AWS, a investigação deve verificar uso das chaves após o período de instalação e limitar permissões com base no menor privilégio. O bloqueio preventivo de credenciais expostas é preferível a confiar apenas na ausência de alerta de abuso.
No controle preventivo, organizações devem reduzir instalações dinâmicas não verificadas, exigir revisão de novas dependências, bloquear nomes suspeitos por política interna e usar repositórios intermediários com análise de pacotes. A verificação deve incluir metadados do mantenedor, data de publicação, histórico de versões, diferenças entre nome e funcionalidade declarada, presença de lógica em setup.py, downloads externos durante instalação e uso de webhooks. Ambientes de CI/CD devem evitar expor segredos a etapas que instalam dependências quando isso não for necessário, separando resolução de pacotes, build e publicação em fases com permissões distintas.
- Pesquisar os nomes dos pacotes em repositórios, lockfiles, caches, imagens de contêiner, ambientes virtuais e logs de build.
- Remover dependências afetadas e reconstruir ambientes a partir de fontes verificadas e controles de integridade.
- Rotacionar credenciais que estavam disponíveis ao processo de instalação, incluindo chaves AWS, tokens de API e segredos de pipeline.
- Correlacionar eventos de instalação com conexões externas, uso de webhooks, downloads remotos e atividade incomum em contas de nuvem.
- Aplicar revisão obrigatória para novas dependências Python, com bloqueio de downloads externos durante instalação sempre que possível.
0 Comentários