PCPJack rouba credenciais e explora cinco CVEs para se propagar em ambientes de nuvem

Framework malicioso mira Docker, Kubernetes, Redis, MongoDB, RayML e aplicações web vulneráveis para coletar segredos, mover-se lateralmente e exfiltrar dados via infraestrutura controlada pelo operador.

Componente	Framework PCPJack, composto por scripts shell, módulos Python, binários Sliver e rotinas voltadas a Docker, Kubernetes, Redis, MongoDB, RayML, IMDS e serviços de nuvem.
Vetor	Execução inicial por script bootstrap em infraestrutura exposta, seguida de exploração de falhas conhecidas, coleta de alvos em arquivos parquet do Common Crawl e propagação para serviços acessíveis.
Impacto	Roubo de credenciais de nuvem, contêineres, ferramentas de desenvolvimento, produtividade e serviços financeiros, com exfiltração criptografada e possibilidade de movimento lateral entre hosts comprometidos.
Prioridade	Remover exposição pública indevida de Docker, Kubernetes, Redis, MongoDB e RayML, corrigir as CVEs citadas, caçar os artefatos do conjunto e rotacionar segredos acessíveis a partir dos hosts afetados.
Versões	O contexto técnico cita exploração de CVE-2025-55182, CVE-2025-29927, CVE-2026-1357, CVE-2025-9501 e CVE-2025-48703, sem mapear cada CVE a um produto ou versão específica.
Artefatos	worm.py, monitor.py, parser.py, utils.py, lateral.py, _lat.py, crypto_util.py, _cu.py, cloud_ranges.py, _cr.py, cloud_scan.py, _csc.py e check.sh.

Resumo técnico

PCPJack é um framework de roubo de credenciais voltado a infraestrutura de nuvem exposta, com comportamento de propagação semelhante a worm e foco em serviços usados para orquestração, armazenamento, computação distribuída e desenvolvimento. O conjunto mira Docker, Kubernetes, Redis, MongoDB, RayML e aplicações web vulneráveis, combinando exploração de falhas conhecidas, varredura de portas, coleta de segredos locais e movimentação lateral. A operação não se limita a um binário único: o fluxo envolve um script bootstrap, módulos Python especializados, um binário Sliver selecionado por arquitetura de CPU e comunicação com canal de comando e controle via Telegram.

A finalidade operacional observada é monetizar acessos e credenciais, não minerar criptomoedas diretamente no host comprometido. O conjunto coleta dados de serviços de nuvem, contêineres, ambientes de desenvolvimento, produtividade e finanças, depois envia o material para infraestrutura controlada pelo operador. Um aspecto técnico relevante é a remoção deliberada de artefatos associados ao TeamPCP, grupo que já explorava vulnerabilidades conhecidas e más configurações em serviços de nuvem. PCPJack compartilha alvos e práticas com esse ecossistema, mas remove funções de mineração ligadas a ele e registra, no campo PCP replaced, se conseguiu desalojar artefatos concorrentes do ambiente comprometido.

Fluxo técnico

A infecção começa com um script shell de bootstrap que prepara o ambiente para a execução dos estágios seguintes. Esse script configura o host de payload, baixa ferramentas adicionais, tenta infectar a própria infraestrutura usada pelo operador, encerra processos associados ao TeamPCP, remove artefatos relacionados, instala Python, cria persistência, baixa seis scripts Python, executa o orquestrador principal e depois remove a si mesmo. Esse desenho reduz vestígios do estágio inicial e transfere a lógica para módulos separados, o que facilita atualização, reutilização e adaptação do conjunto sem alterar todo o fluxo de ataque.

O orquestrador principal é worm.py, gravado em disco como monitor.py. Ele coordena os módulos especializados, executa roubo local de credenciais, aciona propagação para outros hosts e usa Telegram como canal de C2. A lista de alvos externos não depende apenas de varredura aleatória: o worm baixa arquivos parquet do Common Crawl para obter candidatos de propagação. A partir daí, combina dados de faixas de nuvem, varredura de portas e exploração de falhas conhecidas, incluindo CVE-2025-55182, CVE-2025-29927, CVE-2026-1357, CVE-2025-9501 e CVE-2025-48703. O contexto não fornece o mapeamento entre cada CVE e produto afetado, portanto a validação defensiva deve tratar a lista como indicador de exploração usada pela campanha, não como matriz completa de exposição.

parser.py, também referenciado como utils.py, trata a extração e categorização de chaves, tokens e segredos. lateral.py, gravado como _lat.py, apoia reconhecimento, coleta de segredos e movimento lateral em SSH, Kubernetes, Docker, Redis, RayML e MongoDB. crypto_util.py, ou _cu.py, criptografa credenciais antes da exfiltração para o canal do atacante. cloud_ranges.py, gravado como _cr.py, coleta faixas de endereços atribuídas a AWS, Google Cloud, Microsoft Azure, Cloudflare, CloudFront e Fastly, atualizando esses dados a cada 24 horas. cloud_scan.py, ou _csc.py, executa varredura de portas em nuvem para apoiar propagação externa por serviços Docker, Kubernetes, MongoDB, RayML ou Redis.

O script check.sh adiciona uma camada de capacidade pós-comprometimento. Ele identifica a arquitetura da CPU e baixa o binário Sliver compatível, ao mesmo tempo em que examina endpoints de Instance Metadata Service, contas de serviço do Kubernetes e instâncias Docker em busca de credenciais. Os serviços citados como alvo incluem Anthropic, DigitalOcean, Discord, Google API, Grafana Cloud, HashiCorp Vault, OnePassword e OpenAI. Esse comportamento é particularmente sensível porque o comprometimento de um nó com acesso a metadados, volumes de contêiner, variáveis de ambiente ou service accounts pode dar ao operador credenciais úteis fora do host inicial.

Superfície afetada

A superfície de risco concentra-se em ambientes de nuvem com serviços administrativos ou de dados expostos, aplicações web vulneráveis e hosts que mantêm credenciais acessíveis localmente. Docker exposto pode permitir enumeração de contêineres, acesso a variáveis de ambiente, montagem de volumes ou execução de novos processos quando a interface está indevidamente acessível. Kubernetes fica em risco quando contas de serviço, tokens montados em pods, permissões excessivas ou APIs alcançáveis permitem ao malware consultar recursos e avançar para outros workloads. Redis, MongoDB e RayML aparecem como pontos de propagação e coleta quando implantados sem segmentação adequada, autenticação robusta ou correções relevantes.

A campanha também amplia o risco para equipes de engenharia e operações porque procura credenciais de serviços usados em desenvolvimento, observabilidade, cofre de segredos, APIs de IA, produtividade e infraestrutura. Um host comprometido que pareça apenas um nó auxiliar pode conter tokens com alcance de organização, chaves de API, credenciais de cloud provider, configurações de Docker, kubeconfigs, arquivos de ambiente, histórico de execução ou metadados de instância. Como o conjunto atualiza faixas de nuvem e usa dados externos para orientar propagação, ambientes com exposição pública intermitente também entram no escopo de caça, mesmo que o serviço vulnerável tenha sido publicado por pouco tempo.

• Serviços Docker, Kubernetes, Redis, MongoDB e RayML acessíveis a partir da internet ou de redes pouco segmentadas.
• Hosts com acesso a IMDS, service accounts do Kubernetes, sockets Docker, kubeconfigs, variáveis de ambiente ou arquivos com segredos.
• Ambientes que ainda não corrigiram as falhas identificadas como CVE-2025-55182, CVE-2025-29927, CVE-2026-1357, CVE-2025-9501 e CVE-2025-48703.
• Contas e integrações associadas a Anthropic, DigitalOcean, Discord, Google API, Grafana Cloud, HashiCorp Vault, OnePassword e OpenAI quando credenciais estiverem presentes no host.

Hunting e telemetria

A caça deve começar por execução de scripts shell e Python em servidores de nuvem, especialmente quando houver download encadeado de módulos, instalação inesperada de Python, criação de persistência e remoção do próprio script inicial. Em endpoint e EDR, procure gravações ou execuções de monitor.py, utils.py, _lat.py, _cu.py, _cr.py, _csc.py, worm.py, parser.py, lateral.py, crypto_util.py, cloud_ranges.py, cloud_scan.py e check.sh. A presença desses nomes não é necessária para confirmar atividade, pois o operador pode renomear artefatos, mas eles são pontos objetivos para retrocaça em discos, históricos de shell, logs de processo, telemetria de criação de arquivo e alertas de execução de interpretadores.

Na rede, eventos de saída para Telegram a partir de servidores que não deveriam se comunicar com a plataforma merecem investigação, sobretudo quando próximos de varreduras internas, consultas a metadados ou execução de Python. Também é importante revisar acesso a IMDS, leituras incomuns de service accounts em pods, chamadas anômalas a APIs de Kubernetes, conexão com sockets Docker, enumeração de bancos Redis e MongoDB e varreduras direcionadas a portas associadas a esses serviços. Como cloud_ranges.py atualiza faixas de AWS, Google Cloud, Microsoft Azure, Cloudflare, CloudFront e Fastly a cada 24 horas, padrões de varredura saindo de instâncias comprometidas para blocos de nuvem podem indicar tentativa de expansão externa.

Em identidade e segredos, a investigação deve correlacionar o tempo de execução do malware com uso posterior de tokens. Chaves de API consultadas ou usadas logo após atividade suspeita no host devem ser tratadas como comprometidas. Revise logs de Grafana Cloud, Vault, provedores de nuvem, plataformas de IA, contas de produtividade e serviços financeiros associados aos ambientes afetados. Para Kubernetes, compare permissões reais das service accounts com chamadas observadas; uso de permissões de listagem, criação de pods, leitura de secrets ou acesso a namespaces não relacionados ao workload pode indicar movimento lateral ou preparação para persistência.

• Execução de check.sh ou scripts Python com nomes monitor.py, _lat.py, _cu.py, _cr.py e _csc.py em hosts de nuvem.
• Instalação inesperada de Python, download de múltiplos módulos e remoção do script shell inicial logo após execução.
• Conexões de saída para Telegram originadas de servidores, contêineres ou nós Kubernetes sem necessidade operacional.
• Consultas a IMDS, leitura de tokens de service account e acesso incomum ao socket Docker ou à API do Kubernetes.
• Varreduras para Docker, Kubernetes, Redis, MongoDB e RayML partindo de workloads internos ou instâncias cloud.

Mitigação

A resposta deve combinar contenção do host, revogação de credenciais e redução da superfície exposta. Instâncias com indício de PCPJack devem ser isoladas da rede, preservando evidências de disco, memória quando disponível, histórico de processos, logs de rede e artefatos em diretórios temporários ou de trabalho. Em seguida, remova persistências desconhecidas, bloqueie comunicação de saída desnecessária para Telegram, interrompa serviços expostos indevidamente e revise se há binários Sliver compatíveis com a arquitetura do sistema. A limpeza do arquivo malicioso não basta quando o host tinha acesso a credenciais, metadados ou contas de serviço.

A rotação de segredos deve priorizar chaves encontradas em variáveis de ambiente, arquivos de configuração, kubeconfigs, secrets do Kubernetes, credenciais Docker, tokens de Vault, chaves de provedores de nuvem e APIs ligadas a Anthropic, DigitalOcean, Discord, Google API, Grafana Cloud, OnePassword e OpenAI. Tokens com privilégio administrativo ou escopo amplo devem ser revogados antes de recriação com permissões menores. No Kubernetes, revise service accounts montadas por padrão, políticas RBAC, namespaces acessíveis e permissões para leitura de secrets. Em Docker, remova exposição remota não autenticada e limite acesso ao socket apenas a processos que realmente precisam dele.

A correção deve incluir aplicação de patches relacionados às CVEs citadas, validação de versões dos produtos afetados no inventário interno e bloqueio de serviços administrativos na borda. Redis e MongoDB não devem ficar acessíveis publicamente sem autenticação forte, controle de origem e monitoração de comandos sensíveis. RayML, APIs de Kubernetes e endpoints Docker devem ser protegidos por segmentação, autenticação e políticas de menor privilégio. Depois da contenção, execute retrocaça em logs históricos para identificar quando a primeira execução ocorreu, quais credenciais estavam disponíveis naquele período e se houve autenticação bem-sucedida com esses segredos em outros serviços.

• Isolar hosts suspeitos, preservar evidências e bloquear saída desnecessária para Telegram durante a investigação.
• Corrigir exposições e vulnerabilidades associadas a CVE-2025-55182, CVE-2025-29927, CVE-2026-1357, CVE-2025-9501 e CVE-2025-48703 conforme o inventário real de produtos.
• Revogar e recriar credenciais presentes no host comprometido, incluindo tokens de nuvem, Kubernetes, Docker, Vault, observabilidade e APIs externas.
• Remover acesso público indevido a Docker, Kubernetes, Redis, MongoDB e RayML, aplicando segmentação e autenticação forte.
• Revisar permissões de service accounts, escopos de chaves de API e uso posterior dos segredos em logs de identidade e provedores cloud.