Exploitation, Post-Exploitation, and Reporting
Demonstrate impact safely, understand privilege escalation and lateral movement, and write reports that get fixed.
- Certification
- CompTIA PenTest+
- Recommended study time
- 6h 30m
- Status
- Not started
Recommended study time
About 6h 30m in total, measured from the material on this page. At your session length of 45 minutes that is 9 sittings.
- Read the lesson20 min
About 2,604 words at a careful technical reading pace.
- Second pass with notes12 min
Re-read the harder parts and write your own notes.
- Recall from memory12 min
2 written recall questions.
- Practice decision12 min
One applied decision with feedback.
- Teach it back20 min
Write the topic in your own words.
- Real-world scenario15 min
Read the situation and justify your decision in writing.
- Hands-on practice3h 20m
Labs, commands and configuration until you can do it unaided.
- Spaced review1h 40m
4 short review sessions spread over the following weeks.
Learning objectives
- Explain common exploitation, escalation, and lateral movement techniques conceptually.
- Demonstrate impact without causing avoidable damage or data exposure.
- Write findings with evidence, risk rating, and actionable remediation.
Start here
About 8 minutes of reading, in 10 short parts.
Exploitation is the moment a penetration tester turns a theoretical weakness into real, demonstrated access, but the actual value of a test is delivered afterward, in a report clear enough that someone can fix the problem. Testers are judged on how well they communicate impact, not on how many systems they broke into.
Where you meet it: A tester who has gained access to a database during an engagement decides exactly how much data to touch, then spends more time writing the finding than they spent exploiting it.
The lesson, part by part
Open one part at a time. Each part stands on its own, so you can stop and come back.
Imagine a fire inspector who finds a blocked emergency exit. Their job is not to set the building on fire to prove the exit doesn't work; they just need to show, with a photo and a clear explanation, that in a real fire this exit would fail people trying to escape. Exploitation in penetration testing follows the same restraint: prove the door is unlocked, without needing to walk through every room behind it.
Post-exploitation is like that same inspector checking what would happen next if a small fire actually started here: would it spread to the room next door, and how fast. It is about demonstrating real consequence, in a controlled and limited way, so the building's owner understands exactly what is at stake and exactly what to fix.
Key ideas
If you remember nothing else from this topic, remember these.
- Exploitation must respect scope and stability limits agreed in the rules of engagement, favoring the least disruptive proof of a vulnerability.
- A proof of concept should demonstrate impact clearly without causing unnecessary damage, such as reading a single record instead of dumping an entire database.
- Chaining multiple lower-severity findings together often demonstrates greater real business risk than any single finding in isolation.
- A penetration test report's value comes from actionable, specific remediation guidance tied to evidence, not just a list of vulnerabilities.
- Executive summaries and technical findings sections serve different audiences and must both be written clearly and accurately.
- Reproducibility, including exact commands and screenshots, is what allows a client's engineers to trust and fix a finding.
Exploiting and reporting a chained finding
A worked example, step by step.
During an internal test, a tester finds an exposed Jenkins server with default credentials and must exploit it carefully and report it with sufficient chained context.
- 01Confirm the finding safelyLog in to Jenkins with default admin/admin credentials, confirming access without altering any existing jobs.
- 02Assess least disruptive proofRather than deleting or modifying production jobs, create a new, clearly labeled test job that runs a benign command like whoami to prove code execution capability.
- 03Capture evidenceScreenshot the login page, the credential entry, and the whoami output showing execution as a service account with elevated privileges.
- 04Chain to next stepUse the captured service account's stored credentials, found in a Jenkins credential store, to authenticate to an internal Git repository containing production deployment scripts.
- 05Determine business impactRecognise that access to deployment scripts means an attacker could inject malicious code into the software supply chain, a severe impact beyond the initial low-effort default credential issue.
- 06Remove test artifactsDelete the test job created and confirm no other changes were left on the Jenkins server.
- 07Draft the findingWrite the finding with a CVSS-like severity assessment reflecting the full chain impact, exact reproduction steps, screenshots, and specific remediation: rotate credentials, enforce SSO, and disable default accounts.
- 08Deliver the reportPresent the chained finding prominently in the executive summary as a supply chain risk, with the full technical detail in the findings appendix.
Outcome: A seemingly minor default credential issue is proven to enable a supply chain compromise path, reported with reproducible evidence and specific remediation that the client's engineering team can act on immediately.
Exploitation and reporting reference
Worth keeping at hand while you work.
- Proof of concept
- Minimal, safe demonstration that a vulnerability is real and exploitable
- Finding chaining
- Combining multiple lower-severity issues to demonstrate greater business impact
- Executive summary
- Non-technical section describing business risk for leadership
- Technical findings section
- Detailed evidence and reproduction steps for engineering teams
- Severity rating
- Risk score assigned to a finding, often using CVSS-like reasoning
- Remediation guidance
- Specific, actionable fix recommendations tied to each finding
- T1078
- Valid Accounts, applicable to default credential misuse
- T1552
- Unsecured Credentials, applicable to credential store exposure
- Least disruptive proof
- Principle of proving impact with minimal risk to production systems
- Debrief meeting
- Live discussion of findings with the client after report delivery
- Retest
- Follow-up engagement verifying remediation of prior findings
Common misunderstandings
What most beginners get wrong here.
Exploiting a finding fully, including deleting data, proves the point better.
The least disruptive proof of concept should be used to demonstrate impact without unnecessary risk to production systems.
Each finding should be reported in isolation with its own severity.
Chaining lower-severity findings together often reveals a more severe combined business risk that should be reported prominently.
The technical findings section is the most important part of the report for leadership.
Leadership relies on the executive summary written in business terms, while engineers use the technical section.
A report is complete once vulnerabilities are listed.
A report's value comes from specific, actionable remediation guidance tied to each piece of evidence, not just a list of issues.
Once the report is delivered, the engagement is finished.
Many engagements include a debrief meeting and a later retest to verify remediation was effective.
Exam traps
How the question writers try to catch you out.
- PenTest+ exam scenarios test recognising when to choose a low-impact proof of concept over a more destructive one to preserve system stability.
- Expect questions asking which report section is appropriate for a given audience, such as executive summary versus technical appendix.
- Exam items test the concept of finding chaining, where combined low-severity issues produce a high overall risk rating.
- Watch for scenarios emphasising that reproducibility, including exact commands, is required for a client to trust and act on a finding.
- Questions may test that a retest engagement is the correct way to verify remediation, not just trusting the client's confirmation.
Check yourself
Answer in your head first, then reveal. This is not scored.
Why should a tester avoid fully exploiting a finding to its most destructive extent?
What does finding chaining demonstrate?
Who is the audience for the executive summary versus the technical findings section?
What ATT&CK technique applies to default credential misuse?
Why is a retest engagement valuable?
What should remediation guidance in a report include?
Quick reference
A condensed summary of the lesson above, for revision.
What It Is
Exploitation converts a vulnerability into access, often through unpatched services, weak credentials, injection flaws, or misconfiguration. Post-exploitation covers privilege escalation, credential access, persistence, and lateral movement to demonstrate business impact. Reporting documents each finding with evidence, reproduction steps, risk rating in context, and specific remediation, plus an executive summary for decision-makers.
Why It Matters
Unclear or purely technical reports are shelved. Testers who explain business impact and provide fixable steps directly improve the client's security, which is the entire point of authorised testing.
How It Works
- Exploits abuse a flaw to execute code, bypass authentication, or access data.
- Escalation and lateral movement exploit trust relationships, credentials, and misconfiguration.
- Reporting maps each finding to evidence, risk, and a specific remediation action.
Where You See It
- Assurance testing, red team exercises, bug bounty triage, and remediation planning.
Key Terms
- Privilege escalation
- Gaining higher rights than initially obtained.
- Lateral movement
- Using access on one system to reach another.
- Proof of concept
- Minimal evidence demonstrating the issue without excess risk.
- Blast radius
- The potential impact of an action taken during testing.
- Executive summary
- Business-level explanation of risk and priority.
Examples
- Demonstrating access to one record proves impact without exporting an entire customer database.
- Reusing a local administrator password across machines is a classic lateral movement path.
Common Problems
- Excessive data access
- Unremoved test artefacts
- Findings without reproduction steps
- Risk ratings ignoring context
How It Fails
- Leaving persistence or accounts behind creates a real vulnerability.
- Exporting production data during a test can itself become a breach.
- Vague remediation advice such as 'harden the server' is never actioned.
How to Troubleshoot
- Verify each finding is reproducible before reporting it.
- Confirm cleanup of accounts, files, and configuration changes at the end.
- Recheck risk ratings against the client's actual exposure and controls.
Practical Knowledge
- Record commands and timestamps so the client can correlate with their own logs.
- Prioritise findings by the fix that reduces most risk, not by technical elegance.
Exam Coverage
- Exploitation and post-exploitation concepts
- Evidence handling and cleanup
- Report writing and communication
Interview Questions
- How much exploitation is enough to prove a finding?
- What makes a penetration test report actionable?
Watch and read
Verified official and reputable sources for this topic. Links open in a new tab.
Video training
Professor Messer video channel — general CompTIA training (no dedicated CompTIA PenTest+ course)
Professor Messer
WatchVideoFree
Lesson notes and bookmark
Notes and bookmarks for this lesson, saved with everything else you have marked.
No notes on this item yet.
Learning progress
0% across six evidence areas. Reading alone does not change progress.
Prerequisites
Next steps
- 01Write a finding for a known weakness with evidence and remediation steps.
- 02Practise explaining a technical issue in two sentences for an executive audience.