Pacote malicioso no PyPI esconde código em imagem para executar binário externo

O pacote apicolor usava esteganografia, dependência auxiliar e projetos no GitHub com reputação artificial para induzir instalações e ocultar a execução de código durante o processo de instalação.

Componente	Pacote Python apicolor publicado no PyPI, com uso do módulo judyb para revelar conteúdo oculto em imagem durante a instalação.
Vetor	Instalação do pacote a partir de projetos públicos no GitHub que incluíam apicolor e judyb como requisitos, apoiados por sinais artificiais de reputação.
Impacto	O fluxo oculto revelava código Python ofuscado em base64, cujo comportamento observado era baixar um executável malicioso da web e executá-lo localmente.
Prioridade	Remover dependências apicolor e judyb de ambientes e repositórios, auditar execuções ocorridas durante instalação de pacotes e revisar projetos GitHub usados como origem de dependências.
Artefatos	Imagem remota usada como transportador de código, instalação manual de dependências no script de instalação, uso de requests, judyb, método de revelação esteganográfica e chamada dinâmica por exec.
Mitigação	O pacote apicolor foi removido do PyPI após notificação; equipes devem validar lockfiles, caches, ambientes de desenvolvimento e histórico de instalação para descartar execução anterior.

Resumo técnico

Um pacote malicioso chamado apicolor foi identificado no PyPI com uma técnica de ocultação incomum para ecossistemas Python: parte do código não ficava visível diretamente no pacote, mas era recuperada de uma imagem baixada durante a instalação. A imagem aparentava ser legítima quando observada visualmente, porém continha uma mensagem escondida por esteganografia. O pacote usava um segundo módulo, judyb, para processar essa imagem e extrair o conteúdo oculto. O resultado era código Python ofuscado em base64, posteriormente decodificado e acionado pelo fluxo de instalação.

O caso é relevante para segurança de cadeia de suprimentos porque desloca uma parte importante da lógica maliciosa para fora do texto imediatamente auditável do pacote. Em vez de depender apenas de nomes parecidos com pacotes populares ou de ofuscação simples dentro de setup.py, o operador combinou um pacote aparentemente em desenvolvimento, uma dependência auxiliar publicada no mesmo período, uma imagem remota e projetos públicos no GitHub que referenciavam os pacotes como requisitos. Essa composição reduz a visibilidade de cada peça isolada e cria um caminho de infecção que pode atingir desenvolvedores que testam projetos abertos em máquinas de trabalho ou ambientes pessoais conectados a ativos corporativos.

O comportamento técnico observado após a revelação do conteúdo escondido foi o download de um executável malicioso da web e sua execução local. O contexto não sustenta afirmar exploração de vulnerabilidade, movimentação lateral, vazamento confirmado de dados ou comprometimento de infraestrutura específica. O impacto confirmado fica concentrado na execução de código não autorizado no host que instala o pacote. Para times de segurança, o ponto central é tratar instalações de dependências como superfície de execução, especialmente quando scripts de instalação fazem chamadas de rede, instalam requisitos fora do mecanismo esperado ou invocam execução dinâmica de código gerado em tempo de instalação.

Fluxo técnico

O pacote apicolor se apresentava como uma biblioteca genérica para REST API, com descrição vaga e aparência de projeto novo. A técnica principal estava no script de instalação, que começava com uma sequência incomum para pacotes Python legítimos: instalava dependências extras manualmente, em vez de declarar tudo pelo caminho mais comum de requisitos, baixava uma imagem da web, processava essa imagem com o módulo judyb e executava o resultado produzido pelo processamento. Esse padrão difere de um instalador típico porque mistura resolução de dependências, acesso externo, transformação de conteúdo e execução dinâmica no mesmo caminho de instalação.

O módulo judyb também aparentava estar em estágio inicial, com descrição mínima, mas sua função real no fluxo era permitir esconder e revelar mensagens em imagens. Ao aplicar o método de revelação à imagem usada por apicolor, o conteúdo extraído era uma cadeia codificada em base64. A decodificação mostrou uma rotina Python compatível com um padrão recorrente em pacotes maliciosos: recuperar um executável remoto e iniciá-lo no sistema local. O uso de esteganografia nesse ponto torna a análise estática mais difícil, porque o trecho decisivo não precisa aparecer como código legível no pacote principal nem como uma cadeia simples imediatamente detectável por assinatura.

A fase de atração não dependia apenas de usuários encontrarem apicolor diretamente no PyPI. O caminho observado envolvia projetos públicos no GitHub que adicionavam apicolor e judyb como requisitos. Apenas poucos usuários incluíam esses pacotes em projetos, e esses usuários eram novos. Alguns repositórios aparentavam ter reputação por estrelas e forks, mas a distribuição desses sinais indicava reputação fabricada: um número restrito de contas parecia amplificar os projetos, com forks concentrados e contas usadas principalmente para marcar esses repositórios. Essa camada social é parte do vetor, pois aumenta a chance de um desenvolvedor confiar no projeto aberto e instalar suas dependências sem examinar a cadeia de instalação.

Superficie afetada

A superfície exposta inclui ambientes Python que instalaram apicolor a partir do PyPI antes da remoção, repositórios que mantiveram apicolor ou judyb em arquivos de dependências e estáções de desenvolvimento que testaram projetos GitHub contendo esses requisitos. O risco é maior quando a instalação ocorreu em hosts com permissões de usuário suficientes para executar binários baixados, acesso à internet liberado durante o processo de build e ausência de bloqueio para scripts de instalação com chamadas externas. Ambientes de desenvolvimento são particularmente sensíveis porque costumam conter credenciais de repositórios, tokens de CI/CD, chaves de nuvem e sessões autenticadas, embora o material analisado não confirme coleta desses dados neste caso.

Também entram no escopo pipelines que restauram dependências automaticamente, caches internos de pacotes e imagens de build criadas a partir de projetos não verificados. Mesmo que o pacote tenha sido removido do índice público, artefatos podem persistir em caches locais, proxies de dependências, ambientes virtuais, imagens de contêiner ou snapshots de máquinas. A remoção no repositório público reduz novas instalações diretas, mas não elimina instalações reproduzidas por artefatos já armazenados ou por lockfiles que preservam nomes de pacotes e versões baixadas anteriormente.

• Projetos Python que listaram apicolor ou judyb como dependência, requisito direto ou requisito transitivo manualmente adicionado.
• Estáções de trabalho que executaram instalação de pacotes a partir de projetos GitHub com reputação baseada em estrelas e forks artificiais.
• Pipelines, ambientes virtuais, caches de pacotes e imagens de build que possam ter preservado artefatos baixados antes da remoção do pacote.

Hunting e telemetria

A investigação defensiva deve começar por inventariar dependências e histórico de instalação. Em repositórios, procure referências a apicolor e judyb em arquivos de requisitos, manifests, lockfiles, scripts de setup, notebooks e documentação de build. Em endpoints, revise logs de processo no período em que instalações Python foram executadas e correlacione invocações do interpretador com criação de processos filhos incomuns, downloads de arquivos executáveis e gravação de binários em diretórios temporários ou de usuário. O ponto de maior valor é a sequência: instalação de pacote, acesso HTTP para recuperar imagem, processamento por biblioteca de esteganografia, decodificação de conteúdo e execução de binário externo.

Como o código oculto dependia de uma imagem remota, telemetria de rede pode expor requisições anômalas feitas durante instalação de dependências. O tráfego não precisa parecer malicioso pelo tipo de arquivo, pois a imagem visualmente aparentava ser legítima. Por isso, controles que só bloqueiam extensões executáveis podem não perceber o estágio transportador. É mais útil correlacionar downloads de imagens ou outros arquivos de mídia feitos por processos de instalação, seguidos por execução de conteúdo gerado localmente, escrita de arquivos executáveis ou criação de novos processos fora do comportamento esperado de empacotadores Python.

No endpoint, o uso de exec sobre saída gerada em tempo de instalação é um sinal importante, mas nem sempre aparece de forma direta em logs tradicionais. A defesa deve combinar auditoria de arquivos de pacote, telemetria de EDR, histórico de comandos, registros de criação de processo e eventos de rede. Também vale examinar projetos GitHub usados como origem: contas recém-criadas, baixa atividade orgânica, estrelas concentradas em um mesmo conjunto de contas e forks repetitivos são sinais de distribuição artificial. Esses sinais não provam, isoladamente, atividade maliciosa, mas ajudam a priorizar repositórios que merecem revisão manual antes de serem executados em ambientes confiáveis.

• Referências a apicolor e judyb em arquivos de dependências, lockfiles, caches locais, ambientes virtuais e imagens de build.
• Processos Python de instalação realizando download de imagem remota e, em seguida, iniciando executáveis locais ou arquivos recém-gravados.
• Uso de scripts de instalação com instalação manual de dependências, chamada de rede e execução dinâmica de conteúdo processado em tempo de instalação.
• Repositórios GitHub com dependências redundantes, contas novas, estrelas pouco orgânicas e forks concentrados em poucos perfis.

Mitigação

A primeira ação é remover apicolor e judyb de repositórios, ambientes virtuais e pipelines, seguida por uma revisão do histórico de instalação para identificar hosts que executaram o fluxo. Como o pacote apicolor foi removido do PyPI, novas instalações diretas ficam limitadas, mas equipes não devem assumir que o risco desapareceu. Proxies internos, caches de CI/CD, imagens antigas e ambientes de desenvolvimento podem manter cópias suficientes para repetir o comportamento. A limpeza deve incluir invalidação de caches, reconstrução de ambientes a partir de fontes verificadas e revisão de artefatos gerados durante instalações anteriores.

Para contenção, hosts que instalaram o pacote devem ser tratados como sistemas com execução de código não autorizado. A resposta deve revisar processos iniciados no período, arquivos executáveis baixados por processos Python, persistência local não esperada e conexões de saída relacionadas à instalação. O contexto não confirma quais dados foram acessados ou se houve comunicação posterior bem-sucedida, portanto a investigação deve buscar evidências antes de declarar vazamento ou comprometimento ampliado. Caso o host tivesse segredos de desenvolvimento, tokens de repositório ou credenciais de nuvem acessíveis ao usuário, a rotação deve ser avaliada com base na telemetria e na exposição real do ambiente.

No nível preventivo, organizações devem restringir execução de scripts de instalação com acesso irrestrito à rede, usar allowlists ou espelhos internos para dependências aprovadas e exigir revisão de projetos abertos antes de execução local. Dependências de projetos GitHub devem ser avaliadas pela necessidade técnica, histórico do mantenedor, consistência de reputação e comportamento dos scripts de instalação. Em pipelines, builds devem rodar com permissões mínimas, sem segredos amplos por padrão e com bloqueio para downloads externos inesperados durante a resolução de dependências. A defesa mais efetiva é tratar a instalação de pacote como código executável de terceiros, não como simples leitura de bibliotecas.

• Remover apicolor e judyb de manifests, lockfiles, caches, ambientes virtuais, imagens de contêiner e pipelines automatizados.
• Investigar hosts que instalaram o pacote, com foco em processos filhos de Python, executáveis baixados, escrita em diretórios temporários e conexões externas no período.
• Recriar ambientes afetados a partir de dependências verificadas e limpar caches internos que possam preservar o pacote removido do índice público.
• Aplicar política de revisão para projetos GitHub antes de instalação, considerando atividade real do mantenedor, necessidade das dependências e sinais artificiais de reputação.