🚨 NOVA NOTÍCIA EM DESTAQUE! 🚨
A notícia que você procurava está aqui!
Apoie esse projeto de divulgacao de noticias! Clique aqui
O ator de ameaça conhecido como PCPJack sequestrou servidores em nuvem associados à Amazon Web Services (AWS), Google Cloud e Microsoft Azure para criar uma rede secreta de retransmissão de e-mail SMTP.
“Servidores empresariais comprometidos nos EUA, Europa e Ásia foram silenciosamente convertidos em proxies SMTP, verificados quanto à capacidade de retransmissão de correio e sincronizados com um consumidor downstream a cada cinco minutos”, disse Hunt.io em comunicado. "A infraestrutura ainda estava funcionando quando a encontramos."
A empresa de inteligência de ameaças disse que encontrou código-fonte, binários compilados, logs de estado de implantação, scanners de Internet, ferramentas de exploração e uma configuração Sliver ao vivo depois que o agente da ameaça por trás da operação deixou dois diretórios abertos em um servidor de comando e controle (C2) ("213.136.80[.]73") sem qualquer autenticação.
PCPJack foi descoberto pela primeira vez pelo SentinelOne em abril de 2026, depois de identificar uma estrutura de roubo de credenciais que visa especificamente serviços em nuvem, enquanto tomava medidas para encerrar e remover processos ou artefatos associados ao TeamPCP, outro notório grupo de hackers que atraiu a atenção nos últimos meses por seus ataques à cadeia de suprimentos de software.
Preparado em um dos diretórios abertos do kit de ferramentas de implantação de proxy SMTP integrado ao Sliver, junto com tunelamento Chisel e binários de proxy para a maioria das arquiteturas de CPU Linux, como AMD64, ARM64 e x86. No lado da vítima, o binário é descartado como um arquivo oculto com prefixo de ponto e persistido em "/var/tmp/.xs".
Também são encontrados nos diretórios scripts de implantação projetados para carregar a configuração do cliente Sliver C2 e filtrar beacons Linux que fizeram check-in nos últimos dez minutos. Beacons são implantes que ligam periodicamente para o servidor C2 em intervalos regulares para verificar e recuperar comandos.
“Cada beacon recebe uma porta proxy SOCKS5 derivada deterministicamente de um hash MD5 de seu UUID Sliver, mapeado no intervalo 10000-14999”, observou Hunt.io. "O mesmo beacon sempre mapeia para a mesma porta em todas as execuções, eliminando a necessidade de um registro de porta compartilhado."
O script também é capaz de executar um portão de qualidade SMTP que investiga o acesso de saída para smtp.gmail[.]com:587. Os hosts que falharem nessa verificação serão ignorados com um código de saída zero.
“Essa porta define o propósito da operação: hosts que não conseguem retransmitir e-mails não têm valor para esse pipeline”, acrescentou a empresa de segurança cibernética. "Os beacons são processados em lotes de 50, com uma espera de 25 minutos após os uploads e 15 minutos após a execução dos comandos, para acomodar check-ins de beacon em intervalos lentos."
Descobriu-se que iterações subsequentes dos scripts do implementador removem a porta SMTP e a lógica de lote. Também está presente um script de diagnóstico que seleciona cinco beacons ativos e atribui a cada um deles um comando shell que verifica o seguinte -
Presença de binários Chisel em caminhos de queda conhecidos
Um processo Chisel está em execução
Espaço em disco
Acessibilidade da porta 9000 no C2, e
Presença de artefatos de persistência, como a entrada cron ou serviço systemd
Além disso, o servidor C2 executa um script Python chamado "chisel_verifier.py" como um daemon de segundo plano persistente, que enumera portas ativas do túnel Chisel via ss -tlnp a cada 60 segundos, testa cada nova porta quanto à capacidade SMTP e remove túneis com falha ou descartados do pool ativo.
Os proxies verificados são enriquecidos com endereço IP de saída, país e ASN por meio de serviços como api.ipify[.]org e ip-api[.]com. As listas de proxy são então sincronizadas a cada cinco minutos através do Secure Copy Protocol (SCP) para um servidor downstream separado em 38.242.204[.]245. O servidor não está acessível no momento. O objetivo final da operação permanece obscuro nesta fase.
"O resultado de 230 nós é o resultado observável. Se esta progressão reflete a iteração de um único operador ou vários atores compartilhando a mesma infraestrutura não pode ser determinado a partir dos arquivos recuperados", disse Hunt.io, descrevendo-a como uma campanha oportunista.
"A lista de proxy verificada está sendo sincronizada a cada cinco minutos com esse servidor, e alguém a está consumindo. Seja por spam, phishing ou qualquer outra coisa, a infraestrutura para entrega em escala estava claramente funcionando."
“Servidores empresariais comprometidos nos EUA, Europa e Ásia foram silenciosamente convertidos em proxies SMTP, verificados quanto à capacidade de retransmissão de correio e sincronizados com um consumidor downstream a cada cinco minutos”, disse Hunt.io em comunicado. "A infraestrutura ainda estava funcionando quando a encontramos."
A empresa de inteligência de ameaças disse que encontrou código-fonte, binários compilados, logs de estado de implantação, scanners de Internet, ferramentas de exploração e uma configuração Sliver ao vivo depois que o agente da ameaça por trás da operação deixou dois diretórios abertos em um servidor de comando e controle (C2) ("213.136.80[.]73") sem qualquer autenticação.
PCPJack foi descoberto pela primeira vez pelo SentinelOne em abril de 2026, depois de identificar uma estrutura de roubo de credenciais que visa especificamente serviços em nuvem, enquanto tomava medidas para encerrar e remover processos ou artefatos associados ao TeamPCP, outro notório grupo de hackers que atraiu a atenção nos últimos meses por seus ataques à cadeia de suprimentos de software.
Preparado em um dos diretórios abertos do kit de ferramentas de implantação de proxy SMTP integrado ao Sliver, junto com tunelamento Chisel e binários de proxy para a maioria das arquiteturas de CPU Linux, como AMD64, ARM64 e x86. No lado da vítima, o binário é descartado como um arquivo oculto com prefixo de ponto e persistido em "/var/tmp/.xs".
Também são encontrados nos diretórios scripts de implantação projetados para carregar a configuração do cliente Sliver C2 e filtrar beacons Linux que fizeram check-in nos últimos dez minutos. Beacons são implantes que ligam periodicamente para o servidor C2 em intervalos regulares para verificar e recuperar comandos.
“Cada beacon recebe uma porta proxy SOCKS5 derivada deterministicamente de um hash MD5 de seu UUID Sliver, mapeado no intervalo 10000-14999”, observou Hunt.io. "O mesmo beacon sempre mapeia para a mesma porta em todas as execuções, eliminando a necessidade de um registro de porta compartilhado."
O script também é capaz de executar um portão de qualidade SMTP que investiga o acesso de saída para smtp.gmail[.]com:587. Os hosts que falharem nessa verificação serão ignorados com um código de saída zero.
“Essa porta define o propósito da operação: hosts que não conseguem retransmitir e-mails não têm valor para esse pipeline”, acrescentou a empresa de segurança cibernética. "Os beacons são processados em lotes de 50, com uma espera de 25 minutos após os uploads e 15 minutos após a execução dos comandos, para acomodar check-ins de beacon em intervalos lentos."
Descobriu-se que iterações subsequentes dos scripts do implementador removem a porta SMTP e a lógica de lote. Também está presente um script de diagnóstico que seleciona cinco beacons ativos e atribui a cada um deles um comando shell que verifica o seguinte -
Presença de binários Chisel em caminhos de queda conhecidos
Um processo Chisel está em execução
Espaço em disco
Acessibilidade da porta 9000 no C2, e
Presença de artefatos de persistência, como a entrada cron ou serviço systemd
Além disso, o servidor C2 executa um script Python chamado "chisel_verifier.py" como um daemon de segundo plano persistente, que enumera portas ativas do túnel Chisel via ss -tlnp a cada 60 segundos, testa cada nova porta quanto à capacidade SMTP e remove túneis com falha ou descartados do pool ativo.
Os proxies verificados são enriquecidos com endereço IP de saída, país e ASN por meio de serviços como api.ipify[.]org e ip-api[.]com. As listas de proxy são então sincronizadas a cada cinco minutos através do Secure Copy Protocol (SCP) para um servidor downstream separado em 38.242.204[.]245. O servidor não está acessível no momento. O objetivo final da operação permanece obscuro nesta fase.
"O resultado de 230 nós é o resultado observável. Se esta progressão reflete a iteração de um único operador ou vários atores compartilhando a mesma infraestrutura não pode ser determinado a partir dos arquivos recuperados", disse Hunt.io, descrevendo-a como uma campanha oportunista.
"A lista de proxy verificada está sendo sincronizada a cada cinco minutos com esse servidor, e alguém a está consumindo. Seja por spam, phishing ou qualquer outra coisa, a infraestrutura para entrega em escala estava claramente funcionando."
Fonte: https://thehackernews.com
#samirnews #samir #news #boletimtec #pcpjack #sequestra #230 #servidores #aws, #google #cloud #e #azure #para #rede #de #retransmissão #smtp #secreta
⚡ Fique ligado: novidades e promoções em breve por aqui! ⚡
Postar um comentário