Pacotes falsos para Laravel no Packagist distribuem RAT multiplataforma

Bibliotecas PHP publicadas como utilitários Laravel acionam um trojan de acesso remoto por dependência Composer, com execução em Windows, macOS e Linux e acesso aos segredos do ambiente da aplicação.

Componente	Pacotes PHP no Packagist associados a utilitários Laravel: nhattuanbl/lara-swagger, nhattuanbl/lara-helper e simple-queue, com carga em src/helper.php.
Vetor	Instalação via Composer de pacote que se apresenta como biblioteca Laravel; nhattuanbl/lara-swagger declara nhattuanbl/lara-helper como dependência e leva à instalação do RAT.
Impacto	Execução persistente de RAT no processo da aplicação PHP, com reconhecimento do sistema, recebimento de comandos por TCP, leitura e escrita de arquivos e acesso aos segredos visíveis pelo ambiente da aplicação.
Prioridade	Remover os pacotes afetados, assumir comprometimento quando instalados, rotacionar segredos acessíveis pela aplicação e auditar tráfego de saída para helper.leuleu[.]net na porta 2096.
Artefatos	Arquivo src/helper.php, comunicação TCP por stream_socket_client(), repetição de conexão a cada 15 segundos e ofuscação de fluxo, domínios, comandos, caminhos e identificadores.
IoC	Domínio C2 defangado helper.leuleu[.]net com comunicação observada na porta 2096.

Resumo técnico

Pacotes PHP publicados no Packagist foram identificados como bibliotecas falsas para ecossistemas Laravel e usados como canal de entrega de um trojan de acesso remoto multiplataforma. A cadeia não depende de uma vulnerabilidade no Laravel em si; o risco está na confiança concedida ao gerenciador de dependências e na execução automática de código PHP carregado pela aplicação. O pacote nhattuanbl/lara-swagger atua como peça de atração e declara nhattuanbl/lara-helper como dependência Composer, fazendo com que a carga maliciosa seja instalada sem que o operador necessariamente tenha escolhido diretamente o pacote que contém o RAT.

Os pacotes lara-helper e simple-queue contêm um arquivo chamado src/helper.php, usado para acionar a lógica maliciosa. O código emprega ofuscação de fluxo de controle, codificação de nomes de domínio, nomes de comandos e caminhos de arquivo, além de identificadores aleatórios para variáveis e funções. Esse conjunto de técnicas aumenta o custo de revisão manual e prejudica varreduras estáticas simples, especialmente em pipelines que apenas validam presença de dependências conhecidas, sintaxe ou metadados do pacote.

O RAT é projetado para funcionar em Windows, macOS e Linux, desde que seja carregado pelo runtime PHP da aplicação. Depois de executado, ele tenta se conectar ao servidor C2 defangado helper.leuleu[.]net na porta 2096, envia dados de reconhecimento do sistema e aguarda instruções. O C2 foi descrito como não responsivo no momento analisado, mas o código mantém uma rotina persistente de reconexão a cada 15 segundos, o que preserva o risco caso a infraestrutura volte a responder ou seja substituída pelo operador.

Fluxo técnico

A execução começa no caminho de instalação da dependência. Em uma aplicação Laravel, dependências Composer podem ser carregadas por autoload, service providers ou classes inicializadas durante o boot da aplicação. Isso significa que o RAT não precisa ser invocado por uma ação administrativa explícita depois de instalado; ele passa a operar dentro do mesmo processo da aplicação, herdando permissões de sistema de arquivos, variáveis de ambiente e alcance de rede disponíveis ao usuário que executa o servidor PHP ou o worker associado.

A comunicação de comando e controle ocorre por TCP usando stream_socket_client(). Após a conexão, a carga envia um perfil do host ao operador e passa a interpretar instruções recebidas do C2. A capacidade de execução de comandos procura contornar endurecimentos comuns de PHP ao verificar disable_functions e escolher um método disponível entre funções como popen, proc_open, exec, shell_exec, system e passthru. Esse comportamento não deve ser tratado como um simples downloader: o operador recebe uma superfície de shell remota condicionada às permissões reais do processo da aplicação.

O impacto também inclui operações sobre arquivos. O contexto indica capacidade de ler e escrever arquivos arbitrários e de gravar conteúdo em disco com permissões amplas. Em aplicações Laravel, esse escopo é crítico porque o mesmo processo costuma ter acesso a .env, credenciais de banco de dados, chaves de API, tokens de serviços internos e arquivos gerados pela aplicação. A consequência confirmada é controle remoto no nível do usuário da aplicação PHP, com risco direto para segredos em ambiente, integridade de arquivos e execução de lógica não autorizada no servidor.

Superfície afetada

A superfície principal são projetos PHP que instalaram nhattuanbl/lara-helper ou simple-queue, diretamente ou por dependência transitiva. O caso de nhattuanbl/lara-swagger é relevante porque o pacote não precisa carregar código malicioso próprio para introduzir risco; ao declarar a dependência contaminada, ele desloca a carga para outro pacote e dificulta a identificação por revisões superficiais focadas apenas no pacote solicitado pelo desenvolvedor.

Aplicações Laravel expostas à internet ampliam o risco porque o processo web tende a permanecer ativo, carregar providers durante o boot e reutilizar o mesmo ambiente em múltiplas requisições. Workers de fila, comandos agendados e processos CLI que inicializam a aplicação também devem ser considerados, pois o gatilho pode ocorrer por autoload de classe ou inicialização do framework, não apenas por uma rota HTTP específica. Ambientes de desenvolvimento, homologação e CI/CD não devem ser ignorados, já que arquivos .env, caches Composer e segredos temporários podem estar presentes fora de produção.

Além dos pacotes maliciosos, três bibliotecas publicadas pelo mesmo operador foram descritas como limpas: nhattuanbl/lara-media, nhattuanbl/snooze e nhattuanbl/syslog. Elas não devem ser automaticamente classificadas como RAT apenas por associação, mas indicam uma estratégia de reputação no ecossistema de pacotes. Para defesa, a avaliação precisa cobrir o conjunto de dependências, o histórico de instalação, autores desconhecidos e relações transitivas, sem transformar pacotes limpos em indicadores de comprometimento por si só.

• Projetos com nhattuanbl/lara-helper instalado diretamente no composer.lock ou em caches Composer.
• Projetos que instalaram simple-queue e carregam src/helper.php por autoload ou classes associadas.
• Projetos que instalaram nhattuanbl/lara-swagger e receberam nhattuanbl/lara-helper como dependência transitiva.
• Hosts Linux, Windows e macOS que executam a aplicação PHP com saída TCP permitida para a porta 2096.

Hunting e telemetria

A investigação deve começar pelo inventário de dependências. O arquivo composer.lock, os metadados em vendor/composer, caches de instalação e artefatos de build devem ser examinados em busca dos pacotes afetados e do arquivo src/helper.php. Como o pacote pode ter entrado por dependência transitiva, a ausência de uma declaração direta em composer.json não é suficiente para descartar exposição. Em CI/CD, a análise deve incluir imagens de contêiner, artefatos publicados, volumes persistentes e qualquer etapa que tenha feito instalação de dependências PHP antes da descoberta.

Na telemetria de rede, o principal sinal é tráfego TCP de saída para helper.leuleu[.]net na porta 2096, ou tentativas repetidas com intervalo compatível com 15 segundos. Mesmo se o servidor não responder, falhas recorrentes de conexão podem aparecer em logs de firewall, EDR, proxy, DNS, NetFlow ou sensores de egress. Resoluções DNS para o domínio defangado, conexões bloqueadas e processos PHP abrindo sockets diretos são sinais fortes quando correlacionados com a presença dos pacotes.

No endpoint, a defesa deve procurar execução de funções de shell acionadas por processos PHP, criação ou alteração incomum de arquivos pelo usuário da aplicação e leitura de arquivos de configuração sensíveis. A ofuscação no src/helper.php também é um indicador comportamental: código de biblioteca que codifica domínios, caminhos e nomes de comandos, usa identificadores aleatórios e mantém loop persistente de conexão não corresponde ao comportamento esperado de utilitários Laravel comuns. A caça deve diferenciar análise de arquivo, comportamento em runtime e tráfego de rede, porque qualquer uma dessas camadas isoladamente pode ficar incompleta.

• Presença de nhattuanbl/lara-helper, nhattuanbl/lara-swagger ou simple-queue em composer.lock, diretórios vendor ou caches Composer.
• Arquivo src/helper.php contendo ofuscação de fluxo, strings codificadas e lógica de socket TCP.
• Processos PHP tentando conexão recorrente para helper.leuleu[.]net na porta 2096.
• Eventos de execução de shell originados do processo web PHP ou worker Laravel.
• Acessos incomuns a .env, arquivos de configuração, diretórios graváveis e credenciais de aplicação.

Mitigação

A resposta deve tratar instalações confirmadas como comprometimento potencial, não apenas como dependência indesejada. A primeira ação é remover os pacotes afetados do projeto, regenerar dependências de forma controlada e reconstruir artefatos a partir de uma base limpa. Em seguida, todos os segredos acessíveis pelo ambiente da aplicação devem ser rotacionados: credenciais de banco de dados, chaves de API, tokens de serviços internos, segredos em .env e qualquer chave usada por workers ou tarefas agendadas. A rotação precisa ocorrer depois da remoção e contenção, para evitar que novos valores continuem expostos ao mesmo processo.

A contenção de rede deve bloquear saída para o domínio C2 defangado e revisar políticas de egress para aplicações PHP. Um bloqueio pontual ajuda na resposta imediata, mas não substitui controles de saída por destino, porta e necessidade operacional. Servidores web e workers devem ser reiniciados após a limpeza para garantir que código carregado em memória deixe de executar. Imagens de contêiner, snapshots e ambientes derivados do build contaminado precisam ser invalidados ou reconstruídos, pois remover o pacote apenas do repositório não elimina artefatos já publicados.

A prevenção deve reforçar governança de supply chain em PHP: revisão de dependências transitivas, pinagem por lockfile, aprovação de novos mantenedores, alertas para pacotes recém-publicados com baixa reputação e inspeção de scripts ou arquivos PHP carregados automaticamente. Em projetos Laravel, a revisão de service providers, autoload e bibliotecas que executam lógica no boot é especialmente importante. A validação final deve confirmar ausência dos pacotes, ausência de conexões para o C2, rotação de segredos concluída e inexistência de alterações persistentes em arquivos da aplicação.

• Remover nhattuanbl/lara-helper, simple-queue e qualquer dependência transitiva que os introduza.
• Reconstruir dependências e artefatos a partir de ambiente limpo, incluindo imagens de contêiner e caches Composer.
• Rotacionar segredos acessíveis pelo processo da aplicação, incluindo .env, banco de dados e APIs.
• Bloquear e auditar tráfego de saída para helper.leuleu[.]net na porta 2096.
• Revisar logs de processo, rede e sistema de arquivos no período em que os pacotes estiveram instalados.