PCPJack sequestra 230 servidores de nuvem e constrói rede clandestina de relay SMTP
Um operador malicioso identificado como PCPJack montou uma sofisticada infraestrutura de envio de e-mails abusivos ao comprometer pelo menos 230 servidores hospedados em grandes provedores de nuvem, incluindo Amazon Web Services, Google Cloud e Microsoft Azure. Esses sistemas, pertencentes majoritariamente a empresas na América do Norte, Europa e Ásia, foram silenciosamente convertidos em proxies SMTP, formando uma espécie de “backbone” clandestino para encaminhamento de e-mails por meio de máquinas legítimas, porém invadidas.
De acordo com análise da Hunt.io, especializada em inteligência de ameaças, os servidores comprometidos eram continuamente avaliados para verificar se conseguiam retransmitir e-mails e, em seguida, sincronizados com um servidor consumidor downstream a cada cinco minutos. Isso permitia ao operador manter um inventário atualizado apenas com hosts utilizáveis para relay SMTP, enquanto a infraestrutura permanecia ativa e em uso durante o período de investigação.
A investigação avançou após um erro operacional do agente de ameaça: dois diretórios em um servidor de comando e controle (C2), associado ao endereço IP “213.136.80[.]73”, estavam expostos sem qualquer autenticação. Dentro desses diretórios, os analistas encontraram um verdadeiro arsenal: código-fonte, binários compilados, registros de status de implantação, scanners de Internet, ferramentas de exploração e uma instância configurada do Sliver, um framework de comando e controle amplamente usado em operações ofensivas.
Primeira aparição do PCPJack e relação com TeamPCP
O nome PCPJack surgiu pela primeira vez em relatórios de abril de 2026, quando pesquisadores da SentinelOne identificaram um framework de roubo de credenciais projetado especificamente para ambientes em nuvem. Na época, chamou atenção o fato de o toolkit tentar interromper e remover processos e artefatos vinculados ao TeamPCP, outro grupo de ataque que havia ganhado notoriedade por comprometer cadeias de suprimentos de software. Aparentemente, PCPJack não apenas desenvolve suas próprias ferramentas, como também tenta “limpar” a concorrência, removendo vestígios de outros grupos já presentes no mesmo ambiente atacado.
Nos diretórios abertos do C2, os pesquisadores encontraram um conjunto de scripts e binários dedicado à implantação de proxies SMTP integrado ao Sliver. Entre esses componentes estavam versões do Chisel – ferramenta de tunelamento e proxy – compiladas para múltiplas arquiteturas Linux, como AMD64, ARM64 e x86. Em sistemas comprometidos, o binário do Chisel era plantado como um arquivo oculto, com nome iniciado por ponto, e configurado para persistir no caminho “/var/tmp/.xs”, de forma a dificultar sua detecção por administradores e ferramentas de monitoramento.
Mecânica de implantação e controle dos implantes
Foram identificados scripts de implantação criados para carregar automaticamente a configuração do cliente Sliver C2 nos hosts infectados e, em seguida, filtrar os beacons Linux que haviam se comunicado com o servidor de comando e controle nos últimos dez minutos. Nessa arquitetura, o beacon funciona como um implante que estabelece contato periódico com o C2 para sinalizar que o host está ativo e aguarda instruções. Assim, o operador consegue saber rapidamente quais máquinas estão disponíveis para novas tarefas, como a criação de túneis ou o início de sessões de relay SMTP.
A Hunt.io observou um mecanismo engenhoso para associação de portas de proxy SOCKS5 a cada beacon. A porta era derivada, de forma determinística, a partir de um hash MD5 do UUID do cliente Sliver e mapeada para a faixa entre 10000 e 14999. Isso significa que um mesmo implante, em diferentes execuções, era sempre vinculado à mesma porta, dispensando o uso de bancos de dados ou arquivos centrais para registrar manualmente essas associações. Essa abordagem reduz o atrito operacional e dificulta a correlação externa entre beacons e portas utilizadas.
Validação de qualidade para uso como relay SMTP
O processo de seleção dos servidores não se limitava a infectar o máximo possível de máquinas: havia uma etapa de qualificação. O script de implantação incluía um teste que tentava estabelecer comunicação de saída com “smtp.gmail[.]com:587”. Se a conexão não fosse bem-sucedida, o host era descartado silenciosamente, com código de saída zero, o que significa que, do ponto de vista do operador, esse sistema não tinha valor para a campanha de relay SMTP. Somente máquinas que demonstrassem capacidade de comunicação SMTP eram mantidas na infraestrutura.
Os beacons aptos eram processados em lotes de 50, com janelas de espera relativamente longas – 25 minutos após o upload dos componentes e 15 minutos após a emissão de comandos de execução. Essa cadência indica que muitos implantes estavam configurados para se comunicar com o C2 em intervalos maiores, possivelmente como forma de reduzir o ruído de rede e evitar alertas em ferramentas de detecção baseadas em anomalias de tráfego.
Evolução dos scripts e rotinas de diagnóstico
Versões mais recentes dos scripts, porém, mostraram que o operador foi refinando sua metodologia. Em determinada fase, foram removidos tanto o teste explícito de SMTP quanto a lógica de loteamento, sugerindo que PCPJack já tinha confiança suficiente em seu processo de seleção anterior, ou que passou a utilizar mecanismos alternativos de validação. Paralelamente, os pesquisadores encontraram um script de diagnóstico específico, responsável por escolher cinco beacons ativos e disparar comandos em shell para:
– Procurar binários do Chisel em caminhos previamente conhecidos;
– Checar se um processo Chisel estava de fato em execução;
– Verificar o espaço em disco disponível;
– Testar a conectividade com a porta 9000 no C2;
– Confirmar a existência de mecanismos de persistência, como entradas de cron ou serviços systemd.
No próprio servidor de comando e controle, um script Python chamado “chisel_verifier.py” era executado como daemon persistente em segundo plano. A cada 60 segundos, ele listava todas as portas de túneis Chisel ativas com o comando “ss -tlnp”, identificava novas portas e submetia cada uma a um teste de relay SMTP. Túneis que falhavam nesses testes ou que se mostravam indisponíveis eram removidos do conjunto ativo, mantendo a rede de proxies enxuta e funcional.
Enriquecimento de dados e sincronização com servidor downstream
Os proxies aprovados passavam por uma etapa de enriquecimento de dados. O sistema coletava informações como IP de saída, país de origem e ASN (Autonomous System Number). Com isso, o operador conseguia mapear melhor o perfil e a distribuição geográfica de sua infraestrutura, além de potencialmente escolher quais regiões seriam mais adequadas para determinados tipos de envio de e-mail ou campanhas específicas.
Essas listas de proxies, já filtradas e enriquecidas, eram então sincronizadas a cada cinco minutos com um segundo servidor, considerado downstream, associado ao endereço “38.242.204[.]245”. Essa máquina, no momento da análise, não estava acessível, o que limitou a visibilidade dos pesquisadores sobre o estágio final da operação. Ainda assim, o intervalo de sincronização e a automação do processo sugerem que a intenção era manter, em tempo quase real, um inventário confiável de proxies SMTP prontos para uso.
Possíveis objetivos da campanha de PCPJack
Embora o objetivo exato da campanha não tenha sido totalmente esclarecido, o conjunto de evidências aponta para uma infraestrutura com grande potencial para envio de mensagens em larga escala, como spam, phishing, golpe de engenharia social e até distribuição de links maliciosos. Ao usar servidores legítimos de grandes provedores de nuvem como relays, os atacantes conseguem driblar muitos mecanismos de reputação baseados em IP, o que aumenta a taxa de entrega e a credibilidade aparente das mensagens.
Além disso, uma rede de proxies SMTP como a criada por PCPJack pode servir como camada intermediária para ocultar a verdadeira origem das campanhas, fragmentar a responsabilidade entre múltiplos hosts e dificultar a correlação de eventos por parte de analistas de segurança. Em cenários de ataques direcionados, essa infraestrutura poderia ser utilizada para enviar e-mails altamente personalizados, com aparência corporativa legítima, a partir de endereços IP e blocos atribuídos a provedores confiáveis.
Riscos específicos para ambientes em nuvem
O caso evidencia um problema cada vez mais sensível: a exploração de ambientes de nuvem como plataforma de ataque. Servidores em AWS, Google Cloud e Azure costumam contar com alta disponibilidade, boa largura de banda, endereços IP com reputação relativamente positiva e, muitas vezes, configurações de segurança deixadas em segundo plano por falta de hardening adequado. Quando comprometidos, esses ativos se tornam extremamente valiosos para grupos como PCPJack.
Empresas que utilizam nuvem em larga escala, mas não implementam políticas rigorosas de gerenciamento de credenciais, segmentação de rede, controle de portas de saída e monitoramento de processos, acabam oferecendo terreno fértil para esse tipo de campanha. Um único servidor mal configurado pode ser usado como ponto de apoio inicial, permitindo movimento lateral, implantação de implantes como o Sliver e estabelecimento de túneis com ferramentas como o Chisel.
Como identificar sinais de comprometimento
Organizações que suspeitem de possível envolvimento com campanhas semelhantes podem buscar alguns indicadores práticos em seus ambientes:
– Processos desconhecidos ou ocultos relacionados a binários como “chisel” em diretórios temporários, especialmente caminhos do tipo “/var/tmp/.xs” ou similares.
– Conexões recorrentes de saída para portas incomuns, especialmente entre 10000 e 14999, que possam indicar túneis SOCKS5.
– Comunicação periódica com potenciais servidores de comando e controle, caracterizada por contatos em intervalos fixos, como a cada poucos minutos.
– Registros incomuns de conexões SMTP saindo de servidores que, em tese, não deveriam atuar como relay de e-mail.
– Entradas de cron ou serviços systemd recentemente criados para manter processos persistentes sem justificativa operacional clara.
Boas práticas de mitigação e prevenção
Para reduzir a superfície de ataque e dificultar campanhas como a do PCPJack, empresas podem adotar algumas medidas de segurança estruturais em seus ambientes de nuvem:
1. Endurecimento de servidores: desabilitar serviços desnecessários, bloquear portas não utilizadas por firewall, restringir acesso SSH por IP e utilizar autenticação multifator.
2. Monitoramento de tráfego de saída: implementar regras específicas para detectar conexões suspeitas, especialmente relacionadas a portas SMTP e a intervalos regulares de comunicação.
3. Gestão rigorosa de credenciais: rotacionar chaves de acesso regularmente, utilizar cofres de segredos e aplicar o princípio do menor privilégio em contas e serviços.
4. Inventário e revisão periódica: manter um inventário atualizado de máquinas, serviços expostos e regras de firewall, revisando periodicamente permissões e configurações.
5. Ferramentas de detecção de C2 e tunelamento: empregar soluções capazes de identificar padrões de comportamento associados a frameworks como Sliver e ferramentas de tunelamento como Chisel.
Tendência de profissionalização de infraestruturas maliciosas
O caso PCPJack ilustra a crescente profissionalização de grupos de ameaça que atuam exclusivamente na construção e operação de infraestrutura maliciosa. Em vez de necessariamente conduzirem eles próprios as campanhas de phishing, extorsão ou roubo de dados, muitos desses grupos se especializam em oferecer “infraestrutura como serviço” para outros criminosos, fornecendo redes de proxies, relays SMTP, VPNs comprometidas e servidores de comando e controle prontos para uso.
Esse modelo fragmenta as responsabilidades e torna mais difícil desmantelar todo o ecossistema: mesmo que uma campanha de e-mails maliciosos seja derrubada, a infraestrutura subjacente pode continuar disponível para outras operações. A sofisticação observada nos scripts, na automação de verificação de qualidade e na orquestração de centenas de servidores de nuvem comprometidos mostra que PCPJack opera em um patamar industrial, com foco em escalabilidade e resiliência.
Em resumo, embora o propósito final da campanha ainda não tenha sido completamente desvendado, a rede clandestina construída por PCPJack demonstrou capacidade clara para sustentar operações de envio de e-mails potencialmente massivas, discretas e difíceis de rastrear, reforçando a urgência de medidas mais robustas de segurança e monitoramento em ambientes de nuvem corporativos.