Uma nova campanha de ataque à cadeia de suprimentos está atacando silenciosamente desenvolvedores através de um método que a maioria nunca pensaria em procurar. Oculto dentro de pacotes de software no GitHub, um script malicioso baixa um binário Linux durante a instalação e o disfarça usando um nome de arquivo projetado para parecer um processo de sistema padrão. O ataque já tocou mais de 700 repositórios em múltiplos ecossistemas.
Descoberta e escopo da campanha
Investigadores da Socket.dev identificaram esta campanha enquanto investigavam um conjunto de pacotes sinalizados no Packagist. Seu scanner com inteligência artificial detectou o comportamento suspeito no momento da instalação, sinalizando pacotes como maliciosos com base em como eles lidavam com downloads de binários e execução em segundo plano. As descobertas revelaram uma campanha muito mais ampla do que o lote inicial sugerido.
O ataque se espalha tanto pelo Packagist quanto por repositórios de projetos Node.js no GitHub. Os investigadores descobriram que uma conta do GitHub chamada parikhrpreksha serviu como ponto de entrega central para o payload. O mesmo comando postinstall apareceu consistentemente em centenas de repositórios, todos puxando o mesmo binário da mesma URL de releases do GitHub, apontando para uma operação coordenada de cadeia de suprimentos.
Como o payload se esconde
O que torna este ataque difícil de detectar é o quão eficazmente ele esconde sua atividade. O script suprime mensagens de erro que poderiam aparecer durante a instalação e executa o binário baixado silenciosamente em segundo plano. Desenvolvedores revisando logs de instalação padrão não veriam nada incomum, e o arquivo disfarçado sob um nome semelhante a um processo SSH se misturaria ao sistema com poucas chances de se destacar.
O núcleo deste ataque depende de um disfarce simples, mas eficaz. O script malicioso baixa um binário chamado fvbs.network da página de releases do GitHub do atacante e o grava em /tmp/.sshd na máquina infectada. O prefixo de ponto no nome do arquivo oculta o arquivo na maioria dos listagens de diretório padrão, enquanto a nomenclatura .sshd faz com que pareça um serviço de sistema confiável.
Vetor de infecção e execução
Uma vez escrito, o binário é tornado executável usando chmod +x e lançado em segundo plano, cortando qualquer conexão visível com o processo de instalação. O script usa curl com verificação TLS desativada, o que significa que não verifica se a fonte remota é legítima. Até que o comando de instalação termine, o payload já está rodando silenciosamente na máquina do desenvolvedor.
A investigação da Socket.dev também confirmou que commits maliciosos foram enviados diretamente para repositórios upstream do GitHub. Versões de rastreamento de branch como dev-main, dev-master e dev foram usadas, o que significa que qualquer pacote Packagist apontando para essas branches puxaria automaticamente o código infectado na próxima atualização. Simplesmente remover a versão afetada do pacote não foi suficiente, pois o próprio repositório upstream precisava ser corrigido primeiro.
Impacto e alcance
Os pacotes Packagist confirmados carregavam ganchos postinstall idênticos apontando para a mesma conta do GitHub controlada pelo atacante. Em vários repositórios Node.js, o mesmo comando de entrega de payload foi encontrado dentro de arquivos de workflow do GitHub Actions, posicionando-o para ser executado durante a execução do pipeline de CI/CD, em vez de apenas instalações locais de desenvolvedores.
Esta abordagem de vetor duplo significa que o ataque pode atingir tanto desenvolvedores individuais quanto ambientes de build automatizados. Em pelo menos um caso, o comando de payload foi incorporado dentro de um arquivo de workflow usando uma dependência chamada dependency_cache_sync, ampliando a exposição além do que a varredura simples de pacotes poderia capturar.
Medidas de mitigação recomendadas
Equipes usando pacotes Packagist com scripting PHP ou ferramentas baseadas em Laravel devem inspecionar arquivos composer.json em busca de entradas postinstall inesperadas. A Socket recomenda verificar qualquer binário escrito em /tmp com um nome com prefixo de ponto, revisar arquivos de workflow do GitHub Actions em busca de etapas não familiares e auditar pacotes que rastreiam branches de desenvolvimento em vez de tags de lançamento fixas.
Além disso, é crucial que os administradores de sistemas verifiquem a existência de arquivos ocultos em diretórios temporários que imitam processos do sistema, como /tmp/.sshd. A implementação de ferramentas de detecção de anomalias que monitoram a criação de binários executáveis em pastas temporárias pode ajudar a identificar essa atividade antes que ela se torne persistente.
Indicadores de comprometimento (IoCs)
- Conta GitHub:
parikhrpreksha - URL de Download:
https://github.com/parikhrpreksha/system_network_helper_aacf/releases/latest/download/fvbs.network - Nome do Arquivo:
fvbs.network - Caminho do Arquivo:
/tmp/.sshd - Fragmento de Comando:
curl -sk - Fragmento de Comando:
chmod +x - Fragmento de Comando:
/tmp/.sshd & - Nome da Dependência:
dependency_cache_sync
Perguntas frequentes
Como saber se meu sistema foi afetado? Verifique a existência do arquivo /tmp/.sshd e inspecione os logs de instalação de pacotes PHP e Node.js recentes.
É necessário reinstalar o sistema? Se o arquivo /tmp/.sshd for encontrado, ele deve ser removido imediatamente. Recomenda-se também auditar os repositórios upstream para garantir que os commits maliciosos foram corrigidos.