A operação comprometeu 230 servidores associados a AWS, Google Cloud e Azure, instalou túneis e proxies SMTP e sincronizou nós validados para outro servidor a cada cinco minutos.
| Componente | Servidores Linux em AWS, Google Cloud e Microsoft Azure transformados em proxies SMTP por meio de beacons Sliver, túneis Chisel e binários de implantação para múltiplas arquiteturas. |
| Vetor | Acesso a servidores de negócio já comprometidos, com implantação de binário oculto em /var/tmp/.xs, persistência por cron ou serviço systemd e seleção de beacons Linux ativos nos últimos dez minutos. |
| Impacto | Criação de uma rede de 230 nós para retransmissão de e-mail, validação de capacidade SMTP, enriquecimento de IP de saída por país e ASN e sincronização recorrente para um consumidor downstream. |
| Prioridade | Investigar persistência incomum em /var/tmp, beacons Sliver recentes, túneis Chisel, conexões SMTP de saída e cópias recorrentes para infraestrutura externa. |
| Artefatos | Código-fonte, binários compilados, logs de estado de implantação, scanners de internet, ferramentas de exploração, configuração Sliver ativa e diretórios C2 abertos sem autenticação. |
| IoCs | Exemplos defangados incluem o C2 213.136.80[.]73, o servidor downstream 38.242.204[.]245 e testes de saída para smtp.gmail[.]com na porta 587. |
O grupo rastreado como PCPJack foi associado a uma operação que converteu servidores em nuvem comprometidos em uma rede clandestina de retransmissão SMTP. A infraestrutura observada incluía 230 nós vinculados a ambientes da Amazon Web Services, Google Cloud e Microsoft Azure, distribuídos por Estados Unidos, Europa e Ásia. Em vez de usar apenas servidores próprios, a operação aproveitava máquinas de negócio já invadidas para encaminhar tráfego de e-mail, validar capacidade de relay e manter uma lista operacional de proxies que era atualizada continuamente.
O material exposto em dois diretórios abertos de um servidor de comando e controle revelou uma cadeia de automação voltada à implantação, validação e manutenção desses nós. Foram recuperados código-fonte, binários compilados, registros de estado, scanners de internet, tooling de exploração e uma configuração Sliver ativa. A presença desses artefatos indica que a operação não dependia de uma etapa manual isolada: havia scripts para selecionar beacons recentes, carregar configuração de cliente C2, atribuir portas SOCKS5 de forma determinística, testar saída SMTP e sincronizar os proxies aprovados com outro servidor.
No lado da vítima, a cadeia usava um binário oculto com prefixo de ponto e persistência em /var/tmp/.xs. A implantação também incluía artefatos relacionados a Chisel, usados para tunelamento e proxy, com builds para arquiteturas Linux como AMD64, ARM64 e x86. A escolha por múltiplas arquiteturas amplia a capacidade de execução em servidores heterogêneos, especialmente em frotas de nuvem onde instâncias x86 e ARM podem coexistir em ambientes de produção, desenvolvimento, CI/CD ou workloads temporários.
A automação selecionava beacons Linux que haviam se comunicado com o C2 nos dez minutos anteriores. Para cada beacon, uma porta SOCKS5 era calculada a partir de um hash MD5 do UUID Sliver e mapeada para o intervalo de portas 10000 a 14999. Esse desenho reduz a necessidade de um registro compartilhado de portas, porque o mesmo beacon recebe a mesma porta em execuções repetidas. A consequência defensiva é importante: portas altas recorrentes, associadas ao mesmo host e a processos de túnel ou beacon, podem ser um sinal mais forte do que uma conexão isolada.
Uma etapa de controle de qualidade verificava se o host conseguia acessar smtp.gmail[.]com pela porta 587. Máquinas que não passavam nesse teste eram descartadas da fila de implantação, o que demonstra que a finalidade operacional dependia de saída SMTP funcional. Em versões posteriores dos scripts, essa lógica de gate e parte do processamento em lotes foram removidas, mas o desenho recuperado mostra uma evolução da operação: primeiro filtrar hosts capazes de retransmitir e-mail, depois manter uma lista de túneis ativos com verificação periódica.
A superfície exposta é composta por servidores Linux em provedores de nuvem que já tinham sido comprometidos antes da etapa de proxy SMTP. O contexto recuperado não informa a vulnerabilidade inicial, credencial usada, produto explorado ou caminho de entrada. Por isso, a análise defensiva deve tratar a campanha como pós-comprometimento: o risco principal está em hosts com beacons Sliver ativos, túneis Chisel, persistência local e capacidade de conexão SMTP de saída. Não há base para afirmar que todos os tenants de AWS, Google Cloud ou Azure estejam vulneráveis por uma falha comum; o elo observado é o abuso de servidores já invadidos.
O servidor de C2 continha também um processo persistente em Python chamado chisel_verifier.py. Esse componente enumerava portas de túneis Chisel ativos em intervalos de 60 segundos, testava cada nova porta para capacidade SMTP e removia túneis que falhavam ou deixavam de responder. Proxies validados eram enriquecidos com endereço IP de saída, país e ASN por serviços externos como api.ipify[.]org e ip-api[.]com, e depois sincronizados a cada cinco minutos via SCP para um servidor downstream. O objetivo final não foi confirmado, mas a infraestrutura estava apta a entrega de e-mail em escala.
- Servidores Linux comprometidos em nuvem pública, especialmente instâncias com saída SMTP liberada.
- Ambientes com persistência inesperada em
/var/tmp, cron ou systemd associada a binários ocultos. - Hosts com túneis Chisel e beacons Sliver ativos, principalmente quando há portas altas no intervalo 10000 a 14999.
- Contas ou workloads com conectividade externa suficiente para enviar tráfego SMTP pela porta 587.
A investigação deve começar por telemetria de endpoint, rede e cloud egress. Em hosts Linux, procure arquivos ocultos em /var/tmp, serviços systemd criados fora do padrão operacional, entradas de cron recentes e processos com comportamento de túnel ou beacon. O nome do arquivo /var/tmp/.xs é um artefato concreto da operação, mas a caça não deve depender apenas dele: operadores podem renomear binários mantendo a mesma lógica de persistência, seleção de beacons e exposição de portas SOCKS5.
Na rede, priorize conexões SMTP de saída para a porta 587 feitas por servidores que não deveriam enviar e-mail diretamente. O padrão de validação e manutenção também sugere tráfego recorrente para serviços de descoberta de IP público e geolocalização, além de sincronização periódica por SCP para infraestrutura externa. O C2 defangado 213.136.80[.]73 e o downstream 38.242.204[.]245 são exemplos úteis para retrocaça, mas a defesa deve complementar a busca com comportamento: túneis recém-abertos, portas altas persistentes, conexões regulares de beacon e enriquecimento de IP de saída.
- Criação ou execução de binário oculto em
/var/tmp/.xse outros arquivos dot-prefixed em diretórios temporários. - Entradas de cron ou serviços systemd sem justificativa operacional, especialmente apontando para
/var/tmp. - Processos compatíveis com túnel Chisel, beacon Sliver ou proxy SOCKS5 em portas altas.
- Conexões de saída para SMTP na porta 587 originadas de servidores que não são MTAs autorizados.
- Acessos recorrentes a serviços de IP público ou geolocalização seguidos por transferência
SCPexterna.
A resposta deve separar contenção de erradicação. Primeiro, bloqueie egress SMTP direto para workloads que não precisam enviar e-mail e force o uso de gateways autenticados e monitorados. Em seguida, isole hosts com persistência suspeita, preserve artefatos de disco e memória quando possível e remova beacons, túneis e serviços criados pelo operador. Como a origem do comprometimento inicial não foi identificada no material, a correção não deve parar na remoção do proxy: é necessário revisar credenciais, chaves de acesso, histórico de login, mudanças de IAM, imagens base e pipelines que possam ter permitido a implantação.
Depois da contenção, valide grupos de segurança, regras de firewall, listas de egress, permissões de serviço e políticas de envio de e-mail em todas as contas de nuvem afetadas. Organizações com servidores Linux em múltiplas arquiteturas devem incluir AMD64, ARM64 e x86 nos escopos de varredura, já que a operação possuía binários para essas famílias. A detecção contínua deve alertar sobre persistência em diretórios temporários, serviços systemd não aprovados, cron incomum, uso de SCP para destinos externos e conexões SMTP geradas por hosts sem função de correio.
A rotação de credenciais deve ser proporcional ao escopo encontrado. Se houver evidência de beacon Sliver ou tooling de exploração no host, trate o servidor como comprometido além da função de proxy: revise tokens locais, segredos de aplicação, perfis de instância, chaves SSH, variáveis de ambiente e permissões atribuídas ao workload. Quando a reconstrução for viável, prefira substituir a instância por imagem limpa e validar que a nova configuração bloqueia o mesmo caminho de abuso.
- Restringir saída SMTP direta e permitir envio apenas por relays corporativos controlados.
- Isolar servidores com
/var/tmp/.xs, túneis Chisel, beacon Sliver ou portas SOCKS5 inesperadas. - Revisar cron, systemd, chaves SSH, perfis de instância, tokens locais e permissões IAM associadas ao host.
- Executar retrocaça por conexões para
213.136.80[.]73,38.242.204[.]245, porta 587 e serviços de enriquecimento de IP. - Reconstruir hosts comprometidos a partir de imagens confiáveis quando houver evidência de persistência ou tooling pós-exploração.
0 Comentários