Saltar al contenido

Esta semana se ha publicado una investigación por parte del equipo de Socket que pone los pelos de punta: se han detectado paquetes en Packagist que se hacen pasar por utilidades de Laravel y que, en realidad, instalan un troyano de acceso remoto (RAT) en tu sistema. Un RAT que funciona en Windows, macOS y Linux.

El impacto real de este caso concreto ha sido bajo (menos de 120 descargas entre los tres paquetes afectados), pero el mecanismo del ataque es un recordatorio muy importante de algo que muchos desarrolladores ignoran: cada dependencia que instalas es código que se ejecuta en tu máquina y en tu servidor con los mismos permisos que tu aplicación.

Los paquetes afectados

El atacante, bajo el usuario nhattuanbl de Packagist (cuenta registrada desde 2015), publicó seis paquetes entre junio y diciembre de 2024:

Paquetes con payload malicioso:

  • nhattuanbl/lara-helper (37 descargas)

  • nhattuanbl/simple-queue (29 descargas)

  • nhattuanbl/lara-swagger (49 descargas)

Paquetes limpios (para generar confianza):

  • nhattuanbl/lara-media

  • nhattuanbl/snooze

  • nhattuanbl/lara-syslog

El patrón es claro: nombres genéricos que suenan a utilidades legítimas de Laravel, mezclados con paquetes limpios para que el perfil del autor parezca fiable.

Cómo funciona el ataque

Paso 1: La instalación silenciosa

lara-helper y simple-queue contienen el payload malicioso directamente en un archivo src/helper.php.

lara-swagger parece limpio a simple vista, pero en su composer.json declara una dependencia directa a nhattuanbl/lara-helper@dev-master. Al instalar el paquete de Swagger, Composer descarga e instala automáticamente el paquete infectado. Esto es un ataque a la cadena de suministro en toda regla.

Paso 2: La ejecución automática

En lara-helper, el troyano se carga mediante el auto-discovery de service providers de Laravel. El método register() del provider hace un include incondicional del archivo helper.php, lo que significa que se ejecuta en cada arranque de la aplicación, sin que el desarrollador haga nada:

<?php

// Service provider malicioso simplificado
public function register(): void
{
    include_once __DIR__ . '/../helper.php'; // RAT se carga aquí
}

En simple-queue, el enfoque es diferente pero igual de efectivo: usa un include_once a nivel de archivo, así que el payload se ejecuta en cuanto el autoloader de Composer resuelve la clase, aunque nunca la instancies.

Paso 3: El payload

El archivo helper.php tiene 27 KB escritos en una sola línea. Está ofuscado con flujo de control basado en goto, etiquetas aleatorias e identificadores codificados en hexadecimal y octal para dificultar cualquier análisis estático.

Lo que hace al cargarse:

  1. Se relanza como un proceso PHP en background (nohup en Unix, start /B en Windows)

  2. Crea un archivo de lock en el directorio temporal para evitar múltiples instancias

  3. Conecta por TCP al servidor de comando y control (C2) en helper[.]leuleu[.]net:2096

  4. Envía un perfil completo del sistema: OS, hostname, usuario, permisos, ruta del payload

  5. Queda a la espera de comandos del atacante

La comunicación está cifrada con AES-128-CTR usando una clave hardcodeada de 16 bytes y un IV aleatorio por mensaje.

Paso 4: Control total

Una vez conectado, el atacante puede:

  • Ejecutar comandos de shell y PowerShell de forma interactiva

  • Leer y escribir archivos arbitrarios con permisos de escritura global

  • Hacer capturas de pantalla

  • Subir y descargar archivos

  • Ejecutar comandos en background

Y lo más grave: el RAT corre dentro del mismo proceso que tu aplicación Laravel. Tiene acceso directo a tu .env, credenciales de base de datos, API keys, tokens y cualquier archivo accesible por el usuario de la aplicación.

Aunque el servidor C2 no responda en este momento, el malware persiste en disco y reintenta la conexión cada 15 segundos. El atacante puede reactivar la operación en cualquier momento redirigiendo el tráfico DNS.

Si has instalado alguno de estos paquetes

  1. Trata el servidor como comprometido inmediatamente

  2. Elimina los paquetes y el archivo helper.php

  3. Elimina el archivo de lock del directorio temporal

  4. Rota todas las credenciales: base de datos, API keys, tokens, todo lo que esté en tu .env

  5. Revisa los logs de red en busca de conexiones a helper[.]leuleu[.]net:2096

  6. Busca archivos con permisos de escritura global que puedan haber sido subidos por el RAT

Indicadores de compromiso (IOCs)

Indicador

Valor

Paquete

nhattuanbl/lara-helper v5.4.7

Paquete

nhattuanbl/simple-queue v1.5

Paquete

nhattuanbl/lara-swagger v2.0

Servidor C2

helper[.]leuleu[.]net:2096

Archivo malicioso

src/helper.php

SHA-256

a493ce9509c5180e997a04cab2006a48202afbb8edfa15149a4521067191ead7

La lección: menos dependencias, más seguridad

Este caso, aunque de impacto limitado, debería servir como llamada de atención para cualquier desarrollador PHP. Algunas prácticas que deberías aplicar siempre:

Instala solo paquetes de fuentes conocidas y verificadas. Si no conoces al autor, si el paquete tiene pocas descargas, si no tiene un repositorio activo con issues y contribuciones reales, no lo instales. Punto.

Minimiza tus dependencias. Cada paquete que añades a tu composer.json es un vector de ataque potencial. Antes de hacer composer require, pregúntate: ¿realmente necesito este paquete o puedo resolverlo con 20 líneas de código? En muchos casos, la respuesta es que puedes hacerlo tú mismo.

Nunca uses dev-master en producción. Una restricción @dev-master permite al autor del paquete cambiar el código en cualquier momento sin que tú te enteres. Fija siempre versiones concretas.

Audita las dependencias transitivas. No basta con revisar lo que instalas directamente. Ejecuta composer show y revisa qué paquetes se han instalado como dependencias de tus dependencias. En este caso, lara-swagger parecía limpio, pero arrastraba el malware a través de lara-helper.

Revisa el composer.lock en cada PR. Cualquier cambio en el lock file debería levantar una alerta. Si aparece un paquete nuevo que nadie ha solicitado explícitamente, investiga antes de aprobar.

Usa herramientas de análisis de seguridad. Herramientas como composer audit (incluido en Composer 2.4+), Snyk, Socket o Dependabot pueden detectar paquetes con vulnerabilidades conocidas o comportamientos sospechosos:

composer audit

Este comando revisa tu composer.lock contra la base de datos de advisories de seguridad de Packagist y te muestra si alguno de tus paquetes tiene vulnerabilidades conocidas.

La seguridad de tu aplicación empieza en tu composer.json. No instales nada a ciegas. Y ante la duda, menos es más.

Fuentes

school Curso completo

Curso Laravel 12
Completo 2026

El único curso 100% actualizado que incluye Laravel 12, Livewire 3, Vue 3, React 19 e Inertia 2. Aprende con proyectos reales y las últimas funcionalidades.

access_time 8 horas de contenido
layers 4 tecnologías en 1
update 100% actualizado
code Proyectos prácticos
Ver Curso Laravel 12 arrow_forward

star Incluido en cualquier suscripción

Rutas de aprendizaje