La diferencia entre encontrar vulnerabilidades y simular un ataque

Cada vez escucho hablar más de pentesting como un objetivo de seguridad. Sin embargo, muchas veces el término se utiliza para describir trabajos completamente distintos. Hay empresas que reciben un informe de miles de líneas con CVEs, configuraciones inseguras y recomendaciones… y creen que eso es un pentest.

Spoiler: un pentest no es un listado de vulnerabilidades es un escaneo de seguridad intenta responder una pregunta muy concreta:

¿Qué cosas están mal?

Encontrar una vulnerabilidad con un CVSS 9.8 no implica necesariamente que represente un riesgo inmediato. Puede tratarse de un servicio inaccesible desde la red, protegido por otros controles o directamente imposible de explotar en ese contexto.

Un penetration test, en cambio, intenta responder una pregunta completamente distinta:

¿Qué podría hacer un atacante real con esas debilidades?

La diferencia parece sutil, pero cambia completamente el objetivo.

Ya que, en cambio, cinco vulnerabilidades catalogadas como "medias" pueden permitir un compromiso completo cuando se encadenan correctamente.

Pensemos en el siguiente ejemplo:

Un escáner puede encontrar una contraseña por defecto o susceptible a un ataque de diccionario, una versión vulnerable de Apache, un SMB mal configurado, credenciales débiles, un Active Directory con delegaciones excesivas o una aplicación web susceptible a SQL Injection. Todo eso es información valiosa.

Ninguna de esas vulnerabilidades, por separado, parecería representar un desastre. pero ¿Qué pasa si las jutamos?,

Un escáner puede encontrar una contraseña susceptible a ataque de diccionario, una versión vulnerable de Apache, un SMB mal configurado, credenciales débiles, un Active Directory con delegaciones excesivas o una aplicación web vulnerable a SQL Injection. Individualmente, ninguna de esas vulnerabilidades parece capaz de comprometer toda la organización.

Pero un atacante no piensa en vulnerabilidades aisladas.

Piensa en caminos.

Una contraseña débil puede abrir la puerta a un servidor de desarrollo. Desde allí, una cuenta de servicio con permisos excesivos permite consultar Active Directory. Esa información revela un servidor olvidado que todavía acepta autenticación NTLM. El movimiento lateral lleva finalmente a un controlador de dominio.

Debe demostrar hasta dónde puede llegar un atacante. Y, cuando existe un ambiente adecuado para hacerlo, debería poder responder preguntas como:

• ¿Es posible comprometer un servidor crítico?

• ¿Puede obtener privilegios administrativos?

• ¿Es posible moverse lateralmente hacia otros sistemas?

• ¿Qué información podría exfiltrarse?

• ¿Cuánto tiempo llevó lograrlo?

Pero incluso ahí falta otra parte que muchas organizaciones olvidan.

Mientras el equipo de pentesting intenta avanzar…

· ¿El SIEM detectó algo?

· ¿El SOC recibió alertas?

· ¿Si se generaron incidentes?, ¿Alguien inició el proceso de respuesta?

¿O el atacante llegó hasta Domain Admin sin que nadie levantara una ceja? Porque un ataque no termina cuando alguien demuestra que podía entrar.

El verdadero valor aparece cuando la organización entiende si hubiera sido capaz de descubrirlo mientras ocurría. Ahí es donde un pentest empieza a convertirse en un ejercicio de seguridad mucho más cercano a la realidad. Por eso, la pregunta que debería hacerse un CISO no es cuántas vulnerabilidades encontró el proveedor.

La pregunta es mucho más incómoda:

"¿Cuál fue el activo más sensible al que lograron llegar?"

Lo interesante es que un atacante rara vez necesita una única vulnerabilidad crítica. Le alcanza con varias vulnerabilidades "aceptables" correctamente encadenadas. Entender esos caminos de ataque es uno de los motivos por los cuales los penetration tests aportan un valor muy distinto al de un simple escaneo de vulnerabilidades.

En un próximo artículo vamos a hablar justamente de una técnica que ayuda a modelar esos escenarios antes de que ocurran: los Attack Trees, propuestos por Bruce Schneier.