Detección y respuesta
Además de aplicar los parches, el SOC recomienda una revisión retroactiva de los sistemas expuestos al menos desde el 17 de octubre de 2026, siempre que exista telemetría. Correlacione los accesos sospechosos con la ejecución de procesos, los cambios en archivos, las conexiones salientes y los eventos de autenticación. La ausencia de telemetría o de alertas no demuestra que no se haya producido una explotación.
1. Telemetría de procesos / EDR
Genere una alerta ante cualquier proceso iniciado por php-fpm, php-cgi, httpd o apache2 que lance una shell o herramientas de descarga (sh, bash, dash, curl, wget, nc, python, perl). En funcionamiento normal, este comportamiento es poco frecuente y debe tratarse como un posible compromiso.
2. Registros web y de PHP
• Ráfagas de solicitudes POST multipart/form-data desde el mismo origen, especialmente con un número inusual de partes o de encabezados.
• Nombres de campo profundamente anidados o solicitudes que incluyen PHP_SESSION_UPLOAD_PROGRESS, también hacia endpoints que no deberían aceptar subidas de archivos.
• Respuestas HTTP 500 repetidas, caídas o reinicios inesperados de los workers de PHP.
• Cookies PHPSESSID malformadas o inusualmente largas y errores repetidos (SIGSEGV, AH00052, zend_mm_heap corrupted, "Allowed memory size … in Unknown on line 0") en los registros de PHP, Apache o FPM.
3. Sistema de archivos y persistencia
• Archivos PHP nuevos o modificados en directorios de subida, de caché o accesibles desde la web; compruebe la marca de tiempo, el propietario y el contenido.
• Nuevas tareas cron para el usuario del servidor web, claves SSH o cuentas añadidas recientemente; conexiones salientes inusuales iniciadas por los workers web.
4. Cómo utilizar los indicadores de compromiso (IOC)
Trate los IOC como puntos de partida para la correlación, no como prueba por sí solos: algunas direcciones pueden pertenecer a infraestructuras de anonimización o aparecer en tráfico legítimo. Una coincidencia no confirma un compromiso ni justifica un bloqueo automático. Valide el origen, la fecha y el contexto de cada indicador, contrastándolo con la telemetría de host/red.
Respuesta a incidentes: si hay indicios creíbles de compromiso
1. Aísle el sistema afectado y limite el acceso a la red sin destruir las evidencias.
2. Conserve los registros y, si es posible, una imagen del disco y los artefactos de memoria/procesos pertinentes.
3. Rote todas las credenciales accesibles para el proceso web: contraseñas de bases de datos, claves de API, tokens y secretos de .env.
4. Continúe la investigación en busca de persistencia, exfiltración y movimiento lateral. Actualizar PHP por sí solo no elimina el acceso de un atacante si el sistema ya estaba comprometido.
5. Escale al equipo SOC/IR y evalúe las obligaciones de notificación aplicables (RGPD, NIS2).
Para PHP 8.1 y versiones anteriores, compruebe si su distribuidor ofrece parches con backport documentados. Si no existe una corrección con soporte, planifique una migración. Reconstruya las imágenes de contenedor a partir de imágenes base actualizadas y vuelva a desplegarlas; actualizar el host no actualiza el PHP del interior del contenedor.
