Pentesting Fundamentals

knowledge

Overview

Penetration testing is an ethically authorized security assessment that simulates real-world attacks to evaluate the effectiveness of an organization’s defenses. Using the same tools, techniques, and methodologies as malicious actors, pentesters conduct controlled and authorized audits of systems, applications, and networks. All testing must be explicitly approved and scoped — unauthorized testing is illegal regardless of intent.

Terminology

Term	Definition
Penetration Test	Authorized attempt to identify and exploit vulnerabilities in systems
ROE (Rules of Engagement)	Formal document defining how a test is conducted, what is in scope, and what is permitted
Scope	Defined targets, limitations, and allowed actions for the engagement
Authorization	Explicit approval from the system owner before any testing begins
Privilege Escalation	Expanding access after initial compromise — horizontally (same level) or vertically (higher level)
Post-Exploitation	Actions taken after gaining access — pivoting, data collection, persistence, cleanup
OSINT	Open Source Intelligence; publicly available information gathered during reconnaissance
Black-Box	Testing with no prior knowledge of the target system
Grey-Box	Testing with partial knowledge of system internals
White-Box	Testing with full knowledge of system internals, code, and architecture
SOW	Statement of Work; project-specific legal agreement defining scope, deliverables, and timeline for a single engagement
MSA	Master Services Agreement; broader ongoing legal agreement used when a recurring pentesting relationship exists
Vulnerability Assessment	Automated scan to identify and categorize known vulnerabilities — does not include active exploitation
PTES	Penetration Testing Execution Standard; a widely referenced methodology defining the full lifecycle of an engagement

Core Concepts

Penetration Testing Ethics

Pentesting is a legally sanctioned audit — not unauthorized hacking.

Requires formal written agreement between tester and organization
Provides legal protection and clearly defined boundaries
All activity must stay within agreed scope — do not exploit vulnerabilities not covered by the ROE
Confidentiality of all findings and any sensitive data accessed is mandatory
Only collect data required by the test scope; securely destroy it after the engagement
Comprehensive documentation is essential — record timestamps, methodologies, tools used, and findings
When social engineering is in scope, do not cause lasting psychological harm or damage workplace morale

Rules of Engagement (ROE)

Section	Description
Permission	Explicit authorization for testing
Scope	Defines targets — systems, applications, networks
Rules	Specifies allowed and prohibited techniques

Hacker Classifications

Type	Description	Example
White Hat	Ethical and lawful	Authorized penetration tester
Grey Hat	Ethical intent but may violate laws	Taking down a scam site without permission
Black Hat	Malicious and illegal	Ransomware operators

Penetration Testing vs. Vulnerability Assessment

Both are security assessment tools and should be used together — they serve different purposes.

Aspect	Vulnerability Assessment	Penetration Testing
Purpose	Detect and catalog known vulnerabilities	Actively exploit vulnerabilities to validate real-world impact
Method	Automated scanning using signatures	Manual and automated exploitation techniques
Depth	Broad surface scan	Deep exploitation with chained vulnerabilities
Frequency	Monthly or quarterly	Annual, or after major system changes
Output	List of potential vulnerabilities	Exploited findings, attack paths, and validated risk

Vulnerability assessments identify what may be vulnerable; penetration tests prove what is actually exploitable. Regular assessments provide ongoing coverage; annual pentests provide impact validation.

Penetration Testing Methodology

A structured, sequential approach followed during every engagement:

Phase	Description
Pre-Engagement	Establish legal agreements (SOW/MSA), define scope, sign NDA, draft ROE, confirm authorization
Information Gathering	Passive recon (OSINT, public records — no trace left) and active recon (port scanning, service enumeration — direct interaction with target)
Enumeration / Scanning	Identify services, applications, open ports, and potential entry points in depth
Vulnerability Assessment	Analyze gathered data, eliminate false positives, prioritize what to attempt and how
Exploitation	Leverage vulnerabilities to gain access — multiple vulnerabilities can be chained for deeper penetration
Post-Exploitation	Privilege escalation, lateral movement, data exfiltration — assess the full impact of access
Proof of Concept	Document and reproduce all exploitation paths with reliable, evidence-backed steps
Reporting	Deliver a well-written report including findings, evidence, reproduction steps, and remediation guidance
Remediation Support	Answer client questions, guide remediation efforts, and optionally retest fixed vulnerabilities

Types of Testing

Type	Knowledge Level	Use Case
Black-Box	None	Simulates external attacker; heavy recon focus
Grey-Box	Partial	Balanced approach; most common in real engagements
White-Box	Full	Focuses on logic, code, and internal behavior; most time-intensive

Tests are also classified by access perspective:

External Testing — targets publicly accessible systems and internet-facing infrastructure
Internal Testing — simulates an insider threat or compromised internal user; targets resources only reachable within the network

Pre-Engagement Prerequisites

All prerequisites must be confirmed before any testing activity begins.

Legal Documentation

Document	Purpose
SOW (Statement of Work)	Project-specific agreement defining scope, deliverables, and timeline
MSA (Master Services Agreement)	Broader ongoing agreement for recurring pentesting relationships
NDA (Non-Disclosure Agreement)	Protects confidentiality of all findings and organizational information
ROE (Rules of Engagement)	Authorizes specific activities and defines permitted and prohibited techniques

Scope and Technical Setup

Document all systems and assets approved for testing: IP ranges, domain names, applications
Define authorized testing windows (business hours vs off-hours)
Identify sensitive systems requiring special consideration (PII data, critical infrastructure)
Confirm the organization has current backups of all in-scope systems
Establish emergency contacts and incident response procedures in case something goes wrong
Understand the client’s expected reporting format and level of technical detail
Ensure professional liability insurance is in place

Testing Environment Preparation

Use a clean virtual machine for every engagement. This prevents cross-contamination between engagements, contains any payloads or malware encountered during testing, and keeps files, logs, results, and screenshots organized per-engagement. Maintain a base VM snapshot with commonly used tools installed — or write a setup script to reinstall the toolset quickly on a fresh VM.

Required Skills

Skill Area	Description
Networking and Protocols	TCP/IP, DNS, HTTP/HTTPS, packet analysis, port scanning
Operating Systems	Linux and Windows internals, Active Directory, file systems
Web Technologies	HTML, JavaScript, HTTP flows, web application architecture
Vulnerability Knowledge	Understanding how common vulnerabilities work and what to look for
Scripting	At least one scripting language (Python most common) for automation and custom tooling
Tool Proficiency	Nmap, Metasploit, Burp Suite — and the ability to research unfamiliar tools quickly
Documentation	Efficient, accurate recording of findings with timestamps and reproduction steps
Communication	Clear reporting to both technical and non-technical stakeholders
Mindset	Creative problem-solving, patience, thinking outside the box, and continuous learning

Compliance Requirements

Many regulatory frameworks mandate regular penetration testing for organizations in specific sectors. Failure to comply can result in significant financial penalties.

United States

Standard	Requirement
PCI DSS	Annual penetration testing required for all organizations processing card payments
HIPAA	Indirectly requires pentesting through mandatory risk assessment stipulations for healthcare entities
SOC 2	Encourages pentesting to validate effectiveness of implemented security controls
GLBA (FTC Rules)	Requires financial institutions to conduct annual penetration testing

International

Region / Standard	Requirement
EU — GDPR	Requires regular testing of security measures; pentesting typically included for compliance
EU — NIS Directive	Implies pentesting for managing security risks of critical infrastructure operators
UK — Data Protection Act 2018	Aligns with GDPR; suggests pentesting for security measure validation
UK — DSP Toolkit	Healthcare sector; recommends pentesting for data security standards compliance
India — RBI-ISMS	Requires banks and financial institutions to perform regular penetration testing
Brazil — LGPD	Implies pentesting to ensure security of personal data

Compliance Testing Approach

Step	Description
Scoping	Define testing boundaries aligned to the specific regulatory requirements
Documentation	Maintain comprehensive records — timestamps, tools, methodologies, findings
Risk Assessment	Evaluate discovered vulnerabilities against applicable compliance controls
Remediation	Organizations implement fixes; pentesters may verify remediation was effective

Compliance Report Structure

Executive Summary — high-level findings addressing compliance requirements and potential regulatory impact
Detailed Findings — technical details of each vulnerability and its relationship to specific compliance controls
Remediation Guidance — clear, actionable recommendations that maintain compliance while addressing the issue
Attestation — formal certification confirming testing was conducted according to required standards

Documentation & Evidence Collection

Thorough documentation during the engagement is what makes the final report credible and reproducible.

Record every command executed — exact syntax, target, timestamp, and output
Screenshot and log all findings, including error messages and dead ends
For each finding, capture: what was found, why it was significant, what prompted further investigation
Store all evidence securely — findings are sensitive and must not be accessible to unauthorized parties
Include tool names and versions used at each stage

Reporting and Remediation

Effective pentesting output goes beyond listing vulnerabilities.

Tailor findings to the organization — connect technical vulnerabilities to business risk and operational impact
Prioritize by severity and business impact; use CVSS scoring as a baseline
Provide both short-term (quick patches, configuration changes) and long-term (architectural) remediation
Include specific actionable guidance: exact patch versions, configuration change details, affected code locations
Retest fixed vulnerabilities when scope allows — use phased verification for large-scale remediation

Proof of Concept (PoC) Report

The PoC is a technical document — step-by-step reproduction of exploitation paths with commands, screenshots, and results. Structured by engagement stage:

Stage	Content
Information Gathering	Discovered hosts, services, versions, OSINT findings
Vulnerability Assessment	Identified vulnerabilities, CVE references
Exploitation	Exact steps and commands used to gain access
Local Information Gathering	Post-access enumeration output
Local Vulnerability Assessment	Privilege escalation vectors identified
Post-Exploitation	Privilege escalation steps and evidence
Privileged Information Gathering	What was accessible after escalation
Privileged Vulnerability Assessment	Additional vectors accessible only at higher privilege

Documentation Report

The documentation report is the deliverable for management — broader in scope and less technical than the PoC. The PoC is typically included as an appendix.

Section	Content
Statement of Confidentiality	Legal handling and confidentiality requirements for the report
Engagement Contacts	All parties involved: tester, client contacts, emergency contacts
Executive Summary	High-level findings in plain language — business risk focus
Assignment	Overview of what was tested and why
Scope	Exact systems, IP ranges, and applications in scope
Deliverables	What was produced and delivered
Assessment Summary	Overview of methodology and phases
Compromise Walkthrough	Narrative of the attack path from initial access to objective
Remediation Summary	Prioritized list of recommended fixes

A report template is available at: HTB Documentation Reference.docx

Red Team Engagements

Red team operations go beyond standard penetration tests — they simulate a real-world adversary targeting the entire organization over a longer timeframe, testing not just technical controls but also people and processes.

Aspect	Description
Duration	Weeks to months — longer than standard pentests
Scope	Broad — may include technical systems, physical access, and social engineering
Goal	Identify weaknesses that routine assessments miss; test detection and response capabilities
Output	Full writeup of attack path, findings, and recommendations for security and training improvements

Purple Team

Purple team exercises bring red and blue teams together to collaborate rather than operate in isolation. Red team shares attack techniques; blue team shares detection capabilities — both sides improve through joint exercises and shared knowledge.

Benefits:

Faster feedback loop between offense and defense
Enhanced incident response procedures based on real attack simulations
More efficient security improvement than separate red/blue operations alone

Bug Bounty Programs

Bug bounty programs allow independent security researchers to find and report vulnerabilities in exchange for recognition and financial compensation.

Aspect	Description
Scope	Defines which systems, applications, and behaviors are in scope
Rules of Engagement	Permitted techniques and responsible disclosure requirements
Reward Structure	Tiered payouts based on severity — critical findings earn the most
Participants	Independent researchers, freelancers, and security professionals

Benefits for organizations: cost-effective coverage, access to diverse skill sets, continuous testing. Benefits for hunters: skill development, financial rewards, public recognition, and contribution to the security community.

Frameworks

Framework	Focus
PTES	Penetration Testing Execution Standard; 7-phase lifecycle covering pre-engagement through reporting
OSSTMM	Comprehensive testing across telecommunications, wired, and wireless networks
OWASP	Web application security testing and Top 10 vulnerability guidance
NIST SP 800-115	Technical guide to information security testing; formal, risk-based approach
MITRE ATT&CK	Comprehensive knowledge base of adversary tactics, techniques, and procedures (TTPs)
NCSC CAF	14 principles covering data security, system security, identity, monitoring, and response

Combine methodologies rather than relying on a single framework — develop a personal approach over time, adapting lessons from each engagement.

References / Images

Rules of Engagement documentation examples
PTES: http://www.pentest-standard.org/index.php/Main_Page
OSSTMM: https://www.isecom.org/OSSTMM.3.pdf
OWASP Testing Guide: https://owasp.org/www-project-web-security-testing-guide
NIST SP 800-115: https://www.nist.gov/privacy-framework/nist-sp-800-115
NIST Cybersecurity Framework: https://www.nist.gov/cyberframework
MITRE ATT&CK: https://attack.mitre.org