42 Repositórios GitHub Armazenados Revelam um Publisher npm Oculto

Resumo

Uma campanha sofisticada rastreada como testmetest usa pacotes npm maliciosos e repositórios GitHub comprometidos para roubar credenciais e automatizar lançamentos de pacotes maliciosos. Os atacantes dependem de wrappers polimórficos, addons nativos do Node.js e payloads criptografados para evadir a detecção. A campanha também envolve infraestrutura usada para escanear e explorar vulnerabilidades do cPanel.

Investigação

Pesquisadores de segurança da JFrog identificaram 42 repositórios GitHub armados juntamente com múltiplos pacotes npm maliciosos. Eles descobriram que os atacantes usaram uma técnica de camuflagem de addon nativo em que um .node compilado descriptografa um payload oculto em tempo de execução. A investigação também vinculou a atividade ao shellpanel scanners que visam sistemas cPanel através do CVE-2026-41940.

Mitigação

Os usuários devem remover os pacotes npm maliciosos identificados e reconstruir sistemas afetados a partir de fontes confiáveis. As organizações devem rodar todas as credenciais potencialmente comprometidas, incluindo GitHub, npm e tokens de nuvem. Também é crítico auditar repositórios para arquivos de configuração não autorizados como .github/init.js e ganchos de execução inesperados em arquivos package.json ou Makefiles. files or Makefiles.

Resposta

Quando a atividade maliciosa é detectada, revogue segredos expostos e troque credenciais imediatamente. Procure por mecanismos de persistência como net-health-checker or pkg-runtime. Reveja os logs do GitHub Actions em busca de workflows não autorizados e monitore sistemas para payloads descriptografados escritos em diretórios temporários.

Execução de Simulação

• Narrativa do Ataque & Comandos: O adversário conseguiu infiltrar um payload JavaScript malicioso no diretório temporário do usuário, nomeando-o como .nc para potencialmente imitar um arquivo relacionado ao Netcat ou simplesmente para ofuscar seu propósito. Para executá-lo, o adversário utiliza um carregador que invoca a CreateProcessA API Win32 para iniciar o Windows Script Host (wscript.exe) com o arquivo temporário como argumento. Esta sequência específica—usando a versão ANSI da API de criação de processo para executar um script de %TEMP%—é o padrão exato que a regra de detecção foi projetada para interceptar.

• Script de Teste de Regressão:

   # Script de Simulação: Acionando 'Criação Suspeita de Processo e Execução de Arquivo JS Temporário'
  
    # 1. Definir caminhos
    $tempPath = $env:TEMP
    $targetFile = Join-Path $tempPath ".nc"
  
    # 2. Criar um arquivo JS malicioso fictício no diretório %TEMP%
    # Nota: Nós o nomeamos .nc conforme o requisito da lógica de detecção
    "WScript.Echo('Atividade Maliciosa Simulada');" | Out-File -FilePath $targetFile -Encoding ascii
  
    Write-Host "[+] Arquivo malicioso criado em: $targetFile"
  
    # 3. Simular a execução via wscript.exe
    # Em um cenário real, o 'CallTrace' contendo 'CreateProcessA' é gerado 
    # pela chamada de API do Windows subjacente usada pelo carregador de malware.
    # Executar isso via PowerShell/CMD gerará o evento de criação do processo.
    Write-Host "[+] Executando script para acionar detecção..."
    Start-Process "wscript.exe" -ArgumentList "`"$targetFile`""
  
    Write-Host "[+] Comando de simulação enviado."

• Comandos de Limpeza:

   # Script de Limpeza: Remover artefatos de simulação
    $tempPath = $env:TEMP
    $targetFile = Join-Path $tempPath ".nc"
  
    if (Test-Path $targetFile) {
        Remove-Item -Path $targetFile -Force
        Write-Host "[+] Limpeza bem-sucedida: $targetFile removido."
    } else {
        Write-Host "[!] Limpeza falhou: Arquivo não encontrado."
    }