Ethical Hacking Phases: From Reconnaissance to Reporting

Ethical hacking is a controlled security assessment performed with written permission. A professional tester follows a defined process so that testing remains safe, repeatable and useful to the organisation.

This guide explains the ethical hacking phases through an authorised lab scenario. Run the example commands only on systems you own or have explicit permission to test.

What Are the Main Ethical Hacking Phases?

The main phases are reconnaissance, scanning and enumeration, vulnerability analysis, exploitation, post-exploitation, cleanup, reporting and retesting. Before these technical phases begin, the tester and client must agree on scope, rules of engagement and emergency contacts.

A simple diagram-in-words looks like this:

Authorisation and scope
        |
        v
Reconnaissance -> Scanning -> Vulnerability analysis
        |                              |
        v                              v
   Asset map                      Test plan
                                       |
                                       v
Exploitation -> Post-exploitation -> Cleanup
                                       |
                                       v
                              Reporting -> Retesting

Although the diagram is linear, real assessments include feedback loops. For example, service enumeration may reveal a new hostname that requires additional reconnaissance.

Why Must Scope Be Defined Before Testing?

Scope tells the tester what may be tested, when testing may occur and which techniques are prohibited. Without clear written authorisation, even a technically harmless scan can be unlawful or disruptive.

A rules-of-engagement document should normally define:

• In-scope IP addresses, domains, applications and cloud accounts
• Explicitly excluded systems, such as production databases or medical devices
• Permitted test dates and maintenance windows
• Whether phishing, password testing, denial-of-service testing or physical access is allowed
• Source IP addresses used by the testing team
• Data handling and evidence retention requirements
• Emergency contacts and stop conditions
• The required report format and severity model

The tester should also confirm whether third-party services are involved. A company may own an application but not the cloud platform, payment gateway or software-as-a-service system supporting it.

Phase 1: What Happens During Reconnaissance?

Reconnaissance collects information that can help build an accurate target map. Passive reconnaissance uses public or client-provided sources, while active reconnaissance communicates directly with an authorised target.

Passive reconnaissance

Common tasks include reviewing:

• Domain registration and DNS information
• Public DNS records and certificate transparency data
• Public documentation and code repositories
• Internet-facing technologies
• Employee-provided architecture and asset inventories

For an authorised lab domain, DNS records can be inspected with dig:

dig lab.example.test A
dig lab.example.test MX
dig lab.example.test TXT

An abbreviated result might look like this:

lab.example.test.  300  IN  A   192.0.2.20

The A record maps the hostname to an IPv4 address. The value 300 is the time to live in seconds, not a port number or security setting.

Active reconnaissance

Active checks include direct DNS queries, HTTP header inspection and carefully limited host discovery. For example:

curl -I http://192.168.56.20

Example response:

HTTP/1.1 200 OK
Server: Apache/2.4.49
Content-Type: text/html

The header suggests that Apache is in use, but it is not enough to confirm a vulnerability. Headers can be modified, reverse proxies can hide backend servers, and version strings can be inaccurate.

Phase 2: How Do Scanning and Enumeration Work?

Scanning finds reachable hosts, open ports and exposed protocols. Enumeration goes deeper by requesting service-specific information such as HTTP titles, TLS certificates or SMB shares.

Consider an isolated VirtualBox host-only lab with a tester at 192.168.56.10 and a deliberately vulnerable server at 192.168.56.20.

Start with a limited TCP scan:

nmap -sS -T3 -p 22,80,443 192.168.56.20

Example output:

PORT    STATE  SERVICE
22/tcp  open   ssh
80/tcp  open   http
443/tcp closed https

open means an application accepted a connection. closed means the host responded but no service was listening. A filtered result usually means that a firewall or packet filter prevented Nmap from determining the port state.

Next, request service detection only for open ports:

nmap -sV -p 22,80 192.168.56.20

Example output:

22/tcp open  ssh   OpenSSH 8.2p1 Ubuntu
80/tcp open  http  Apache httpd 2.4.49

Enumeration should be deliberate rather than noisy. The tester may inspect HTTP methods and page titles with safe Nmap scripts:

nmap -p 80 --script http-title,http-methods 192.168.56.20

Tool output is evidence to investigate, not an automatic finding. Service banners must be checked against configuration, operating system packages and vendor advisories.

Phase 3: What Is Vulnerability Analysis?

Vulnerability analysis connects observed technology and configuration details to weaknesses that may create real risk. The tester verifies scanner results, removes false positives and prioritises test cases before attempting exploitation.

A sound analysis asks four questions:

1. Is the affected component actually present and reachable?
2. Does its exact version or configuration meet the vulnerable conditions?
3. Are compensating controls reducing exposure?
4. What business asset or data could be affected?

Suppose a scanner flags an Apache version. The tester should not report a vulnerability from the banner alone. On a client-provided Linux host, package information can provide better evidence:

apache2 -v
dpkg -l apache2
apt-cache policy apache2

Linux distributions sometimes backport security patches without changing the upstream version in the way a scanner expects. Vendor package advisories and changelogs should therefore be checked before assigning severity.

Students who want guided practice with scoped labs, enumeration and evidence collection can review the Ethical Hacking (CEH) course.

Phase 4: What Does Safe Exploitation Mean?

Exploitation confirms that a weakness can be used to cross a security boundary or access protected functionality. Ethical testers use the least harmful method that proves impact and stop when sufficient evidence has been collected.

Imagine that the authorised lab application exposes these endpoints after login:

GET /api/profile/101
GET /api/profile/102

The tester is assigned account 101. If changing the identifier to 102 returns another user's record without an authorisation check, the issue may be an insecure direct object reference.

A controlled request could be recorded as:

curl -i \
  -H 'Authorization: Bearer LAB_TOKEN_REDACTED' \
  http://192.168.56.20/api/profile/102

Evidence should show only enough data to prove unauthorised access. Tokens, personal details and secrets must be redacted from screenshots and reports.

A safe proof should document:

• The authorised test account used
• The exact request and affected endpoint
• The expected result
• The observed unauthorised result
• The minimum data required to demonstrate impact
• The time of testing for log correlation

Do not download an entire database when one synthetic record proves the issue. Do not establish persistence, alter production data or run destructive payloads unless these actions are explicitly approved.

Phase 5: What Happens After Initial Access?

Post-exploitation measures the practical impact of confirmed access. It may examine privileges, accessible network paths, exposed secrets and whether one compromised component can reach another in-scope asset.

Typical questions include:

• Which user or service account context was obtained?
• Can that identity access restricted files or APIs?
• Are cloud credentials or plaintext passwords exposed?
• Can the host reach sensitive management networks?
• Do endpoint and SIEM controls detect the activity?

On an authorised Linux lab host, basic context checks may include:

whoami
id
hostname
ip route
sudo -l

whoami displays the current username, while id shows user and group membership. sudo -l lists permitted sudo operations, but it may prompt for a password and should not be followed by privilege escalation unless that test is approved.

Post-exploitation is not an invitation to explore without limits. The assessment scope still controls which systems, accounts and data can be accessed. Blue-team learners can study how related activity appears in a SIEM through the guide to searching logs and building a Splunk dashboard.

Phase 6: Why Are Cleanup and Restoration Important?

Cleanup removes files, accounts, configuration changes and other artefacts created during testing. It helps return the environment to its original condition without deleting legitimate logs that defenders may need.

The tester should maintain an artefact log throughout the engagement. It can include:

2026-08-10 10:20 UTC | Created /tmp/nr-proof.txt | 192.168.56.20
2026-08-10 10:24 UTC | Added test account nr-audit | Lab application
2026-08-10 10:40 UTC | Removed file and test account | Verified

Cleanup may involve deleting uploaded proof files, removing approved test users, revoking temporary tokens and restoring modified settings. The client should verify significant restoration steps. Security, web and authentication logs should remain available unless the rules of engagement specify a different process.

Phase 7: What Should an Ethical Hacking Report Contain?

The report translates technical evidence into decisions that technical teams and business owners can act on. It should explain what was tested, what was found, why each issue matters and how the organisation can fix it.

A useful report normally has two layers:

1. Executive summary: overall exposure, important business risks and priority actions.
2. Technical findings: affected assets, evidence, reproduction steps, impact and remediation guidance.

A clear finding structure is:

Avoid vague remediation such as “improve security.” For the API example, the developer should derive the allowed object from the authenticated identity or perform a server-side authorisation check before returning it.

Retesting is a separate verification step. A fixed finding should be marked accordingly only after the original request no longer produces unauthorised access and the control has been checked for simple bypasses. Broader monitoring and incident-handling skills are covered in the Cybersecurity & SOC course.

How Do the Phases Work Together in a Practical Lab?

Each phase transforms raw information into stronger evidence. The following workflow shows how a tester can move from an unknown host to a defensible report without exceeding the lab scope.

1. Scope confirms 192.168.56.20 is authorised.
2. Reconnaissance identifies an HTTP service.
3. Nmap confirms ports 22 and 80 are open.
4. Enumeration identifies the web application and API routes.
5. Analysis suspects missing object-level authorisation.
6. One synthetic cross-account request confirms the issue.
7. The tester records timestamps and redacts the token.
8. Temporary artefacts are removed.
9. The report explains impact and server-side remediation.
10. Retesting confirms that account 101 cannot request profile 102.

This chain is important because a report must be reproducible. A scanner alert without validation may waste remediation time, while an uncontrolled exploit may create more risk than the original weakness.

How Can Common Lab Problems Be Troubleshot?

Troubleshooting should begin with network reachability and then move up the protocol stack. Confirm the lab scope before changing scan options, disabling controls or increasing test intensity.

Nmap reports the host as down

The target may block ICMP discovery even though its services are reachable. If the host is definitely authorised, skip discovery and scan only the approved ports:

nmap -Pn -p 22,80,443 192.168.56.20

Also check the local interface and route:

ip address
ip route get 192.168.56.20

A port appears filtered

Use a TCP connection test to confirm whether a firewall is dropping traffic:

nc -vz -w 3 192.168.56.20 80

Do not assume that filtered means the server is vulnerable or offline. Check VirtualBox networking, host firewalls, cloud security groups or access control lists as appropriate.

Curl reaches the wrong website

Name-based virtual hosting may require the correct hostname:

curl -I -H 'Host: lab.example.test' http://192.168.56.20

In a closed lab, an approved temporary /etc/hosts entry can map the name:

192.168.56.20 lab.example.test

Scanner and manual results disagree

Check redirects, authentication requirements, proxy behaviour and version detection. Save raw requests and responses, compare the scanner's vulnerable condition with the vendor advisory, and report only what the available evidence supports.

What Mistakes Should New Ethical Hackers Avoid?

New testers often focus on tools before learning scope, protocols and evidence handling. Effective ethical hacking depends on disciplined decisions, not the number of scanners or exploits used.

Avoid these common mistakes:

• Testing public targets without written permission
• Running every Nmap script against production systems
• Treating scanner results as confirmed vulnerabilities
• Collecting more sensitive data than necessary
• Failing to record commands, timestamps and source IPs
• Leaving uploaded files or temporary accounts behind
• Reporting technical details without explaining business impact
• Assigning critical severity to every issue
• Retesting a changed environment without confirming approval

Summary

The ethical hacking phases provide a controlled path from asset discovery to verified remediation. Reconnaissance builds the target map, scanning identifies services, analysis prioritises weaknesses, exploitation proves impact, post-exploitation measures exposure, and cleanup removes test artefacts.

Reporting is not an administrative afterthought. It is the phase that turns technical evidence into practical remediation, while retesting confirms that the security control now works.

To practise this workflow in guided labs and learn how to document findings, enquire about upcoming batch details for the Ethical Hacking (CEH) course.

*Reviewed by Network Rhinos cybersecurity trainers.*

Related reading: FortiGate Firewall Basics: Policies, NAT and Logging