Last Updated: July 27, 2026 Updated Date: July 27, 2026 Exam Version: Verify current PNPT reporting requirements in the official candidate guide before submission. Reading Time: 9 minutes Author: Cyber Services Research Team – penetration testers and certification mentors focused on practical methodology, Active Directory tradecraft, and evidence-led reporting.
A technically sound compromise can still lose value if your report is rushed, vague, or impossible for a client to act on. This PNPT reporting example walkthrough shows how to convert raw exam notes, screenshots, command output, and attack paths into a report that proves impact without burying the reader in terminal noise.
Your report is not an afterthought. It is the deliverable that demonstrates whether you can communicate like a consultant rather than simply operate tools. Write it with the same discipline you used during enumeration.
Quick Summary
A strong PNPT-style report has two jobs: give decision-makers a clear risk picture and give technical teams enough evidence to reproduce and fix the findings. Start with the business impact, document the attack chain in order, separate findings by root cause, and attach only evidence that supports a claim.
Do not treat screenshots as decoration. Every image, hostname, timestamp, user context, and proof file should answer a question: what happened, where did it happen, why does it matter, and how can the client verify the fix?
Table of Contents
- Build the report before the final hour
- Use a client-ready structure
- Follow a PNPT reporting example
- Write findings that survive scrutiny
- Run a final submission check
Build the Report Before the Final Hour
The common failure is waiting until access is complete before organizing evidence. By then, terminal history is cluttered, screenshots lack context, and the exact route from initial foothold to domain-level impact is harder to explain.
Create a working evidence log as soon as you begin. Record the target, date and time, source IP or testing host, command purpose, outcome, and the file path for supporting evidence. If credentials are obtained, document the account, privilege level, source, and validation method. Never place reusable secrets in a public-facing executive section.
Use a simple naming pattern for screenshots such as `01-external-service.png`, `02-valid-user-enumeration.png`, and `03-admin-share-access.png`. The number should match the order of your attack narrative. This prevents the reviewer from jumping between unnamed images trying to reconstruct your work.
For Active Directory-heavy scenarios, pair your report notes with a clean AD Enumeration checklist. It keeps the difference between observed facts and assumptions visible. That distinction matters when a client asks whether a vulnerability was confirmed or merely suspected.
Use a Client-Ready PNPT Report Structure
A good report is readable in two directions. Executives should understand the exposure in minutes, while administrators should be able to validate every technical statement without scheduling another call.
Executive Summary
Open with the scope, testing window, and a direct statement of outcome. State what level of access was achieved and what that access could permit in a real incident. Avoid tool names here unless they materially affect the risk.
For example: “Testing demonstrated that an external attacker could obtain access to an internal workstation and escalate to high-privilege Active Directory access. This could enable unauthorized access to sensitive systems, credential theft, and disruption of business operations.”
That is stronger than “Domain Admin was achieved.” The latter is technically meaningful, but it does not explain why leadership should care.
Scope, Rules, and Limitations
List the approved targets, exclusions, assessment dates, and limitations. If a host was unreachable, an application was out of scope, or phishing was not permitted, record it. A clean limitation section protects the credibility of the engagement because it makes clear what you did not test.
Attack Narrative
The narrative is the spine of the technical report. Present the route in chronological order: external discovery, initial access, local enumeration, privilege escalation, lateral movement, and final impact. Keep it concise, but do not skip the transition that made the next stage possible.
This section should read like an incident reconstruction. It should not read like copied command history.
Findings and Remediation
Each finding needs a consistent format: title, severity, affected assets, description, evidence, impact, remediation, and references if applicable. One attack path can produce multiple findings. Weak password policy, excessive share permissions, and misconfigured delegation may all contribute to the same compromise, but they should not be collapsed into one vague “Active Directory issue.”
PNPT Reporting Example Walkthrough
Assume a fictional assessment of `northstar.local`. The test began with an externally available remote access portal. Valid low-privilege credentials were obtained through an approved testing path, then used to access an internal workstation. Local enumeration identified a service account with excessive rights. Those rights allowed access to a sensitive network share and facilitated movement to a management server.
The executive summary should not list every command used to discover that path. It should state that a low-privilege compromise led to access beyond the intended role and created a credible route to sensitive systems.
The technical narrative can then show the chain:
- The remote access portal accepted valid credentials without a second authentication factor.
- The compromised user could authenticate to an internal workstation.
- The workstation exposed configuration data that revealed service-account access.
- The service account had permissions beyond its operational purpose.
- Those permissions enabled access to a management server and protected data.
The key is causality. Each step explains how the next one became possible.
Example Finding: Excessive Service Account Permissions
Severity: High Affected assets: `APP-SRV01`, `MGMT-SRV01`, `northstar.local` Affected identity: `NORTHSTARsvc_backup`
Description: The `svc_backup` account held permissions that exceeded its backup function. During testing, the account was used to access administrative resources on `MGMT-SRV01`. This converted a limited internal foothold into access to a high-value management system.
Evidence: Include a screenshot showing the authenticated identity and successful resource access, plus sanitized command output demonstrating the assigned group membership or permission. Label the image with a short caption. Do not make the reviewer infer what a blurred terminal window proves.
Impact: An attacker who obtains this account could access systems used for administration, collect credentials or configuration information, and potentially expand control across the environment.
Remediation: Remove unnecessary administrative rights, limit the account to the systems and shares required for backup operations, rotate its password, and monitor interactive or remote logons by the account. If the account must retain elevated privileges, use a dedicated privileged-access design and document its approved use.
This finding is better than “service account was domain admin.” It identifies the affected identity, shows the business consequence, and gives the defender a remediation path that can be assigned to an owner.
What Separates a Passable Report From a Strong One
| Report decision | Weak approach | Strong approach | |—|—|—| | Severity | Labels every compromise Critical | Rates impact based on realistic access, scope, and business consequence | | Evidence | Adds every screenshot captured | Uses the minimum evidence needed to prove the claim | | Attack path | Lists tools and commands | Explains the conditions and transitions that enabled compromise | | Remediation | “Patch and use strong passwords” | Assigns specific, testable corrective actions | | Executive content | Repeats technical details | Translates technical control failure into operational risk |
Severity is not a reward for finding something interesting. A Critical rating may be justified when compromise enables broad control of a production environment or material data exposure. A High finding may be more accurate when escalation was proven but the blast radius remained limited. Explain your reasoning. Clients can disagree with a rating, but they should never be left guessing why you assigned it.
Final Submission Check
Before submitting, read the report as both a security manager and a systems administrator. The manager should understand the attack outcome and priority actions. The administrator should know exactly which identity, host, permission, or control requires attention.
Confirm that all screenshots are legible, sensitive values are redacted where appropriate, hostnames are consistent, and finding titles match their remediation sections. Verify that the report accurately reflects what you actually demonstrated. Do not claim data exfiltration if you proved only file access, and do not claim domain-wide control when you validated one server.
If reporting is your weak point, practice it alongside exploitation. Use a reporting template after every lab, then compare your narrative against your Active Directory Guide, Privilege Escalation notes, and Red Team Guides. Cyber Services organizes practical reporting references and exam-focused documentation so you can spend less time formatting and more time refining judgment.
FAQ
How detailed should command output be?
Include only output that proves the finding or allows technical validation. Full tool logs usually belong in an appendix only when they provide material evidence. A report should explain the result, not force the client to parse raw output.
Should one attack chain be one finding?
It depends. Use separate findings when the root causes and remediation owners differ. For example, missing MFA and excessive service-account rights should normally be separate findings even if both were required for the same compromise.
Can I use a report template for PNPT preparation?
Yes. A template saves formatting time, but it cannot replace accurate evidence, clear impact analysis, or tailored remediation. Treat templates as structured practice materials, not a substitute for understanding the assessment.
Related Guides
For the technical side of the workflow, review OSCP vs PNPT, the Active Directory Guide, AD Enumeration, Privilege Escalation, CPTS preparation, CRTO methodology, OSEP study planning, and Certification Roadmaps. Each topic strengthens the evidence and decision-making behind a credible report.
Customer Reviews
No customer review snippets are included here because testimonials should be attributable to verified buyers, not invented to fill a page.
Get Started
Build a report from your next lab before you move to the next module. The fastest way to improve is to make every enumeration decision, privilege escalation step, and remediation recommendation readable to someone who was not sitting at your terminal.