## Operação Clandestina de Nuvem do PCPJack Descoberta O ator de ameaça conhecido como **PCPJack** orquestrou uma campanha sofisticada, sequestrando servidores em nuvem da **Amazon Web Services (AWS)**, **Google Cloud** e **Microsoft Azure** para forjar uma rede massiva e oculta de retransmissão de e-mails SMTP. Essa extensa infraestrutura converteu silenciosamente servidores corporativos comprometidos nos EUA, Europa e Ásia em proxies SMTP, que foram então verificados quanto às capacidades de retransmissão de e-mail e sincronizados com um consumidor downstream a cada cinco minutos. A empresa de inteligência de ameaças **Hunt.io** descobriu a operação, observando que a infraestrutura ainda estava totalmente ativa na descoberta. "Servidores corporativos comprometidos nos EUA, Europa e Ásia foram silenciosamente convertidos em proxies SMTP, verificados quanto à capacidade de retransmissão de e-mail e sincronizados com um consumidor downstream a cada cinco minutos", afirmou a **Hunt.io**. "A infraestrutura ainda estava em funcionamento quando a encontramos."  ## Descoberta Acidental: Servidor C2 Aberto Expõe Táticas Os detalhes intrincados da campanha do **PCPJack** vieram à tona devido a uma falha crítica de segurança operacional. O ator de ameaça deixou dois diretórios abertos em um servidor de comando e controle (C2) (213.136.80[.]73) sem qualquer autenticação. Essa negligência permitiu que a **Hunt.io** acessasse o código-fonte, binários compilados, logs de estado de implantação, scanners de internet, ferramentas de exploração e uma configuração ativa do **Sliver**. O **PCPJack** surgiu pela primeira vez em abril de 2026, identificado pela **SentinelOne** como um framework de roubo de credenciais que visava especificamente serviços em nuvem. Notavelmente, o **PCPJack** também toma medidas para remover artefatos associados ao **TeamPCP**, outro grupo de hacking proeminente conhecido por seus ataques à cadeia de suprimentos de software, sugerindo rivalidade ou uma tentativa de ofuscar sua identidade. ## Ferramentas do Ofício: Sliver, Chisel e Scripts Personalizados Entre os arquivos descobertos nos diretórios abertos estava um kit de ferramentas de implantação de proxy SMTP integrado ao **Sliver**. Este kit de ferramentas incluía binários de tunelamento e proxy **Chisel**, compilados para várias arquiteturas de CPU Linux, como AMD64, ARM64 e x86. Nas máquinas vítimas, o binário é discretamente depositado como um arquivo oculto prefixado por ponto e persistido em "/var/tmp/.xs". Scripts de implantação também foram encontrados, projetados para carregar a configuração do cliente C2 do **Sliver** e filtrar por beacons Linux. Esses beacons são implantes que se conectam periodicamente ao servidor C2 para verificar e recuperar comandos. ## Gerenciamento Sofisticado de Proxy A operação demonstra capacidades avançadas de gerenciamento de proxy. "Cada beacon recebe uma porta de proxy SOCKS5 derivada deterministicamente de um hash MD5 de seu UUID do **Sliver**, mapeada para o intervalo 10000-14999", explicou a **Hunt.io**. "O mesmo beacon sempre é mapeado para a mesma porta entre as execuções, eliminando a necessidade de um registro de porta compartilhado."  Um componente crucial do script de implantação é um "gate de qualidade" SMTP. Este gate sonda o acesso de saída para `smtp.gmail[.]com:587`. Hosts que falham nesta verificação são ignorados, pois "hosts que não conseguem retransmitir e-mail não têm valor para este pipeline", de acordo com a empresa de cibersegurança. Os beacons são processados em lotes de 50, com atrasos programados para acomodar intervalos lentos de verificação. ## Táticas em Evolução e Capacidades de Diagnóstico Iterações posteriores dos scripts de implantação mostram uma evolução, com a remoção do gate SMTP e da lógica de loteamento. Além disso, um script de diagnóstico estava presente, projetado para selecionar cinco beacons ativos e atribuir-lhes comandos de shell para verificar: * Presença de binários **Chisel** em caminhos de depósito conhecidos * Um processo **Chisel** está ativamente em execução * Espaço em disco disponível * Acessibilidade da porta 9000 no C2 * Presença de artefatos de persistência, como entradas cron ou serviços systemd  O servidor C2 também executa um script Python, `chisel_verifier.py`, como um daemon de segundo plano persistente. Este script enumera as portas ativas do túnel **Chisel** via `ss -tlnp` a cada 60 segundos, testa-as quanto à capacidade SMTP e remove quaisquer túneis falhados ou descartados do pool ativo. ## Enriquecimento de Proxy e Motivo Desconhecido Proxies verificados são ainda mais enriquecidos com dados de endereço IP de saída, país e Número de Sistema Autônomo (**ASN**) usando serviços como `api.ipify[.]org` e `ip-api[.]com`. Essas listas de proxy refinadas são então sincronizadas a cada cinco minutos via **Secure Copy Protocol (SCP)** para um servidor downstream separado (38.242.204[.]245), embora este servidor esteja atualmente inacessível. O propósito final desta operação extensa permanece incerto. A **Hunt.io** a descreveu como uma campanha oportunista, afirmando: "O resultado de 230 nós é o resultado observável. Se essa progressão reflete um único operador iterando ou múltiplos atores compartilhando a mesma infraestrutura não pode ser determinado a partir dos arquivos recuperados." Independentemente da intenção específica, as implicações são significativas. "A lista de proxies verificados está sendo sincronizada a cada cinco minutos para este servidor, e alguém está consumindo-a. Seja para spam, phishing ou algo mais, a infraestrutura para entrega em escala estava claramente em funcionamento."