Campanha automatizada mira APIs Docker expostas, Kubernetes, Ray, Redis e falhas em aplicações React/Next.js para criar proxies, túneis, C2, mineração e roubo de dados.
| Componente | Ambientes cloud native com APIs Docker expostas, clusters Kubernetes, painéis Ray, servidores Redis e aplicações React/Next.js vulneráveis. |
| Vetor | Exploração oportunista de serviços expostos, configurações incorretas e vulnerabilidades conhecidas, incluindo React2Shell CVE-2025-55182 e um módulo react.py associado a CVE-2025-29927. |
| Impacto | Implantação de scripts shell e Python para varredura, propagação, túneis, proxies, relays C2, mineração de criptomoedas, hospedagem de dados, roubo de informações e extorsão. |
| Prioridade | Remover exposição pública de APIs administrativas, corrigir aplicações vulneráveis, auditar workloads Kubernetes e procurar execução de proxy.sh, scanner.py, kube.py, react.py e pcpcat.py. |
| Artefatos | A cadeia inclui proxy.sh, scanner.py, kube.py, react.py, pcpcat.py e referência ao nó C2 defangado 67.217.57[.]240. |
| Alvos | A atividade foi observada principalmente contra ambientes AWS e Microsoft Azure, com seleção oportunista de infraestrutura útil para escala, não de setores específicos. |
A campanha atribuída ao cluster TeamPCP, também identificado pelos nomes DeadCatx3, PCPcat, PersyPCP e ShellForce, opera como um worm voltado a ambientes cloud native. A atividade foi observada por volta de 25 de dezembro de 2025 e combina exploração automatizada, varredura contínua e implantação de componentes auxiliares para transformar infraestrutura exposta em uma malha de abuso. O objetivo técnico não se limita ao comprometimento inicial: a cadeia tenta criar uma base distribuída para proxy, tunelamento, comando e controle, hospedagem de dados, mineração de criptomoedas, roubo de informações e extorsão.
O diferencial operacional está na integração de técnicas conhecidas em um fluxo industrializado. Em vez de depender de exploração inédita, o grupo usa APIs Docker e Kubernetes mal configuradas, painéis Ray acessíveis, Redis exposto e aplicações React/Next.js vulneráveis. Esse conjunto reduz a barreira de entrada porque muitas organizações mantêm serviços administrativos acessíveis por erro de configuração, ausência de autenticação forte, segmentação fraca ou permissões excessivas em workloads. A consequência é um ecossistema de propagação em que servidores comprometidos passam a procurar novos alvos, ampliando a superfície da própria operação criminosa.
A infraestrutura abusada tem papel duplo. Primeiro, fornece computação e conectividade para executar scanners, proxies, relays e mineradores. Segundo, serve como ponto de apoio para coleta e publicação de dados roubados, incluindo bases de currículos, registros de identidade e informações corporativas citadas na atividade do grupo. Essa combinação permite monetizar tanto recursos computacionais quanto informação, o que aumenta a resiliência da operação diante de remoções parciais de infraestrutura.
A cadeia começa com descoberta em larga escala de serviços alcançáveis pela internet. O componente pcpcat.py é descrito como uma rotina para percorrer grandes faixas de endereços IP em busca de APIs Docker e painéis Ray expostos, implantando contêineres ou jobs maliciosos quando encontra uma superfície explorável. O uso de payload codificado em Base64 aparece como mecanismo de entrega, mas a função relevante para defesa é a execução remota de estágio inicial dentro do serviço vulnerável ou mal configurado, sem necessidade de interação legítima do operador da vítima.
O módulo scanner.py amplia a varredura ao baixar listas CIDR de uma conta GitHub associada ao nome DeadCatx3. A rotina procura APIs Docker e Ray dashboards com configuração insegura e também possui opção relacionada a mineração por meio de mine.sh. Para equipes de defesa, isso indica que o comprometimento pode gerar tráfego de saída incomum para obtenção de listas de rede, aumento súbito de conexões contra portas e serviços administrativos e criação de processos com perfil de scanner dentro de instâncias que normalmente não executam esse tipo de atividade.
O script proxy.sh é um dos componentes centrais. Ele instala utilitários de proxy, P2P e tunelamento, além de entregar scanners para continuar a busca por servidores vulneráveis. Durante a execução, o script realiza fingerprinting do ambiente e verifica se está dentro de um cluster Kubernetes. Quando identifica Kubernetes, segue uma trilha específica e baixa um payload secundário direcionado a esse contexto. Essa ramificação mostra que a operação não trata servidores Linux e clusters cloud native como alvos equivalentes; há lógica própria para ambientes orquestrados.
O componente kube.py concentra ações específicas contra Kubernetes. Ele realiza descoberta via API, coleta credenciais do cluster e enumera recursos como pods e namespaces. Depois, tenta levar proxy.sh para pods acessíveis e configurar persistência por meio de pods privilegiados em cada nó, com montagem do host. Esse comportamento é crítico porque transforma uma execução em workload em risco para o nó subjacente, principalmente quando políticas de admissão, permissões de serviço e restrições de privilégio não bloqueiam contêineres privilegiados ou montagens sensíveis.
A campanha também explora falhas em aplicações React/Next.js. O material técnico cita React2Shell CVE-2025-55182 com severidade máxima e descreve react.py como módulo voltado à exploração de CVE-2025-29927 para execução remota de comandos em escala. Na operação defensiva, essas referências devem ser tratadas como trilhas de verificação separadas: inventário de aplicações expostas, versão efetivamente executada, presença de correções e logs de requisições anômalas precisam ser correlacionados antes de concluir qual falha foi usada em cada ambiente.
A superfície mais exposta envolve planos de controle e interfaces administrativas que não deveriam estar disponíveis publicamente. APIs Docker expostas permitem criação de contêineres ou execução de workloads quando não há autenticação e segmentação adequadas. Clusters Kubernetes ficam em risco quando a API aceita requisições não autorizadas, quando tokens de serviço têm escopo excessivo ou quando workloads conseguem montar recursos do host. Ray dashboards e Redis expostos aumentam a área de ataque por funcionarem como componentes de infraestrutura frequentemente implantados por times de dados, engenharia e automação com foco em disponibilidade, nem sempre com controles de segurança equivalentes aos de aplicações externas.
A atividade foi observada com foco predominante em AWS e Microsoft Azure. Isso não significa que o ataque dependa exclusivamente desses provedores, mas indica que ambientes com elasticidade, endereçamento público, instâncias efêmeras e múltiplos times criando recursos podem oferecer material abundante para a campanha. Organizações atingidas podem ser vítimas colaterais quando executam o tipo de infraestrutura útil para proxy, varredura, C2, hospedagem ou mineração, mesmo sem pertencer a um setor previamente selecionado.
A presença pública do grupo em canal Telegram com mais de 700 membros e a publicação de dados de vítimas no Canadá, Sérvia, Coreia do Sul, Emirados Árabes Unidos e Estados Unidos reforçam que a operação combina infraestrutura comprometida e exposição de dados. Para defesa, a conclusão prática é que um incidente inicialmente classificado como abuso de compute ou mineração pode evoluir para roubo de informações e extorsão se credenciais, volumes, buckets, bancos de dados ou segredos de CI/CD estiverem acessíveis a partir do ambiente comprometido.
- APIs Docker acessíveis pela internet sem controles fortes de autenticação e rede.
- Clusters Kubernetes com API exposta, permissões amplas, pods privilegiados ou montagem do host permitida.
- Ray dashboards e Redis alcançáveis externamente por configuração incorreta.
- Aplicações React/Next.js expostas sem correções para as falhas citadas.
- Ambientes AWS e Microsoft Azure usados como fonte de compute, tráfego, proxy e persistência operacional.
A investigação deve começar pela fronteira de exposição. Inventários de ativos, logs de firewall, registros de balanceadores, grupos de segurança, regras de NSG, portas administrativas e trilhas de auditoria cloud devem ser usados para identificar Docker API, Kubernetes API, Ray e Redis publicados indevidamente. A ausência de autenticação, a origem de requisições em faixas incomuns e a criação repentina de workloads fora do fluxo de implantação esperado são sinais relevantes.
Em Kubernetes, a telemetria de auditoria deve ser revisada para criação de pods privilegiados, uso de hostPath, montagem de diretórios do host, enumeração incomum de pods e namespaces, criação de recursos em múltiplos nós e uso de contas de serviço fora do padrão da aplicação. Também é importante procurar execução de shells, downloads externos, processos de proxy, scanners e conexões persistentes a destinos desconhecidos. Em nós de cluster, picos de CPU associados a mineração, novos binários de tunelamento e tráfego de varredura de saída indicam possível uso da infraestrutura como pivô.
Em Docker, os sinais incluem criação de contêineres fora do pipeline normal, imagens desconhecidas, comandos de inicialização incomuns, containers com privilégios elevados e conexões para baixar scripts ou listas de endereços. Em ambientes Ray, jobs submetidos por origens externas, execução de código não relacionada às cargas de trabalho de dados e conexões de saída de workers devem ser tratados como evidência de abuso. Para Redis, a busca deve focar exposição pública, comandos administrativos atípicos, persistência inesperada e conexões vindas de redes sem relação com a aplicação.
Na rede, a defesa deve correlacionar tráfego para o nó C2 defangado 67.217.57[.]240, quando aplicável, com conexões para relays, túneis e infraestrutura P2P. A presença de Sliver associada ao nó citado eleva a prioridade da investigação de pós-exploração, mas a confirmação deve depender de telemetria local: processos, conexões, memória, artefatos em disco e eventos de criação de sessão. Como a operação reaproveita ferramentas conhecidas e componentes abertos modificados, detecções baseadas apenas em nome de arquivo podem falhar; comportamento e contexto são mais confiáveis.
- Criação de pods privilegiados, uso de
hostPathe montagem do host em Kubernetes. - Execução ou presença de
proxy.sh,scanner.py,kube.py,react.py,pcpcat.pyemine.sh. - Tráfego de saída com padrão de varredura, tunelamento, proxy, P2P ou mineração em servidores que não executam essas funções.
- Jobs Ray, contêineres Docker ou workloads Kubernetes criados fora do processo normal de implantação.
- Conexões para C2 defangado
67.217.57[.]240ou para infraestrutura externa sem relação operacional conhecida.
A resposta deve priorizar remoção de exposição antes de limpeza pontual. APIs Docker, Kubernetes, Ray e Redis não devem ficar publicamente acessíveis por padrão. Onde o acesso remoto for necessário, ele deve ser limitado por rede privada, VPN, identidade forte, autorização explícita e monitoramento. Em Kubernetes, controles de admissão devem bloquear pods privilegiados, montagens do host e permissões incompatíveis com o perfil da aplicação. Contas de serviço precisam de escopo mínimo e tokens devem ser rotacionados quando houver suspeita de coleta de credenciais.
Para aplicações React/Next.js, a mitigação exige inventário de serviços expostos e verificação objetiva de correção para as falhas citadas. Como a cadeia menciona React2Shell CVE-2025-55182 e um módulo de exploração associado a CVE-2025-29927, a validação não deve se apoiar apenas em nome de framework. É necessário confirmar versões, dependências implantadas, imagens de contêiner, artefatos de build e rotas acessíveis. Logs de aplicação e de borda devem ser preservados para diferenciar exploração tentada, falha e execução confirmada.
Após conter a exposição, a limpeza deve tratar infraestrutura comprometida como potencialmente não confiável. Instâncias, nós e contêineres que executaram payloads de proxy, scanner, túnel ou mineração podem ter sido usados para roubo de segredos, movimentação dentro do ambiente cloud e preparação de extorsão. A resposta deve incluir coleta forense proporcional, revogação de credenciais, revisão de chaves de acesso, inspeção de buckets, bancos e volumes montados, além de busca por tarefas agendadas, imagens persistentes, pods recorrentes e artefatos de C2.
A validação final deve medir reincidência. Se novos scanners ou proxies reaparecem após a remoção, a organização ainda mantém vetor inicial aberto ou credencial válida em posse do operador. A defesa deve combinar bloqueio de exposição, correção de vulnerabilidades, políticas de runtime, detecção comportamental e auditoria de identidade cloud para impedir que a campanha recupere presença usando o mesmo fluxo automatizado.
- Fechar exposição pública de Docker API, Kubernetes API, Ray dashboards e Redis; permitir acesso apenas por caminhos autenticados e restritos.
- Aplicar correções em aplicações React/Next.js vulneráveis e validar versões realmente implantadas em produção.
- Bloquear pods privilegiados, montagens do host e permissões excessivas por políticas de admissão e segurança de runtime.
- Revogar e rotacionar tokens, chaves cloud, credenciais de cluster e segredos acessíveis a workloads suspeitos.
- Remover contêineres, jobs, pods e scripts não autorizados, depois reconstruir nós comprometidos quando houver indício de persistência ou acesso ao host.
- Monitorar criação de novos proxies, túneis, scanners, relays C2 e mineração após a contenção inicial.
0 Comentários