Offensive Security / Methodology
A penetration test is only as good as the methodology behind it. Ad-hoc testing finds ad-hoc bugs; a structured methodology finds the paths an actual attacker would take — and produces a report a client can act on. What follows is the phase-by-phase approach we run on engagements, along with what tends to go wrong at each stage when teams skip a step.
None of this is exotic. It's the same five-phase backbone used across the industry — reconnaissance, scanning and enumeration, vulnerability assessment, exploitation, and post-exploitation — closed out by a reporting phase that's frequently treated as an afterthought and shouldn't be. The value isn't in any single phase; it's in not skipping one because the previous phase already turned up something interesting.
Nothing below happens without a signed scope document and rules of engagement. At minimum that means:
- Written authorization naming the specific systems, IP ranges, and applications in scope
- Explicit testing windows and any systems or actions that are off-limits (production databases, physical access, social engineering targets)
- An emergency contact and a process for pausing the engagement if something unexpected breaks
Everything past this point assumes that agreement is already in place.
The five phases
Reconnaissance
Passive and active information gathering to map the target's footprint before a single packet touches anything sensitive: domains and subdomains, exposed services, technology stack, employee and organizational structure, and anything leaked in public records, code repositories, or breach data.
- Passive: DNS records, certificate transparency logs, job postings, public code repos
- Active: light, low-noise probing to confirm what's actually live
The most common failure here is rushing it. A shallow recon phase means the exploitation phase is working with an incomplete map, and incomplete maps are how testers miss the system that actually matters.
Scanning & enumeration
Turning the recon map into a concrete inventory: open ports, running services and versions, and how those services are configured. This is where automated tooling earns its keep, but the output still needs a human reading it — a scanner reports what's listening, not what's actually exploitable in this specific environment.
# illustrative — a standard, non-intrusive service scan
nmap -sV -sC -p- --min-rate 1000 -oA scan_results target-rangeEnumeration output feeds directly into the next phase, so accuracy matters more than speed here.
Vulnerability assessment
Mapping the enumerated services and versions against known weaknesses, then — critically — validating which of those are real in context rather than trusting a scanner's severity score at face value. A CVSS 9.8 that requires local access on a system nobody can reach isn't the same risk as a CVSS 6 that's exposed to the internet with no compensating control.
This phase produces the prioritized list that exploitation will actually work through, ranked by real-world exploitability and business impact rather than raw score.
Exploitation
Controlled, scoped attempts to confirm that a vulnerability is genuinely exploitable in this environment — not just theoretically present. The goal is proof, not damage: the least invasive method that demonstrates impact, with every action logged so it can be reversed and explained afterward.
This is also where the rules of engagement earn their keep. Anything with a real chance of causing an outage (denial-of-service style findings, destructive tests against production data) gets flagged and confirmed with the client before it's attempted, not after.
Post-exploitation & lateral movement
Once initial access is confirmed, the question shifts from “can we get in” to “what does that access actually expose.” That means assessing privilege escalation paths, what other systems are reachable from this foothold, and what data or trust relationships an attacker in this position could realistically abuse — the part of the report that tends to matter most to leadership, since it translates a technical finding into business risk.
Reporting is a phase, not a formality
A finding that doesn't get fixed didn't help anyone. The report needs two distinct layers: an executive summary that translates technical risk into business terms for people who won't read the technical appendix, and a technical section detailed enough that an engineering team can reproduce and verify the fix without guessing at what was actually done.
DeliverableAudienceWhat it answers Executive summaryLeadership, risk ownersWhat's the business exposure, and how urgent is it? Technical findingsEngineering, ITExactly what was found, how it was confirmed, and how to reproduce it Remediation guidanceEngineering, ITWhat to fix first, and what a fix actually looks like Retest resultsAll partiesDid the fix hold?That last row matters more than it gets credit for. A pentest that ends at the report, with no retest of the highest-severity findings, leaves the client unable to confirm whether the risk was actually closed.
Retesting should confirm both that the original condition is fixed and that the remediation did not introduce an equivalent weakness elsewhere. Re-run the smallest effective validation first, then perform targeted regression checks around authentication, authorization, network exposure, and the specific control that was changed. Mark findings as remediated, partially remediated, accepted, or still exploitable, and preserve the evidence supporting that disposition.
Retesting closes the assessment loop
Risk dimensionQuestionWhy it matters ExposureIs the asset internet-facing, internal, or isolated?Reachability changes the practical attack surface. PrivilegeWhat level of access can be obtained?Administrative access can turn a local issue into broad compromise. Asset valueWhat business process depends on it?Technical impact becomes meaningful when tied to business operations. Attack pathCan this finding be chained with another weakness?Several moderate weaknesses can form a critical path.A severity score is useful, but it should not be the entire risk decision. Prioritize findings using the interaction between exploitability, affected asset value, exposure, privilege obtained, data sensitivity, compensating controls, and realistic attack paths. A medium technical weakness on an internet-facing identity system can deserve more attention than a high-scoring issue on an isolated test host.
Risk should connect technical severity to business exposure
Evidence quality and reproducibility
Each material finding should have enough evidence to demonstrate the condition without exposing unnecessary sensitive data. Record timestamps, affected assets, request or command context, screenshots where appropriate, relevant logs, and the exact validation path. Separate proof of vulnerability from proof of impact so remediation teams can reproduce the issue without repeating unnecessary offensive activity.
Rules of engagement and safety gates
Before active testing begins, define target ranges, excluded assets, permitted techniques, testing windows, source addresses, emergency contacts, credential handling, evidence retention, and escalation procedures. High-risk tests should have an explicit approval path. If production availability is a requirement, destructive or denial-of-service techniques should be excluded unless separately authorized and safely staged.
A professional penetration test is not simply a collection of successful exploits. It is a controlled assessment in which scope, evidence, decision points, and limitations are documented well enough that another qualified practitioner can understand what was tested and why the conclusions are justified. That distinction matters when the results are used for remediation, audit evidence, executive risk decisions, or regulatory reporting.
Making the methodology defensible
Want this methodology run against your own environment?
Scoped engagements, clear rules of engagement, and a report your engineering team can actually act on.
Talk to us about a penetration test
