What is an attack vector? Understanding its relationship with the attack surface

Understand what an attack vector is, how it relates to the attack surface, and why connecting exposures helps identify possible attack paths.

ByLeonnes Cybersecurity | 25 August 2026

Lion Focus — exposed assets and published services on the attack surface

During an attack surface mapping exercise, a subdomain appears that was not in the inventory. It responds and leads to an old application whose technology can be identified externally, with a known vulnerability affecting that version.

So far, this is a fairly common situation in exposure analysis. We have an asset that was not being tracked, an Internet-facing application, and a vulnerability that needs to be assessed. The question becomes: How could an attacker use this exposure to gain access or move further into the environment?

This is where the concept of an attack vector starts to make sense.

Attack surface and attack vector are not the same thing

The two concepts are related, but they describe different things. When we talk about the attack surface, we are looking at assets and points that can be found or reached, such as applications, IP addresses, services, APIs, cloud environments, and other exposed resources. An attack vector is a possible way of using one of those points to try to compromise a system or gain access. OWASP uses the term attack vector to describe the path an attacker can take to exploit a vulnerability.

In our old-application example, the subdomain and application are part of the attack surface. If the identified vulnerability can be exploited remotely, we begin to see a possible vector:

Internet → Exposed application → Vulnerability → Access

The investigation rarely needs to stop at the first finding. While analyzing the application, we find a reference to an API and, while looking for related information, a public repository appears with old integration documentation and a secret apparently used to access it.

The subdomain, application, vulnerability, API, repository, and secret could have been identified by different tools and recorded as separate findings. From an offensive perspective, what matters is whether there is a relationship between them. Perhaps the application vulnerability provides access; perhaps the secret in the repository still works and can authenticate directly to the API; or perhaps neither option is viable. At this point, we are still investigating.

A vulnerability is not always the beginning of the path

When we think about an attack, it is natural to associate the entry point with a vulnerability, especially because CVEs, exploits, and outdated software are part of everyday security work. In practice, there are other paths. A leaked corporate credential may provide access to an Internet-facing service without exploiting software at all. An exposed secret may allow authentication to an API, while a cloud misconfiguration may make resources accessible in a way they should not be. Phishing and other social engineering techniques can also be the starting point.

CISA uses the concept of an initial attack vector during incident investigations to understand how an adversary first gained access to an environment. In our example, if the secret found in the repository is still valid and works against the API, the attacker may not need to exploit the vulnerability that initially caught our attention.

During an analysis, it is relatively common to start investigating one exposure and find information that points to another. Sometimes the path ends quickly; in other cases, a finding that looked secondary becomes more interesting than the one that started the investigation.

Our scenario might evolve like this:

Subdomain → Application → API → Secret → Access

If that access can reach another resource, the analysis may continue. At that point we begin to approach the concept of an attack path, where different conditions and access opportunities form a route from the initial point to other resources in the environment. We do not need to turn every group of findings into a major attack path; often, no such path exists. What matters is not assuming that exposures must always be analyzed in isolation.

A relationship between exposures does not prove the attack

Let us return to the previous scenario. We found the subdomain, identified the application and its API, and discovered a secret in a public repository. There is an interesting relationship between those pieces of information, but we still do not know whether the path works. The secret may have been revoked months ago, the API may require another authentication mechanism, the application vulnerability may not be exploitable in that specific configuration, or controls may prevent movement toward other resources.

Validation helps separate a technically possible hypothesis from an exposure supported by more concrete evidence. Depending on the situation, this may involve confirming that a service is actually reachable, checking specific technical conditions, determining whether a credential is still relevant, or performing deeper offensive analysis.

The goal is not to exploit everything we find; in most cases, that would not even make sense. We want to reduce uncertainty enough to understand which exposures deserve attention. If, for example, we have two critical vulnerabilities and a third rated high, the critical ones naturally come first when we look only at severity. But if the high-severity vulnerability sits in an Internet-facing application and is part of a path we can connect to other exposures, that information may change the priority of the analysis. The severity did not change; what changed is what we know about the exposure.

From attack surface to a possible path

Attack surface and attack vector are more useful when analyzed together. The first helps us understand where exposed points are; the second brings us closer to understanding how those points might be used.

In an organization with many assets, discovery may find dozens of subdomains, applications, and services, while other sources bring vulnerabilities, leaked credentials, secrets, public information, and misconfigurations. If each finding remains isolated, we have an inventory of exposures. Once we start establishing relationships between some of them, possible paths begin to emerge.

Not all of those paths will be relevant, and many will stop making sense as soon as they are analyzed more deeply. Others may show that an apparently simple exposure deserves more attention than it first seemed. Thinking in terms of vectors brings exposure management closer to an offensive perspective because, instead of asking only what is published or which vulnerabilities exist, we begin to consider another question: If I were trying to get in, where would I start?

The answer may be a known vulnerability, but it may also be a leaked credential, a forgotten secret in a repository, or an application nobody remembered was still online. For an attacker, finding an asset is rarely the objective; it is simply where the path begins.