Alerta: Paquetes de Laravel en Packagist traen backdoor y acceso remoto

En las últimas semanas, investigadores de seguridad han detectado una campaña que utiliza la propia infraestructura del ecosistema PHP para colar malware en proyectos Laravel: varios paquetes publicados en Packagist se hacían pasar por utilidades legítimas y, en realidad, activaban un acceso remoto persistente a las máquinas afectadas. El equipo que informó el hallazgo publicó un análisis detallado que puedes consultar en su blog (Socket), y las páginas de los paquetes están todavía accesibles en el registro público (perfil del autor en Packagist y los paquetes individuales como nhattuanbl/lara-helper, nhattuanbl/simple-queue y nhattuanbl/lara-swagger).

La táctica no era trivial: algunos de los paquetes no contenían código malicioso directamente, sino que introducían una dependencia que sí lo hacía. En concreto, uno de los paquetes actúa como puente y provoca que otra librería se instale como dependencia de Composer —el gestor de dependencias estándar en PHP— con todo lo que ello conlleva (documentación de Composer). Esa segunda librería incluye un archivo PHP ofuscado que, una vez cargado por la aplicación, establece comunicación con un servidor de mando y control (C2) y abre una puerta trasera.

Los analistas describen que el código malicioso está diseñado para dificultar el análisis: el autor recurrió a técnicas de ofuscación del flujo de control, nombres de funciones y variables aleatorios, además de codificar rutas y dominios. Cuando el payload se ejecuta, recoge información del sistema y mantiene una conexión con el C2 mediante sockets TCP usando funciones propias de PHP (por ejemplo, stream_socket_client()), esperando órdenes que pueden incluir ejecución de comandos, transferencia de ficheros, capturas de pantalla y la ejecución de PowerShell en sistemas Windows.

El riesgo va más allá de un simple script que se ejecuta: por cómo se activa el código —al iniciar la aplicación Laravel a través de un proveedor de servicios o mediante autoloading—, el malware corre dentro del mismo proceso que la aplicación web. Eso significa que hereda los permisos y las variables de entorno de la aplicación, y por ende puede acceder a credenciales almacenadas en .env, llaves de bases de datos, APIs y otros secretos que el proyecto tenga disponibles.

La muestra examinada intentaba reconectar continuamente si no encontraba respuesta del servidor C2, lo que la hace persistente y capaz de reestablecer comunicación en cuanto el atacante reactive su infraestructura. Aunque en el momento del informe el servidor de mando estaba fuera de línea, la presencia del código en sistemas en producción representa una amenaza real y duradera si no se actúa.

Si tu proyecto utiliza paquetes de terceros, y en particular si dependes de paquetes de autores poco conocidos, hay que asumir una postura defensiva. En primer lugar, hay que identificar rápidamente si alguno de los paquetes señalados está presente en el árbol de dependencias revisando composer.json y composer.lock y escaneando la carpeta vendor en busca de archivos sospechosos como helpers ofuscados. Si aparece código comprometido, lo prudente es eliminar la dependencia afectada, pero eso es solo el comienzo.

Asume que hubo compromiso: cualquier sistema que haya cargado el código malicioso debería considerarse potencialmente controlado. Es necesario rotar todas las credenciales que pudieran haber estado accesibles desde la aplicación (bases de datos, claves de servicio, tokens de terceros), auditar las salidas de red en busca de conexiones hacia dominios o IPs inusuales y revisar logs para detectar actividad remota. También conviene verificar integridad y permisos de archivos sensibles y, si hay dudas, restaurar desde copias de seguridad fiables y limpiar el entorno antes de volver a ponerlo en producción.

Este incidente encaja en el patrón más amplio de ataques a la cadena de suministro de software: actores maliciosos publican paquetes con apariencia legítima para que desarrolladores los instalen sin sospechar. Organizaciones y desarrolladores pueden reducir el riesgo adoptando prácticas como revisar cuidadosamente la procedencia de las dependencias, fijar versiones en composer.lock, auditar paquetes nuevos antes de su inclusión y usar herramientas de escaneo automatizado que detecten comportamientos sospechosos. Proyectos expertos y guías de seguridad sobre la cadena de suministro ofrecen recomendaciones prácticas que conviene seguir; por ejemplo, la comunidad OWASP mantiene recursos sobre seguridad en la cadena de suministro de software (OWASP Supply Chain).

Para administradores y desarrolladores PHP, también es útil conocer las configuraciones de PHP que limitan vectores de ataque, como la directiva disable_functions en php.ini, aunque el malware detectado intenta sortear estas protecciones probeando múltiples métodos para ejecutar comandos. La página oficial de PHP documenta estas y otras funciones relevantes (disable_functions en la documentación de PHP).

La lección es clara: la comodidad de instalar una utilidad desde el registro no puede sustituir a una mínima diligencia. Revisar reputación del autor, comprobar el contenido del paquete antes de instalarlo en entornos productivos y mantener políticas de rotación de secretos son medidas que ya no son opcionales. Si crees que has usado alguno de los paquetes implicados, actúa con rapidez, documenta las acciones y, si es necesario, busca ayuda profesional para la respuesta a incidentes.

Si quieres profundizar en el informe técnico, el despiece de la campaña y recomendaciones concretas están disponibles en el análisis de los investigadores (Socket), y las entradas de los paquetes pueden revisarse públicamente en Packagist (perfil del autor y las páginas de cada paquete). Para entender mejor las implicaciones de la cadena de suministro y las prácticas de defensa, consulta también recursos comunitarios y guías como los de OWASP y la documentación oficial de Composer (Composer).