Network Penetration Testing: A Buyer's Guide

What a network penetration test is

Network segmentation is the control that organizations are most confident about before a pentest and most surprised by after. Almost every organization with documented network segmentation believes the payment network is isolated from the corporate network, that guest WiFi cannot reach internal file servers, that the production database is not reachable from a developer workstation. The pentest consistently shows otherwise — not because the architectural intent was wrong, but because a misconfigured switch port, a routing exception someone added in 2019 and forgot to remove, or a cloud security group rule opened for a temporary integration test is still present. The test finds these gaps. Your vulnerability scanner does not.

A network penetration test is a controlled, authorized simulation of external or internal attacks against your network infrastructure, designed to determine what an attacker could access and how far they could move once inside. Unlike an automated vulnerability scan that flags open ports and missing patches, a network pentest attempts actual exploitation, tests your segmentation’s real-world effectiveness, and maps whether an attacker reaching one system can pivot to sensitive assets.

The network pentest answers questions that vulnerability scanning cannot:

• Can an external attacker actually breach the perimeter, or do your edge controls stop the known techniques?
• Once inside your network, what systems can an attacker reach, and how quickly?
• Does your network segmentation actually stop lateral movement, or is it broken?
• Can a compromised standard workstation become a foothold to Active Directory control?
• How far can an attacker move before detection systems catch them?

These questions sit at the intersection of your attack surface (what is exposed), your vulnerability management baseline (what is weak), and your defensive controls (what stops attackers). A network pentest validates all three.

External vs internal network testing

Network penetration tests split into two distinct scopes based on the attacker’s starting position. Both matter, and both test different defensive layers.

External network testing

External network penetration testing simulates an attacker with no initial access, attempting to breach the perimeter from the internet. The tester is positioned outside your network, scanning for exposed services, testing edge security controls (firewalls, intrusion prevention, DDoS mitigation), and attempting to gain initial access to internal systems.

External testing validates your perimeter controls:

• Are internet-facing services (web servers, VPNs, mail servers, DNS) properly hardened or do they expose vulnerabilities?
• Do your firewall rules block unexpected outbound connections from compromised internal systems?
• Can an attacker achieve code execution on an edge system (web server, load balancer) that might provide access to internal networks?
• Are there configuration weaknesses in your cloud security groups, WAF rules, or SSL/TLS implementations?

The external test typically takes 1-2 weeks. The tester conducts extensive reconnaissance—DNS enumeration, ASN lookups, public code repositories, LinkedIn profiles, email patterns—before attempting any exploit. This reconnaissance phase matters because real attackers spend significant time gathering intelligence before attacking. A good external pentest includes this reconnaissance, not just a skip to exploitation.

Internal network testing

Internal network penetration testing simulates an attacker who has already cleared the perimeter—either through social engineering, breach of a partner, or compromise of a VPN user account—and is now attempting to move laterally and reach sensitive assets.

Internal testing validates your internal defenses:

• Network segmentation: Can the attacker move from a standard workstation to sensitive network segments?
• Active Directory: How quickly can privilege be escalated to domain admin?
• Trust relationships: Are there misconfigurations between domains, forests, or security groups?
• Lateral movement: What systems can an attacker reach, and through which paths?
• Detection: How long before security monitoring catches the attacker’s presence?

Internal testing typically takes 2-3 weeks because the lateral movement and privilege escalation chains are more complex than edge testing. A good internal pentest includes targeted testing of your segmentation boundaries—the tester intentionally attempts to cross from non-sensitive to sensitive network segments to validate your controls actually work.

Operator note: The Active Directory attack path finding that appears most consistently in internal pentests is unconstrained delegation misconfiguration — service accounts that were granted broad delegation permissions for a legitimate integration years ago and were never cleaned up. This is not an exotic attack technique. It is a standard check any competent tester runs in the first two hours. If your organization runs Windows Active Directory and has never done an internal pentest, assume this finding exists until proven otherwise. Run BloodHound against your own environment before the pentest does. The finding will either disappear or you will have remediated it before the report makes it worse.

Scoping a network penetration test

The most common reason network pentests produce worthless findings is poor scoping. A badly scoped test either covers too narrow a range to validate real attack paths or defines such a broad scope that the tester cannot complete the work meaningfully within budget.

IP range definition

Define the exact IP ranges in scope. This sounds simple but often is not. Many organizations discover during a pentest that they do not have a complete, accurate network diagram. Cloud infrastructure, legacy systems, branch offices, and partner connections often sit outside the primary scope definition. Before engaging a tester, inventory your actual IP space:

• All production network ranges (on-premises data centers, cloud VPCs, hybrid connections)
• All non-production ranges that touch production (development, staging, integration environments)
• All out-of-band management networks (IPMI, remote hands, console servers)

Exclude third-party infrastructure and systems you do not own, but be explicit about this decision. Many organizations exclude their cloud infrastructure, then are surprised to discover that lateral movement from an on-premises workstation to a cloud database is possible because of poor cloud networking configuration.

Segmentation boundaries to test

Define which segmentation boundaries the test should validate:

• Payment network isolation from general corporate network
• PCI scope boundary (if applicable)
• Healthcare or sensitive data enclaves (if applicable)
• Production vs non-production isolation
• Guest or contractor networks
• OT/operational technology networks (if applicable)

The tester should document whether they can move across these boundaries. A finding that says “segmentation between guest and corporate networks is ineffective—an attacker could move from guest WiFi to internal file servers” is a finding. A report that never tests these boundaries is incomplete.

Active Directory scope

If your environment runs Active Directory, define the scope:

• All domains in the forest
• Trust relationships between domains
• Service accounts and their privileges
• Delegation settings (unconstrained delegation, resource-based delegation)

A thorough internal pentest includes specific testing of AD attack paths. This is not generic “weak AD configuration” but specific chains like: “an attacker obtained the credentials of a service account, which was granted unconstrained delegation to a critical server, allowing a ticket-granting ticket (TGT) to be harvested and used for lateral movement.”

Network penetration testing methodology

A quality network pentest follows a distinct methodology across five phases. This structure is important because it determines what the tester actually tests versus what they claim to test.

Phase 1: Reconnaissance and information gathering

The tester gathers intelligence about your environment without touching systems:

• Passive reconnaissance: DNS enumeration, WHOIS lookups, certificate transparency logs, public code repositories, employee information leaks on LinkedIn or GitHub
• Active reconnaissance: Port scanning, OS fingerprinting, service version detection, DNS zone transfers if misconfigured
• Social engineering targeting: Email pattern collection, phone number research, VoIP enumeration

External reconnaissance can take several days. A good pentest includes this phase explicitly in the statement of work, because it mirrors what real attackers do. A report that skips reconnaissance and jumps to exploitation is missing a critical phase.

Phase 2: Enumeration and vulnerability scanning

The tester maps the target environment more deeply:

• Open ports and services on each target system
• Application banners and version information
• Identifying systems running vulnerable software versions
• Mapping authentication mechanisms (LDAP, Kerberos, local accounts)
• Cloud environment configuration review (S3 bucket policies, IAM permissions, security group rules)

This phase identifies the initial attack surface. The findings from this phase inform which targets are worth attempting exploitation against.

Phase 3: Exploitation and initial access

The tester attempts to gain initial access to systems. This might be:

• Exploiting a known vulnerability in an exposed service
• Credential harvesting (phishing simulator, password spraying against exposed services)
• Abusing default configurations or hardcoded credentials
• Compromising a VPN or remote access solution
• Social engineering for credentials or physical access

A quality pentest documents which exploitation techniques worked and which did not. A report that lists all the tools used but does not clearly state which specific exploits resulted in system compromise is unclear about what actually worked versus what the tester tried.

Phase 4: Privilege escalation and lateral movement

Once the tester has initial access to a system, they attempt to move laterally and escalate privileges:

• Vertical escalation: Local privilege escalation on the compromised system (kernel exploits, misconfigured services, sudo misconfigurations)
• Horizontal movement: Moving from the compromised system to other systems on the network (pass-the-hash, credential reuse, exploiting trust relationships)
• Segmentation testing: Attempting to cross network boundaries to reach sensitive segments
• AD attack chains: Enumerating AD structure, identifying delegation weaknesses, escalating to domain admin

This phase is where network pentesting differs from vulnerability scanning. The tester is not listing findings in isolation; they are chaining them into real attack paths. An AD attack path might be: “From the compromised user account, the tester enumerated service accounts, found that Account A had unconstrained delegation enabled, forged a TGT, and gained domain admin access.”

Phase 5: Reporting and remediation guidance

The final phase is documenting findings and recommendations:

• Confirmed exploitable vulnerabilities: Findings the tester actually exploited, with evidence and business impact
• Attack chains: The sequences of steps that led from initial access to sensitive assets
• Segmentation findings: Specific documentation of which segmentation boundaries were breached
• Detection gaps: The tester documents how long they operated in the environment undetected
• Remediation priority: Recommendations ranked by actual validated risk, not CVSS scores

Black box, gray box, and white box testing

Network pentests vary in the starting assumptions and information provided to the tester.

Black box testing assumes the tester has no prior knowledge of your environment—they start with only a domain name or IP range. This mimics an external attacker approaching your organization. External network pentests are almost always black box because the tester should not have insider information.

Gray box testing provides limited information—perhaps network diagrams, a list of systems in scope, or documentation of your architecture. This is more realistic for internal testing because an insider or compromised employee would have some organizational knowledge. Gray box testing is more efficient because the tester spends less time on reconnaissance that might not be relevant.

White box testing provides complete access: network diagrams, source code access if applicable, database schemas, Active Directory documentation. The tester is focused entirely on exploitation and attack path validation rather than discovery. White box is rarely used for network testing (it is more common for application testing) but can be appropriate for validating a new security architecture where you want to ensure the design assumptions hold even with complete environmental knowledge.

Reading a network penetration test report

A network penetration test report should be a narrative of attack paths, not a finding list. Many vendors and consultants produce reports that look like vulnerability assessment output—a spreadsheet with 50 findings ranked by CVSS score. This is a sign that the pentest was mediocre.

A quality network pentest report includes:

Executive summary: One-page summary of what the tester could actually achieve. Example: “An external attacker could reach the customer database within four hours using techniques that would evade detection for two days.” This is threat-relevant. A mediocre summary lists findings by count: “47 critical, 120 high, 83 medium.”

Attack narratives: For each successful attack path, a detailed narrative showing the sequence of steps. Example: “The tester conducted OSINT to identify that mail.company.com was running an outdated Postfix version. Exploitation yielded shell access to the mail server. From the mail server, the tester enumerated the internal network, discovered a database backup server on a misconfigured network segment, and accessed all customer records.”

Evidence: Screenshots, command output, data samples, network traffic captures that prove exploitability. Do not trust a report that claims “SQL injection was found” without showing the actual query being injected and the response proving data extraction.

Segmentation validation: Specific documentation of which network segments were crossed, whether they should have been isolated, and what compensating controls failed. Example: “The intended segmentation between payment network and guest network is ineffective due to misconfigured VLAN tagging on switch port 23. An attacker reaching guest network can ping internal payment systems.”

AD attack paths: If applicable, specific AD attack chains with clear step-by-step documentation of how the attacker moved from initial compromise to domain admin.

Detection and response gaps: Documentation of how long the tester operated undetected, which security monitoring should have caught the attacker, and why it did not.

Exploitability vs severity: For each finding, clarity on whether it was confirmed exploitable or theoretical. A finding that says “SQL injection was discovered but could not be exploited due to input filtering compensating controls” is useful. A CVSS score without this context is not.

Comparing external vs internal network tests

Choosing a network penetration testing provider

The quality variance between network penetration testing firms is enormous. Many consultancies deliver checkbox reports that read like vulnerability assessments. Finding a provider that actually tests what matters requires specific evaluation criteria.

Methodology clarity: Ask the provider to describe their specific methodology for your scope. Do they include reconnaissance as a distinct phase? How much time is allocated to segmentation testing? How do they validate Active Directory attack paths? A provider who gives vague answers (“we follow industry best practices”) is a red flag. A provider who describes a specific methodology adapted to your environment is more credible.

Team composition: Who executes the test? If the entire engagement is conducted by a single mid-level consultant with supervision, that is concerning. Quality network pentests involve senior testers capable of adapting when expected paths are blocked. Ask about the team lead’s certifications (OSCP, GPEN) and years of experience.

Segmentation testing specificity: Ask whether the provider will specifically test segmentation boundaries you define and document which boundaries are broken. A provider who includes segmentation testing as a distinct scope item is more thorough than one who tests it opportunistically.

Active Directory focus: If AD is central to your environment, confirm the provider has specific expertise in AD attack path testing. Ask for redacted examples showing documented attack chains within their previous client reports (with names removed).

Sample reports: Request redacted samples. Look for narrative attack chains, specific evidence of exploitation, and clear communication of validated risk. If the samples look like vulnerability assessment output, keep looking.

Credentials and certifications: OSCP (Offensive Security Certified Professional), GPEN (GIAC Penetration Tester), or similar indicate foundational offensive security competence. But certifications are table stakes, not differentiators. The report quality is.

Remediation independence: Avoid providers who also sell the security tools or services they recommend for fixing findings. A provider who recommends specific vendors for remediation should not have financial ties to those vendors.

Frequency and compliance drivers

For external network tests: Annual minimum is table stakes. After major perimeter changes (new cloud infrastructure, major firewall upgrade, new remote access solution), a targeted external test focused on the changed areas is worth the cost. If you detect an external-facing vulnerability during the year, a follow-up external test may be warranted to ensure compensating controls are sufficient.

For internal network tests: Annual minimum. Increase to semi-annual if your network topology changes frequently or if incident response has identified active lateral movement. Quarterly testing is warranted if you have a high-risk environment (financial services, healthcare, regulated critical infrastructure).

Compliance frameworks impose testing frequency mandates that override these general guidelines:

• PCI DSS: Requires both annual external and internal network penetration testing. After “significant infrastructure change,” both tests must be re-run. Segmentation testing is explicitly called out if you are using segmentation for PCI scope reduction.
• SOC 2: Does not mandate network pentesting by name, but auditors expect evidence of control validation. Many SOC 2 engagements include annual network penetration testing to demonstrate control effectiveness.
• HIPAA: Does not explicitly mandate network penetration testing, but OCR enforcement has cited absence of network security testing as a contributing factor in breaches. Best practice is annual testing.
• NIST CSF 2.0: Includes network security assessment and penetration testing as part of the Protect function.

Common findings in network penetration tests

Understanding the findings you are likely to encounter helps you evaluate reports and prioritize remediation.

Segmentation failures are the most common and highest-impact findings. An attacker who can move from a non-sensitive network segment to a sensitive one has broken a foundational control. This might manifest as:

• VLAN hopping via misconfigured trunk ports
• Routing misconfigurations allowing cross-segment traffic
• Lack of ACLs between network segments
• Broadcast domain overlap

Lateral movement via credential reuse is frequently successful. When a single service account password is hardcoded in multiple systems or when local administrator passwords are reused across workstations, an attacker compromising one system gains credentials for many others.

Active Directory privilege escalation via delegation weaknesses is extremely common. Unconstrained delegation, resource-based delegation misconfiguration, or abuse of service account privileges allows an attacker to escalate from a standard user account to domain admin in a handful of steps.

Lack of network monitoring or insufficient detection means attackers operate undetected for extended periods. A finding that “the tester exfiltrated 5 GB of data over three weeks and no detection occurred” is a detection gap, not a network vulnerability, but it is equally critical.

Weak or default credentials on network infrastructure (switches, routers, firewalls, management interfaces) allow direct compromise of network devices. This is rarer in modern environments but still occurs in legacy infrastructure.

Building a sustainable network testing program

A one-time network penetration test checks a compliance box. A repeating program reduces risk.

Establish regular testing cadence: annual minimum for external tests, semi-annual for internal tests if your environment is volatile. Schedule tests around your release calendar so findings can be remediated without disrupting production.

Feed findings into your vulnerability management workflow. Do not treat pentest findings separately from vulnerability scanner findings—assign owners, set remediation SLAs, and track closure like any other security finding.

Track metrics that prove the program works: closure rate of previous findings, mean time to remediate by severity, year-over-year trend in segmentation effectiveness. If your internal pentest findings are not declining year-over-year, the remediation program is producing reports, not outcomes.

Operator note: The metric that most reliably predicts whether a network testing program is producing outcomes versus producing reports is the re-finding rate — the percentage of findings from the previous test that appear again in the current test. A re-finding rate above 30% means remediation is not sticking: fixes are partial, the root cause was not addressed, or the same configuration drift is recurring. Track re-finding rate annually. When it goes down, the program is working. When it stays flat, the remediation workflow has a structural problem.

Use internal testing to validate that your security posture assessment is actually improving. If an internal pentest in year two finds the same AD attack paths as year one, your remediation did not work.

Link network testing to incident response. When you detect lateral movement during an incident, that finding should trigger a follow-up network pentest focused on the attack path the attacker used. This ensures that both your immediate remediation and your broader network hardening address the actual threat.