
El objetivo es clasificar ataques conocidos y aprender cómo los equipos de seguridad responden rápidamente.
Para este laboratorio, el objetivo era hacer triage de otra vulnerabilidad real y conocida, esta vez EternalBlue, la falla de SMBv1 que fue explotada famosamente por el brote de ransomware WannaCry.
Fui a la Base de Datos Nacional de Vulnerabilidades y busqué el CVE:
https://nvd.nist.gov/vuln/search#/nvd/home?resultType=records
Busqué CVE-2017-0144 y abrí la página de resultados.
Después de leer la descripción, respondí algunas preguntas básicas para entender qué está realmente en riesgo:
Encontré la puntuación CVSS y la cadena del vector en la página:

Revisé la cadena del vector parte por parte para ver qué significaba cada componente:
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Esta requiere una pequeña cantidad de privilegios para explotarse (a diferencia de ProxyLogon, que no requería ninguno), pero tampoco necesita interacción del usuario, y un ataque exitoso sigue comprometiendo por completo la confidencialidad, la integridad y la disponibilidad. Esa combinación es una gran parte de la razón por la que EternalBlue fue tan peligroso una vez que se emparejó con un gusano de autopropagación como WannaCry.
Revisé la sección de Enumeración de Debilidades en la página de NVD para este CVE, pero no se listó ningún CWE para él.
Consideré si trataría esto como un riesgo mayor o menor bajo dos escenarios diferentes.
Escenario 1: El software vulnerable está activo y es accesible. Riesgo mayor. Esta vulnerabilidad permite a un atacante acceder remotamente al servidor, ejecutar código y acceder a archivos.
Escenario 2: El software vulnerable está instalado en una máquina que está apagada y no es accesible. Riesgo menor. Sin energía ni conexión de red, no hay forma de que un atacante alcance realmente el servidor para explotar la vulnerabilidad en primer lugar.
Comparando esto con el triage de ProxyLogon, es un buen ejemplo de cómo dos vulnerabilidades críticas pueden diferir en los detalles: EternalBlue necesita privilegios bajos mientras que ProxyLogon no requería ninguno, pero ambas siguen cayendo en la categoría de "tratar como alto riesgo" una vez que se observa cuánto daño podría causar una explotación exitosa. Igual que antes, el riesgo real sigue dependiendo del contexto: la misma vulnerabilidad es mucho menos peligrosa en una máquina que está fuera de línea e inaccesible.