One house.
One safe.
Five testing phases.
Learn penetration testing through an authorized burglary simulation: inspect the house, test an entry, map the rooms, cross permission boundaries, and explain the route toward the safe.
Start with Recon →5 PHASES / COMMAND EXAMPLES / TOOL REFERENCES
Watch the engagement unfold.
Recon
Inspect the house from outside
Check doors, windows, and vents, then identify the services they represent. An open entry point is not automatically an exploitable weakness.
Explore Recon →
Inspect doors, windows and vents
Discover exposed services01THE FLOW CAN LOOP: INTERNAL DISCOVERY MAY REVEAL NEW EXPLOITATION AND ESCALATION OPPORTUNITIES.
The safe is the objective. The house is the system.
The assessor simulates a burglar with the homeowner’s authorization. The goal is to explain which security boundaries fail and what access those failures actually enable.
01Recon
Check the doors, windows, and ventilation openings. Which entry points exist, and which answer when checked?
02Exploit
Use an agreed simulation to show that one entry point lets the assessor cross the outer boundary.
03Internal Recon
Once inside—or starting from an agreed internal position—learn the layout, stairways, locked rooms, CCTV, alarms, and route toward the safe.
04Privilege Escalation
Test whether a guest can obtain access reserved for the keyholder, such as entry to the upstairs safe room.
05Reporting
Show the homeowner which route was demonstrated, what protected the safe, and which doors or permissions need repair.
A connected process, not a rigid checklist.
Recon informs validation. Initial access changes what you can observe. Internal discovery and privilege escalation often repeat as new paths emerge. Collect evidence and draft findings throughout the engagement.
01Recon
Identify in-scope assets, reachable services, and application entry points before selecting a test.
↗02Exploit
Validate a specific weakness with a controlled test and show the minimum impact needed to demonstrate the finding.
↗03Internal Recon
After initial access—or from an agreed internal starting point—map reachable hosts, identities, and trust relationships.
↗04Privilege Escalation
Determine whether the current identity can obtain higher privileges through misconfiguration or a validated vulnerability.
↗05Reporting
Translate the observed attack path into clear technical evidence, business impact, and practical remediation.
↗Define the engagement.
Agree on authorization, target boundaries, credentials, testing windows, stop conditions, and how evidence will be handled. Internal tests may begin with an existing foothold; not every engagement requires exploitation.
One question per phase
- What is exposed?
- Can a weakness be demonstrated?
- What becomes reachable from here?
- Can this identity cross a privilege boundary?
- What should the organization fix, and why?
Commands with context.
All output is illustrative, not captured from a real assessment. The 192.0.2.0/24 network and example.test names are placeholders. Use an authorized lab and substitute approved targets. Tools and operating systems can produce different output.
Evidence follows the entire path
Preserve timestamps, target, test identity, request or command, observed response, and a concise explanation. Redact credentials and retain only the data needed to substantiate the finding.
Close the loop
Remove test artifacts, document changes, communicate urgent findings, and retest the original boundary after remediation. Reporting should connect technical weaknesses to demonstrated outcomes.
Penetration Testing vs. Red Teaming
Both use authorized adversarial techniques. The key distinction is what the engagement is designed to learn—not simply which tools it uses.
| Dimension | Penetration Testing | Red Teaming |
|---|---|---|
| Primary question | Which weaknesses are exploitable, and what impact do they enable? | Can an adversary achieve an agreed objective, and can defenders detect and respond? |
| Scope | Usually defined systems, applications, networks, or configurations. | Often an objective-driven scenario across multiple approved attack surfaces. |
| Approach | Prioritizes identifying and validating weaknesses within the agreed scope. | Emulates selected adversary behaviors and chains techniques toward the objective. |
| Defender awareness | Commonly coordinated with system owners; stealth is optional. | May limit defender awareness to assess detection and response. Some exercises are collaborative. |
| Success measures | Evidence quality, demonstrated impact, coverage, and useful remediation. | Objective outcomes, prevention and detection gaps, and response effectiveness. |
| Deliverables | Validated findings, reproduction steps, fixes, and retest results. | Attack narrative, objective results, defensive observations, and improvement priorities. |
Penetration test example
Assess an internal network and validate whether an exposed service and weak permissions allow unauthorized access to a business system.
Red team example
Emulate an agreed threat scenario to reach a designated test dataset, then evaluate where defenders prevented, detected, or responded to the activity.
These are common engagement patterns, not universal definitions. A penetration test can include detection checks, and red teaming can uncover vulnerabilities. The rules of engagement determine the actual scope and methods.
Web. Mobile. Platform. IoT. OT.
Explore how the workflow changes across applications, infrastructure, connected devices, and industrial environments.
Web ↗
Applications, APIs, authentication, and business logic.
Mobile ↗
Android and iOS apps, their local data, platform interactions, and backend APIs.
Platform ↗
Hosts, operating systems, infrastructure services, cloud configurations, and identity systems.
IoT ↗
Connected devices, firmware, physical interfaces, companion apps, and device-to-cloud communication.
OT ↗
Industrial control systems, engineering workstations, supervisory systems, and their relationship to physical processes.
Follow the evidence, not just the tools.
Each phase now includes four detailed method topics, diagrams, additional command examples, interpretation, and source references. Explore scope reconciliation, authorization comparisons, segmentation, identity paths, permission boundaries, and retesting.
Explore the expanded guide →