Make the findings actionable. Translate the observed attack path into clear technical evidence, business impact, and practical remediation.
The house & safe / Chapter 05
Explain the route and repair the weak points
Show the homeowner which route was demonstrated, what protected the safe, and which doors or permissions need repair.
Technical meaning: Connect technical evidence to observed impact, prioritized fixes, and retesting. Reaching the safe room does not prove its contents were accessed.
Separate demonstrated impact from conditional consequences.
Provide concise reproduction steps and sanitized evidence.
Assign remediation owners and define a retest that checks the security boundary.
Phase deliverable
An executive summary, technical findings, attack-path narrative, remediation plan, and retest results.
Document what you observed, the assumptions you tested, and what remains unverified.
Field method / Expanded guide
Work through the phase.
This guide uses a five-phase teaching model. PTES separates additional stages, and NIST uses a different lifecycle. The topics below adapt those ideas to the workflow here; they are not a claim that every framework uses these five names.
1. Synthesize the attack path while testing
HOUSE LENS Draw the demonstrated route from the outside to the last boundary reached; mark doors that held as well as those that failed.
Reporting runs throughout the engagement and connects isolated observations.
Maintain a concise finding record as evidence is collected. Explain which weaknesses combined and which controls stopped a path. Use an attack-path diagram to connect the starting identity, affected services, crossed boundaries, and final demonstrated access.
Keep the report readable; retain large raw logs separately as supporting evidence when needed.
Distinguish untested assets and unsuccessful paths from tested controls.
Avoid counting several symptoms of one root cause as unrelated findings without explanation.
2. Write for executives and developers
HOUSE LENS The homeowner needs priorities; the person repairing the latch needs the exact fault and a repeatable test.
Different audiences need different levels of detail from the same evidence.
Executives need the test objective, meaningful outcomes, business exposure, limitations, and remediation priorities. Developers need the affected location, prerequisites, reproduction steps, technical cause, and a concrete fix. Use precise language that a reader can act on without deciphering tool output.
Describe observed impact first, followed by conditional consequences with their assumptions.
Tie severity to the affected asset, prerequisites, exposure, and agreed scoring method.
Avoid claiming financial loss or full compromise when neither was demonstrated.
3. Build a complete technical finding
HOUSE LENS Describe the opening, the conditions, what crossed the boundary, and how to repair that boundary.
A finding is useful when another tester can reproduce it and an owner can fix it.
Include a descriptive title, affected endpoints or hosts, test identity, setup, ordered reproduction steps, sanitized evidence, impact, and remediation. Explain why the response violates the intended policy. Reference a relevant standard or vendor advisory when it helps implement the fix.
Use dedicated test-data identifiers so the reproduction does not depend on customer data.
List prerequisites such as roles, feature flags, and reachable services.
Use stable evidence references instead of pasting every command log into the narrative.
4. Plan remediation, cleanup, and retesting
HOUSE LENS After the repair, verify that the unauthorized route is closed while legitimate residents still have access.
A successful retest confirms the security property, not simply a changed error message.
Give each finding an owner and a practical priority. Retest the original path and relevant variants after the fix. Verify legitimate behavior still works; for authorization, the owner should retain access while an unauthorized identity is denied. Close test artifacts and note residual limitations.
Record fixed, partly fixed, not fixed, or not retested with supporting rationale.
Confirm cleanup of test files, accounts, sessions, and configuration changes.
Define evidence retention and disposal according to the engagement agreement.
Tools / Practical reference
Commands, outputs, interpretation.
Use approved targets. These examples show representative behavior; output varies by environment. Angle-bracket values must be replaced. No command here guarantees a finding.
No console output on success.
Created file: report.html
How to interpret it: The input must exist. Review the generated report for content, formatting, and accidental secrets; successful conversion does not validate findings.
How to interpret it: Store the real digest with the evidence manifest. A digest can detect later changes; it does not prove that evidence was collected correctly.
PORT STATE SERVICE VERSION
443/tcp open https nginx
Created: services.xml
Interpretation: The XML file captures observations from this active test. Record its time and scope; a later report should not treat the file as proof of exploitation.
Generate a structured deliverable from reviewed Markdown
No console output on success.
Created: report.html
Interpretation: Requires the reviewed report.md source. Confirm that code examples, figures, evidence references, and redaction survive conversion. Converting a document is not technical verification.
A finding that developers can use
Illustrative finding / broken access control
User A can read User B’s lab document
Observed impact: A user accessed one document belonging to another account in the lab. Broader exposure has not been demonstrated.
Reproduction: Create two accounts, record ownership of a test document, request its identifier using the other account’s token, and preserve the response.
Fix: Enforce object-level authorization on every document request. Derive access from the authenticated identity and server-side policy.
Retest: Confirm the owner can access the document, while another account receives a denial without document content. Test equivalent endpoints as well.
Interpretation / Common mistakes
Observation versus business impact
Observation versus business impact
Copying tool output without explaining the violated security boundary.
Presenting conditional consequences as observed outcomes.
Retesting only the status code and missing an unchanged data exposure.
Evidence checklist for this phase
Target and test identity
Timestamp and relevant configuration
Exact command or sanitized request
Observed output and its interpretation
Limitations, changes made, and cleanup status
Sources / Further reading
Read the underlying guidance.
Original guidance consulted for methodology and tool behavior. Commands and outputs on this page are illustrative lab examples, not output captured from these sources.
Show the homeowner which route was demonstrated, what protected the safe, and which doors or permissions need repair. Connect technical evidence to observed impact, prioritized fixes, and retesting. Reaching the safe room does not prove its contents were accessed.
