PCPJack sequestra 230 servidores em AWS, Google Cloud e Azure para criar rede oculta de relay SMTP

O agente de ameaça conhecido como PCPJack sequestrou servidores em ambientes associados à Amazon Web Services, Google Cloud e Microsoft Azure para montar uma rede oculta de relay SMTP, usada para encaminhamento de e-mails por meio de infraestrutura comprometida. A descoberta foi divulgada pela Hunt.io, que identificou servidores empresariais comprometidos nos Estados Unidos, Europa e Ásia convertidos silenciosamente em proxies SMTP.

Segundo a empresa de inteligência de ameaças, os servidores invadidos eram verificados quanto à capacidade de retransmitir e-mails e sincronizados com um consumidor downstream a cada cinco minutos. A infraestrutura ainda estava em operação quando foi encontrada pelos pesquisadores.

A investigação ganhou força após o operador por trás da campanha deixar dois diretórios abertos, sem autenticação, em um servidor de comando e controle localizado em “213.136.80[.]73”. Nesses diretórios, a Hunt.io encontrou 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, framework de comando e controle usado em operações ofensivas.

O PCPJack foi identificado pela primeira vez pela SentinelOne em abril de 2026, quando pesquisadores descobriram um framework de roubo de credenciais voltado especificamente para serviços em cloud. Na ocasião, a atividade também chamou atenção por tentar encerrar e remover processos ou artefatos associados ao TeamPCP, outro grupo hacker que ganhou visibilidade nos últimos meses por ataques à cadeia de suprimentos de software.

Em um dos diretórios expostos, os pesquisadores encontraram um toolkit de implantação de proxies SMTP integrado ao Sliver, além de binários do Chisel, ferramenta usada para tunelamento e proxy, compilados para várias arquiteturas Linux, incluindo AMD64, ARM64 e x86. Nos sistemas das vítimas, o binário era instalado como um arquivo oculto com prefixo de ponto e persistia no caminho “/var/tmp/.xs”.

Também foram encontrados scripts de implantação criados para carregar a configuração do cliente Sliver C2 e filtrar beacons Linux que haviam se comunicado com o servidor nos dez minutos anteriores. Em operações desse tipo, beacons são implantes que se conectam periodicamente ao servidor de comando e controle para informar que estão ativos e buscar novas instruções.

De acordo com a Hunt.io, cada beacon recebia uma porta de proxy SOCKS5 derivada de forma determinística a partir de um hash MD5 do UUID do Sliver. Esse valor era mapeado dentro da faixa de portas 10000 a 14999. Com isso, o mesmo beacon sempre era associado à mesma porta em diferentes execuções, eliminando a necessidade de manter um registro compartilhado de portas.

O script também executava uma etapa de validação de qualidade SMTP. Essa checagem testava se o host comprometido conseguia estabelecer comunicação de saída com “smtp.gmail[.]com:587”. Máquinas que falhavam nesse teste eram ignoradas com código de saída zero, indicando que não serviam ao objetivo da operação.

Para a Hunt.io, esse mecanismo deixa clara a finalidade da campanha: servidores incapazes de retransmitir e-mails não tinham valor para a infraestrutura montada pelo PCPJack. Os beacons eram processados em lotes de 50, com espera de 25 minutos após uploads e 15 minutos após comandos de execução, para acomodar implantes configurados com intervalos lentos de comunicação com o C2.

Versões posteriores dos scripts de implantação removeram tanto a validação SMTP quanto a lógica de processamento em lotes. Os pesquisadores também identificaram um script de diagnóstico que selecionava cinco beacons ativos e enviava comandos shell para verificar a presença de binários Chisel em caminhos conhecidos, confirmar se um processo Chisel estava em execução, avaliar espaço em disco, testar a conectividade com a porta 9000 no C2 e verificar artefatos de persistência, como entradas de cron ou serviços systemd.

O servidor de comando e controle também executava um script Python chamado “chisel_verifier.py” como daemon persistente em segundo plano. Esse script enumerava portas de túneis Chisel ativas por meio do comando “ss -tlnp” a cada 60 segundos, testava cada nova porta quanto à capacidade de relay SMTP e removia túneis com falha ou indisponíveis do pool ativo.

Os proxies verificados eram enriquecidos com informações como endereço IP de saída, país e ASN, usando serviços como “api.ipify[.]org” e “ip-api[.]com”. Em seguida, as listas de proxies eram sincronizadas a cada cinco minutos, por meio do protocolo SCP, com um servidor downstream separado em “38.242.204[.]245”. Esse servidor não estava acessível no momento da análise.

O objetivo final da operação ainda não foi determinado. No entanto, a infraestrutura construída pelo PCPJack tinha capacidade clara de envio em escala, o que poderia ser usado para spam, phishing ou outras campanhas que dependem de retransmissão de e-mails por servidores com melhor reputação do que infraestruturas maliciosas tradicionais.

A Hunt.io descreveu a campanha como oportunista e afirmou que o resultado observável foi uma rede com 230 nós. Ainda não é possível determinar, com base nos arquivos recuperados, se essa evolução representa a ação de um único operador ajustando a infraestrutura ao longo do tempo ou de múltiplos atores compartilhando o mesmo ambiente.

A relevância do caso está no abuso de servidores cloud empresariais para criar uma camada de infraestrutura difícil de atribuir e bloquear. Ao transformar máquinas legítimas hospedadas em AWS, Google Cloud e Azure em proxies SMTP, os operadores podem se beneficiar da reputação de provedores amplamente confiáveis e distribuir o tráfego por diferentes regiões, dificultando ações de resposta baseadas apenas em bloqueio de IPs ou domínios.

A campanha também mostra como frameworks de C2, ferramentas de tunelamento e scripts de automação podem ser combinados para transformar servidores comprometidos em recursos operacionais reutilizáveis. Nesse caso, a infraestrutura não parecia voltada apenas ao acesso inicial ou à movimentação lateral, mas à criação de uma rede funcional de retransmissão, validada continuamente e sincronizada com outro servidor para consumo externo.

Para equipes de segurança, a atividade reforça a importância de monitorar servidores Linux em ambientes cloud em busca de arquivos ocultos incomuns em diretórios temporários, serviços systemd ou cron suspeitos, processos Chisel inesperados, beacons Sliver, conexões de saída para servidores SMTP e túneis SOCKS5 em portas altas. Também é recomendável revisar tráfego periódico para servidores desconhecidos, principalmente quando há sincronização constante ou comunicação com infraestrutura externa não documentada.