Reporting and Communication of Findings
Reporting and Communication of Findings
This domain tests whether you can turn technical work into a decision-ready report. CPTS expects a reproducible narrative, risk-ranked findings, and evidence that another tester could follow.
Core rules
- Structure: executive summary, scope and RoE, methodology, attack narrative, findings, remediation, and appendices. The summary should state business impact, not command output.
- Each finding needs a title, affected asset(s), description, impact, evidence, CVSS vector with justification, remediation, and references. Keep evidence minimal but sufficient: request/response, command, output, timestamp.
- Write the attack path as a chain: initial access, privilege escalation, lateral movement, and objective. This shows risk better than isolated issues.
- Separate observation from inference. SMB signing disabled is an observation; enables relay to domain admin needs proof or a clearly labeled risk.
- Communicate early on critical findings and scope changes. Record cleanup and any residual access.
Worked example
Finding: Kerberoastable service account enables offline password cracking. Affected: svc_backup on DC01. Evidence: impacket-GetUserSPNs output showing the SPN and TGS hash; hashcat mode 13100 recovering the password; nxc winrm confirming admin access. Impact: an authenticated user can request a service ticket and crack it offline, leading to backup server compromise. Remediation: rotate the password, remove the SPN if unused, use a gMSA, and monitor 4769. CVSS: AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H. The reasoning is: prove the path, quantify impact, prescribe a fix.
Traps
Screenshots without commands, CVSS scores inconsistent with the vector, no business impact, missing affected versions or assets, and findings that cannot be reproduced. Also: no timeline, no scope or exclusion statement, and no note on out-of-scope discoveries.