Skip to main content

Professional methodology

Machines are solved with technique. Real audits are won with methodology. The difference between a junior who takes 8 hours and a consultant who takes 2 isn’t typing speed: it’s knowing what to discard and when.
This page doesn’t teach tools. It teaches the decision tree a professional auditor runs mentally. Master this and you’ll differentiate from 90% of candidates who shoot blindly.

The 5 phases (PTES)

The industry standard is the Penetration Testing Execution Standard. Phases are immovable and sequential — skipping one guarantees failure.
1

Reconnaissance (OSINT)

Passive intelligence. Zero packets to the target. Wayback Machine, Shodan, Censys, certificate transparency, Google dorking, GitHub Search, LinkedIn (org chart), Hunter.io (emails).
2

Enumeration

Active and silent mapping. Ports, subdomains, API endpoints, technologies. No exploits, no waking the WAF.
3

Threat modeling

Cross discovered topology with logical attack vectors. Here you decide what to attack and in what order, not before.
4

Exploitation

Technical execution. What the public associates with “hacking” is actually the shortest phase — 10-20% of total time.
5

Post-exploitation

Privilege escalation, persistence, lateral movement, and finally: the report. The report is 40% of the value the client pays for.

Decision tree: SMB

Every protocol has its tree. Memorizing commands without structure is useless; the value is in the order of the questions.
Stopwatch rule: if after 15 min on SMB you haven’t identified a clear path, switch protocol. You can come back later with more context. Stubbornness costs exams.

Decision tree: Active Directory (post-foothold)


Decision tree: Web application


The stopwatch rule

The OSCP candidate’s #1 mistake is falling in love with a useless vector.
⚠️ Rabbit hole warning
If after X minutes a vector hasn’t produced any sign of progress, don’t insist. Pivot. Come back later if needed.
4× rule: if you’ve spent 4× target time on a vector, it’s a definitive sign that’s not the vector or your initial enum was incomplete. Go back to step 1 with a fresh head.

Exploit chaining: turning “medium” into “critical”

A standalone flaw is medium severity. A chained flaw is critical. The professional value is in chaining.

LFI → RCE

XSS → ATO (Account Takeover)

SSRF → Cloud Metadata


Plan B: when everything fails

Tools fail 80% of the time on first try. The standard guide assumes sqlmap works. That’s science fiction. Here’s the checklist when a vector crashes:

File upload blocked

Reverse shell that won’t connect

Hashes that won’t crack


Cemetery of failed vectors

In real audits, discarding is as important as exploiting. The client’s report must include what you tried and why it failed, not just what worked. Maintain throughout the audit a discard section in this format:
This demonstrates methodology to your report reviewer. Difference between “I tried everything and nothing” (junior) and “I tried these 12 vectors; these 8 failed for these specific reasons; these 4 worked” (senior).

MITRE ATT&CK mapping

When reporting a finding, map it to the MITRE ATT&CK framework. Don’t say “I did an RCE”: say T1059 — Command and Scripting Interpreter. This sets you apart in any technical interview. Full catalog: attack.mitre.org.

Final checklist before delivery

Before calling a machine “completed” (HTB, exam, or real audit), answer this:
  • Do I know the CVE (if any) or CWE of the flaw?
  • Do I know the CVSS score I’d assign?
  • Can I write the business impact in non-technical language?
  • Do I have the exact remediation code/config block?
  • Do I know what alerts would fire in a real SOC?
  • Do I have the MITRE ATT&CK ID mapped?
  • Did I document which vectors failed and why?
If you answer “no” to more than 2, you haven’t completed it: you’ve technically solved it, which is different.
HTB machine solved without these 7 points = a line in your CV. HTB machine solved with these 7 points = real case for your professional portfolio. Same time invested. 10× return.