Penetration Testing -- Tricks

Trick 1 Rules of Engagement Come BEFORE Any Testing — No Exceptions

The exam frequently tests the sequence of events in a penetration test. The rules of engagement are always established and documented before any testing begins — not after, not during, not "when it becomes relevant."

What the rules of engagement contain (exam checklist):

Type of testing authorized (external, internal, physical, social engineering)
Permitted timing (hours, days of week)
In-scope systems (specific IPs, ranges, domains)
Out-of-scope systems (explicitly excluded)
Emergency contacts (both the testing team and the client)
Sensitive data handling procedures

Out-of-scope trap: A common exam question describes a tester who reaches an out-of-scope system via an in-scope entry point and asks what they should do. The answer is always: stop, document the finding (the path itself is a vulnerability), contact the emergency contact, do not proceed. Reaching an out-of-scope system from an in-scope system does not authorize testing the out-of-scope system.

Rule: Rules of Engagement = Authorization Document. No document = no authorization. Out-of-scope = always off-limits regardless of how you got there.

Trick 2 The Four Phases in Order — Initial, Lateral, Persistence, Pivot

The exam tests the ability to match a described scenario to the correct phase. The phases are not strictly sequential — lateral movement and pivoting can interleave — but knowing the defining characteristic of each phase eliminates wrong answers.

Identifying characteristics for each phase:

Initial exploitation — the first foothold; getting into the network from outside; no prior access existed. Keywords: "first access," "initial foothold," "bypassing perimeter."
Lateral movement — using the foothold to reach additional internal systems on the same accessible network. Keywords: "credential reuse," "pass-the-hash," "moving from system to system," "spreading through internal network."
Persistence — establishing mechanisms that survive patching or session loss. Keywords: "backdoor," "new account," "scheduled task," "startup modification," "continues after patch applied."
The pivot — using a compromised system to reach architecturally isolated systems not directly accessible. Keywords: "unreachable network," "relay," "proxy," "routing through," "bypassing VLAN or firewall separation."

Persistence vs. Lateral Movement confusion: Persistence is about surviving loss of access (backward-looking — maintaining what was gained). Lateral movement is about expanding access (forward-looking — reaching new systems). Creating a backdoor account is persistence; using stolen credentials to log into a new server is lateral movement.

Mnemonic: I Love Persistent Pirates. Initial → Lateral → Persistence → Pivot.

Trick 3 Patching Does NOT Remove Persistence — Remediation Must Hunt All Backdoors

The exam frequently presents a scenario where an organization patches the vulnerability used by an attacker (or pen tester) and asks whether the threat is eliminated. The answer is: not if persistence was established.

Why patching is not enough:

Persistence mechanisms (backdoor accounts, scheduled tasks, web shells, startup scripts, remote access tools) operate independently of the original vulnerability
Closing the door does not remove the spare key someone left behind inside
A well-established persistence mechanism can survive reboots, user password changes, and even re-imaging if the attacker has access to the Active Directory or backup infrastructure

Complete post-breach remediation requires:

Identify and remove all unauthorized accounts
Review and reset all service account credentials
Audit all startup services and scheduled tasks against a known-good baseline
Scan web server directories for web shells
Review network connections for unauthorized outbound callbacks
Only after all persistence is confirmed removed: patch the original vulnerability

Rule: Patch closes one door. Persistence hunt closes all the spare keys. Both are required.

Trick 4 Responsible Disclosure Sequence — Private First, Public Only After the Patch

The exam tests whether candidates understand that public disclosure happens after the patch is available, not before or simultaneously with discovery.

The four-step sequence to memorize in order:

Researcher privately reports — to the vendor, through defined channel; no public disclosure yet
Vendor creates a fix — investigate, develop, test the patch; up to 90 days (industry norm)
Patch deployed — distributed to users; coordinated with major platforms
Public disclosure — vulnerability details + CVE published; simultaneous with patch availability; researcher credited

Wrong answer patterns on the exam:

"Researcher discloses publicly immediately" — wrong; this is full disclosure, not responsible disclosure, and gives attackers a window with no available fix
"Researcher sells the vulnerability" — wrong; this is exploit brokering, not responsible disclosure
"Vendor patches before the researcher is notified" — wrong order; researcher notifies first

Bug bounty adds to, not replaces, responsible disclosure: Bug bounty programs follow the same sequence but add financial compensation. The disclosure process is identical.

Rule: Private → Fix → Deploy → Publish. Never publish before the fix is ready.

Practice Scenarios

Scenario A: A penetration testing engagement specifies testing is permitted only between 8 PM and 4 AM. At 2 AM, the tester discovers that an in-scope web application has a SQL injection vulnerability. She also discovers that the web application's database shares infrastructure with a production billing system that is explicitly out-of-scope. She estimates that demonstrating the SQL injection's impact would require querying tables also used by the billing system. What should she do?

Answer: Stop the current line of testing, document the finding (the SQL injection vulnerability is a valid finding; the shared database infrastructure is also a finding), and contact the emergency contact listed in the rules of engagement. Do not query the billing system tables, even to demonstrate impact — those tables belong to an out-of-scope system. The SQL injection finding can be documented based on what was discovered without accessing out-of-scope data. The client can then decide whether to expand scope to include the billing database for further demonstration, or accept the finding as documented. Testing hours (2 AM) are within the permitted window, so timing is not an issue here — the scope violation is the only concern.

Scenario B: After completing an engagement, a penetration testing firm presents their findings to the client. The report shows that the team: (1) gained initial access via a phishing email; (2) used pass-the-hash to compromise 12 internal servers; (3) created three backdoor accounts that survived for two weeks post-engagement; (4) reached an isolated development network via a management server that bridged the corporate and development VLANs. The client asks: "Which finding represents the most serious long-term risk if left unaddressed?" How should the pen testing team respond?

Answer: The persistence finding (backdoor accounts that survived two weeks) represents the most serious long-term risk. While all four findings require remediation, persistence is the finding that would survive patching the initial entry point — the most natural first remediation action. If the client patches the phishing vector and the pass-the-hash credentials but does not remove the backdoor accounts, the attacker retains access. The client should also recognize that the chronological order of risk severity is: remove all persistence mechanisms first, then address the pivot path (the management server bridge exposes the dev network), then address lateral movement controls (credential segmentation), then address the phishing-resistant authentication gap. The correct remediation sequence is not necessarily the order in which findings are listed.

Scenario C: A researcher finds a zero-day vulnerability in a widely used operating system kernel that allows local privilege escalation to root/SYSTEM without any credentials. She is deciding between three options: (1) publish immediately to warn all users; (2) sell the vulnerability to a broker; (3) report privately to the vendor and wait for a patch before publishing. Which option represents responsible disclosure, and what is the argument against immediate publication even though it would warn users fastest?

Answer: Option 3 is responsible disclosure. The argument against immediate publication (option 1), even though it warns users fastest: a warning with no available fix leaves users with no defensive action other than disabling or removing the affected system. Meanwhile, every attacker who reads the disclosure now knows exactly what to exploit. The net effect of immediate disclosure without a patch is to dramatically expand the attack surface while providing no mitigation. Users who learn about a vulnerability they cannot patch cannot protect themselves — they can only worry. Responsible disclosure delays the public warning until users can act on it meaningfully, by applying the patch. Option 2 (selling to a broker) is exploit brokering — the opposite of responsible disclosure, as it delivers the vulnerability to parties who will exploit it rather than fix it.

Penetration Testing — Exam Tricks