PT0-003 — CompTIA PenTest+ V3 Cheat Sheet

Last revised: September 16, 2026

Compact PT0-003 Cheat sheet covering pentest methodology, recon, scanning, exploitation, cloud, reporting, and exam traps.

Use the tables for a quick pre-exam check. Expand a topic’s notes for explanations, examples, and additional distinctions.

Scope and study context

Know what to choose: tool, scan type, attack path, report section, or remediation.
Know why: active vs. passive, authenticated vs. unauthenticated, exploit vs. validate, proof-of-concept vs. production-safe.
Watch for exam traps around scope, authorization, safety, evidence handling, and least disruptive testing.

The exam mindset is practical: you are expected to understand how an authorized penetration test is planned, executed, documented, and communicated. Tool names matter, but the more important skill is choosing the right action given the scope, evidence, risk, and business context.

After this Cheat Sheet, move into IT Mastery practice:

Start with topic drills for weak areas such as web apps, Active Directory, cloud, scripting, and reporting.
Use original practice questions to test decision-making, not memorization.
Review detailed explanations for both correct and incorrect answers.
Run mixed question bank sets to practice switching between planning, enumeration, exploitation, and reporting scenarios.
Finish with timed mock exams to build speed and reduce second-guessing.

Practical next step: choose one weak PT0-003 topic, complete a focused drill set, and review every explanation until you can justify the safest, most professional answer without relying on tool-name memorization.

Penetration Test Lifecycle Reference

Phase	Primary Goal	High-Yield Outputs	Common Exam Traps
Pre-engagement	Define authorization, scope, rules, constraints	SOW, ROE, communication plan, escalation path, test windows	Starting scans before authorization; ignoring third-party/cloud approval
Reconnaissance	Identify targets, technologies, people, exposures	Domains, IPs, DNS records, emails, tech stack, attack surface	Confusing passive OSINT with active probing
Enumeration	Confirm live hosts, services, versions, users, shares	Open ports, banners, AD objects, APIs, web paths	Treating a vulnerability scanner result as confirmed exploitation
Vulnerability analysis	Map findings to likely weaknesses	CVEs, misconfigurations, weak auth, missing patches	Chasing high CVSS findings outside scope
Exploitation	Validate risk through controlled attack	Shell, data access proof, privilege boundary crossing	Causing outage, persistence without permission, data overcollection
Post-exploitation	Assess impact and pivot potential	Privilege level, lateral movement path, sensitive data proof	Expanding beyond scope or failing to preserve evidence
Reporting	Communicate risk, evidence, and remediation	Executive summary, technical findings, risk ratings, retest plan	Writing only tool output; missing business impact
Cleanup and debrief	Remove artifacts and transfer knowledge	Removed accounts/files, restored settings, lessons learned	Leaving payloads, test accounts, or scheduled tasks behind

Rules of Engagement and Scope Checklist

Item	What to Verify	Why It Matters
Written authorization	Who approves testing and what systems are included	Prevents unauthorized access claims
In-scope targets	IP ranges, domains, APIs, apps, cloud accounts, facilities	Defines legal and operational boundaries
Out-of-scope targets	Shared infrastructure, third-party systems, production components	Prevents collateral impact
Test windows	Dates, times, maintenance periods, blackout periods	Reduces business disruption
Allowed techniques	Phishing, password spraying, exploitation, DoS testing, physical testing	Some tests require explicit approval
Data handling	Collection limits, storage, encryption, retention, disposal	Protects sensitive evidence
Emergency contacts	Incident escalation path and stop-test authority	Needed for instability or detection events
Success criteria	Objectives, flags, crown jewels, demonstration requirements	Keeps testing aligned with client goals
Reporting format	Audience, due dates, severity model, evidence standards	Avoids unclear deliverables

Notes and examples

Exam cue: If the scenario asks what to do first, choose authorization, scope validation, or ROE review before scanning or exploitation.

Planning, scope, and rules of engagement

Planning questions are often about professional judgment. Before testing, the penetration tester needs clear written authorization and boundaries.

Core pre-engagement artifacts

Artifact	Purpose
Statement of work	Defines services, deliverables, assumptions, constraints
Scope	Identifies included and excluded IPs, domains, apps, facilities, users, cloud accounts, time windows
Rules of engagement	Defines permitted techniques, testing windows, rate limits, escalation paths, emergency stop conditions
Authorization letter	Provides written permission to conduct testing
Communication plan	Defines primary contacts, status updates, emergency contacts, and incident handling
Data handling requirements	Defines how evidence, credentials, logs, screenshots, and sensitive data are stored and transmitted
Success criteria	Defines what the test is intended to prove or measure

Decision rules

Situation	Best professional response
Asset appears vulnerable but is out of scope	Do not test it; document and escalate through approved contacts
Testing causes instability	Stop or reduce activity; notify according to ROE
You discover evidence of active compromise	Preserve evidence and follow the escalation plan
Client asks to add targets mid-test	Update written scope/authorization before testing them
You obtain sensitive data	Minimize access, protect evidence, document impact, avoid unnecessary exfiltration
A destructive exploit is available	Prefer safe validation unless destructive testing is explicitly authorized

Common traps

Scope beats curiosity. If it is not authorized, do not test it.
ROE beats tool defaults. Scanner rate, brute-force attempts, payloads, and timing must match the engagement.
Safety matters. Denial-of-service, phishing, physical access, and social engineering usually require explicit permission.
Evidence must be enough, not excessive. Prove access without collecting unnecessary confidential data.

Passive vs. Active Reconnaissance

Technique	Passive or Active	Typical Tools / Sources	Use When
WHOIS/RDAP lookup	Passive	whois, registrar data	Identifying ownership and contacts
DNS record review	Passive or active depending method	dig, nslookup, DNSDumpster	Mapping domains, MX, TXT, SPF, DKIM, DMARC
Certificate transparency search	Passive	crt.sh, search engines	Finding subdomains without touching target
Search engine dorking	Passive	Google/Bing operators	Discovering exposed files and admin portals
Social media review	Passive	LinkedIn, public posts	Identifying roles, naming conventions, phishing targets
Port scan	Active	nmap, masscan	Discovering exposed services
Web crawling	Active	Burp Suite, OWASP ZAP, feroxbuster	Mapping application paths
Banner grabbing	Active	netcat, curl, nmap scripts	Identifying versions and service behavior
Password spraying	Active	kerbrute, custom scripts, cloud login portals	Testing weak password patterns with lockout risk

Fast Tool Selection Matrix

Task	Preferred Tool Types	Examples	Notes
Port/service discovery	Network scanners	Nmap, Masscan	Use slower, safer scans when stealth or stability matters
Vulnerability scanning	Vulnerability scanners	Nessus, OpenVAS/Greenbone, Qualys	Authenticated scans produce better results
Web proxy testing	Intercepting proxies	Burp Suite, OWASP ZAP	Best for auth flows, parameter tampering, API testing
Directory/content discovery	Web fuzzers	ffuf, gobuster, dirsearch, feroxbuster	Tune wordlists and extensions
Password auditing	Crackers and online testers	Hashcat, John the Ripper, Hydra, Medusa	Distinguish offline cracking from online guessing
AD enumeration	AD tools	BloodHound, SharpHound, enum4linux-ng, ldapsearch	Focus on relationships and privilege paths
Exploitation framework	Exploit frameworks	Metasploit	Use for validation, not as a substitute for understanding
Packet analysis	Protocol analyzers	Wireshark, tcpdump	Useful for credentials, protocols, anomalies
Wireless testing	Wi-Fi tools	Aircrack-ng suite, Kismet	Requires explicit wireless scope
Cloud assessment	Cloud CLI and posture tools	AWS CLI, Azure CLI, ScoutSuite, Prowler	Requires tenant/account authorization
Container/Kubernetes review	Container and cluster tools	docker, kubectl, Trivy, kube-bench	Check images, RBAC, secrets, exposed APIs
Source/code review	Static analysis and manual review	Semgrep, Bandit, grep, IDE tools	Trace input validation, auth, crypto, secrets
Reporting	Evidence and documentation tools	Screenshots, logs, issue trackers	Preserve command, timestamp, target, result

Nmap and Network Scanning Cheat Sheet

Common Nmap Patterns

Goal	Command Pattern	Exam Notes
Basic TCP SYN scan	`nmap -sS <target>`	Requires privileges on many systems; stealthier than full connect but still active
TCP connect scan	`nmap -sT <target>`	Uses OS TCP connect; useful without raw socket privileges
UDP scan	`nmap -sU <target>`	Slower and less reliable; useful for DNS, SNMP, NTP, VPN services
Service/version detection	`nmap -sV <target>`	Helps map CVEs but may be noisy
OS detection	`nmap -O <target>`	Accuracy depends on network conditions and open/closed ports
Default scripts	`nmap -sC <target>`	Runs common NSE scripts; can increase traffic
Aggressive scan	`nmap -A <target>`	Combines OS, version, scripts, traceroute; noisier
Scan selected ports	`nmap -p 80,443,8080 <target>`	Better when scope is narrow
Scan all TCP ports	`nmap -p- <target>`	Finds nonstandard services; takes longer
Output all formats	`nmap -oA basename <target>`	Saves normal, grepable, and XML output
Timing template	`nmap -T0` to `-T5`	Faster is noisier and more disruptive
No ping discovery	`nmap -Pn <target>`	Use when ICMP is blocked or hosts appear down
Script by category	`nmap --script vuln <target>`	Validate script behavior before using against production

Notes and examples

Scan Decision Points

Scenario	Better Choice	Why
Firewalled host appears down	`-Pn`	Treat host as up and scan ports
Need safe initial discovery	Low-rate TCP scan of approved ports	Minimizes disruption
Need reliable web service version	`-sV` plus manual banner validation	Reduces false assumptions
Need confirm UDP exposure	UDP scan plus protocol-specific query	UDP responses are often ambiguous
Need preserve evidence	`-oA`, screenshots, timestamps	Supports repeatable reporting

High-Yield Ports and Services

Port / Protocol	Service	Common Test Focus
21/TCP	FTP	Anonymous access, cleartext credentials, writable directories
22/TCP	SSH	Weak passwords, old algorithms, exposed keys
23/TCP	Telnet	Cleartext login, legacy systems
25/TCP	SMTP	Open relay, user enumeration, spoofing controls
53/TCP/UDP	DNS	Zone transfer, subdomain enumeration, misconfigured records
80/443/TCP	HTTP/HTTPS	Web vulnerabilities, TLS configuration, auth/session flaws
88/TCP/UDP	Kerberos	AD attacks, user enumeration, Kerberoasting paths
110/995/TCP	POP3/POP3S	Cleartext or weak mailbox auth
111/TCP/UDP	RPCbind	NFS/RPC enumeration
135/TCP	MS RPC	Windows enumeration and lateral movement context
139/445/TCP	SMB	Shares, signing, null sessions, relay risk, legacy protocols
143/993/TCP	IMAP/IMAPS	Mailbox access, credential testing
161/UDP	SNMP	Community strings, device info disclosure
389/636/TCP	LDAP/LDAPS	Directory enumeration, weak binds
445/TCP	SMB	File shares, named pipes, Windows auth
1433/TCP	MSSQL	Default credentials, xp_cmdshell, weak permissions
1521/TCP	Oracle DB	Listener exposure, default accounts
2049/TCP/UDP	NFS	Export permissions, no_root_squash
3306/TCP	MySQL/MariaDB	Weak auth, exposed DB
3389/TCP	RDP	External exposure, weak passwords, NLA status
5432/TCP	PostgreSQL	Weak auth, exposed DB
5900/TCP	VNC	Weak/no password, exposed remote desktop
5985/5986/TCP	WinRM	Remote admin, credential reuse
6379/TCP	Redis	Unauthenticated access, data exposure
8080/8443/TCP	Alternate HTTP(S)	Admin panels, proxies, dev apps
9200/TCP	Elasticsearch	Unauthenticated data exposure
11211/TCP/UDP	Memcached	Unauthenticated access, amplification risk
27017/TCP	MongoDB	Unauthenticated DB exposure

Vulnerability Validation Logic

Scanner Finding Says	Do This Before Reporting as Confirmed	Evidence to Capture
Missing patch / CVE	Verify version, configuration, and exploitability context	Version output, package info, vendor advisory mapping
Default credentials	Attempt approved login with safe credentials list	Login proof without excessive data access
SQL injection	Confirm with controlled payloads and response difference	Request/response pairs, parameter, impact
XSS	Demonstrate script execution safely	Payload, affected parameter, browser evidence
Weak TLS	Validate with TLS scanner and protocol/cipher evidence	Protocols, ciphers, certificate chain issues
SMB signing disabled	Confirm host policy and relay relevance	SMB negotiation evidence
Exposed sensitive file	Prove existence with minimal access	Path, headers, redacted content sample
Privilege escalation	Show before/after privilege boundary	User context, command output, access gained

Web Application Testing Reference

Web Vulnerability Matrix

Vulnerability	Core Test	Common Payload / Signal	Impact
SQL injection	Input changes query logic	`' OR '1'='1`, time delay, error difference	Data disclosure, auth bypass, RCE in some stacks
Reflected XSS	Payload returns in response and executes	`<script>alert(1)</script>` or safe proof payload	Session theft, user action abuse
Stored XSS	Payload persists and executes for others	Comment/profile field execution	Broader user compromise
DOM XSS	Client-side JS writes unsafe input to DOM	URL fragment reflected in sink	Browser-side execution
CSRF	State-changing request lacks anti-CSRF control	Forced form submit or crafted request	Unwanted user actions
SSRF	Server fetches attacker-controlled URL	Request to internal metadata or callback host	Internal service access, cloud credential exposure
IDOR/BOLA	Change object ID and access another user’s data	`/api/users/123` to `/api/users/124`	Unauthorized data access
Broken authentication	Weak login/session controls	No lockout, weak reset, predictable tokens	Account takeover
Broken access control	User reaches forbidden function	Direct admin URL/API call	Privilege abuse
File upload flaw	Upload executable or polyglot content	Web shell, MIME bypass, extension trick	RCE or stored payload
Path traversal	Access files outside web root	`../../../../etc/passwd`	Sensitive file disclosure
Command injection	OS command executed by app	`; id`, `&& whoami`	RCE
XXE	XML parser resolves external entity	External entity callback/file read	File disclosure, SSRF
Insecure deserialization	Tampered serialized object changes behavior	Signed/unsigned object manipulation	RCE, auth bypass
Security misconfiguration	Default config or verbose errors	Stack traces, admin consoles	Information disclosure, takeover path
Sensitive data exposure	Secrets or PII exposed	Keys in JS, logs, backups	Credential/data compromise

Notes and examples

HTTP Status Codes Worth Knowing

Code	Meaning	Pentest Relevance
200	OK	Content exists; check authorization
301/302	Redirect	Follow auth flows and open redirect risk
400	Bad request	Input validation clue
401	Unauthorized	Authentication required
403	Forbidden	Authenticated but not authorized, or blocked path
404	Not found	May hide resources; compare response size
405	Method not allowed	Try allowed methods if in scope
500	Server error	Possible injection, parsing, or backend issue

Useful Web Testing Commands

## Inspect headers and TLS behavior
curl -k -I https://target.example

## Send a custom host header or token
curl -k -H "Host: app.target.example" -H "Authorization: Bearer TOKEN" https://IP/

## Basic directory fuzzing pattern
ffuf -u https://target.example/FUZZ -w wordlist.txt -mc all -fs <filter_size>

## Parameter fuzzing pattern
ffuf -u "https://target.example/search?q=FUZZ" -w payloads.txt

Web application and API Cheat Sheet

Web questions often test input validation, authentication, authorization, session handling, and evidence interpretation.

Common web vulnerabilities

Vulnerability	What it means	Validation idea	Typical remediation
SQL injection	User input alters database query logic	Safe boolean/time/error-based checks	Parameterized queries, ORM safeguards, input validation
Command injection	Input reaches OS command execution	Harmless command proof within ROE	Avoid shell calls, allowlists, escaping, least privilege
Cross-site scripting	Input executes in another user’s browser	Prove script execution context	Output encoding, CSP, input validation
Stored XSS	Payload persists for other users	Confirm persistence and affected roles	Encode output and sanitize stored content
Reflected XSS	Payload reflected in immediate response	Confirm browser execution	Encode output and validate inputs
DOM XSS	Client-side JavaScript handles input unsafely	Inspect sinks and sources	Safe DOM APIs, client-side sanitization
IDOR / BOLA	User can access another user’s object	Change object IDs with different auth context	Server-side authorization checks
CSRF	User is tricked into performing an action	Check missing anti-CSRF protections	Anti-CSRF tokens, SameSite cookies, re-auth for sensitive actions
SSRF	Server makes attacker-controlled requests	Test access to internal or metadata endpoints safely	URL allowlists, network egress controls
XXE	XML parser processes external entities	Safe entity test	Disable external entities, secure parser config
File inclusion	App includes unintended local or remote files	Test controlled file paths	Path allowlists, sandboxing
Path traversal	Input accesses files outside intended directory	Use safe traversal proof	Normalize paths, restrict file access
Insecure deserialization	Untrusted serialized data alters execution flow	Identify framework-specific payload risk	Avoid unsafe deserialization, sign/validate objects
Mass assignment	Client sets fields that should be server-controlled	Try role/isAdmin-style fields safely	Explicitly bind allowed fields
JWT weakness	Token can be forged or misused	Check alg confusion, weak secrets, claims validation	Strong signing, validate issuer/audience/expiry
Broken access control	Users perform actions outside permissions	Test role boundaries	Centralized authorization checks

HTTP status codes worth recognizing

Code	Review point
200	Success; check content and authorization context
301 / 302	Redirect; may reveal routing or auth flow
400	Bad request; input handling issue may be visible
401	Authentication required
403	Authenticated or unauthenticated user lacks authorization
404	Not found; may hide resources intentionally
500	Server error; may indicate injection, parsing, or exception handling issue

API-specific traps

Authentication is not authorization. A valid token does not mean a user should access every object.
Object IDs are high-yield. Changing user IDs, account IDs, tenant IDs, or document IDs can reveal IDOR/BOLA.
JWTs must be validated server-side. Expiration, issuer, audience, signature, and algorithm handling matter.
Rate limiting matters. APIs often expose brute-force or enumeration risk.
Verbose errors leak information. Stack traces, framework versions, SQL errors, and internal hostnames are useful evidence.

API Testing Cheat Sheet

Area	What to Test	Common Failure
Authentication	Token validation, expiration, refresh, signing	Accepting expired or unsigned tokens
Authorization	Object-level and function-level access	BOLA/IDOR, normal user reaches admin action
Rate limiting	Login, OTP, password reset, expensive queries	Brute force or resource exhaustion
Input validation	JSON fields, types, nested objects	Injection or mass assignment
Error handling	Verbose errors, stack traces, debug info	Information disclosure
Versioning	Old endpoints still reachable	Deprecated insecure functionality
CORS	Origins, credentials, methods	Overly permissive cross-origin access
GraphQL	Introspection, nested queries, auth on resolvers	Data overexposure, expensive query abuse

Notes and examples

JWT inspection reminders:

header.payload.signature

JWT Check	Risk If Weak
Algorithm confusion	Token signature bypass
Missing signature validation	Forged identity
Long token lifetime	Extended compromise
Sensitive data in payload	Client-side data exposure
Weak secret	Offline token cracking

Authentication and Password Attack Reference

Attack	Online or Offline	Target	Key Constraint
Brute force	Online	Login service	Lockouts, rate limits, detection
Password spraying	Online	Many accounts, few passwords	Safer than brute force but still risky
Credential stuffing	Online	Known breached credentials	Depends on password reuse
Dictionary attack	Offline or online	Hashes or login forms	Wordlist quality matters
Mask/rule attack	Offline	Hashes	Efficient when pattern is known
Rainbow table	Offline	Unsalted hashes	Less useful against salted hashes
Kerberoasting	Offline cracking after ticket request	AD service accounts	Requires valid domain account
AS-REP roasting	Offline cracking	AD users without preauth	Requires vulnerable account setting
Pass-the-hash	Online lateral movement	NTLM environments	Uses hash without plaintext password
Pass-the-ticket	Online lateral movement	Kerberos tickets	Uses ticket material
MFA fatigue	Online social/technical	Push-based MFA	Depends on user interaction

Notes and examples

Password cracking examples:

## Identify hash type separately; do not guess blindly
hashcat -m <mode> hashes.txt wordlist.txt

## John format example
john --wordlist=wordlist.txt hashes.txt

Active Directory Attack Path Reference

Technique	Required Starting Point	What It Abuses	Evidence / Outcome
LDAP enumeration	Network access, sometimes credentials	Directory visibility	Users, groups, computers, SPNs
Kerberoasting	Valid domain account	Service ticket encrypted with service account key	Crackable TGS hash
AS-REP roasting	User without Kerberos preauth	AS-REP encrypted with user key	Crackable AS-REP hash
Password spraying	User list and password guess	Weak/reused passwords	Valid credential
SMB share enumeration	Network access or creds	Excessive share permissions	Sensitive files, scripts, configs
GPP password discovery	SYSVOL read	Legacy Group Policy preference secrets	Recoverable local admin password
NTLM relay	Captured authentication and unsigned/weak target	Relays auth to another service	Access without knowing password
Pass-the-hash	NTLM hash	NTLM authentication	Lateral access
Pass-the-ticket	Kerberos ticket	Kerberos authentication	Lateral access
DCSync	Directory replication rights	Replication protocol permissions	Domain credential material
Golden ticket	KRBTGT key	Forged Kerberos TGT	Domain persistence
Shadow credentials	Write privileges on account attributes	Key trust abuse	Account impersonation path

Notes and examples

AD Defensive Control Distinctions

Control	Helps Against	Notes
SMB signing	NTLM relay	Prevents tampering/relay to SMB when required
LDAP signing/channel binding	LDAP relay	Hardens LDAP authentication
Least privilege	Lateral movement, privilege escalation	Reduces blast radius
Tiered administration	Domain compromise	Separates admin contexts
LAPS / local admin password management	Local admin reuse	Unique managed local passwords
Strong service account passwords/gMSA	Kerberoasting	Makes offline cracking harder
Disable legacy protocols	Downgrade/relay	Reduce NTLM/LM exposure where possible
MFA for remote access/admin	Credential replay	Does not protect every legacy protocol

Linux and Windows Privilege Escalation Checklist

Linux

Check	Command Examples	What to Look For
Current identity	`id`, `whoami`, `groups`	Group memberships, sudo rights
Kernel/version	`uname -a`, `cat /etc/os-release`	Known local privilege escalation context
Sudo rights	`sudo -l`	NOPASSWD, allowed binaries
SUID/SGID files	`find / -perm -4000 -type f 2>/dev/null`	Abusable binaries
Writable paths	`find / -writable -type d 2>/dev/null`	PATH hijacking, cron abuse
Cron/systemd	`ls -la /etc/cron*`, `systemctl list-timers`	Writable scripts or timers
Capabilities	`getcap -r / 2>/dev/null`	Dangerous capabilities like file read/write or shell execution
Secrets	Config files, history, backups	Passwords, tokens, private keys
Network	`ss -tulpn`	Local-only services to pivot into

Notes and examples

Windows

Check	Command Examples	What to Look For
Current identity	`whoami /all`	Privileges, groups, integrity level
System info	`systeminfo`	Patch and OS context
Users/groups	`net user`, `net localgroup administrators`	Privileged accounts
Services	`sc query`, PowerShell service queries	Unquoted paths, weak permissions
Scheduled tasks	`schtasks /query /fo LIST /v`	Writable task actions
Saved credentials	`cmdkey /list`	Reusable credentials
Shares	`net share`, `net use`	Sensitive data, writable shares
Registry	Autoruns, stored config	Credentials, autostart abuse
Defender/exclusions	PowerShell security settings	Avoid assuming controls are disabled

Exploitation Safety Decision Table

Situation	Safer Action	Avoid
Production database injection suspected	Use time-based or limited Boolean proof, confirm with owner	Dumping full tables
RCE suspected	Run benign identity/hostname command	Destructive commands or persistence
File read suspected	Read a harmless known file or approved marker	Accessing sensitive files unnecessarily
Weak credentials found	Login once, capture minimal proof	Broad mailbox or file browsing
Shell obtained	Stabilize only if allowed, record context	Installing persistence tools without approval
Service crash risk	Use non-invasive checks or ask for test window	Running DoS modules by default
Sensitive data encountered	Stop, document path, redact evidence	Copying large datasets

Post-Exploitation Reference

Objective	Examples	Exam Boundary
Establish context	Hostname, user, groups, network interfaces	Document before changing anything
Identify sensitive access	Config files, keys, DB connections, shares	Collect minimum proof
Privilege escalation	Local misconfigurations, credential reuse	Stay within ROE
Lateral movement	SMB, WinRM, SSH, RDP, cloud roles	Confirm target is in scope
Pivoting	SOCKS proxy, SSH tunnel, port forward	Avoid unauthorized third-party routing
Persistence	Scheduled task, service, startup item	Only if explicitly permitted
Cleanup	Remove tools, accounts, payloads, logs as agreed	Do not destroy audit evidence unless instructed

Notes and examples

Exploitation fundamentals

Exploitation is not about “running the biggest exploit.” It is about safely proving business impact within the engagement rules.

Exploitation decision rules

Question pattern	Best answer pattern
Need to prove impact safely	Use minimal proof-of-concept evidence
Exploit may crash service	Avoid unless explicitly authorized; choose safer validation
Need shell access	Confirm payload architecture, egress path, listener, AV/EDR considerations, authorization
Need credentials	Prefer scoped password testing rules; avoid account lockouts
Need lateral movement	Confirm segmentation, trust relationships, and allowed targets
Need persistence	Only if explicitly authorized and documented
Need data proof	Capture limited, relevant evidence; protect sensitive data

Bind shell vs. reverse shell

Shell type	How it works	Common issue
Bind shell	Target listens; tester connects to target	Blocked by inbound firewall rules
Reverse shell	Target connects back to tester	Requires outbound path from target to tester
Web shell	Command execution through web-accessible script	Easy to leave behind; cleanup is critical

Encoding, hashing, and encryption

Concept	Purpose	Reversible?
Encoding	Format data for transport or storage, such as Base64 or URL encoding	Yes
Hashing	One-way digest for integrity or password storage	No, but weak passwords can be cracked by guessing
Encryption	Protect confidentiality with a key	Yes, with the correct key
Obfuscation	Make code or data harder to read	Usually yes

A frequent exam trap is treating Base64 as encryption. Base64 is encoding.

Pivoting and Tunneling Patterns

Need	Pattern	Example Use
Reach internal service through compromised host	Local port forward	Access internal web admin from tester machine
Expose tester service to target	Reverse port forward	Receive callback from isolated network
Route multiple tools through foothold	SOCKS proxy	Proxychains with browser/scanner
Transfer files safely	SCP/SFTP/HTTPS	Move approved tooling or evidence
Avoid file transfer	Living-off-the-land commands	Use native shell commands when allowed

## SSH local port forward: tester connects to localhost:8080 to reach internal target:80
ssh -L 8080:internal.target:80 user@pivot-host

## SSH dynamic SOCKS proxy
ssh -D 9050 user@pivot-host

Cloud Penetration Testing Reference

Area	What to Check	Common Findings
Identity and access	Users, roles, groups, service principals, policies	Overprivileged roles, stale keys, weak separation
Storage	Buckets/blobs/shares, ACLs, public access settings	Public data exposure, weak encryption settings
Network exposure	Security groups, firewalls, load balancers, public IPs	Exposed admin ports, overly broad ingress
Compute	VM metadata, instance roles, startup scripts	Credential exposure, lateral movement via role
Serverless	Function permissions, triggers, environment variables	Secrets in env vars, broad execution roles
Containers	Registries, image vulnerabilities, cluster RBAC	Privileged containers, exposed dashboards
Logging	Audit logs, flow logs, alerting	Missing detection or retention gaps
Secrets	Key vaults, secret managers, CI/CD variables	Hardcoded or broadly accessible secrets

Notes and examples

Cloud-Specific Exam Traps

Trap	Correct Thinking
Treating cloud like only virtual machines	Include IAM, managed services, metadata, storage, and APIs
Testing a cloud tenant without provider/client approval	Confirm scope, authorization, and acceptable use constraints
Reporting public bucket only as “misconfiguration”	Explain data exposure and access path
Ignoring temporary credentials	Session tokens and instance role credentials matter
Assuming encryption solves access control	Encryption does not fix public or excessive permissions
Using destructive tests against managed services	Prefer read-only validation unless explicitly approved

Container and Kubernetes Reference

Component	What to Review	Risk
Image	Base image, packages, secrets, build history	Vulnerabilities, embedded credentials
Dockerfile	User, permissions, exposed ports	Running as root, excessive capabilities
Runtime	Privileged mode, host mounts, socket mounts	Host compromise path
Registry	Public/private access, signing, scanning	Unauthorized image pull/push
Kubernetes API	Authentication, network exposure	Cluster takeover
RBAC	ServiceAccount permissions, role bindings	Excessive pod/secret access
Secrets	Kubernetes Secrets, env vars, mounted files	Credential disclosure
Network policies	Pod-to-pod restrictions	Flat internal network
Admission controls	Policy enforcement	Unsafe workloads allowed
Etcd	Access and encryption	Cluster secret exposure

## Kubernetes context awareness
kubectl config current-context
kubectl auth can-i --list

## Check pods and service accounts in a namespace
kubectl get pods -n <namespace>
kubectl get serviceaccounts -n <namespace>

Notes and examples

Cloud, container, and Kubernetes review

Cloud questions usually test identity, permissions, exposed services, metadata, storage, logging, and boundaries.

Cloud testing concepts

Area	What to review
IAM	Overly permissive roles, privilege escalation paths, unused keys, weak separation of duties
Storage	Public buckets, overly broad ACLs, sensitive files, versioned data
Metadata service	Instance role credentials exposed through SSRF or local access
Network security	Security groups, firewall rules, public management ports
Secrets	Hardcoded keys in repos, images, environment variables, CI/CD logs
Logging	Cloud audit logs, object access logs, detection coverage
Serverless	Function permissions, event triggers, environment variables
SaaS	Tenant boundaries, delegated admin rights, app integrations

Container and Kubernetes quick table

Component	Risk pattern
Container image	Vulnerable packages, embedded secrets, running as root
Container runtime	Privileged mode, host namespace access, mounted host paths
Docker socket	Mounting the socket can lead to host-level control
Kubernetes RBAC	Excessive permissions, service account token misuse
Secrets	Base64-encoded Kubernetes secrets are not encrypted by default in all configurations
Network policies	Weak pod-to-pod segmentation
Admission controls	Missing guardrails for privileged workloads
CI/CD	Pipeline secrets, artifact poisoning, dependency risks

Cloud trap: do not assume that finding a public cloud asset means it is in scope. Confirm account, tenant, region, and authorization.

Wireless and RF Testing Reference

Topic	Key Concept	Exam Relevance
WPA/WPA2/WPA3	Wi-Fi security protocols	Know handshake capture vs. online attack
PSK cracking	Offline attack against captured handshake	Depends on passphrase strength
Evil twin	Rogue AP impersonates legitimate SSID	Credential capture/social engineering
Deauthentication	Forces clients to reconnect	Disruptive; requires explicit approval
WPS weakness	PIN-based enrollment risk	Can expose network key when vulnerable
Bluetooth	Pairing, discoverability, weak services	Mobile/IoT attack surface
RFID/NFC	Proximity credentials	Cloning/relay considerations
SDR	Software-defined radio	RF signal analysis in approved scope

Mobile, IoT, OT, and ICS Testing Distinctions

Environment	Testing Focus	Extra Caution
Mobile apps	Local storage, API calls, certificate validation, jailbreak/root detection	Device and account authorization
IoT	Default creds, firmware, exposed services, update mechanism	Fragile devices, limited logging
OT/ICS	Protocol exposure, segmentation, vendor access paths	Safety and availability are primary
Embedded firmware	Hardcoded secrets, outdated libraries, debug interfaces	Avoid bricking devices
Medical/industrial systems	Network segmentation and vendor-approved checks	Do not disrupt operations

Exam cue: For OT/ICS, prefer passive discovery, maintenance windows, vendor coordination, and strict scope controls.

Attack	Description	Key Control / Remediation
Phishing	Email lures for credentials/actions	User training, email filtering, MFA, reporting process
Spear phishing	Targeted phishing	Role-based awareness and verification
Vishing	Voice-based manipulation	Call-back verification, help desk scripts
Smishing	SMS phishing	Mobile awareness, link filtering
Pretexting	Fabricated scenario	Identity verification procedures
Tailgating	Following authorized person into facility	Badges, mantraps, challenge culture
USB drop	Malicious removable media	Device control, awareness, endpoint controls
MFA fatigue	Repeated push prompts	Number matching, phishing-resistant MFA, alerting

Notes and examples

Social engineering tests people and processes. It is sensitive and must be explicitly authorized.

Technique	Review focus
Phishing	Pretext, payload safety, tracking, reporting, training outcomes
Vishing	Call scripts, caller ID considerations, consent and recording rules if applicable
Smishing	SMS-based pretexts and link tracking
Physical access	Badging, tailgating, visitor procedures, safety
USB drops	Payload safety, consent, tracking, endpoint response
Impersonation	Pre-approved roles and escalation boundaries

Common trap: selecting a social engineering action when the scenario did not authorize social engineering.

Code Review and Scripting Cues

Common Insecure Code Patterns

Pattern	Risk	Safer Direction
String-concatenated SQL	SQL injection	Parameterized queries
Shell command with user input	Command injection	Avoid shell; validate allowlist
Hardcoded secrets	Credential exposure	Secret manager, environment isolation
Disabled TLS verification	MITM exposure	Validate certificates
Unsafe deserialization	RCE/data tampering	Use safe formats and integrity checks
Weak randomness	Predictable tokens	Cryptographic RNG
Verbose error output	Information disclosure	Generic errors, server-side logging
Client-side authorization only	Access control bypass	Server-side authorization checks

Regex and Search Patterns for Secrets

## Search recursively for likely secrets; tune to reduce false positives
grep -RniE "password|passwd|pwd|secret|token|api[_-]?key|client[_-]?secret" .

## Find private keys
grep -Rni "BEGIN .*PRIVATE KEY" .

Parameterized Query Concept

## Safer concept: parameter binding, not string concatenation
cursor.execute("SELECT * FROM users WHERE email = ?", (email,))

Cryptography and Hashing Distinctions

Concept	Purpose	Pentest Relevance
Encoding	Data representation	Base64 is not encryption
Hashing	One-way integrity representation	Password hashes can be cracked offline
Salting	Unique value added before hashing	Defeats rainbow table reuse
Key stretching	Slows password cracking	bcrypt/scrypt/Argon2-style concepts
Symmetric encryption	Same key encrypts/decrypts	Key protection is critical
Asymmetric encryption	Public/private key pair	Used in TLS, SSH, signatures
Digital signature	Integrity and authenticity	Validates origin and tampering
Certificate	Binds identity to public key	Expired/mismatched/untrusted certs are findings
HMAC	Keyed integrity check	Prevents tampering when key is secret

Vulnerability Severity and Risk Rating

Risk is commonly based on likelihood and impact, not scanner output alone.

\[ \text{Risk} = \text{Likelihood} \times \text{Impact} \]

Factor	Raises Likelihood	Raises Impact
Exposure	Internet-facing, no auth, known exploit	Public access to sensitive function
Complexity	Simple exploit, reliable payload	No user interaction needed
Privileges	No credentials required	Admin/root/domain impact
Data	Easy discovery	Regulated, financial, credential, or sensitive business data
Compensating controls	Missing logging, weak segmentation	No containment or monitoring
Exploit maturity	Public exploit available	Wormable or repeatable at scale

Reporting Cheat Sheet

Report Structure

Section	Audience	Include
Executive summary	Business and leadership	Overall posture, major risks, business impact
Scope and methodology	Technical and management	Systems tested, dates, constraints, approach
Findings summary	Both	Severity list, affected assets, status
Technical findings	Technical owners	Evidence, steps, affected components, root cause
Risk analysis	Both	Likelihood, impact, exploitability, compensating controls
Remediation	System owners	Specific fixes, priority, validation guidance
Appendix	Technical readers	Tool output, payloads, logs, references, artifacts
Cleanup/retest notes	Project stakeholders	Artifacts removed, retest results, residual risk

Notes and examples

Finding Template

Field	What Good Looks Like
Title	Clear vulnerability and affected component
Severity	Justified by likelihood and impact
Description	What is wrong, not just scanner text
Affected assets	Hostnames, IPs, URLs, accounts, endpoints
Evidence	Minimal, redacted proof with timestamps
Reproduction steps	Repeatable steps within scope
Impact	Business and technical consequence
Root cause	Missing patch, weak config, design flaw, process gap
Remediation	Actionable fix, not vague advice
Validation	How to confirm the fix worked

Evidence Handling Checklist

Record command, target, timestamp, user/context, and result.
Redact secrets, tokens, customer data, and personal data where possible.
Preserve original logs or tool output when required by the engagement.
Avoid collecting more sensitive data than necessary to prove impact.
Use encrypted storage and approved transfer channels.
Track cleanup items: payloads, accounts, files, scheduled tasks, keys.

Reporting and communication

A professional penetration test is only useful if the findings are clear, accurate, and actionable.

Report structure

Section	Purpose
Executive summary	Business-level risk, major themes, overall impact
Scope and objectives	What was tested and what was excluded
Methodology	High-level approach and constraints
Findings	Vulnerability details, evidence, impact, likelihood, affected assets
Risk ratings	Consistent severity reasoning
Remediation	Specific, practical fixes
Retest guidance	How to verify fixes
Appendices	Tool output, detailed evidence, technical notes

Executive vs. technical communication

Audience	Emphasize
Executives	Business impact, risk themes, priorities, remediation roadmap
IT operations	Affected systems, configuration changes, patching, detection
Developers	Root cause, vulnerable parameters, secure coding fixes
Security team	Attack path, evidence, detection opportunities, control gaps
Legal/compliance	Scope, authorization, data handling, evidence preservation

Finding quality checklist

A strong finding includes:

Clear title
Affected asset or application area
Severity and rationale
Reproduction steps appropriate for the report audience
Evidence, such as screenshots or sanitized output
Business and technical impact
Root cause where known
Practical remediation
References or validation guidance if appropriate
Retest recommendation

Avoid dumping raw scanner output as the report. Scanner output can support a finding, but it is not a complete finding.

Remediation Mapping

Finding Type	Strong Remediation
SQL injection	Parameterized queries, input validation, least-privileged DB account
XSS	Output encoding, context-aware escaping, CSP as defense-in-depth
IDOR/BOLA	Server-side object authorization checks
Weak passwords	Strong policy, breached password screening, MFA, lockout/rate limiting
Exposed admin service	Restrict by VPN/bastion/allowlist, enforce MFA, monitor access
Missing patches	Patch management process and compensating controls
Public storage	Remove public access, least privilege, monitor access, classify data
Hardcoded secrets	Rotate secret, remove from history if needed, use secret manager
Excessive IAM	Least privilege, role separation, periodic access review
Insecure TLS	Disable weak protocols/ciphers, use trusted certificates
SMB relay risk	Require SMB signing, harden NTLM/LDAP, reduce broadcast name resolution
Container running as root	Non-root user, drop capabilities, avoid privileged mode
Kubernetes excessive RBAC	Narrow roles, namespace isolation, service account minimization
Missing logs	Enable audit logs, centralize, alert on high-risk actions

Common Exam Decision Traps

If the Question Says…	Usually Think…
“Before beginning testing”	Authorization, scope, ROE, communication plan
“Least intrusive”	Passive recon, authenticated scan, safe validation
“Production system”	Avoid disruptive payloads; coordinate test window
“Scanner reports critical finding”	Validate before claiming exploitability
“Cloud-hosted target”	Confirm cloud account/provider scope and IAM context
“Third-party service”	Verify permission before testing
“Need business audience”	Executive summary and risk impact, not raw tool output
“Need technical remediation”	Specific configuration/code fix
“Evidence contains sensitive data”	Redact and minimize collection
“Credential discovered”	Rotate/remediate; do not broadly reuse outside scope
“OT/ICS environment”	Safety, availability, passive methods, vendor coordination
“Password attack with lockout risk”	Password spraying carefully or offline cracking if hashes are available
“Need to test authorization”	Use two accounts with different privilege levels
“Need to find hidden web paths”	Content discovery/fuzzing
“Need to intercept and modify requests”	Burp Suite or OWASP ZAP
“Need prove command injection”	Benign command like identity/hostname
“Need identify lateral movement path in AD”	BloodHound-style relationship analysis

Mini Workflow: From Target to Finding

    flowchart TD
	    A[Confirm scope and ROE] --> B[Passive recon]
	    B --> C[Active discovery]
	    C --> D[Enumeration]
	    D --> E[Vulnerability hypothesis]
	    E --> F{Safe to validate?}
	    F -- No --> G[Document risk and request approval/window]
	    F -- Yes --> H[Controlled validation]
	    H --> I{Impact proven?}
	    I -- No --> J[Report as potential or informational if relevant]
	    I -- Yes --> K[Capture minimal evidence]
	    K --> L[Map root cause and remediation]
	    L --> M[Cleanup and report]

Final Review Checklist

Before test day, be able to answer quickly:

Which action comes first: authorization/scope before testing.
Which method is passive vs. active.
Which tool fits the task: Nmap, Burp/ZAP, Hashcat/John, BloodHound, Wireshark, cloud CLI.
How to validate a finding safely without overcollecting data.
How AD attacks differ: Kerberoasting, AS-REP roasting, pass-the-hash, relay, DCSync.
How web flaws differ: SQLi, XSS, CSRF, SSRF, IDOR/BOLA, upload, traversal, deserialization.
How cloud findings differ from traditional network findings: IAM, storage, metadata, managed services.
How to write a report finding with impact, evidence, and remediation.
How to choose least disruptive testing in production, OT/ICS, and cloud scenarios.

For your next step, move from review to timed practice: answer scenario-based PT0-003 questions, then explain why each wrong option is unsafe, out of scope, too disruptive, or the wrong tool for the objective.

High-yield exam mindset

For PT0-003, think like a professional tester, not just an attacker.

If the question is about…	The best answer usually emphasizes…
Starting work	Written authorization, scope, rules of engagement, contacts, timing
Unexpected access	Stop, preserve evidence, notify according to escalation procedures
Production systems	Avoid unnecessary disruption; validate safely
Vulnerability findings	Evidence, impact, likelihood, remediation, reproducibility
Exploit selection	Authorized, scoped, proportional, and aligned to objectives
Tool output	Confirm false positives; do not trust a scanner blindly
Reporting	Audience-appropriate communication and actionable remediation
Credentials	Secure handling, minimal exposure, cleanup, and documentation
Cloud or SaaS	Shared responsibility, IAM permissions, logs, and tenant boundaries
OT/ICS or fragile systems	Safety, availability, and explicit permission before active testing

A common candidate mistake is choosing the most technically aggressive option when the best professional answer is to verify authorization, reduce risk, or communicate with the client.

Penetration testing lifecycle at a glance

Phase	What you should remember	Common exam traps
Pre-engagement	Scope, objectives, statement of work, authorization, ROE, timelines, communication plan	Starting scans before authorization
Reconnaissance	Passive and active information gathering	Confusing passive OSINT with active probing
Enumeration	Identify hosts, services, users, shares, technologies, trust paths	Treating open ports as confirmed vulnerabilities
Vulnerability analysis	Correlate findings, validate risk, remove false positives	Ranking solely by scanner severity
Exploitation	Prove impact safely and within scope	Exploiting out-of-scope assets or causing denial of service
Post-exploitation	Privilege escalation, lateral movement, data access validation, persistence only if authorized	Collecting excessive sensitive data
Cleanup	Remove test artifacts, accounts, shells, payloads, temporary files	Leaving tools or credentials behind
Reporting	Executive summary, technical findings, evidence, risk, remediation, retest guidance	Writing only a tool-output dump

Reconnaissance and enumeration

Reconnaissance identifies the attack surface. Enumeration turns discovered systems and services into useful test targets.

Passive vs. active reconnaissance

Type	Examples	Risk profile
Passive reconnaissance	Public websites, search engines, certificate transparency, WHOIS/RDAP, social media, job postings, breach data, code repositories	Lower chance of interacting directly with target systems
Active reconnaissance	DNS queries, port scans, web crawling, banner grabbing, directory brute forcing, service enumeration	Direct interaction with target systems; must follow ROE

Notes and examples

High-yield recon targets

Target	What to look for
DNS	Subdomains, MX records, TXT records, SPF/DMARC/DKIM, zone transfer exposure
Certificates	Subject alternative names revealing hidden hosts
Web apps	Frameworks, login portals, APIs, admin panels, robots.txt, sitemap.xml
Source repositories	Secrets, tokens, API keys, credentials, internal hostnames
Cloud storage	Public buckets, exposed files, permissive access policies
Email infrastructure	Phishing targets, SPF/DMARC gaps, exposed mail services
Job postings	Technology stack, cloud platforms, security tools
Breach data	Reused passwords, username formats, leaked credentials

Common service and port review

Port / service	What to consider during authorized testing
21 FTP	Anonymous login, cleartext credentials, writable directories
22 SSH	Version, weak credentials, exposed keys, password authentication
23 Telnet	Cleartext remote access, default credentials
25 SMTP	Open relay, user enumeration, spoofing controls
53 DNS	Zone transfer, subdomain enumeration, misconfigured records
80 / 443 HTTP(S)	Web app vulnerabilities, headers, TLS configuration, exposed admin panels
110 / 143 / 993 / 995 Mail	Cleartext protocols, weak authentication, exposed mailboxes
135 / 139 / 445 SMB/RPC	Shares, signing, null sessions, outdated Windows services
161 SNMP	Default community strings, information disclosure
389 / 636 LDAP	Anonymous bind, directory enumeration, AD information leakage
1433 MSSQL	Weak credentials, excessive privileges, xp_cmdshell exposure
3306 MySQL	Weak credentials, exposed databases
3389 RDP	Internet exposure, weak credentials, NLA configuration
5900 VNC	Weak or no authentication
6379 Redis	Unauthenticated access, data exposure, possible code execution paths
8080 / 8443	Alternate web services, admin consoles, proxy interfaces

Tool-output interpretation traps

Observation	Do not assume	Better next step
Open port	Vulnerability exists	Enumerate service/version and configuration
Scanner says “critical”	Exploitability is confirmed	Validate manually or with safe proof
HTTP 403	No access path exists	Check alternate methods, headers, paths, auth context
HTTP 500	Exploit confirmed	Determine input and reproducibility
Old banner	System is vulnerable	Confirm patch/backport status
No ping response	Host is down	Try permitted TCP/UDP discovery methods

Vulnerability analysis and prioritization

A penetration tester should prioritize based on risk, not just scanner output. Risk combines exploitability, business impact, asset criticality, exposure, and compensating controls.

Prioritization quick table

Factor	Higher-risk signal
Exposure	Internet-facing, unauthenticated, broadly reachable
Exploitability	Public exploit, low complexity, reliable exploit path
Privilege required	No credentials or low-privilege access required
Impact	Remote code execution, sensitive data access, privilege escalation
Asset value	Domain controller, payment system, customer database, production API
Evidence	Reproducible proof, confirmed access, meaningful data exposure
Compensating controls	Weak or absent monitoring, segmentation, MFA, patching

Notes and examples

Scanner findings: how to think

Finding type	Review approach
Missing patch	Confirm version, configuration, and exploitability
Weak TLS	Determine actual risk based on supported protocols/ciphers and exposure
Default credentials	Attempt only within ROE; document successful authentication
SQL injection	Validate with safe payloads before using automated exploitation
XSS	Prove execution context and impact, not just reflected input
Open storage bucket	Verify permissions and exposure without over-collecting data

Password attacks and credential testing

Credential attacks must follow the rules of engagement because they can lock accounts, trigger alerts, or expose sensitive data.

Password attack types

Attack	Description	Key risk
Password spraying	Few common passwords across many users	Account lockout if not rate-limited properly
Brute force	Many guesses against one or more accounts	Noisy; often prohibited or tightly limited
Dictionary attack	Wordlist-based guessing	Depends heavily on password policy and user behavior
Credential stuffing	Testing known breached credentials	Legal/ethical and scope concerns; must be authorized
Offline cracking	Cracking captured hashes outside live system	Safer for lockouts; still requires secure hash handling
Pass-the-hash	Use NTLM hash without knowing plaintext password	Requires compatible environment and captured hash
Pass-the-ticket	Use Kerberos ticket to authenticate	Requires ticket material and Kerberos context

Notes and examples

Hash-cracking review

Concept	Why it matters
Salt	Makes identical passwords produce different hashes
Slow hash	Increases cracking cost, such as bcrypt/scrypt/Argon2-style approaches
Fast hash	Easier to crack at scale if passwords are weak
Rules/masks	Efficiently mutate wordlists based on likely patterns
Rainbow tables	Precomputed hashes; less useful against proper salting

Do not confuse password cracking with decryption. Hashes are not decrypted; candidates are guessed and hashed for comparison.

Active Directory and Windows environment review

Active Directory questions often test enumeration, privilege paths, credential exposure, and lateral movement.

AD attack concepts

Concept	What to remember
Kerberoasting	Request service tickets for SPNs and crack them offline if service account passwords are weak
AS-REP roasting	Targets accounts not requiring Kerberos preauthentication
LLMNR/NBT-NS poisoning	Captures authentication attempts on local networks when name resolution falls back insecurely
NTLM relay	Relays captured authentication to another service when protections such as signing/channel binding are absent
Pass-the-hash	Authenticates using NTLM hash rather than plaintext password
Pass-the-ticket	Uses Kerberos ticket material for access
Unconstrained or constrained delegation abuse	Misconfigured delegation can allow privilege escalation
ACL abuse	Over-permissive object rights can allow password reset, group membership changes, or replication rights
DCSync-style risk	Directory replication rights can expose credential material
Local admin reuse	Same local admin credentials across hosts enable lateral movement

Notes and examples

AD enumeration focus

Area	What to enumerate
Users and groups	Privileged groups, service accounts, stale accounts
Computers	Workstations, servers, domain controllers
Shares	Sensitive files, scripts, backups, passwords
Group Policy	Login scripts, local admin settings, security configuration
SPNs	Kerberoastable service accounts
Trusts	Cross-domain or forest relationships
Sessions	Where privileged users are logged in
ACLs	Misconfigured permissions and privilege paths

Windows privilege escalation signals

Unquoted service paths
Weak service permissions
Writable directories in privileged execution paths
Stored credentials
Scheduled tasks running as privileged users
AlwaysInstallElevated-style installer misconfiguration
Insecure registry permissions
Token privileges that enable elevation paths
Missing patches combined with local exploit feasibility

Linux and network service exploitation review

Linux-focused questions may involve permissions, services, sudo rules, cron jobs, web app deployment mistakes, and exposed keys.

Area	High-yield checks
File permissions	World-writable files, sensitive readable files, SUID/SGID binaries
Sudo	Commands allowed without password; command escape paths
Cron	Writable scripts executed by privileged users
SSH	Private keys, authorized_keys misuse, weak permissions
Web services	App config files, database credentials, upload directories
Containers	Mounted Docker socket, privileged containers, host mounts
Environment variables	Secrets or tokens exposed to processes
Logs and backups	Credentials, tokens, database dumps

Candidate trap: finding a local privilege escalation exploit does not mean you should run it. Consider kernel version, stability, scope, and authorization.

Wireless, mobile, IoT, and OT review

Wireless testing

Topic	What to know
WPA/WPA2 personal	Capture handshake and attempt offline cracking if authorized
WPS	PIN weaknesses can expose wireless access
Evil twin	Rogue AP impersonates legitimate network
Deauthentication	Often disruptive; requires explicit authorization
WPA Enterprise	EAP configuration, certificate validation, credential capture risk
Guest networks	Segmentation from internal resources

Notes and examples

Mobile testing

Area	Common weakness
Local storage	Tokens, credentials, or PII stored insecurely
Transport security	Weak TLS validation or certificate pinning issues
API authorization	Mobile APIs vulnerable to IDOR/BOLA
Hardcoded secrets	API keys or credentials embedded in app package
Logging	Sensitive data written to logs
Platform permissions	Excessive app permissions

IoT and OT considerations

Environment	Testing priority
IoT	Default credentials, insecure firmware, exposed services, weak update mechanisms
OT/ICS	Safety and availability, vendor constraints, passive analysis, explicit approvals
Embedded devices	Debug interfaces, hardcoded credentials, outdated libraries
Medical/industrial systems	Avoid disruptive testing unless specifically authorized and controlled

For OT and safety-critical systems, the exam answer often favors caution, passive techniques, coordination, and strict adherence to the engagement plan.

Scripting and automation

PT0-003 candidates should be comfortable reading and reasoning about simple automation. You may need to understand what a script does, identify a bug, parse output, or select the right logic.

Scripting concepts to review

Concept	Why it matters
Variables	Store hostnames, ports, tokens, paths, counters
Conditionals	Branch based on status codes, strings, or errors
Loops	Iterate through hosts, users, URLs, or files
Functions	Reuse logic and reduce errors
Input validation	Avoid unsafe command construction
Error handling	Continue safely or fail clearly
File handling	Read wordlists, write logs, parse results
JSON/YAML/CSV parsing	Common for API results and tool output
Regular expressions	Extract IPs, emails, URLs, tokens, or hashes
APIs	Authenticate, send requests, handle responses
Exit codes	Determine whether commands succeeded

Notes and examples

Automation traps

Unsafe string concatenation can create command injection.
Hardcoded credentials should not be embedded in scripts.
Scripts should respect rate limits and ROE.
Output should not expose secrets unnecessarily.
Error handling matters during long scans or batch testing.
A script that “works” may still be unsafe for production systems.

Common PT0-003 candidate mistakes

Mistake	Better exam habit
Choosing exploitation before authorization	Verify scope and ROE first
Treating every scanner alert as true	Validate and prioritize
Ignoring business impact	Tie findings to risk and affected assets
Over-collecting sensitive data	Capture minimal proof and protect evidence
Confusing authentication and authorization	Test role and object-level access
Confusing encoding with encryption	Base64 is not encryption
Ignoring cleanup	Remove artifacts and document cleanup
Assuming cloud assets are in scope	Confirm account, tenant, and written scope
Using disruptive tests casually	Confirm explicit authorization
Reporting only technical details	Match detail to audience

Fast decision table for scenario questions

Scenario clue	Likely best answer
“Before beginning testing…”	Obtain written authorization and confirm ROE
“Out-of-scope host discovered…”	Do not test; report through approved channel
“Production service becomes unstable…”	Stop or throttle testing and notify contact
“Scanner reports critical vulnerability…”	Validate safely and document evidence
“Need to avoid account lockouts…”	Use approved password spraying limits or offline cracking
“Need to prove SQL injection…”	Use safe payloads; avoid dumping entire database
“Found credentials in repository…”	Protect evidence, validate only if scoped, recommend secret rotation
“Need to test fragile OT system…”	Prefer passive methods and explicit coordination
“Executive audience…”	Summarize business risk and remediation priorities
“Developer audience…”	Explain root cause and code/configuration remediation

Put the review into practice

Study Plan

PT0-003 — CompTIA PenTest+ V3 Cheat Sheet

Penetration Test Lifecycle Reference

Rules of Engagement and Scope Checklist

Planning, scope, and rules of engagement

Core pre-engagement artifacts

Decision rules

Common traps

Passive vs. Active Reconnaissance

Fast Tool Selection Matrix

Nmap and Network Scanning Cheat Sheet

Common Nmap Patterns

Scan Decision Points

High-Yield Ports and Services

Vulnerability Validation Logic

Web Application Testing Reference

Web Vulnerability Matrix

HTTP Status Codes Worth Knowing

Useful Web Testing Commands

Web application and API Cheat Sheet

Common web vulnerabilities

HTTP status codes worth recognizing

API-specific traps

API Testing Cheat Sheet

Authentication and Password Attack Reference

Active Directory Attack Path Reference

AD Defensive Control Distinctions

Linux and Windows Privilege Escalation Checklist

Linux

Windows

Exploitation Safety Decision Table

Post-Exploitation Reference

Exploitation fundamentals

Exploitation decision rules

Bind shell vs. reverse shell

Encoding, hashing, and encryption

Pivoting and Tunneling Patterns

Cloud Penetration Testing Reference

Cloud-Specific Exam Traps

Container and Kubernetes Reference

Cloud, container, and Kubernetes review

Cloud testing concepts

Container and Kubernetes quick table

Wireless and RF Testing Reference

Mobile, IoT, OT, and ICS Testing Distinctions

Social Engineering Reference

Social engineering review

Code Review and Scripting Cues

Common Insecure Code Patterns

Regex and Search Patterns for Secrets

Parameterized Query Concept

Cryptography and Hashing Distinctions

Vulnerability Severity and Risk Rating

Reporting Cheat Sheet

Report Structure

Finding Template

Evidence Handling Checklist

Reporting and communication

Report structure

Executive vs. technical communication

Finding quality checklist

Remediation Mapping

Common Exam Decision Traps

Mini Workflow: From Target to Finding

Final Review Checklist

High-yield exam mindset

Penetration testing lifecycle at a glance

Reconnaissance and enumeration

Passive vs. active reconnaissance

High-yield recon targets

Common service and port review

Tool-output interpretation traps

Vulnerability analysis and prioritization

Prioritization quick table

Scanner findings: how to think

Password attacks and credential testing

Password attack types

Hash-cracking review

Active Directory and Windows environment review

AD attack concepts

AD enumeration focus