01 — Ethical Hacking Foundations

Ethical hacking begins long before exploitation.

A professional Ethical Hacker must understand:

• Why the assessment is being performed
• What is authorised
• Which systems are in scope
• How the target environment works
• What evidence is required
• How weaknesses should be validated
• When testing should stop
• How technical results should be communicated

This module establishes the foundation for every later area of the Ethical Hacker learning path.

You will repeatedly use the same core methodology when working with:

• Networks
• Web applications
• Active Directory
• Wireless environments
• Mobile applications
• Cloud platforms
• Red team engagements

Module Mission

Your mission is to develop a repeatable ethical hacking methodology.

The core workflow is:

Authorisation
      ↓
Scoping
      ↓
Reconnaissance
      ↓
Enumeration
      ↓
Vulnerability Analysis
      ↓
Controlled Validation
      ↓
Privilege / Attack Path Analysis
      ↓
Evidence Collection
      ↓
Risk Analysis
      ↓
Reporting
      ↓
Remediation Guidance

The objective is not to randomly attack systems.

The objective is to answer:

What can an attacker realistically reach, exploit, combine, and impact within the authorised environment?

1. Ethical Hacking as a Professional Discipline

Ethical hacking uses offensive security techniques to identify weaknesses before malicious attackers exploit them.

A professional engagement combines:

Technical Testing
      +
Authorisation
      +
Methodology
      +
Risk Analysis
      +
Evidence
      +
Reporting

Without these additional elements, technical exploitation alone is not professional penetration testing.

2. Understand the Objective

Every engagement should begin with a clear objective.

Examples:

Identify vulnerabilities in an externally accessible network.

Assess the security of a customer-facing web application.

Determine whether a compromised workstation could lead to domain compromise.

Evaluate whether cloud identities can be abused to gain privileged access.

The objective determines the methodology.

3. Different Offensive Security Engagements

Ethical hackers may participate in different assessment types.

Vulnerability Assessment

Primarily identifies and validates security weaknesses.

Discover
   ↓
Scan
   ↓
Validate
   ↓
Prioritise

Penetration Test

Attempts to determine whether weaknesses can be exploited and chained.

Discover
   ↓
Enumerate
   ↓
Exploit
   ↓
Escalate
   ↓
Demonstrate Impact

Red Team Engagement

Simulates realistic adversary behaviour against defined objectives.

Objective
   ↓
Initial Access
   ↓
Persistence
   ↓
Privilege Escalation
   ↓
Lateral Movement
   ↓
Target Objective

Security Assessment

May include technical testing plus:

• Architecture

• Configuration

• Policies

• Controls

• Risk

Understand which engagement you are performing.

4. Authorisation

The most important requirement is explicit permission.

Authorisation should define:

• Who owns the systems

• Who authorises the testing

• Which environments may be tested

• Which techniques are permitted

• When testing may occur

Never assume permission.

5. Scope

Scope defines the boundaries of the assessment.

It may include:

IP Addresses

CIDR Ranges

Domains

Subdomains

Applications

APIs

Cloud Accounts

Wireless Networks

Mobile Applications

It may also define exclusions.

6. Example Scope

In Scope

10.20.30.0/24
portal.lab.local
api.lab.local

Out of Scope

10.20.40.0/24
Third-Party SaaS
Production Payment Gateway

Prohibited

Denial-of-Service
Destructive Testing
Unapproved Social Engineering

Read scope carefully before testing.

7. Rules of Engagement

Rules of Engagement define how the assessment will operate.

Typical areas include:

Testing Window

Source IP Addresses

Allowed Techniques

Prohibited Techniques

Credentials Provided

Emergency Contacts

Incident Escalation

Data Handling

Cleanup Requirements

These rules protect both the tester and the organisation.

8. Stop Conditions

You should know when testing must stop.

Examples:

• Production instability

• Unexpected outage

• Sensitive data exposure

• Out-of-scope access

• Third-party infrastructure

• Critical safety systems

• Client request

A stop condition should trigger communication rather than continued experimentation.

9. Penetration Testing Lifecycle

A practical lifecycle is:

Planning
   ↓
Reconnaissance
   ↓
Scanning
   ↓
Enumeration
   ↓
Vulnerability Analysis
   ↓
Exploitation
   ↓
Post-Exploitation
   ↓
Privilege Escalation
   ↓
Lateral Movement
   ↓
Impact Analysis
   ↓
Reporting

Real engagements are iterative.

You may repeatedly move between discovery, analysis, and validation.

10. Phase 1 — Planning

Planning establishes:

• Objective

• Scope

• Methodology

• Tools

• Testing window

• Contacts

• Deliverables

Ask:

What question is the assessment trying to answer?

Without this, testing can become unfocused.

11. Phase 2 — Reconnaissance

Reconnaissance gathers information about the target.

Think:

Organisation
    ↓
Domains
    ↓
Infrastructure
    ↓
Applications
    ↓
Technologies

Reconnaissance helps build the initial attack surface.

12. Passive Reconnaissance

Passive reconnaissance uses publicly available information where permitted.

Potential sources include:

• DNS data

• Certificate transparency

• Search engines

• Public repositories

• Public documentation

• Technology information

The goal is information gathering without directly probing target systems.

13. Active Reconnaissance

Active reconnaissance interacts with authorised targets.

Examples:

• Host discovery

• Port scanning

• Service detection

• HTTP probing

• DNS enumeration

This produces more direct evidence of the target environment.

14. Attack Surface Discovery

Your first major technical objective is often:

What can an attacker reach?

Create an attack surface map.

External Attack Surface
│
├── Domain
│   ├── www
│   ├── api
│   └── vpn
│
├── Public IPs
│
├── Cloud Services
│
└── Remote Access

An accurate attack surface reduces blind spots.

15. DNS Fundamentals

DNS often reveals useful infrastructure information.

Understand records such as:

A
AAAA
CNAME
MX
NS
TXT

Example:

portal.example.com
        ↓
A Record
        ↓
203.0.113.10

DNS relationships can reveal externally accessible infrastructure.

16. Domain and Subdomain Discovery

Organisations may expose services through multiple subdomains.

Examples:

www.example.com

api.example.com

vpn.example.com

dev.example.com

admin.example.com

Each may represent a different attack surface.

Do not assume the main website represents the complete environment.

17. Host Discovery

Once authorised address ranges are known, determine which systems respond.

Conceptually:

Network Range
     ↓
Host Discovery
     ↓
Live Hosts

The result becomes input for deeper enumeration.

18. Port Scanning

Ports reveal accessible network services.

Example:

Target
│
├── 22  SSH
├── 80  HTTP
├── 443 HTTPS
└── 445 SMB

A port is not automatically a vulnerability.

It tells you what to investigate next.

19. Understand TCP

A basic understanding of TCP is essential.

Simplified connection:

Client
  │
  │ SYN
  ↓
Server
  │
  │ SYN/ACK
  ↓
Client
  │
  │ ACK
  ↓
Connection

Understanding protocols makes scan results more meaningful.

20. TCP vs UDP

TCP

Connection-oriented.

Common examples:

• HTTP

• HTTPS

• SSH

• SMB

UDP

Connectionless.

Common examples:

• DNS

• SNMP

• NTP

UDP scanning often requires different interpretation because there is no TCP-style connection handshake.

21. Service Enumeration

Once an open port is found, determine the actual service.

Example:

Port 22
   ↓
SSH
   ↓
OpenSSH
   ↓
Version
   ↓
Configuration

The deeper you understand the service, the better you can evaluate its security.

22. Banner Grabbing

Services sometimes reveal information such as:

• Product

• Version

• Hostname

• Operating system

• Configuration

Treat banners as clues.

Validate important conclusions using multiple techniques where possible.

23. Technology Fingerprinting

Identify technologies such as:

Operating System

Web Server

Framework

CMS

Database

Application Platform

Cloud Provider

Fingerprinting helps direct later testing.

24. Enumeration Is More Important Than Random Exploitation

A common beginner pattern is:

Scan
  ↓
Find Port
  ↓
Search Exploit

A stronger pattern is:

Discover
   ↓
Enumerate Thoroughly
   ↓
Understand Service
   ↓
Identify Weakness
   ↓
Develop Hypothesis
   ↓
Validate

Good enumeration often reveals the real attack path.

25. Common Enumeration Targets

Depending on scope, you may enumerate:

Web

SMB

SSH

FTP

DNS

LDAP

Kerberos

SNMP

Databases

Cloud Services

Each service has its own security model.

26. Web Enumeration

For web services determine:

• Hostname

• Application

• Framework

• Authentication

• Paths

• APIs

• Technologies

• Headers

Example:

HTTPS
  ↓
Web Application
  ↓
Authentication Portal
  ↓
API

You will investigate web applications deeply in Module 03.

27. SMB Enumeration

SMB environments may expose:

• Shares

• Hosts

• Users

• Domain information

• Access permissions

In enterprise environments, SMB often connects closely with Active Directory.

28. DNS Enumeration

DNS analysis may reveal:

• Internal naming patterns

• Mail infrastructure

• Name servers

• Public services

• Cloud services

DNS is both a network service and a valuable reconnaissance source.

29. SNMP Enumeration

Poorly secured SNMP deployments can expose:

• Device information

• Interfaces

• Routes

• System names

• Configuration details

Again, use only authorised environments.

30. Vulnerability Analysis

After enumeration, identify potential weaknesses.

Sources may include:

Configuration Review

Version Research

Vulnerability Databases

Security Advisories

Automated Scanners

Manual Testing

The objective is to develop candidates for validation.

31. Vulnerability Scanner Limitations

Automated scanners can produce:

False Positives

False Negatives

Incorrect Versions

Duplicate Findings

Context-Free Severity

Therefore:

Scanner Result
     ↓
Manual Validation
     ↓
Environment Context
     ↓
Final Finding

32. Vulnerability Research

When researching a potential vulnerability, determine:

• Affected product

• Affected versions

• Required configuration

• Exploitation prerequisites

• Authentication requirements

• Impact

• Available patches

Do not assume every public exploit applies to the target.

33. CVE

CVE provides standardized identifiers for publicly disclosed vulnerabilities.

Example format:

CVE-YYYY-NNNNN

A CVE identifies a vulnerability.

It does not tell you the complete business risk of the target environment.

34. CVSS

CVSS provides a standardized technical severity score.

It can help answer:

How severe is this vulnerability technically?

It does not fully answer:

How important is it to this organisation?

Business risk requires context.

35. Exploitability

Evaluate:

Reachability

Authentication

Privileges Required

User Interaction

Complexity

Available Exploit

Existing Controls

A technically severe vulnerability may have low practical exploitability in a specific environment.

36. Exposure

Compare:

Internet-Facing Vulnerability

with:

Vulnerability on Isolated Lab Server

The weakness may be identical.

The risk may be completely different.

37. Form an Exploitation Hypothesis

Before attempting exploitation, state what you expect.

Example:

The service version may be vulnerable to an authentication bypass that could allow unauthorised administrative access.

Then:

Hypothesis
   ↓
Controlled Test
   ↓
Evidence
   ↓
Confirmed / Rejected

This produces disciplined testing.

38. Controlled Exploitation

The purpose of exploitation is to validate risk.

Use the smallest amount of exploitation necessary to prove the issue.

Example:

Vulnerability
   ↓
Controlled Validation
   ↓
Proof of Access
   ↓
Stop

Do not cause unnecessary impact.

39. Proof of Concept

A proof of concept should demonstrate the weakness safely.

Evidence might show:

• Unauthorized access

• Ability to execute a benign command

• Access to a non-sensitive test record

• Successful privilege boundary bypass

Avoid destructive proof where a safer method exists.

40. Exploit Reliability

Do not blindly execute exploit code.

Consider:

• Source

• Code behavior

• Target compatibility

• Stability

• Potential side effects

A public exploit may:

• Crash services

• Modify systems

• Create accounts

• Install payloads

Understand what it does first.

41. Exploit Development Is Not Always Required

Professional penetration testing often involves validating known vulnerability classes.

You do not need to develop custom exploits for every assessment.

The goal is security assurance, not demonstrating exploit development capability unless the engagement specifically requires it.

42. Initial Access

Successful exploitation may provide:

Application Access

User Account

Shell

API Token

Cloud Credential

Service Account

The next question becomes:

What does this access allow?

43. Post-Exploitation

After gaining access, carefully determine:

• Current identity

• Privileges

• Host information

• Network context

• Accessible resources

• Potential credentials

• Trust relationships

Remain within scope.

44. Current Identity

One of the first questions after gaining access should be:

Who am I?

Conceptually:

Access
   ↓
Identity
   ↓
Privilege
   ↓
Capability

The compromised identity determines much of the available attack path.

45. Privilege Escalation

Privilege escalation attempts to move from limited access to greater permissions.

User
 ↓
Local Administrator
 ↓
System / Root

Potential causes include:

• Weak file permissions

• Misconfigured services

• Vulnerable software

• Credential exposure

• Excessive sudo rights

46. Horizontal vs Vertical Privilege Escalation

Vertical

Moving to a more privileged role.

User
 ↓
Administrator

Horizontal

Accessing another account at the same privilege level.

User A
 ↓
User B

Both can create significant security risk.

47. Credential Access

Credentials can become one of the most valuable attack paths.

Examples:

Passwords

API Keys

Tokens

SSH Keys

Cloud Credentials

Service Account Credentials

If encountered, protect them as sensitive evidence.

48. Password Security Testing

Password assessments may evaluate:

• Weak passwords

• Default passwords

• Password reuse

• Exposed hashes

• Weak password policies

Password auditing must remain within authorised scope.

49. Password Hashes

Passwords should ideally be stored using secure password-hashing mechanisms rather than plaintext.

A hash may conceptually look like:

Password
   ↓
Hash Function
   ↓
Hash Value

Testing may determine whether weak passwords can be recovered from authorised hash sets.

50. Credential Reuse

Credential reuse can create attack paths.

Compromised Account
       ↓
Same Credential
       ↓
Another Service
       ↓
Higher Privilege

This is one reason attackers value credential discovery.

51. Lateral Movement

Lateral movement occurs when access to one system enables movement to another.

Example:

Workstation
    ↓
Credential
    ↓
Server
    ↓
Administrative Credential
    ↓
Critical Server

Enterprise compromises frequently involve chains like this.

52. Pivoting

A compromised system may provide network access to otherwise unreachable systems.

Conceptually:

Attacker
   ↓
Compromised Host
   ↓
Internal Network
   ↓
Internal Target

Pivoting must only be performed when explicitly permitted.

53. Attack Chaining

Individual weaknesses may combine.

Example:

Weak Web Application
       ↓
Shell
       ↓
Configuration File
       ↓
Database Credential
       ↓
Database
       ↓
Sensitive Data

The complete chain explains the real security impact.

54. Attack Graph Thinking

Think of systems and permissions as relationships.

User
 ├──→ Web Application
 │
 └──→ VPN

Web Application
 └──→ Database

Database Credential
 └──→ Internal Server

Ask:

Which path leads to the most important asset?

This approach becomes extremely valuable in Active Directory and cloud environments.

55. Identify Critical Assets

Examples:

Domain Controllers

Production Databases

Cloud Control Plane

Customer Data

Payment Systems

Source Code

Backup Infrastructure

Attack paths matter because of what they eventually reach.

56. Demonstrate Impact Safely

Suppose you obtain database administrative access.

You may not need to download customer records.

A safer proof might demonstrate:

• Authentication succeeded

• Database role

• Database names

• Access permissions

Collect only enough evidence to prove the risk.

57. Data Handling

Treat assessment data as sensitive.

Examples include:

• Credentials

• Screenshots

• Vulnerability output

• Architecture

• Personal data

• Source code

Use the engagement’s approved storage and handling process.

58. Maintain Testing Notes

A useful structure:

Timestamp

Target

Action

Observation

Result

Evidence Reference

Next Step

Example:

10:32
Target: 10.20.30.15
Action: Service enumeration
Observation: HTTPS application present
Evidence: EV-004
Next: Enumerate application paths

59. Evidence IDs

Use consistent evidence references.

Example:

EV-001
EV-002
EV-003

Then findings can reference specific evidence.

60. Evidence Should Support the Finding

Example:

Finding
   ↓
Evidence
   ↓
Technical Conclusion

Avoid findings based only on assumptions.

61. Screenshots

Screenshots should capture the relevant proof.

Avoid screenshots filled with unrelated information.

Where possible:

• Highlight the important area

• Protect credentials

• Remove unrelated sensitive information

• Add context in the report

62. Command Output

Command output may provide stronger evidence than screenshots alone.

Record:

Command

Relevant Output

Target

Timestamp

This improves reproducibility.

63. Maintain a Finding Register

Example:

ID	Finding	Asset	Severity	Evidence
PT-001	Weak Authentication	VPN	High	EV-012
PT-002	Excessive SMB Access	Server01	Medium	EV-018

The finding register becomes your reporting source.

64. Write Factual Observations

Weak:

The server is insecure.

Strong:

The server permits anonymous access to the FTP service and exposes files containing internal configuration information.

Be specific.

65. Separate Observation and Risk

Observation:

Administrative interface is accessible from the internet.

Risk:

An externally accessible administrative interface increases exposure to credential attacks and exploitation of administrative functionality.

Keeping these separate improves clarity.

66. Develop an Attack Scenario

Example:

Internet
   ↓
Administrative Portal
   ↓
Weak Authentication
   ↓
Administrator Access
   ↓
Production Configuration

Attack scenarios help explain why findings matter.

67. Explain Business Impact

Technical impact might be:

Remote command execution.

Business impact might include:

• Service disruption

• Data exposure

• Fraud

• System compromise

• Operational interruption

Use realistic impact.

68. Finding Structure

A professional finding may contain:

Finding ID

Title

Severity

Affected Assets

Observation

Evidence

Attack Scenario

Impact

Recommendation

Optional:

• References

• CVE

• CVSS

• Framework mapping

69. Example Finding

PT-001 — Administrative Interface Exposed to the Internet

Observation

The assessment identified an administrative management interface accessible from the public internet.

Evidence

The service was accessible on the authorised target address and presented an administrator authentication portal.

Risk

Internet exposure increases the likelihood that the interface could be targeted through credential attacks or future vulnerabilities.

Recommendation

Restrict management access to authorised administrative networks or secure remote-access infrastructure and enforce strong authentication controls.

70. Avoid Severity Inflation

Not every successful exploit is Critical.

Determine severity using:

Likelihood
   ×
Impact

Consider:

• Exposure

• Authentication

• Privilege

• Criticality

• Existing controls

• Blast radius

71. Positive Observations

Professional reports may also recognise strong controls.

Examples:

• MFA enforced

• Network segmentation effective

• Sensitive data encrypted

• Strong patch management

Positive observations help provide a balanced assessment.

72. Root Cause

A good recommendation should address why the issue exists.

Example:

Finding:

Multiple internet-facing management interfaces.

Possible root cause:

No enterprise standard restricting management-plane exposure.

Strategic recommendation:

Establish and enforce a management-access security baseline.

73. Remediation Guidance

Recommendations should be:

Specific

Practical

Risk-Based

Proportionate

Weak:

Improve security.

Strong:

Restrict SSH access to the approved management network, require key-based authentication, disable direct root login, and monitor administrative authentication events.

74. Immediate vs Strategic Remediation

Some findings need multiple layers.

Example:

Immediate

Disable exposed administrative interface.

Short Term

Restrict administrative access.

Strategic

Establish enterprise management-plane standards and automated enforcement.

This helps clients address both symptom and root cause.

75. Reporting Structure

A penetration testing report commonly includes:

Executive Summary

Scope

Methodology

Assessment Overview

Risk Summary

Detailed Findings

Recommendations

Appendices

The report should support decision-making.

76. Executive Summary

Executives generally need:

What Was Tested?

What Was the Overall Risk?

What Were the Most Important Attack Paths?

What Should Be Fixed First?

Do not fill the executive summary with commands and tool output.

77. Technical Report

Technical teams require more detail.

Include:

• Target

• Technical explanation

• Evidence

• Reproduction context

• Risk

• Remediation

Keep destructive procedural detail out when unnecessary.

78. Attack Narrative Reporting

A powerful report may include:

External Service
      ↓
Initial Access
      ↓
Credential Exposure
      ↓
Internal Access
      ↓
Privilege Escalation
      ↓
Critical Asset

This tells the client how weaknesses combine.

79. Reporting Is Part of Ethical Hacking

If you can exploit a vulnerability but cannot explain:

• Why it matters

• How it was validated

• What should change

the engagement has limited value.

Communication is part of offensive security.

80. Cleanup

At the end of testing:

Remove Test Files

Remove Test Accounts

Terminate Sessions

Remove Payloads

Restore Modified Configuration

Confirm Cleanup

Follow the agreed cleanup process.

81. Evidence Retention

Follow the engagement’s rules regarding:

• Storage

• Encryption

• Retention

• Client delivery

• Secure deletion

Testing evidence can be highly sensitive.

82. Ethical Hacking Lab Workflow

For every practical lab use:

Mission
   ↓
Environment
   ↓
Scope
   ↓
Reconnaissance
   ↓
Enumeration
   ↓
Analysis
   ↓
Hypothesis
   ↓
Controlled Validation
   ↓
Evidence
   ↓
Finding
   ↓
Remediation
   ↓
Cleanup

This pattern should become automatic.

83. Build Your Foundation Lab Environment

Your environment may contain:

Attacker VM
    │
    ├── Linux Target
    ├── Windows Target
    └── Vulnerable Web Application

Place these inside an isolated training network.

84. Learn Your Attacker Environment

Understand:

• Network interfaces

• IP addresses

• Routing

• DNS

• File system

• Shell

• Package management

• Tools

Do not treat your attacker VM as a magical hacking appliance.

Understand the operating system.

85. Important Tool Categories

You will encounter tools for:

Reconnaissance

Port Scanning

Service Enumeration

Web Assessment

Packet Analysis

Vulnerability Analysis

Password Auditing

Directory Services

Cloud Assessment

The exact tools will change over time.

The methodology matters more.

86. Reconnaissance Tool Mindset

Before choosing a tool ask:

What information am I trying to discover?

For example:

Question:
Which TCP services are accessible?

Technique:
Port scanning

Tool:
Appropriate network scanner

Question first.

Tool second.

87. Build a Command Journal

Rather than trying to memorise everything, maintain:

Ethical Hacking Commands/
│
├── Network Discovery
├── Port Scanning
├── DNS
├── HTTP
├── SMB
├── LDAP
├── Linux
└── Windows

For every command record:

• Purpose

• Syntax

• Important options

• Example output

• Interpretation

88. Learn to Interpret Output

Knowing how to run a command is not enough.

Ask:

What does this output mean?

What should I investigate next?

Example:

445/tcp open

The next thought should not simply be:

SMB exploit.

Instead:

What SMB Version?

What Host?

Domain Joined?

Anonymous Access?

Shares?

Authentication?

Interpretation drives testing.

89. Manual vs Automated Testing

Use both.

Automation
    ↓
Broad Discovery

Manual Testing
    ↓
Deep Validation

Automation provides scale.

Manual analysis provides context.

90. Develop Hypothesis-Driven Testing

Instead of random actions:

Maybe this works.

Use:

Observation

Hypothesis

Test

Result

Conclusion

Example:

Observation:

SMB allows anonymous connection.

Hypothesis:

Anonymous users may access internal shares.

Test safely.

Then document the result.

91. Avoid Exploit-First Thinking

Do not make every assessment:

Scan
 ↓
Search Exploit
 ↓
Run Exploit

Many important weaknesses involve:

• Misconfiguration

• Identity

• Authorization

• Trust relationships

• Business logic

• Exposed information

Offensive security is broader than CVE exploitation.

92. Think Like an Attacker

Attackers do not ask:

Which module of this course am I currently studying?

They ask:

What is the easiest path to the objective?

Your methodology should eventually connect:

Network
   +
Application
   +
Identity
   +
Cloud
   +
Human

Attack paths cross technologies.

93. Think Like a Defender Too

After identifying a weakness ask:

How Could This Be Prevented?

How Could This Be Detected?

What Logs Would Show It?

What Architecture Change Removes the Attack Path?

This builds stronger security judgement.

94. Ethical Hacking and MITRE ATT&CK

As you progress, map techniques to attacker behaviour.

A simplified sequence:

Reconnaissance
      ↓
Initial Access
      ↓
Execution
      ↓
Persistence
      ↓
Privilege Escalation
      ↓
Credential Access
      ↓
Discovery
      ↓
Lateral Movement
      ↓
Collection

This helps place techniques inside realistic adversary operations.

95. Ethical Hacking and Risk

Ultimately, your testing should answer:

What Is the Weakness?
       ↓
Can It Be Exploited?
       ↓
What Can Be Reached?
       ↓
What Is the Impact?
       ↓
How Should It Be Fixed?

This connects technical testing to enterprise security.

96. Common Beginner Mistakes

Avoid:

Running Tools Without Understanding

Learn what the protocol and service actually do.

Scanning Without Scope

Always confirm your target.

Trusting Scanner Results

Validate important issues.

Chasing Every CVE

Focus on realistic attack paths.

Ignoring Notes

You will forget important details.

Collecting Too Much Sensitive Data

Only collect what is necessary.

Trying to “Own Everything”

Demonstrate risk safely.

Ignoring Reporting

The report is part of the engagement.

97. Professional Ethical Hacker Habits

Build these habits early:

Confirm Scope

Take Notes

Record Evidence

Think Before Testing

Understand Impact

Minimise Disruption

Protect Data

Validate Findings

Clean Up

Communicate Clearly

These habits separate professional testers from tool users.

98. Foundation Practice Scenario

You are authorised to assess:

10.10.20.15

You discover:

22/tcp  SSH
80/tcp  HTTP
445/tcp SMB

Do not immediately exploit.

Build questions.

SSH

• Which version?

• Is password authentication permitted?

• What users may authenticate?

HTTP

• What application?

• Which technologies?

• Authentication?

• Hidden paths?

SMB

• Which version?

• Is anonymous access possible?

• Which shares exist?

• Is the system domain joined?

Now you have an enumeration plan.

99. Scenario Development

Suppose SMB enumeration reveals a readable share.

Inside the share is an application configuration backup.

The configuration contains a test credential.

Your attack path may become:

SMB Exposure
    ↓
Readable Share
    ↓
Configuration Backup
    ↓
Credential
    ↓
Application Login

Now ask:

Does the credential work?

What access does it provide?

Is reuse authorised to test?

What is sufficient proof?

This is disciplined ethical hacking.

100. Build the Finding

Possible finding:

Sensitive Configuration Files Accessible Through Network Share

Observation

A network share accessible to low-privileged users contained application configuration backups containing authentication information.

Risk

An attacker obtaining internal network access could retrieve the configuration data and potentially use exposed credentials to gain unauthorised access to additional services.

Recommendation

Restrict share permissions, remove sensitive configuration backups from general file shares, securely manage application credentials, and rotate any exposed credentials.

This transforms technical discovery into useful security advice.

101. Foundation Knowledge Checklist

Before moving forward, you should understand:

[ ] Ethical hacking vs malicious hacking
[ ] Authorisation
[ ] Scope
[ ] Rules of Engagement
[ ] Stop conditions
[ ] Penetration testing lifecycle
[ ] Passive reconnaissance
[ ] Active reconnaissance
[ ] Attack surface
[ ] Host discovery
[ ] Port scanning
[ ] TCP vs UDP
[ ] Service enumeration
[ ] Vulnerability analysis
[ ] Scanner limitations
[ ] CVE
[ ] CVSS
[ ] Controlled exploitation
[ ] Proof of concept
[ ] Post-exploitation
[ ] Privilege escalation
[ ] Credential access
[ ] Lateral movement
[ ] Attack chaining
[ ] Evidence handling
[ ] Finding development
[ ] Risk communication
[ ] Remediation guidance
[ ] Reporting
[ ] Cleanup

102. Ethical Hacking Foundations Toolkit

Build:

Ethical Hacking Foundations Toolkit/
│
├── 01 Scope Checklist
├── 02 Rules of Engagement Template
├── 03 Reconnaissance Checklist
├── 04 Attack Surface Worksheet
├── 05 Host Discovery Notes
├── 06 Service Enumeration Checklist
├── 07 Vulnerability Validation Worksheet
├── 08 Exploitation Decision Checklist
├── 09 Evidence Log
├── 10 Finding Template
├── 11 Attack Path Worksheet
├── 12 Reporting Template
└── 13 Cleanup Checklist

You will reuse these resources throughout the path.

103. Ethical Hacker’s Core Questions

During every assessment repeatedly ask:

Scope

Am I authorised to test this?

Exposure

What can the attacker reach?

Service

What exactly is running?

Identity

Which users or services exist?

Weakness

What security assumption can be broken?

Exploitability

Can this realistically be abused?

Access

What access does exploitation provide?

Path

Where can the attacker move next?

Impact

What valuable asset can eventually be reached?

Detection

Would the organisation notice?

Evidence

What proves the issue?

Remediation

What change removes or reduces the attack path?

Key Takeaways

Ethical hacking foundations are not about memorising exploitation commands.

They establish a professional methodology.

Your core workflow is:

Authorisation
      ↓
Understand Scope
      ↓
Discover
      ↓
Enumerate
      ↓
Analyse
      ↓
Form Hypothesis
      ↓
Validate Safely
      ↓
Understand Access
      ↓
Develop Attack Path
      ↓
Demonstrate Impact
      ↓
Collect Evidence
      ↓
Report
      ↓
Recommend

Remember:

Reconnaissance identifies where to look.

Enumeration helps you understand what you found.

Vulnerability analysis identifies potential weaknesses.

Exploitation validates whether the weakness matters.

Attack chaining demonstrates how weaknesses combine.

Evidence makes the conclusion defensible.

Reporting turns offensive testing into security improvement.

The most valuable skill you can develop at this stage is disciplined curiosity.

Do not simply ask:

“What exploit can I run?”

Ask:

“What does this system expose, what does it trust, what can be abused, and where could that lead?”

That mindset becomes the foundation for every advanced offensive security discipline.

What’s Next?

➡️ 02 — Network Penetration Testing

In the next module, you will apply these foundations directly to network security assessments.

You will move deeper into:

• Network reconnaissance

• Host discovery

• TCP and UDP scanning

• Port and service enumeration

• DNS enumeration

• SMB assessment

• SSH and remote-service analysis

• SNMP enumeration

• Network vulnerability assessment

• Controlled exploitation

• Network privilege escalation

• Pivoting concepts

• Lateral movement

• Attack-path development

• Network penetration testing reporting

The objective is to move from:

“I understand the ethical hacking methodology.”

to:

“I can systematically assess an authorised network, understand its exposed services, validate meaningful weaknesses, and develop realistic network attack paths.”