4.4
Documenting Technical Findings
Each finding in a pentest report follows a consistent structure. This makes findings scannable, comparable, and actionable for the team that has to fix them.
Severity classification is heavily debated based on the classification used. For example, some people still use CVSS v3.1, some people have switched to CVSS v4, and some people prefer the Impact-Likelihood matrix. What you need to do is learn the classification used by your organization or your team and how to justify your findings accordingly.
A complete finding includes:
Title. Clear and context specific.
- “Kerberos Issue” ❌
- “Weak Service Account Passwords Enable Kerberoasting Attack.” ✅
Severity rating. Using a consistent rubric (CVSS, or a custom rubric developed by your team). The rating drives prioritization.
Description. What the vulnerability is and how it was exploited. Technical, clear, and easy to reproduce.
Business impact. What could happen if this vulnerability were exploited by a real attacker? This is what turns a technical finding into a business risk.
Evidence. Screenshots, command output, and documentation proving the vulnerability exists. This is where your Module 3 documentation pays off.
Remediation. Specific, actionable steps to fix the issue. Prioritized with context about effort and trade-offs.
Included with this specific lesson is a severity rubric that shows an example of how some teams have template classifications for all their findings that allow for adjusting the context to reduce reporting time.
Five findings from the Navigating Security Corp engagement need severity ratings. Use the rubric to rate each one and justify your choice.
Rate Finding Severity
severity-rating
Assign a severity rating to each finding using the provided rubric. Select your rating, then see the consultant's assessment.
Kerberoastable Service Account with Weak Password
svc_adbackup had its TGS ticket cracked in 6 minutes using a standard wordlist. This account is a member of Backup Operators and holds DCSync replication rights on the domain root.
Complete Attack Path to Domain Admin via DCSync
BloodHound confirmed a two-step path from the initial low-privilege account (t.chigubhu) to full domain compromise: Kerberoast svc_adbackup → DCSync via DS-Replication-Get-Changes-All rights → extract krbtgt hash → Golden Ticket.
Excessive Domain Admin Group Membership
The Domain Admins group contains 9 members. At most 2 are expected (built-in Administrator and one named admin). Members include stale accounts, service accounts, and role-inappropriate accounts that should not hold Domain Admin privileges.
No Account Lockout Policy Configured
The Default Domain Policy has the account lockout threshold set to 0, allowing unlimited password attempts against any domain account.
AS-REP Roastable Account — Kerberos Pre-Authentication Disabled
svc_monitor has 'Do not require Kerberos pre-authentication' set. An AS-REP hash was retrieved and exported for offline cracking. The hash was not cracked within the testing window.