¿Qué es un vector de ataque? Entiende su relación con la superficie de ataque

Entiende qué es un vector de ataque, cómo se relaciona con la superficie de ataque y por qué conectar exposiciones ayuda a identificar posibles caminos de ataque.

PorLeonnes Cybersecurity | 25 de agosto de 2026

Lion Focus — activos expuestos y servicios publicados en la superficie de ataque

Durante el mapeo de la superficie de ataque aparece un subdominio que no estaba en el inventario. Responde y conduce a una aplicación antigua cuya tecnología puede identificarse externamente y que utiliza una versión afectada por una vulnerabilidad conocida.

Hasta aquí, es una situación relativamente común en un análisis de exposición. Tenemos un activo que no estaba siendo monitoreado, una aplicación accesible desde Internet y una vulnerabilidad que necesita ser analizada. La pregunta pasa a ser: ¿Cómo podría un atacante utilizar esta exposición para intentar obtener acceso o avanzar sobre el entorno?

Es en ese momento cuando el concepto de vector de ataque comienza a tener sentido.

Superficie de ataque y vector de ataque no son lo mismo

Los dos conceptos están relacionados, pero representan cosas diferentes. Cuando hablamos de superficie de ataque, observamos los activos y puntos que pueden encontrarse o alcanzarse, como aplicaciones, direcciones IP, servicios, APIs, entornos cloud y otros recursos expuestos. Un vector de ataque representa una posible forma de utilizar alguno de esos puntos para intentar comprometer un sistema u obtener acceso. OWASP utiliza el término attack vector para representar el camino que un atacante puede recorrer para explotar una vulnerabilidad.

En el ejemplo de la aplicación antigua, el subdominio y la aplicación forman parte de la superficie de ataque. Si la vulnerabilidad identificada puede explotarse remotamente, comenzamos a ver un posible vector:

Internet → Aplicación expuesta → Vulnerabilidad → Acceso

La investigación, sin embargo, difícilmente tiene que terminar en el primer hallazgo. Al analizar la aplicación encontramos una referencia a una API y, buscando información relacionada, aparece también un repositorio público con documentación antigua de esa integración y un secret aparentemente utilizado para acceder a ella.

El subdominio, la aplicación, la vulnerabilidad, la API, el repositorio y el secret podrían haber sido identificados por herramientas diferentes y registrados como findings independientes. Desde una perspectiva ofensiva, interesa entender si existe alguna relación entre ellos. Tal vez la vulnerabilidad de la aplicación permita obtener acceso; quizá el secret encontrado en el repositorio todavía funcione y permita autenticarse directamente en la API; o puede que ninguna de las dos posibilidades sea viable. En este momento todavía estamos investigando.

No siempre hay una vulnerabilidad al inicio del camino

Cuando pensamos en un ataque, es natural asociar el punto de entrada con una vulnerabilidad, especialmente porque CVEs, exploits y software desactualizado forman parte del trabajo cotidiano de seguridad. En la práctica existen otros caminos. Una credencial corporativa filtrada puede permitir acceso a un servicio publicado en Internet sin necesidad de explotar software. Un secret expuesto puede permitir autenticación en una API, mientras que una configuración inadecuada en cloud puede hacer accesibles recursos que no deberían estarlo. El phishing y otras técnicas de Ingeniería Social también pueden ser el inicio de un ataque.

CISA utiliza el concepto de initial attack vector durante la investigación de incidentes para entender cómo el adversario consiguió el primer acceso al entorno. En nuestro ejemplo, si el secret encontrado en el repositorio todavía es válido y puede utilizarse en la API, quizá el atacante ni siquiera necesite explotar la vulnerabilidad que inicialmente llamó nuestra atención.

Durante un análisis es relativamente común comenzar investigando una exposición y encontrar información que apunta hacia otra. A veces el camino termina rápidamente; en otras situaciones, un hallazgo que parecía secundario termina siendo más interesante que aquel que inició la investigación.

Podemos imaginar que nuestro escenario evolucionó de esta manera:

Subdominio → Aplicación → API → Secret → Acceso

Si el acceso obtenido permite alcanzar otro recurso, el análisis puede continuar. En ese punto nos acercamos al concepto de attack path, donde diferentes condiciones y accesos forman un camino entre el punto inicial y otros recursos del entorno. No necesitamos convertir cada conjunto de findings en un gran camino de ataque; muchas veces ese camino simplemente no existe. Lo importante es no asumir que las exposiciones encontradas deben analizarse siempre de forma aislada.

Encontrar una relación entre exposiciones todavía no demuestra el ataque

Volvamos al escenario anterior. Encontramos el subdominio, identificamos la aplicación y su API y descubrimos un secret en un repositorio público. Existe una relación interesante entre esa información, pero todavía no sabemos si el camino funciona. El secret puede haber sido revocado hace meses, la API puede exigir otro mecanismo de autenticación, la vulnerabilidad de la aplicación puede no ser explotable en esa configuración específica o pueden existir controles que impidan avanzar hacia otros recursos.

La validación ayuda a separar una hipótesis técnicamente posible de una exposición respaldada por evidencias más concretas. Dependiendo de la situación, esto puede implicar confirmar que un servicio realmente está accesible, verificar determinadas condiciones técnicas, analizar si una credencial todavía tiene relevancia o realizar una evaluación ofensiva más profunda.

El objetivo no es explotar todo lo que aparece; en la mayoría de los casos ni siquiera tendría sentido. Queremos reducir la incertidumbre lo suficiente para entender mejor qué exposiciones merecen atención. Si tenemos, por ejemplo, dos vulnerabilidades clasificadas como críticas y una tercera de severidad alta, las críticas naturalmente aparecen primero cuando miramos solamente la clasificación. Pero si la vulnerabilidad de severidad alta está en una aplicación expuesta a Internet y forma parte de un camino que podemos relacionar con otras exposiciones, esa información puede modificar la prioridad del análisis. La severidad no cambió; cambió lo que sabemos sobre la exposición.

De la superficie de ataque al posible camino

Superficie de ataque y vector de ataque son más útiles cuando se analizan en conjunto. El primer concepto ayuda a entender dónde están los puntos expuestos; el segundo nos acerca a la forma en que esos puntos podrían utilizarse.

En una organización con muchos activos, un discovery puede encontrar decenas de subdominios, aplicaciones y servicios, mientras otras fuentes aportan vulnerabilidades, credenciales filtradas, secrets, información pública y configuraciones inadecuadas. Si cada hallazgo permanece aislado, tendremos un inventario de exposiciones. Cuando comenzamos a establecer relaciones entre algunas de ellas, empezamos a ver posibles caminos.

No todos serán relevantes y muchos dejarán de tener sentido apenas se analicen con mayor profundidad. Otros pueden mostrar que una exposición aparentemente simple merece más atención de la que parecía inicialmente. Pensar en vectores acerca la gestión de exposición a una perspectiva ofensiva porque, en lugar de preguntar solamente qué está publicado o qué vulnerabilidades existen, comenzamos a considerar otra pregunta: Si estuviera intentando entrar, ¿por dónde comenzaría?

La respuesta puede estar en una vulnerabilidad conocida, pero también en una credencial filtrada, un secret olvidado en un repositorio o una aplicación que nadie recordaba que seguía publicada. Para un atacante, encontrar un activo rara vez es el objetivo; es simplemente el lugar por donde comienza.