Penetration testing reveals a lot about the unique configuration of your environment — but after hundreds of engagements across industries, certain findings appear with striking consistency. These are not exotic zero-days or nation-state techniques. They are structural weaknesses that automated scanners often miss and that attackers reliably exploit.

Here are the five vulnerabilities our team finds most frequently, what they look like in practice, and why they persist despite widespread awareness.

1. Credential Weaknesses and Password Reuse

If there is one finding that appears in nearly every engagement, it is this one. Weak or reused credentials remain the most exploitable entry point across every industry we test.

This takes several forms:

  • Default credentials on network devices, administrative panels, and services that were never changed after deployment
  • Password reuse across internal systems, with credentials harvested from public breach databases valid against corporate accounts
  • Overprivileged service accounts running with domain-level access far beyond what the service requires
  • Shared credentials in documentation, wikis, or source code repositories

    • The underlying cause is rarely negligence — it is the gap between security policy and operational reality. Service accounts get created under deadline pressure. Shared credentials accumulate over years. Default passwords on an obscure internal device never make the audit list.

    What makes this particularly dangerous is the lateral movement potential. A single valid credential with excessive privileges can pivot from a workstation to domain controller faster than most incident response teams can detect it.

    2. Excessive Attack Surface — Services That Shouldn’t Be Exposed

    In most environments, we find more exposed services than the client is aware of. Legacy systems left running after a migration. Development or staging environments accessible from the internet. Administrative interfaces (RDP, SSH, management panels) reachable without a VPN.

    This is a byproduct of how environments grow. Infrastructure expands faster than firewall rules and network segmentation policies keep pace. Cloud environments accelerate this problem dramatically — an S3 bucket made public during testing, a security group rule opened for debugging that never got closed, a development server with relaxed access controls that became quietly permanent.

    From an attacker’s perspective, these exposed services are gifts. A forgotten development server often runs older software, has weaker credential controls, and is not monitored with the same rigor as production systems — but it has the same network access.

    3. Missing or Inconsistent Patch Management

    Unpatched software is one of the most straightforward vulnerabilities to exploit and one of the most difficult to fully remediate at scale. In penetration tests, we routinely find:

  • End-of-life operating systems still running in production or on internal infrastructure
  • Known critical CVEs that are months or years old on internet-facing systems
  • Patched externally but not internally — many organizations prioritize external patching while internal systems lag significantly behind

    • The challenge is not awareness of patching — every organization knows it matters. The challenge is execution at scale across heterogeneous environments, competing priorities, and systems that cannot be patched without downtime. Applications that require specific library versions. Legacy software that breaks under newer dependencies.

    Attackers know this. Exploit frameworks are updated within hours of a CVE publication. Organizations measured in weeks or months are operating in a different threat environment than they realize.

    4. Broken or Misconfigured Authentication

    Authentication failures are a broad category that shows up in virtually every web application and API assessment we conduct. The specific issues vary, but the patterns are consistent:

  • Missing multi-factor authentication on administrative interfaces, VPNs, and sensitive applications
  • Session management flaws — tokens that don’t expire, session IDs transmitted in URLs, or cookies missing Secure and HttpOnly flags
  • Insecure password reset flows — predictable tokens, reset links that don’t expire, or questions that can be socially engineered
  • API endpoints without authentication — particularly common in microservices architectures where internal services are assumed to be trusted

    • The API authentication gap deserves special attention. As organizations have expanded their API footprints, authentication enforcement has not kept pace. We frequently find internal APIs, mobile application backends, and third-party integrations that lack proper authentication controls — assumed to be “internal only” but reachable with minimal effort.

    5. Overly Permissive Access Controls

    The principle of least privilege is universally understood and rarely fully implemented. In practice, most organizations have significant access control debt — accumulated over years as roles expanded, users changed positions, and administrative access was granted without a corresponding process to revoke it.

    What this looks like in a pentest:

  • Users with local admin rights on workstations across the organization, enabling rapid lateral movement if any endpoint is compromised
  • Active Directory permissions misconfigurations — excessive privileges on service accounts, misconfigured group policies, or delegation rights that allow privilege escalation
  • Over-permissioned cloud IAM roles — S3 buckets accessible with credentials that shouldn’t have access, IAM roles with wildcard permissions, or overly broad trust relationships
  • Stale accounts — former employees, contractors, or service accounts that remain active long after they should have been deprovisioned

    • In red team engagements, access control misconfigurations are frequently the difference between a limited compromise and full domain takeover. It is rarely a single permission misconfiguration — it is a chain of them.

    What These Findings Mean

    These vulnerabilities are not exotic. They are not the result of sophisticated nation-state techniques. They are structural weaknesses that exist in most organizations and that attackers have operationalized into reliable attack chains.

    The encouraging part: they are fixable. Credential hygiene, attack surface reduction, consistent patching, authentication controls, and access privilege reviews are tractable problems. They require organizational commitment and sustained attention, not specialized technology.

    The concerning part: automated scanners find a fraction of these issues. Misconfigured Active Directory permissions, weak credential reuse, and session management flaws require the kind of manual testing that separates penetration testing from vulnerability scanning. To ensure you get the most out of your next assessment, read How to Prepare Your Team for a Penetration Test.

    If you’re running a single annual test and hoping it covers these gaps, it won’t — see Why Annual Penetration Tests Are Not Enough for why continuous testing is the more effective model.

    Want to know which of these vulnerabilities exist in your environment? StrikeHaven’s penetration testing team conducts comprehensive manual assessments that go beyond automated scanning to identify the issues that matter most. Schedule a consultation to discuss scope and approach for your organization.