Exploit
En seguridad ofensiva, un exploit es el software, la secuencia de comandos o la técnica que convierte una vulnerabilidad en acceso no autorizado o en impacto real. La vulnerabilidad es el defecto; el exploit es la demostración de que ese defecto se puede usar. La distancia entre las dos cosas es lo que decide con qué urgencia hay que actuar.
Cómo funciona
Un exploit toma una condición concreta y lleva al sistema a un estado que quien lo diseñó no previó: control del flujo de ejecución, una operación ejecutada con otra identidad, datos que salen y no debían salir, o una comprobación que se esquiva. Su fiabilidad depende del entorno, y por eso la explotación es un rango y no un sí o un no. Una petición que funciona en cualquier sitio y una técnica que necesita una disposición de memoria precisa, una versión concreta y varios intentos son ambas exploits, y solo una de ellas es el riesgo que llega solo, sin que nadie tenga que fijarse en tu empresa.
La prueba de concepto, que demuestra que la condición se puede disparar, es un artefacto distinto del exploit armado que consigue impacto fiable sobre objetivos reales. Buena parte del código publicado es de la primera clase, y esa es una de las razones por las que un exploit público no significa explotación masiva.
Los tipos que más se nombran describen desde dónde se dispara y contra qué. El de día cero (zero-day) aprovecha una vulnerabilidad para la que todavía no existe actualización de seguridad, así que no hay defensa preparada. El remoto llega por la red; el local necesita acceso previo a la máquina y suele ser el paso anterior a una escalada de privilegios. Y los de aplicación web, como la inyección SQL o el cross-site scripting, no tocan la memoria: abusan de la lógica de la propia aplicación.
Qué sale mal
Los dos sentidos del mismo error. Dar por inofensivo un agujero de seguridad porque no hay exploit público ignora que la ausencia de uno dice algo sobre la publicación, no sobre la dificultad. Tratar cada exploit publicado como una emergencia ignora que la mayoría necesitan condiciones que tu parque no presenta.
La salida es medir en vez de opinar. EPSS da una probabilidad de que llegue a observarse explotación. El catálogo KEV registra que ya se ha observado. Ninguna de las dos es severidad, y CVSS por sí solo no es explotabilidad, y por eso una cola ordenada por cualquiera de las tres está mal de una forma distinta.
El error emparentado es reducir la palabra a la corrupción de memoria. Buena parte de lo que explotamos en un encargo no lleva código: una comprobación de autorización que no está, un paso del flujo que se puede saltar, un token aceptado de una audiencia equivocada. Eso son exploits en todos los sentidos que le importan al cliente, y no tienen identificador ni parche.
Dónde aparece esto en una auditoría
Probamos la explotación y no la presencia, porque esa diferencia es para lo que sirve un informe. Cuando hay que ejecutar algo explotable en producción se acuerdan antes los límites, se demuestra el control con una acción que no deja efectos, y se deja escrito qué decidimos no hacer. El hallazgo lleva la petición, el resultado observado, las condiciones que hicieron falta y la identidad obtenida, para que el cliente distinga lo que un oportunista alcanzará la semana que viene de lo que necesitaba nuestra posición concreta dentro de su red. Es la diferencia entre un escáner y un test de intrusión.