Common Penetration Test Findings and How to Write Them Up
The 27 findings that recur in almost every infrastructure, Active Directory, web, cloud and API test, what to say about each, and how to write each one once so it is reused.
Most reports are built from the same two dozen or so findings, raised in a different order against a different target. The value of a tester is in the handful of findings that are specific to the system in front of them; the rest are routine, and routine is exactly what should be written once and reused. Below are the 27 that recur across infrastructure, Active Directory, web, cloud and API work, with what the weakness is, why it matters, and what the remediation should say. Everything here is at the level a report describes a finding, not how to exploit one.
Why the same findings appear in every report
They recur because the causes recur: software falls out of support, defaults never get changed, a protocol that was fine a decade ago is still enabled, a permission is broader than it needs to be. None of that is a reflection on the client, and none of it is interesting to write for the twentieth time. The skill is in scoring each instance for the environment it sits in and describing the specific exposure, not in rediscovering the general wording every engagement.
Infrastructure
The findings a network test raises most, before anything target-specific. Severity depends heavily on exposure, so the same weakness can be Critical on an internet-facing host and Low on an isolated segment.
| Finding | Why it matters, and what remediation says |
|---|---|
| Unsupported or unpatched software | Software past its support date, or missing fixes for known flaws, carries public weaknesses an attacker does not have to discover. Remediation: upgrade to a supported version, apply the outstanding fixes, and put the asset on a patching schedule with a defined window by severity. |
| Default or weak credentials | A documented default or an easily guessed password on a service gives an attacker the access the login was meant to stop. Remediation: change every default, set a strong unique credential, and where possible disable the account or require a second factor on the interface. |
| Weak transport encryption | Deprecated protocol versions or weak ciphers let an attacker on the network path recover or tamper with traffic. Remediation: disable the old versions and weak ciphers, offer only current ones, and prefer configurations with forward secrecy. |
| Authentication relay exposure (SMB signing not required) | A service that does not enforce message signing lets an on-path attacker relay a user's authentication to another system. Remediation: require signing on both clients and servers, and reduce the broadcast and coercion paths that feed a relay. |
| Exposed management interfaces | Administrative services (remote desktop, database ports, device consoles) reachable from a wide network are a direct target for credential attacks. Remediation: restrict them to a management network or bastion, and never expose them to the internet. |
| Insecure or cleartext services | Protocols that carry credentials or data in the clear, or legacy services with weak defaults, expose information to anyone on the path. Remediation: replace them with encrypted equivalents, disable what is not needed, and change default community strings and settings. |
Active Directory
An internal test against a Windows estate raises most of these every time. They chain, so the write-up should say where each one sits on the path to wider access rather than treating each as isolated.
| Finding | Why it matters, and what remediation says |
|---|---|
| Name-resolution spoofing (LLMNR, NBT-NS, mDNS) | Legacy broadcast name resolution lets an attacker on the segment answer failed lookups and capture authentication material. Remediation: disable LLMNR and NBT-NS through policy, and rely on properly configured DNS. |
| Kerberoasting | Any domain account can request service tickets and attempt to recover the service account password offline. Remediation: give service accounts long random passwords or group-managed accounts, and remove unnecessary service principal names. |
| AS-REP roasting | Accounts that do not require pre-authentication let an attacker request crackable material without any credential. Remediation: require Kerberos pre-authentication on all accounts, and set strong passwords where it cannot be enforced. |
| Reused or unmanaged local administrator passwords | A shared local administrator password lets one compromised host unlock many. Remediation: use a managed solution that sets a unique, rotated password per machine, and remove standing shared credentials. |
| Excessive privilege and dangerous ACL paths | Over-broad group membership or permissions create a chain from an ordinary account to domain control. Remediation: review privileged groups and delegated rights, remove what is not needed, and tier administrative access. |
| Certificate services misconfiguration | A certificate template or service setting that lets a low-privileged user obtain a certificate for a stronger identity is a reliable route to domain compromise. Remediation: correct the template permissions and enrolment settings, and restrict who can request what. |
Web applications
The web findings that recur across almost every application. The current category names come from the OWASP Top 10 2025, which is worth citing in the report so a reader can place each finding against the list they know.
| Finding | Why it matters, and what remediation says |
|---|---|
| Injection (SQL and similar) | Untrusted input reaching an interpreter lets an attacker read or change data, or run commands. Remediation: use parameterised queries and safe APIs, validate input against an allow-list, and never build commands from raw input. |
| Cross-site scripting | Unescaped input rendered in a page runs script in another user's browser, enabling session theft or actions as that user. Remediation: encode output for its context, validate input, and apply a content security policy as defence in depth. |
| Broken access control (IDOR) | The application trusts a parameter to decide what a user may see or do, so a user reaches other users' data or functions. Remediation: enforce authorisation on the server for every object and action, keyed to the session, not the request. |
| Authentication weaknesses | Missing second factors, weak password rules or no lockout make account takeover cheap. Remediation: require a second factor, follow current password guidance, and throttle and monitor failed attempts. |
| Session management flaws | Cookies without secure attributes, sessions that never expire, or tokens that survive logout extend the window for hijacking. Remediation: set Secure, HttpOnly and SameSite, expire sessions, and invalidate tokens on logout. |
| Security misconfiguration and information disclosure | Verbose errors, directory listing, debug features, left-behind backups and missing headers hand an attacker detail and footholds. Remediation: harden the configuration, remove debug and sample content, and suppress detail in error responses. |
| Cross-site request forgery | A logged-in user can be made to submit a request they did not intend. Remediation: use anti-forgery tokens and the SameSite cookie attribute, and require re-authentication for sensitive actions. |
Cloud
A cloud configuration review raises these across AWS, Azure and Google Cloud. Check each provider's own rules on what you may test, and what needs permission, before an engagement, and record the permission you relied on.
| Finding | Why it matters, and what remediation says |
|---|---|
| Public object storage | A storage container readable or writable by anyone exposes whatever it holds, or lets an attacker plant content. Remediation: make buckets private by default, block public access at the account level, and grant access through scoped policies. |
| Overly permissive identity and access management | Broad roles, wildcards and usable escalation paths let a minor identity reach administrator rights. Remediation: apply least privilege, remove wildcard and unused permissions, and cut the paths that let a role grant itself more. |
| Missing logging and alerting | Without audit logging and alerts, an intrusion leaves no trail and no one is told. Remediation: enable the provider's audit logging across accounts and regions, protect the logs, and alert on sensitive events. |
| Unrestricted network exposure | Security groups or firewall rules open to the whole internet put services in reach of everyone. Remediation: restrict ingress to known sources, close unused ports, and avoid blanket rules that allow all addresses. |
API
An API test raises these even where the equivalent web application is sound, because the controls that a front end relied on are often missing behind it. Testing one without a specification raises them more often, not less, because the undocumented endpoints are where authorisation is weakest.
| Finding | Why it matters, and what remediation says |
|---|---|
| Broken object-level authorisation (BOLA) | The endpoint accepts a valid token but does not check the object belongs to that caller, so a user reaches others' records. Remediation: check ownership on the server for every object reference, on every request. |
| Excessive data exposure | The response returns more than the client needs, trusting the front end to hide it. Remediation: return only the fields the caller is entitled to, shaped on the server rather than filtered in the client. |
| Missing rate limiting and resource controls | Endpoints with no throttling allow credential attacks, enumeration and resource exhaustion. Remediation: apply rate and resource limits per caller, and alert on abnormal volume. |
Writing each one once
Every finding above has a general description, a general reason it matters and a general remediation that do not change between clients. What changes is the specific instance: the host, the parameter, the evidence and the score for that environment. Keeping the general part somewhere it can be reused in one action, and leaving the specifics on the finding, is the difference between a report that takes an afternoon and one that takes a week.
In Pental the reusable part lives in a findings Library. You add a finding to the Library once, and import it from the Library into an engagement when you meet it again, so the wording, remediation and score arrive already written and you adjust the specifics rather than starting from an empty box. Custom finding fields and custom report sections let the Library hold the fields your firm reports on, not a fixed set.
- Write the general, not the specific, into the Library. Hostnames, screenshots and account names belong on the instance, or a saved entry will carry one client into another client's report.
- Score the vector once, adjust per instance. A default CVSS vector your firm has already argued over gives every instance a consistent starting point, scored from the vector in 3.1 or 4.0.
- Keep remediation actionable. The entry should say what to change, in the terms the person fixing it works in. The post on remediation a developer will action is the standard to hold each entry to.
- Improve in place. When a better version of a write-up appears on a later engagement, it should replace the entry rather than fork it, so the Library always holds your current best wording.
A library grown as a by-product of real reports beats one written in a fortnight away from engagements. The reasoning, and the way reuse has to be the fast path rather than the diligent one, is in building a findings library your team actually uses.
When a common finding is not routine
A routine finding stops being routine the moment its specifics change the risk. A reused entry is a starting point, never a verdict, and three things should always make you stop and write fresh.
- The exposure is unusual. The same weak cipher is a footnote on an internal host and a serious finding on a payment page. Re-score for where it actually sits.
- You walked a chain. If a routine finding was the first step to something worse, the chain is its own finding with its own score, and the routine entry only describes the first step.
- The impact is concrete. "Could expose data" becomes a stronger finding when you have shown which data. If you proved it, say what you proved, and let the generic wording give way to the specific.
The test that a finding is genuinely routine: could you hand the client the entry and the evidence, and would a competent reader reach the same severity you did? If not, it needs the part only this engagement can supply.
Stop Rewriting the Same Finding
Add a finding to your Library once, with its wording, remediation and score, and import it into the next engagement rather than typing it again.
Also Worth Reading
How to Write a Penetration Test Report, Step by Step
The process from first note to delivery: set the report up before testing, write findings as you confirm them, score severity with reasons, write the summary last, and QA everything before it leaves.
ReferencePenetration Testing Severity Levels and Risk Rating Matrix
Critical, high, medium, low and informational defined in one table and mapped to CVSS 4.0, with a likelihood and impact matrix for findings CVSS does not fit, and the habits that keep testers consistent.
ReferenceCVSS 4.0 Examples: 15 Common Pentest Findings Scored
Fifteen findings you raise in almost every test, each scored in CVSS 4.0 with a full vector and the reasoning behind it, set beside its 3.1 score so you can see exactly where the two versions part company.
Setup guide
Prefer to watch it?
The whole setup recorded, with chapters you can jump to: registering, your own domain, your own database in any of three places, your own mail server, branding, the first sign-in, updating the database on Supabase Cloud, and moving the database if you change your mind.
- 0:00 · Registering, signing in, and the free trial
- 0:51 · Your name and your firm’s name
- 0:57 · Custom domain
- +6 more