M01-04 · Attack surface and attack vector

CEH M01-04 | Attack Surface and Attack Vector

Module 01: Introduction to Ethical Hacking

Lesson objective: understand where hackers might contact a system, which methods they might use to attack it, and how security practitioners identify what needs protection.

Editorial supplement: The bank, school and Northstar scenarios are synthetic teaching examples. Example URLs are not testing instructions; no real third-party system is tested.

Suggested study time: 10–15 minutes.

1. Grasp the key distinction first: attack surface means “where”; attack vector means “how”

Imagine that you are a bank's head of cybersecurity.

The bank has an entrance, ATMs, an automated customer-service telephone line, online banking and internal employee systems.

One day, your boss asks:

“Where could our bank be attacked?”

You cannot simply answer, “We have a firewall, so we are secure.”

An attacker does not necessarily have to defeat the firewall.

They might impersonate customer-service staff to obtain customers' credentials, exploit a software vulnerability in online banking, or even reach internal systems through an employee's computer.

We therefore need to separate two questions:

Question A: which places could be attacked?

This is the attack surface.

Question B: which methods might an attacker use?

These are attack vectors.

NIST defines the attack surface as the collection of points on a system boundary where an attacker might try to enter, cause an effect or obtain data. The UK's NCSC explains an attack vector in terms of a method for gaining unauthorized access. NIST Computer Security Resource Center

Source supplement: The attack-vector definition is also supported by the NCSC glossary; this adds the corresponding link to the two-source statement.

Four easily confused terms

Importantly, an attack vector does not necessarily require a software vulnerability.

For example, an attacker who deceives an employee through social engineering may exploit weaknesses in human judgment or operational processes rather than a software flaw.

Also, “exploit” sometimes refers to a tool or program used to exploit a vulnerability, rather than only the act of exploitation.

Remember this important relationship:

Having an attack surface does not mean a vulnerability exists; having a vulnerability does not mean an attack has succeeded.

2. Attack surface: why can normal functions also be part of it?

Suppose you operate an online learning platform.

Students can log in, watch courses, upload assignments and download grades.

To let students use these features, the website must interact with the outside world.

Those points of interaction form the attack surface we need to analyze.

1. Websites and APIs

For example:

https://school.example/login

This is a login interface.

Users can enter their usernames and passwords through it.

But consider this:

If users can submit login data, could attackers also submit data through the same interface?

Yes, they could.

This does not mean the login interface is vulnerable. It means that the interface is a point of contact requiring security protection.

Next, consider an API: Application Programming Interface.

An API can be understood as:

A communication interface that lets different software make requests and exchange information in an agreed way.

For example:

Student uses a mobile app
          |
          v
App requests grades from the school API
          |
          v
School server
          |
          v
Check student identity and data permissions
          |
          v
Return the grades the student may view

This API is also part of the attack surface.

Someone might use it to make a request that should not be permitted.

2. Networks and devices

Besides websites, other company equipment can also form part of the attack surface.

Examples include remote administration services used by administrators, employee laptops and internal company file servers.

Even if a service is not publicly exposed, that does not mean it has no attack surface.

The reason is straightforward:

An attacker might first obtain an ordinary employee account or control an internal device, then try to reach other systems.

This introduces two concepts:

External Attack Surface: parts of a system that could be contacted from external environments such as the internet.

Internal Attack Surface: parts of a system that can be contacted only with internal network connectivity, a particular identity or other prerequisites.

OWASP emphasizes that attack surface analysis should not examine only a website's homepage. It should also include data entry and exit paths, APIs, administration functions and different users' permissions. OWASP Cheat Sheet Series

3. People and operational processes

Beginners often overlook this area.

Suppose customer service can help users reset their passwords.

Someone who impersonates a user and asks customer service to reset an account might cause a security problem through that process.

Security therefore cannot focus only on computer programs.

People, physical equipment and operational procedures can also form part of the overall attack surface.

An important point: a larger attack surface does not necessarily mean higher risk

Suppose there are two companies.

Company A has 20 public webpages, but all are static information pages without login functionality.

Company B has only three external-facing features, one of which can access all customers' personal information.

Which company faces greater danger?

We cannot decide solely by counting entry points.

We also need to analyze access conditions, weaknesses, protective controls and the damage that exploitation could cause.

This is another reason why the risk concepts from M01-02 matter.

3. Attack vector: how might the attacker act?

We now know that an online banking login page is part of the attack surface.

The next question is:

“How might an attacker use this point of contact?”

We can analyze several possible attack vectors.

These attack vectors are not mutually exclusive.

For example, phishing is itself a form of social engineering.

A real attack may also combine several methods.

Why is knowing the attack's name not enough?

Suppose someone says:

“This bank could be attacked through phishing.”

That is a reasonable statement, but it does not provide enough information.

Security practitioners must further establish the conditions needed for the attack to work.

For example, could an employee receive a malicious email? If it arrives, does the employee actually click? Even if credentials are entered, are there additional authentication mechanisms?

Therefore, an attack vector describes a possible method of attack. It does not mean that the attack has occurred, much less that it has succeeded.

4. Trust boundary: why does successful login still not allow access to all data?

Next is a concept that is especially important in software security.

Trust boundary.

Think of it as:

A boundary between different levels of trust or permission scopes where security checks must be performed again.

Suppose there is a school grade system.

Student A has successfully logged in.

However, Student A wants to view Student B's grades.

What should the system do?

The answer is:

It must not let Student A view Student B's data merely because Student A is logged in.

This involves two essential security terms.

They are different.

Terminology supplement: Here, authorization means the system deciding access to data or operations. In M01-03, security-testing authorization means an appropriate party approving testing activities. Both concern permission, but at different levels.

Successful authentication establishes the user's identity.

The system must then still check whether that identity has permission for the particular operation and data access.

Understand through a flow diagram

Student A logs in
       |
       v
System verifies identity
       |
       v
Authentication succeeds
       |
       v
Student A requests a grade-report download
       |
       v
Authorization check
       |
       +-- Authorized to download --> Provide the report
       |
       +-- Not authorized ---------> Reject the request

If the system performs authentication but fails to perform authorization correctly, unauthorized access may result.

OWASP recommends deny by default, least privilege and appropriate permission checks on every access request, rather than relying only on the fact that a user is logged in. OWASP Cheat Sheet Series

A common programming mistake is also relevant here:

Hiding an administrator button does not mean ordinary users have been prevented from performing administrative functions.

Hiding a button changes only what the user sees.

The actual security checks must still be performed by a trusted system component.

5. Complete example: how do we apply these concepts?

Suppose there is a fictional platform called Northstar.

The platform provides personal learning-report downloads.

Its rule is that each student may download only their own report.

We are legally authorized security testers assessing this feature.

Step 1: Asset Identification

First ask:

“What are we protecting?”

The answer is students' private learning reports.

They involve students' personal information, so their confidentiality must be maintained.

Step 2: Attack Surface Identification

Next ask:

“Where do users interact with the reports?”

The answer is the report download feature and the backend API handling download requests.

These are points of contact that need assessment.

Step 3: Attack Vector Analysis

We propose a hypothesis:

If Student A tries to obtain Student B's report through the download feature, might the system incorrectly provide the data?

Notice that we are only proposing a possible attack method at this stage.

We do not yet know whether the system has a vulnerability.

Step 4: Authorized Testing

In an explicitly authorized test environment, we create two test accounts.

We test using synthetic data containing no real people's information.

Suppose the second test reveals that:

Student A actually obtains Student B's report.

We then have evidence indicating that:

This feature has an improper authorization issue under the specific test conditions.

This type of issue involves Broken Access Control and may also be classified as IDOR (Insecure Direct Object Reference) or BOLA (Broken Object Level Authorization).

For now, recognize these advanced terms; there is no need to study them in depth yet.

Step 5: Mitigation

The improvement is not to hide the download button.

Instead, when the server receives a download request, it must verify that the current user is genuinely authorized to access the specified report.

Run the tests again after applying the fix.

Besides confirming that Student A cannot obtain Student B's report, confirm that Student A can still download their own report normally.

This establishes that the protective control has not unnecessarily disrupted the legitimate service.

Step 6: Evidence

Suppose we successfully reproduce Student A obtaining Student B's report without authorization.

What does this mean?

We can reasonably conclude that an access-control weakness exists under the test conditions.

However, we cannot immediately claim:

“All student data has already leaked.”

Finding a vulnerability and proving that someone exploited it in the past are two different things.

A formal assessment must also establish the actual scope of impact and examine relevant incident records.

6. Organize the whole lesson using one framework

Now connect M01-01 through M01-04.

             Asset
      What are we protecting?
                 |
                 v
          Attack Surface
     What could be contacted?
                 |
                 v
          Attack Vector
     What might an attacker do?
                 |
                 v
          Vulnerability
 Is there an exploitable weakness?
                 |
                 v
        Security Controls
 Can existing protections block it?
                 |
                 v
         Risk Assessment
  How likely is it, and how severe
          is the impact?
                 |
                 v
            Mitigation
 How can risk be reduced or controlled?
                 |
                 v
           Verification
 Does protection work without
       disrupting service?

This is an analysis workflow designed to support learning, not a claim that every attack follows a fixed sequence. In practice, hypotheses and assessments usually need repeated revision.

Trust boundaries are important checkpoints within this workflow.

Pay particular attention to whether appropriate checks exist when data or operation requests move from one trust domain into another.

OWASP threat modeling also emphasizes using data flows, system components and trust boundaries to identify possible attack points. OWASP Cheat Sheet Series

The five concepts most worth mastering for the CEH exam and practical work

This teaching priority is based on conceptual importance and subsequent learning needs. It is not an official allocation of exam marks.

7. After-lesson check: try answering

A company's employee inboxes can receive mail normally.

One day, an employee receives an email impersonating the IT department.

The email says:

“Your company account is about to be disabled. Click the link below immediately to verify your password again.”

The link takes the user to a fake company login website.

Currently, we know only that the email was delivered successfully.

There is no evidence that the employee clicked the link, entered credentials or had their account accessed by someone else.

Answer three questions:

Q1. Which parts of this case can be considered attack surface?

Q2. What attack vector might the attacker be using?

Q3. Based on the current evidence, can we conclude that the employee's account has been compromised? Why?

You do not need to recite English definitions. Simply distinguish the concepts clearly in your own words.

After you answer, I will assess each response using the CEH concepts, identify what is correct and explain what needs reinforcement.

The most important memory aid: attack surface asks “where”; attack vector asks “how”; vulnerability asks “where protection is inadequate”; finally, use evidence to determine whether something actually happened.

Reveal reference answer: Q1: What is the attack surface?

Relevant contact points include corporate email reception, the employee processes for reading and verifying notifications, and subsequent login interfaces. External messages reaching people or systems does not prove that the mailbox itself contains a vulnerability.

Reveal reference answer: Q2: What is the attack vector?

The possible route is phishing: impersonating IT and directing the employee to a fake login site to disclose credentials. This is also social engineering. Attempting this method does not establish that later steps succeeded.

Reveal reference answer: Q3: Can account compromise be concluded?

Not yet. Only delivery is established; there is no evidence here of clicking, submitting credentials, another party successfully signing in or improper access. Report the observed phishing attempt, not confirmed account compromise.

Even if a password was disclosed, other authentication or access controls may still block use. Missing records do not guarantee that no incident occurred; assess logging completeness and the investigation scope.

Reference answers support self-checking; publishing them does not establish a learner response or understanding. This is a revision of the same concept, not another lesson delivery.