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-medianhattuanbl/snoozenhattuanbl/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:
Se relanza como un proceso PHP en background (
nohupen Unix,start /Ben Windows)Crea un archivo de lock en el directorio temporal para evitar múltiples instancias
Conecta por TCP al servidor de comando y control (C2) en
helper[.]leuleu[.]net:2096Envía un perfil completo del sistema: OS, hostname, usuario, permisos, ruta del payload
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
Trata el servidor como comprometido inmediatamente
Elimina los paquetes y el archivo
helper.phpElimina el archivo de lock del directorio temporal
Rota todas las credenciales: base de datos, API keys, tokens, todo lo que esté en tu
.envRevisa los logs de red en busca de conexiones a
helper[.]leuleu[.]net:2096Busca archivos con permisos de escritura global que puedan haber sido subidos por el RAT
Indicadores de compromiso (IOCs)
Indicador | Valor |
|---|---|
Paquete |
|
Paquete |
|
Paquete |
|
Servidor C2 |
|
Archivo malicioso |
|
SHA-256 |
|
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 auditEste 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
Socket - Malicious Packagist Packages Disguised as Laravel Utilities
The Hacker News - Fake Laravel Packages on Packagist Deploy RAT
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.
star Incluido en cualquier suscripción