🕵️ Penetration Testing Language

Black/white/grey box refers to how much prior knowledge and access testers have — not the network position or authentication state.

Assessment type	Tester knowledge	Pros	Cons
Black-box	Zero — simulates an external attacker with no insider knowledge	Realistic attacker simulation; tests external defences	Time-intensive; may miss internal vulnerabilities
White-box	Full — source code, architecture, credentials, design docs	Maximum coverage; finds logic flaws missed by automated tools	Expensive; doesn't test external-facing defences
Grey-box	Partial — user credentials, API docs, but not source code	Most common real-world engagement; good depth-to-cost ratio	May miss issues only visible with full source access

Pivoting = attacker uses a foothold (the compromised DMZ server) to reach systems that are unreachable directly from the external network.

Term	Meaning
Foothold	Initial access point — the first system compromised in an attack chain
Pivoting	Using the foothold to route attacks to otherwise unreachable internal systems
Lateral movement	Moving between systems at the same privilege level within a network segment
Tunnelling	Encapsulating one protocol inside another to bypass firewalls (e.g., SSH tunnelling, DNS tunnelling)
Privilege escalation	Moving from a lower-privilege account (e.g., www-data) to a higher-privilege one (e.g., root)

Why this matters: Pivoting is why network segmentation is a critical defence. If the DMZ server can directly reach database servers on the internal network, a single compromise unlocks the entire environment.

Rules of Engagement (RoE) and scope of work define what testers can and cannot do — testing outside scope is legally unauthorised access.

RoE element	What it covers
In-scope targets	IP ranges, domains, application URLs, API endpoints that may be tested
Out-of-scope targets	Third-party services, production databases, shared hosting — explicitly excluded
Testing windows	Permitted hours (e.g., off-hours only to avoid disrupting production)
Emergency stop	Contact number to halt testing immediately if unintended impact is detected
Get-out-of-jail letter	Written authorisation the tester carries to show law enforcement if questioned

Key vocabulary: "scope of engagement", "out of scope", "authorisation to test", "rules of engagement", "get-out-of-jail letter".

The Executive Summary is written for C-suite / non-technical stakeholders — not engineers. It communicates business risk, not technical mechanics.

Report section	Audience	Key content
Executive Summary	CISO, CEO, board members	Overall risk rating, key findings in business terms, remediation priorities, business impact
Technical Findings	Security engineers, developers	Vulnerability details, CVSS scores, reproduction steps, screenshots or proof-of-concept
Remediation Guidance	Engineering teams	Specific fix recommendations prioritised by severity and effort

Executive Summary key elements: Overall risk posture (e.g., "the application has 3 Critical, 7 High findings"), the most significant finding and its business impact (e.g., "an unauthenticated attacker could access customer payment data"), and recommended immediate vs. medium-term remediation priorities.

Attack surface reduction = actively remove, disable, or restrict anything not strictly needed. For POODLE: disable SSL 3.0 and enforce TLS 1.2+.

Remediation concept	Meaning	POODLE example
Remediation	Fix the root cause of the vulnerability	Disable SSL 3.0 entirely — root cause removed
Mitigation	Reduce impact without fixing the root cause (temporary control)	WAF rule to block SSL 3.0 requests — root cause still present
Attack surface reduction	Remove unnecessary features, protocols, services, and entry points	Disable SSL 3.0, SSLv2, TLS 1.0, TLS 1.1 — enforce TLS 1.2+ minimum

Key vocabulary:

• Legacy protocol deprecation — formally removing support for old, insecure protocol versions
• Cipher suite hardening — configuring the server to only accept strong cipher suites
• Protocol downgrade attack — POODLE exploits a fallback mechanism where the server agrees to use SSL 3.0 even if TLS is supported
• TLS configuration — the set of protocol versions and cipher suites a server will accept

While demonstrating impact is important, immediately exploiting a vulnerability without proper verification can lead to unintended consequences. Documenting the misconfiguration ensures reproducibility and provides context for remediation. Requesting access through a formal process aligns with security best practices and allows for controlled investigation – it's the least immediate action needed before further steps.

The primary goal of including command-line output is to provide a detailed technical analysis for developers. This allows them to understand *how* the exploit was executed, aiding in recreating the attack and designing effective countermeasures. Demonstrating skill level or complexity isn't the focus; clear technical documentation is key.

Input validation is the core principle David is referencing. It's crucial to prevent malicious data from entering the system and potentially causing harm, such as SQL injection attacks. The other options represent distinct security concepts but aren't directly addressed in this scenario.

Remediation guidance focuses on actionable steps. Prioritizing remediation based on risk (severity and likelihood) is essential for efficient resource allocation. The report should guide the team on how to address vulnerabilities in order of importance – details about tools or systems are not central to this section.

A threat model is a systematic process of identifying potential threats and vulnerabilities. It's about analyzing *what* an attacker might do – in this case, brute-forcing passwords – and considering the likelihood and impact of that attack. The other options represent related concepts but aren't the core definition of a threat model.