Señales de compromiso previo al parche

La mitigación cierra la puerta desde el momento en que se aplica. No dice nada de quién entró antes. Un fallo de borde que se explotaba antes del aviso obliga a hacer dos preguntas distintas: si el equipo sigue siendo vulnerable (lo responde la mitigación o el parche) y si el equipo ya estaba comprometido (lo responde la evidencia anterior a la mitigación).

En la matriz MITRE ATT&CK, la entrada por un fallo de un servicio expuesto es la técnica T1190 (explotación de una aplicación expuesta al público), y lo que se deja dentro para volver suele ser un componente añadido al servidor web del equipo (T1505.003) o una cuenta local nueva (T1136.001). Las señales que publica el fabricante apuntan justo a eso.

Abre la consola y ejecuta SELECT * FROM senales_del_aviso, SELECT * FROM mitigacion y SELECT * FROM registro_portal. Las peticiones sin sesión a rutas de administración que reciben 403 llegaron con la mitigación ya aplicada: son intentos rechazados. Lo que buscas es lo que recibió 200 sin sesión antes de la mitigación de ese mismo equipo.

La hora de la primera señal de compromiso es el dato que más se usa después: fija el inicio de la revisión de ese equipo, entra en el reporte a la autoridad y permite que otros comparen con lo suyo. Fíjate que es anterior al aviso del fabricante.

Ejecuta SELECT * FROM integridad. Las cuatro pasarelas salieron limpias el 5 de marzo con la v1. El 11, con la v2, una de ellas muestra un archivo que no forma parte de la imagen del fabricante, en la partición que la v1 no revisaba. Mira su fecha de creación: encaja con las peticiones de la tarea anterior.

Ejecuta SELECT * FROM salidas_de_equipos. El mismo equipo se conecta cada pocos días hacia una dirección que no es la de actualizaciones de Quelmar, también desde antes del aviso. Con tres señales que encajan entre sí, el caso deja de ser «vulnerable» y pasa a ser «comprometido».