What are attack vectors, attack paths and attack surfaces?

A vector is a Latin word that means carrier, and it still retains this sense within biology where it is used to refer to the transporter of an infection. However, attack vectors within cybersecurity are a broader concept that encompasses more than just the transport mechanism used in an attack. Attack vectors are perhaps most clearly understood by considering the meaning of the word vector in mathematics, physics, and geometry from which it originates. In these fields, a vector consists of an object that has a starting point known as the initial point or tail (the origin with cybersecurity), a destination known as the terminal point or head (the target within cybersecurity), a direction and a magnitude (the payload within cybersecurity). It also has a scale that may define the time taken.

Within cybersecurity, therefore, an attack vector encompasses many elements of a potential attack including the origin of the attacker (an external criminal or insider threat, for example), the targeted system, and also other elements such as the attack payload, impact, methodology and tools used:


What is an attack surface?


The set of all possible attack vectors in a system or organization is called the attack surface. The more attack vectors an organization has, the greater the attack surface that is available to attackers, and the greater the overall risk to the organisation. Keeping the attack surface as small as possible should therefore be considered to be key in maintaining a strong security posture for any organisation.

The attack surface of an organisation can be visualized using the analogy of a “bean bag toss” game that you might see at a fairground or carnival in which points are awarded for throwing bean bags through marked holes in the board. The board represents the organisation’s presence and technical estate, and a perfectly smooth board with no holes would indicate an impenetrable façade that provides total security. Each given attack vector in an organisation’s attack surface can be linked to one of the holes punched through the board, and the total area covered with holes is the overall attack surface. The larger each hole (attack vector), and the greater the number of holes, the more chance an attacker has of conducting a successful attack and punching through the security defenses. To carry out an attack successfully via a given attack vector requires there to be multiple elements: a vulnerability that has not been mitigated and is exploitable (a hole), a suitably positioned attacker in the right spot to launch an attack that can reach a vulnerability, and an available payload (beanbag).


What are attack paths?


An attack path is not quite the same as an attack vector, although the two terms are often confused or used interchangeable. An attack path is a visual representation of the complete and potentially ongoing flow that occurs during the exploitation of one or more vectors by an attacker. Specifically, an attack vector can be considered theoretically as a general case to be protected against, whereas an attack path is more typically used to model the specific path and methodology that an actual attack took, after the event. An attack path will typically string together multiple attack vectors into a single exploit. This is one of the factors that makes cybersecurity relatively complex, in that a successful attack may make multiple changes of directions known as pivots as well as use different techniques and the chaining together of multiple vulnerabilities that each – individually – appear to be relatively benign.

The attack path provides emphasis on “connecting the dots” and looking at the entire context of an attack and attack paths can include vectors that transition multiple layers of an organisation’s technical stack including identity, compute, network, data, service, and storage layers. The ability of an attacker to pivot from one system to another in a series of hops also means that individual attack vectors may have potentially unanticipated origins. It is perhaps natural to focus on potential threats from attack vectors that originate outside an organisation’s perimeter. However, attack vectors can also originate in assumed-trusted internal hosts if those hosts have been compromised by an earlier attack and are being utilised by an attacker to perform further onward attacks as a continuation of their overall attack path.

An example of how attack vectors and paths can combine might be where an attacker is able to gain access to a system by exploiting a weak password. Once they gain that initial foothold, however, they are then able to harvest credentials that permit them to transition to a second system using the credentials from a compromised trusted administrative user account. Via one or more further steps in their ongoing attack path, they reach their target objective and deliver on their objectives by for example exfiltrating (stealing) confidential data. The attack path is the visual representation of the combination of the multiple exploited attack vectors along this path that led to the eventual exploit, with some originating on trusted internal hosts.

One way of visualizing an attack path (as well as clarifying the distinction between attack paths and attack vectors) is to use a matrix with origins on one axis, and targets on the other axis. Each step of the attack has a different attack vector involving a different origin, destination, attack methodologies and technique. Cumulatively, the attack path is the sum of the chained vectors used in the exploit:


How are attack vectors different to vulnerabilities?


Attack vectors often involve the exploit of a technical security vulnerability on a target system. However, they may also involve the risk posed by something more abstract or less binary and which is impossible to definitively mitigate or eradicate – such as a general susceptibility of humans to social engineering. Additionally, a vulnerability is an atomic construct existing even in the absence of an attacker. It can be objectively determined to exist, and it also exists regardless of whether it can be exploited at a given moment in time. For example, a system with a weak password requirement has a vulnerability, but if it is powered down for maintenance, then the system is not currently exploitable. An attack vector by contrast is somewhat more theoretical and involves both a vulnerability that is susceptible to exploit, as well as an attacker that is suitably positioned and motivated to attempt to exploit it.

Whereas vulnerabilities are passive, static and in situ, attack vectors also typically require some positive action to be taken on the part of attacker. Attack vectors are therefore intentional threats as they require some planning and analysis on the part of the attacker in order to discover potential vulnerabilities and then attempt to exploit them.

Likewise, on the part of a security organisation, enumerating potential attack vectors is relatively complex and demanding. A set of vulnerabilities can be determined relatively robustly via vulnerability scanning. However, understanding the potential attack vectors that could incorporate these involves a degree of human creative thinking, and imagination, such as through a threat modelling process.


What forms can attack vectors take?


Attack vectors can target technical weaknesses, but also vulnerabilities that involve social engineering and phishing to gain passwords, for example. Other common methodologies used within attack vectors include the use of malware and trojans, compromise of client-side scripts within web browsers, or the use of social engineering via phone calls, text messages, or even in person.

A given organisation’s attack surface will generally consist of multiple attack vectors, in many of these forms. In the analogy of a security firm that is tasked with guarding a bank, there may be several ways that a thief could carry out a robbery. These could incorporate different origins (front doors, back doors, elevators, and unsecured windows) as well as different tools or techniques (guns, explosives, or simply posing as a member of the bank’s staff). Each combination of origin, target and technique or method represents a distinct attack vector.

An often-overlooked set of attack vectors are those involving third -party vendors, suppliers, and service providers within an organisation’s supply chain. No matter how robust the security posture of an organisation internally, the inter-connectedness of modern businesses can mean that the compromise of a key supplier can provide an often-unconsidered (and hence unmitigated) attack vector that threatens substantial risk to an organization.


How can attack vectors be useful to attackers?


Attack vectors may be exploited by a variety of threat actors, from a disgruntled former employee that is looking to disrupt your business to an attacker that wishes to access your sensitive data in order to encrypt it in a ransomware attack.

Whatever the exact motivation, an attacker will generally have at least some plans as to how they will conduct their attack, involving a target system and objective. Whether consciously or not, the attacker will build up an “attack plan” of their planned exploit. A successful attacker is going to follow the general methodology of a kill chain in performing their attack, in which reconnaissance of the target (identifying a target system that they wish to penetrate or exploit) is followed by the use of data collection and observation tools such as sniffing, emails, malware or social engineering to obtain more information about the target. An attacker will then use this information to identify the best attack vector or attack vectors by which to conduct their attack. Whether they use the term “attack vector” or not, the process of conducting a successful attack intrinsically incorporates the consideration of one or more attack vectors.


How is knowing attack vectors useful to security teams?


Just as knowledge of available attack vectors is indispensable to attackers, it is also critical to security teams looking to protect an organisation from attack. A major part of any information security programme is closing off attack vectors whenever possible by applying appropriate controls (safeguards and countermeasures) to them. In our bank analogy from above, the security firm may try to eliminate attack vectors that they can envisage by placing security guards at all entrances, ensuring that windows are locked and fitted with security grilles, and regularly screening staff using access cards and biometrics in order to confirm their identity.

However, teams can only defend effectively against that which they can see. Whilst it is relatively simple to determine a list of technical vulnerabilities, effective prioritization for remediation means understanding the risk presented by a given vulnerability. This is partially inherent to the asset in question as the target (the more critical the asset the higher the vulnerability impact). However, effective risk management means understanding the potential attack surface of a given system also, since the more potential attack vectors a system has, the higher the likelihood of an exploit being conducted. This means that visualizing potential attack vectors, and the risk they present to business-critical assets, is one of the best tools that security teams have to protect assets.


How can you discover attack vectors?


Modern organisations and networks are highly complex and inter-connected, which means that the attack surface (and number of potential attack vectors) for a typical organisation have grown exponentially in recent years. This can make it relatively challenging to comprehensively catalogue all potential attack vectors in order to map your overall attack surface.

Threat modelling and attack surface analysis are approaches that attempt to produce a risk-weighted attack surface map, in order to allow a security programme to focus greatest effort on the highest risks that it faces.

Conducting an attack surface analysis in order to create model of the organisation’s attack surface includes producing a list of key assets that represent the prime targets for attackers and understanding both the criticality of each in terms of its data set, as well as its context in terms of the underlying network topology and system connections that provide options for potential attack vectors or paths to the asset, as well as which access control measures are in place. This attack surface analysis can be conducted in a scoping exercise that is performed on a set cycle in order to keep the resulting generated attack surface map up to date.


What best practices can be followed to reduce the number of potential attack vectors?


It is not possible for an organisation to eliminate an its attack surface completely, but efforts can be made to both understand it as well as to minimise it as much as possible without impacting the usability of operated services. There is usability/security trade-off in most operated services in that there exists an inversely proportional relationship between usability and security: data and system access can either be very secure but restrictive or very open yet risky: services must be secure, but they must also be fit for purpose, which means accepting the existence of at least some potential attack vectors. To give a somewhat extreme or absurd example, you could arguably make a web application very secure by air-gapping it (removing its network connection entirely), however it is no use making something so secure if that results in a service that’s unusable to its intended audience.

The following list are some general principles that can be followed by any organisation to attempt to reduce their attack surface in order to minimise the risks posed to their organisation


Map your attack surface


Effective vulnerability management can only be performed if the risks to each asset are fully understood. As we saw above, simply enumerating attack vectors for critical systems can be key in prioritization of vulnerability remediation, by focusing on key systems with open attack surfaces.

In order to effectively drive prioritization, it is necessary to initially map an entire estate along with all critical assets and understand their context. By assessing the interconnectedness of systems and the relationships between key assets, it is possible to produce a simple visualization in the form of a graph. The topological graph produced by this attack path analysis can then be used to provide an intuitive and comprehensive visualization of an environment. This can be used to identify likely attack vectors, in a threat modelling process, indicating how attackers could potentially gain unauthorized access to assets, and highlighting vectors that need to be screened against as a priority.

Since it is possible to group or class by threat actors and targets, these maps or graphs do not have to be unnecessarily complex, and can provide a highly intuitive visibility into potential attack vectors:


Eliminate Complexity


One of the benefits of modelling your organisational attack surface as part of a threat modelling exercise is that it can help to highlight any unnecessary complexity that is either present or which might be introduced via proposed changes to the environment. Unnecessary complexity can creep into networks over time via a process of sprawl: disconnected management decisions taken by different individuals over time, a lack of visibility as to current state when making forward- effecting decisions, and the tendency for changes to only be additive (e.g., adding new firewall rules but never removing or re-evaluating old ones) can lead to a gradual, creeping increase in complexity.

Complexity can be harmful in that it can lead to redundant or counteracting rules or processes, access permissions that are stale and no longer required to meet business requirements yet are still active. A complex system or environment may also lead to a greater possibility of human error and risk that leads to outage, as well as to a paralysis or fear of change due to lack of understanding of a system, which can mean that teams are no longer confident in applying security patches to a system, too afraid that they do not understand the system well enough to restore service in the event that the pathing fails. Eliminating or reducing this complexity can be highly beneficial in reducing the size of the attack surface.


Apply Defense in Depth


Defense in depth is a principle that involves the deployment of multiple layers of defense in any given attack path, rather than relying on a single hardened perimeter or single control to prevent all attacks. Just as there are multiple attack vectors, there should be multiple layers of security and protection. Specifically, it may not be appropriate to focus all security controls against the threat of attack vectors that originate outside an organisation. If your threat map or attack surface graph illustrates that there is a threat from an attack vector against a database system from internal systems, then controls may need to be focused on the thwarting of attacks that originate inside your network, for example.

Defense In Depth can apply in a topographical sense in terms of providing multiple redundant security controls in a given attack vector path, but it can also mean ensuring that security measures are broad in nature and incorporate al broad range of control types in order to maximise protection. Not every control type will be suitable to mitigate a given threat, but in many cases several different control types can (and under defense in depth should) be employed:


Implement Zero Trust Architecture


Zero Trust or zero-trust is a strategic approach to cybersecurity that secures an organisation by eliminating implicit trust (known as “allow-all”), replacing it with a “deny-all” default access set. Individual access permissions are then established and continuously validated at every stage of a digital interaction. Zero Trust was created based on the realization that traditional security models operate on the outdated assumption that everything inside an organization’s network should be implicitly trusted. This implicit trust means that once on the network, users – including threat actors and malicious insiders – are free to move laterally and access or exfiltrate sensitive data due to a lack of granular security controls.

In a zero-trust architecture, the exact tools and techniques used may vary but the general approach is to assume a baseline of zero trust for any subject to access any given system object, and then to only add explicit individual trust relationships as needed. Critically, zero trust as a concept can be applied via policies implemented at multiple layers, applying baselines of zero access to users, to applications, and even to infrastructure elements such as routers and switches by default.

Zero Trust is not trivial to impose on an existing infrastructure but can be used to guide configuration of new elements and systems even in “brownfield” technical estates.


Apply Strong Access Control


Many attack vectors rely on the use of compromised credentials or accounts in order to perform attacks. The compromise of one system or service can be more easily chained into a further attack if the compromised account or service is executing with higher privileges than are required, and the compromised account has access to perform further malicious actions.

The use of strong Role-Based Access Control (RBAC) for users can be paired with a capability-based security model for operating system and application services that together operate on a model of least privilege. Most operating systems to not provide true capability-based security since they lack the underlying data structures and access models to secure such transactions robustly. However, a reasonable approximation can be applied by restricting the access rights belonging to each service by having it execute as a unique and non-privileged account with sufficient permissions required to operate the service in question and no more.


Upgrade Authentication Systems


An attack path that leads to a successful exploit very commonly involves at one stage or another the use of an account that has been compromised via leaked, guessed, intercepted or brute-forced credentials. The use of strong authentication that relies on multiple factors at a minimum can go some distance to mitigating this threat. Multi-factor authentication ensures that a user is granted access to a target service only after successfully presenting two or more pieces of evidence (or factors) to an authentication mechanism: knowledge (something only the user knows), possession (something only the user has), and inherence (something only the user is).

No authentication system can be totally attack-proof, but multi-factor authentication can provide a significant additional hurdle and mean that compromised credentials may not immediately be utilised by an attack in a forward pivot attack to another system or service.


Introduce Network Segmentation


Network security historically has focused primarily on a perimeter model in which network controls are deployed primarily at the periphery of a network at the boundary between the public network (internet) and the organisation’s screened private (internal) network.

However, networks are increasingly porous, and the use of data feeds, APIs, VPN tunnels, wireless access points and BYOD (bring your own) devices can mean that threats can just as likely originate from somewhere within the internal network estate. In recognition of this new reality, recent paradigms focus more on the provision of strong network segmentation. This approach involves partitioning a network into multiple zones of trust, each of which contains assets (objects) that exist at different levels of system or service criticality and data sensitivity, as well as subjects at different levels of trust. The use of strong network controls between each network segment is used to provide lateral access restriction and restrict lateral movement: there is no “blanket access” for an individual situated on the internal network to all services and systems. One basic form of this model is to separate web application layers from one another in line with what is known as a three-tier architecture (shown below), but the same principles can be applied to corporate (campus) networks. Likewise, network segmentation can be applied in a more granular fashion to separate data layers into multiple, discrete trust zones with the partitioning determined based upon differing data sensitivities of the individual systems.

Implementing network segmentation can help to reduce an organisation’s overall attack surface by increasing the number of barriers that an attacker would encounter and need to overcome when attempting to traverse through a network in chaining together multiple attack vectors. In a more advanced form, network segmentation can be expanded upon using micro segmentation, wherein security controls are applied at increasingly granular levels to individual systems, hosts, partition, workloads or even applications.


How can AppCheck Help?


AppCheck can help you with providing assurance in your entire organisation’s security footprint, by detecting vulnerabilities and enabling organizations to remediate them before attackers are able to exploit them. AppCheck performs comprehensive checks for a massive range of web application and infrastructure vulnerabilities – including missing security patches, exposed network services and default or insecure authentication in place in infrastructure devices.

External vulnerability scanning secures the perimeter of your network from external threats, such as cyber criminals seeking to exploit or disrupt your internet facing infrastructure. Our state-of-the-art external vulnerability scanner can assist in strengthening and bolstering your external networks, which are most-prone to attack due to their ease of access.

The AppCheck Vulnerability Analysis Engine provides detailed rationale behind each finding including a custom narrative to explain the detection methodology, verbose technical detail, and proof of concept evidence through safe exploitation.


About AppCheck


AppCheck is a software security vendor based in the UK, offering a leading security scanning platform that automates the discovery of security flaws within organisations websites, applications, network, and cloud infrastructure. AppCheck are authorized by the Common Vulnerabilities and Exposures (CVE) Program as a CVE Numbering Authority (CNA)


Additional Information


As always, if you require any more information on this topic or want to see what unexpected vulnerabilities AppCheck can pick up in your website and applications then please get in contact with us: info@appcheck-ng.com


Get started with Appcheck

No software to download or install.

Contact us or call us 0113 887 8380

Start your free trial

Your details
IP Addresses

Get in touch

Please enable JavaScript in your browser to complete this form.