Las cookies acaban de convertirse en el mando a distancia perfecto para hackers.
El equipo de Defender de Microsoft soltó una bomba: los actores de amenazas están weaponizando cookies HTTP para controlar shells web PHP controlados por cookies en servidores Linux, esquivando detecciones como verdaderos expertos. Olvídate de parámetros URL o cuerpos POST: estos shells extraen las instrucciones directamente de $_COOKIE, activándose solo con los valores precisos. ¿Sigilosos? Ni te cuento. Y los combinan con jobs de cron para una persistencia de auto-reparación que se burla de los equipos de limpieza.
Así va la mecánica pura, directamente de la investigación. Los atacantes logran acceso inicial —credenciales legítimas o explotando una vulnerabilidad— y plantan un job de cron que invoca un loader PHP ofuscado cada pocos minutos. ¿Ese loader? Duerme con el tráfico normal. Pero introduces la cookie mágica, y ¡zas!: ejecución remota de código, subidas de archivos, despliegue de payloads. Microsoft lo describe a la perfección:
“Al trasladar el control de ejecución a las cookies, el web shell puede permanecer oculto en el tráfico normal, activándose solo durante interacciones deliberadas.”
Tres variantes detectadas. Una es una bestia de ofuscación multicapa que parsea datos de cookies para desempaquetar payloads secundarios. Otra reconstruye funciones desde fragmentos de cookies, las escribe en disco y las ejecuta. La más simple: una sola cookie como gatillo para el caos que le metas.
¿Por qué las cookies aplastan los trucos clásicos de web shells?
Las web shells no son ninguna novedad —piensa en las olas de los años 2010 azotando servidores Apache—. Pero ¿cookies? Giro genial. Vienen en cada request legítima, sin dolores de cabeza de parsing, sin gritos en logs. Acceso en runtime vía superglobals: cero código extra. Se mimetizan con el ruido de la app normal, y tu EDR bosteza.
Comparadas con los trucos viejos de URL: esos brillan como luces de Navidad en los logs de acceso. ¿Cookies? Enterradas en headers, a menudo filtradas o ignoradas. Además, este control las mantiene inertes —ideal para C2 a largo plazo sin pings constantes.
Pero mi lectura, la que Microsoft pasa de puntillas: esto apesta a estrategias de backdoors Unix reciclados de los 90. ¿Recuerdas esos worms académicos que se cronizan en /tmp? Misma onda —usar paths legítimos (procs web, paneles de control, crons) para staging. No es innovador, solo reutilización brutalmente efectiva. Apuesto: esto salta a nubes contenedorizadas, mutando crons en jobs de Kubernetes.
La pesadilla del cron de auto-reparación
La persistencia es la estrella aquí. ¿Borrás el loader? El cron lo revive. Sin escrituras ruidosas durante las operaciones, solo hits programados. Microsoft lo vio en entornos Linux hospedados —víctimas de cPanel incluidas—.
“Esta arquitectura de ‘auto-reparación’ permite que el loader PHP se recree repetidamente mediante la tarea programada, incluso si se eliminó durante esfuerzos de limpieza y remediación.”
Brillantez operativa. Separa persistencia (cron) de control (cookies), silenciando logs. No hacen falta cadenas de exploits; secuestran lo que ya está. Hemos visto picos en shells Linux post-Log4j —esto encaja, con actores extendiendo tiempos de permanencia post-brecha.
Los detectores patinan. Escaneos estáticos fallan con código dormido. ¿Comportamiento? Las cookies parecen inofensivas. Huella mínima: ofuscación por todos lados, sin binarios gordos.
Y sí, el comunicado de Microsoft lo pinta como ‘técnica establecida’ —justo, pero subestiman el ángulo económico. Barrera baja: cualquier script kiddie con habilidades en PHP lo clona. ¿Dinámica de mercado? Los proveedores de hosting sangran primero —cajas Linux compartidas son un buffet libre.
¿Esto destroza las defensas tradicionales?
Respuesta corta: en gran parte sí. ¿WAFs? Las cookies suelen quedar exentas. El volumen de logs ahoga señales. Pero hay grietas.
El playbook de Microsoft —base sólida—. MFA en todo (SSH, panele
