Um grupo de atacantes chamado PCPJack sequestrou 230 servidores em nuvem da AWS, Google Cloud e Microsoft Azure para montar uma rede clandestina de relay SMTP. Os servidores empresariais comprometidos nos EUA, Europa e Ásia foram convertidos silenciosamente em proxies de e-mail, verificados para relay e sincronizados a cada cinco minutos com um servidor downstream. A infraestrutura ainda estava rodando quando os pesquisadores da Hunt.io a encontraram.

A campanha foi descoberta depois que o operador deixou dois diretórios abertos em um servidor de comando e controle (C2) no IP 213.136.80[.]73, hospedado pela Contabo GmbH na França, sem qualquer autenticação. Os 12 arquivos expostos totalizavam 29,1 MB e incluíam código-fonte, binários compilados, logs de deploy e o estado completo da operação. Um segundo diretório no porto 9443 expunha o diretório /tmp ativo do atacante, com scanners, ferramentas de exploração e uma configuração Sliver C2 ao vivo.

Como os servidores são sequestrados

O PCPJack não escolhe alvos manualmente. Ele automatiza tudo. O grupo usa implantes do framework Sliver — uma ferramenta de C2 open-source popular entre red teams e APTs — que funcionam como beacons. Esses beacons se conectam periodicamente ao servidor C2 para receber comandos. A pipeline de deploy foi documentada em três versões de scripts Python recuperados pelos pesquisadores.

Na primeira versão, o script filtra beacons Linux ativos nos últimos dez minutos e executa um teste de qualidade SMTP — uma probe que verifica acesso de saída ao smtp.gmail.com:587. Servidores que falham no teste são descartados silenciosamente. O critério é claro: máquinas que não conseguem enviar e-mail não têm valor para a operação.

Na terceira versão, o script removeu o filtro SMTP e passou a implantar em todos os beacons ativos. O arquivo de estado recuperado confirma o resultado: 230 uploads executados com sucesso em uma única execução em março de 2026. Os beacons são processados em lotes de 50, com esperas de 25 minutos entre uploads e 15 minutos após execução, calibrados para o intervalo de check-in padrão do Sliver.

Persistência que passa despercebida

O binário do Chisel — ferramenta de tunelamento TCP open-source — é dropado como arquivo oculto em /var/tmp/.xs. O atacante prefere /var/tmp em vez de /tmp porque muitas distribuições Linux montam /tmp como tmpfs com a flag noexec, impedindo execução de binários. O nome “xsync” se disfarça como o utilitário rsync.

A persistência varia conforme privilégio. Com acesso root, o malware instala um serviço systemd chamado xsync. Sem root, instala um cron watchdog de cinco minutos. O comentário # xsync na entrada do crontab funciona como marcador, permitindo que runs subsequentes encontrem e substituam a entrada sem acumular duplicatas.

A infraestrutura de verificação SMTP

Após a implantação, um daemon Python chamado chisel_verifier.py roda continuamente no servidor C2. A cada 60 segundos, ele enumera as portas de túnel Chisel ativas via ss -tlnp, testa cada nova porta para capacidade SMTP e remove túneis falhos do pool ativo.

O teste SMTP é completo — não apenas uma verificação de porta. O daemon se conecta através do proxy SOCKS5 para smtp.gmail.com:587, lê o banner 220, envia saudação EHLO e tenta STARTTLS. Proxies verificados recebem enriquecimento de IP de saída, país e ASN via serviços como api.ipify.org e ip-api.com.

A lista de proxies verificados é sincronizada via SCP para /root/excalibur/smtp_proxies.csv no servidor downstream 38.242.204[.]245 a cada cinco minutos. O servidor não estava acessível durante a análise da Hunt.io. Alguém está consumindo esses dados — seja para spam, phishing ou outra operação em escala.

Conexão com TeamPCP e escala global

O PCPJack foi documentado pela primeira vez pela SentinelOne em abril de 2026 como um framework de roubo de credenciais voltado especificamente para serviços em nuvem. O grupo toma medidas para remover processos e artefatos associados ao TeamPCP, outro grupo notório responsável por ataques de supply chain nos últimos meses. A relação entre os dois grupos ainda não está clara.

O payload inclui binários Chisel stock para três arquiteturas — AMD64, ARM64 e x86 — cobrindo todas as arquiteturas de CPU Linux relevantes na nuvem, incluindo instâncias AWS Graviton. Os binários não foram modificados, o que significa que seus hashes combinam com o projeto upstream e podem não acionar detecções baseadas em hash.

Quais servidores correm risco real

A campanha afeta qualquer organização que rode servidores Linux expostos na nuvem. O foco em SMTP relay indica que o objetivo final é montar infraestrutura para campanhas de engenharia social em escala — phishing e smishing — com IPs de saída limpos e reputação de provedores legítimos como AWS e Azure. Empresas brasileiras com workloads Linux na nuvem estão no mesmo perfil de risco.

O acesso não autorizado a servidores empresariais continua sendo o vetor de entrada preferido. Uma vez dentro, o PCPJack automatiza a conversão do servidor em proxy sem interação humana, em escala industrial.

O que fazer agora

Para equipes de segurança e administradores de infraestrutura em nuvem, as ações de mitigação são diretas:

  1. Audite processos ativos em /var/tmp — procure arquivos ocultos com prefixo de ponto e nomes genéricos como .xs. Verifique serviços systemd com nomes suspeitos e entradas de cron sem justificativa.
  2. Monitore conexões SOCKS5 não autorizadas — especialmente na faixa de portas 10000-14999, o range usado pelo deployer do PCPJack. Conexões persistentes para portas altas em servidores sem expectativa de proxy são um sinal forte.
  3. Verifique acesso de saída a SMTP — muitos servidores em nuvem não precisam enviar e-mail. Bloquear saída para portas 25, 587 e 465 reduz drasticamente o valor operacional dessas máquinas para o atacante.
  4. Habilite detecção de Chisel stock — mesmo binários não modificados deixam rastros. Monitorar a criação de túneis reversos e comportamento de beacon no intervalo típico do Sliver ajuda a identificar comprometimentos antes que o servidor se torne parte da infraestrutura de relay.
  5. Rotacione credenciais cloud — se o PCPJack obteve acesso inicial via credenciais vazadas, a rotação de chaves SSH, tokens e API keys corta o acesso persistente.

Indicadores de comprometimento

A Hunt.io publicou indicadores técnicos completos no relatório. Os IOCs principais incluem os IPs de C2 213.136.80[.]73 e 38.242.204[.]245, o caminho de persistência /var/tmp/.xs, o serviço systemd xsync, e os hashes dos binários Chisel stock para AMD64, ARM64 e x86 do repositório jpillora/chisel no GitHub.

Referências