Ataque Masivo a la Cadena de Suministro de Laravel Lang Robo de Credenciales

Investigadores de seguridad han identificado una campaña de compromisos en la cadena de suministro de software que aprovechó versiones maliciosas de varios paquetes PHP del proyecto Laravel-Lang para introducir un marco de robo de credenciales de gran alcance. Los atacantes publicaron cientos de etiquetas en muy poco tiempo, lo que sugiere que no se trató de una única versión comprometida sino de una violación en el proceso de publicación de la organización: la reutilización de credenciales de automatización o el control de la infraestructura de releases permite repoblar múltiples repositorios con cambios maliciosos de forma masiva.

El componente malicioso principal se ocultaba en un archivo llamado src/helpers.php, registrado en composer.json bajo autoload.files, de modo que se ejecuta automáticamente en cada petición PHP del proyecto infectado. Desde allí se fingerprinta la máquina y se contacta a un servidor externo para descargar un payload multiplataforma: en Windows la cadena de entrega dispara un launcher en VBScript ejecutado por cscript, y en Linux/macOS se lanza mediante llamadas a exec(). Los informes describen un ladrón modular en PHP —con colecciones especialistas para distintos tipos de secretos— que cifra los resultados con AES-256 y los exfiltra, eliminando rastros locales tras la ejecución.

El alcance técnico de lo exfiltrado es extraordinario y explica por qué este tipo de intrusión es tan peligrosa: se buscan credenciales y tokens de proveedores de nube, metadatos de instancias, credenciales de runners y pipelines CI/CD, tokens de registries y servicios de despliegue, configuraciones de Kubernetes y Helm, pares de claves SSH, ficheros .env, credenciales de Git y gestores de contraseñas y carteras de criptomonedas, además de cookies y credenciales de navegadores. Con esa información los atacantes pueden pivotar rápidamente desde una aplicación web comprometida hasta infraestructuras en la nube o cuentas de desarrolladores, multiplicando el daño.

Las señales técnicas descritas —más de 700 versiones etiquetadas en cuestión de segundos— apuntan a un compromiso a nivel organización/automatización más que a un acto aislado. Esto tiene consecuencias operativas: cualquier proyecto que dependa de esos paquetes y que actualice dependencias automáticamente, o que realice despliegues desde entornos con acceso a secretos, puede haber activado el ladrón sin intervención humana. Además, la ejecución vía autoload implica que una simple petición HTTP a una aplicación web desplegada podría ser suficiente para desencadenar el robo.

Para equipos que mantienen proyectos y para administradores que dependen de paquetes de terceros hay medidas urgentes que conviene tomar de inmediato. En el plano operativo es imprescindible auditar los repositorios afectados y las pipelines: revisar los logs de publicación, rotar y revocar cualquier credencial asociada a la organización (tokens de automatización, claves de CI/CD, credenciales de empaquetado), y verificar la integridad de las imágenes y artefactos desplegados. También hay que comprobar el composer.lock y el árbol de vendor en instalaciones existentes, buscando la presencia de ese helpers.php u otros indicadores de compromiso, y reinstalar dependencias desde orígenes conocidos y firmados cuando sea posible.

Los desarrolladores y proveedores de servicios deben priorizar la contención en los entornos productivos: ejecutar análisis forense en servidores web y build servers, buscar procesos y scripts anómalos (VBScript en Windows, ejecuciones exec() inesperadas en Unix), monitorizar salidas de red hacia dominios sospechosos y suspender o aislar sistemas con evidencias de ejecución. A nivel de credenciales, la rotación inmediata de claves de proveedor de nube, tokens de registries y secretos usados por runners y Deploy Keys es crítica; donde sea posible, reemplazar secretos permanentes por mecanismos de identidad federada (por ejemplo OIDC) y políticas de acceso temporal. Para guiar prácticas de defensa más amplias conviene consultar recursos sobre hardening de organizaciones y seguridad de la cadena de suministro, como la documentación de GitHub para organizaciones (https://docs.github.com/en/organizations/keeping-your-organization-secure/securing-your-organization) y las recomendaciones del proyecto OWASP sobre seguridad de la cadena de suministro de software (https://owasp.org/www-project-software-supply-chain-security/).

Para los mantenedores de paquetes y las organizaciones que publican artefactos, el incidente es un recordatorio de la necesidad de proteger la infraestructura de releases: activar la verificación en dos pasos para las cuentas del equipo, limitar el uso de tokens con scope mínimo, auditar y rotar runners y claves de CI, y configurar controles de aprobaciones manuales para publicaciones masivas. La firma de paquetes y la adopción de mecanismos como sigstore/SLSA pueden mitigar riesgos similares en el futuro; mientras tanto, comprobar que las releases provienen de procesos reproducibles reduce la vulnerabilidad a modificaciones en la cadena de publicación. La documentación de Composer sobre autoload y su impacto operativo es una referencia útil para entender cómo un archivo incluido en autoload.files puede convertirse en vector de ejecución (https://getcomposer.org/doc/04-schema.md#autoloadfiles).

Si usted mantiene una aplicación que usa paquetes de Laravel-Lang, actúe con prioridad: fije versiones conocidas buenas en lugar de aceptar actualizaciones automáticas, inspeccione el vendor por la presencia de helpers u otros archivos inusuales, y rehaga despliegues desde fuentes limpias tras rotar secretos. Si detecta signos de compromiso, coordine la respuesta con su equipo de seguridad, preserve registros para análisis forense y notifique a los proveedores afectados para que puedan revocar credenciales potencialmente exfiltradas. También es recomendable activar sistemas de detección de intrusiones y EDR con reglas que identifiquen ejecuciones inusuales de cscript, llamadas exec() sospechosas y conexiones salientes a dominios de exfiltración.

Este incidente subraya que la seguridad en el desarrollo no es solo una cuestión de código sino de procesos y permisos: la automatización que acelera entregas también expone a la organización si los tokens y pipelines no se gestionan con el principio de menor privilegio. Adoptar prácticas de protección de la cadena de suministro, auditar accesos regularmente y minimizar secretos persistentes en pipelines son pasos que reducen la probabilidad de que una única cuenta comprometida derive en una campaña de mayor escala.

Finalmente, si necesita información técnica adicional o plantillas de respuesta, consulte las guías de respuesta a incidentes de su proveedor de nube y herramientas de análisis de dependencias como escáneres comerciales y gratuitos; y manténgase atento a los avisos oficiales del proyecto afectado (por ejemplo, el repositorio Laravel-Lang/lang) y de equipos de respuesta que publiquen IOCs y remedios concretos.