What is network penetration testing?

Network penetration testing is an authorised assessment that simulates an attacker probing a network to find and exploit security weaknesses. It covers external (internet-facing) and internal (post-foothold) perspectives, evaluates infrastructure, services, authentication, segmentation, and Active Directory, and produces evidence-based findings with prioritised remediation guidance.

What is the difference between external and internal network penetration testing?

External testing targets internet-facing assets such as VPNs, mail servers, web infrastructure, edge firewalls, and exposed services. Internal testing simulates an attacker who has already gained a foothold (a phished employee, a malicious insider, or a compromised device) and evaluates segmentation, Active Directory weaknesses, lateral movement, and privilege escalation paths. Mature programmes run both because they answer different questions.

How long does a network penetration test take?

Duration depends on scope. A small external estate (under 50 hosts) typically takes 3 to 5 testing days. A medium internal network with Active Directory may take 5 to 10 days. Large multi-site enterprises with complex segmentation can run 15 days or longer. Add time for scoping, retests, and reporting. Continuous coverage between annual assessments is increasingly expected.

What tools are used for network penetration testing?

Reconnaissance and scanning use Nmap, Masscan, and dedicated vulnerability scanners. Exploitation uses Metasploit, custom proof-of-concept code, and CVE-specific scripts. Active Directory testing uses BloodHound, Impacket, CrackMapExec, Rubeus, and Mimikatz. Wireless testing uses Aircrack-ng and Kismet. The choice of tool matters less than methodology and the tester documenting reproduction steps clearly.

Does a network penetration test satisfy compliance requirements?

Yes, when scoped correctly. PCI DSS requirement 11.4 mandates internal and external network penetration testing at least annually and after significant change. ISO 27001 A.12.6.1 expects technical vulnerability management with assessment evidence. SOC 2 CC4.1 expects monitoring and assessment activities. HIPAA risk assessment expectations and Cyber Essentials Plus also accept network penetration testing as evidence when methodology and qualifications are documented.

How often should network penetration tests be run?

At minimum annually and after any significant infrastructure change (new internet egress, network segmentation change, major Active Directory restructure, or new sensitive system). Combine periodic deep tests with continuous automated scanning so configuration drift, new CVEs, and exposed services are caught between assessments rather than waiting twelve months.

What deliverables should a network penetration test produce?

A clear written report with executive summary, scope, methodology, prioritised findings (with reproduction commands and CVSS scores), an attack narrative explaining how chained findings led to compromise, and remediation guidance per finding. Findings should also be available in a portal so engineering and infrastructure teams can pick them up directly, mark them ready for retest, and track remediation status. A static PDF alone is no longer sufficient for teams operating continuously.

What is the difference between a vulnerability scan and a network penetration test?

A vulnerability scan is automated discovery: it enumerates services, matches versions to CVEs, and reports possible weaknesses. A penetration test goes further: a human tester validates findings, chains them to demonstrate real impact, and tests business logic, segmentation, and privilege escalation paths that scanners cannot reason about. Both belong in a programme. Automated scans run continuously; pentests run periodically and dig deeper.

← Back to Blog

Guides6 May 202615 min read

Network Penetration Testing Checklist: A Practical Guide

Networks remain the connective tissue of every breach narrative. An exposed service, a misconfigured firewall rule, an old domain controller, a flat segment, and the attacker chains them into domain compromise. This checklist covers the practical steps for scoping, executing, and reporting on external and internal network penetration tests, with dedicated coverage for Active Directory, segmentation, and continuous follow-up. It aligns with structured pentest methodology and frameworks such as PTES and NIST SP 800-115.

Why Networks Need Their Own Checklist

Web, API, and mobile checklists focus on application logic. Network testing is a different discipline. The findings sit at layers 3, 4, and 7: routable services, authentication protocols, identity infrastructure, segmentation, and trust relationships. Most major breaches that progress beyond initial access do so because the network gave the attacker room to move, not because a single application failed.

A good network test answers three questions. What is exposed externally that should not be. Once an attacker is inside, how far can they reach. And how quickly does the blue team detect or contain the activity. The checklist below is structured around those questions, with an external phase, an internal phase, and Active Directory depth where it applies.

For complementary application coverage, see the web application pentest checklist, API security testing checklist, and mobile application pentest checklist.

1. Scoping and Pre-Test Preparation

Network engagements live and die by scoping. An ambiguous CIDR or an undeclared cloud VPC eats days of testing time and produces findings the client cannot action. Lock scope down before any packets leave the lab.

Define scope precisely: exact CIDR ranges, hostnames, AWS accounts and VPCs, Azure subscriptions, on-premises subnets, and third-party hosted services. List in-scope and explicitly out-of-scope assets.
Pick the perspective: external only, internal only, or both. Internal tests need a network drop, a connected jump host, or a VPN. Document where the test originates.
Identify sensitive systems: domain controllers, ICS/OT, medical devices, payment processors, life-safety systems. Decide upfront whether they are testable, scan-only, or fully excluded.
Verify ownership and authorisation: the client must own or operate every in-scope asset. For external scopes, use domain verification and a signed authorisation letter. SecPortal supports DNS TXT and meta tag verification before any external scan runs.
Set rules of engagement: testing windows, authorised source IPs, escalation contacts, denial-of-service limits, social engineering boundaries, and what to do on detection of real intrusion or sensitive data exposure.
Plan for safety: rate-limit aggressive scans against fragile devices, avoid weaponised payloads on production unless approved, and have a rollback plan for accidental service impact.
Confirm reporting expectations: deliverable format, retest scope, finding portal access, evidence handling, and timeline. Agree the scope of work in writing.

2. External Reconnaissance and Discovery

External testing starts with the perimeter the attacker actually sees. Build the inventory before scanning so coverage is honest.

Enumerate domains, subdomains, and hostnames using passive sources (CT logs, DNS records, search engines)
Discover cloud-hosted assets across AWS, Azure, and GCP that map back to the organisation
Identify shadow IT: forgotten subdomains, dev environments exposed to the internet, vendor-hosted instances
Resolve every hostname and confirm IPs land within the agreed scope
Capture publicly-exposed third-party services (mail, support, marketing) and decide if they belong in scope
Document the inventory before scanning so coverage gaps are visible

SecPortal's attack surface management and external scanning modules cover subdomain enumeration, cloud exposure, and fingerprinting as a starting inventory, which a human tester then validates and prioritises.

3. Port Scanning and Service Enumeration

Once the inventory is locked, enumerate listening services. Be deliberate: aggressive scans against fragile devices cause outages and waste credibility.

Run TCP scans across all 65,535 ports on every in-scope host (not just the top 1,000)
Run UDP scans on common services (53, 67, 69, 123, 161, 500, 514, 1434)
Identify service versions, banners, and TLS configuration on each open port
Map running protocols to authentication endpoints (SSH, RDP, SMB, LDAP, IPMI, web admin)
Flag services that should never be internet-facing (RDP, SMB, RPC, MSSQL, SNMP, Redis, MongoDB)
Capture TLS misconfigurations, expired certificates, weak ciphers, and missing HSTS

For TLS spot-checks during testing, the SSL checker and security headers analyser provide quick verification alongside a full scanner pass.

4. External Vulnerability Identification and Validation

Scanners find candidates. The tester validates. False positives are toxic to trust; unconfirmed findings should not appear in a final report.

Match service versions to known CVEs, especially actively exploited issues on the CISA KEV catalogue
Validate every CVE candidate manually before reporting (banner version is necessary but not sufficient)
Test default and weak credentials on management interfaces, databases, and IPMI
Check for anonymous access on FTP, SMB, NFS, LDAP, and snmp public
Identify exposed VPN concentrators and test for known weaknesses (Pulse, Citrix, Fortinet, GlobalProtect)
Probe email infrastructure: open relay, SPF, DKIM, DMARC, and authentication bypass
Look for exposed admin panels, dev environments, and management consoles
Capture screenshots and request/response evidence on every confirmed finding

5. Internal Network Testing

Internal testing assumes the attacker has a foothold. The objective is to measure how quickly that foothold becomes domain-wide compromise and what stops it along the way.

Initial reconnaissance from the foothold

Map the local subnet and adjacent subnets, then probe routing into other segments
Identify the domain, domain controllers, time servers, and DNS servers
List file shares, printers, network appliances, and management interfaces visible from the foothold
Capture broadcast and multicast traffic (LLMNR, NBT-NS, mDNS, IPv6) for relay opportunities
Test segmentation by attempting to reach known sensitive segments (PCI, OT, dev, lab)

Common internal weaknesses

SMB signing not required (NTLM relay across the network)
LLMNR and NBT-NS poisoning capturing NetNTLM hashes
IPv6 DHCPv6 takeover (mitm6) used to relay to LDAP and ADCS
Unauthenticated SMB shares, IPC$ enumeration, and null session disclosure
Unpatched Windows hosts vulnerable to PrintNightmare, Zerologon, NoPac, PetitPotam
Default credentials on switches, routers, iDRAC/iLO, IPMI, and printers (often domain-joined)

6. Active Directory Testing

Active Directory is the centre of gravity for most internal tests. The patterns below are not exotic; they appear in nearly every engagement. For a deep dive on identity attacks, see our Active Directory penetration testing guide.

Enumeration

Enumerate users, groups, computers, GPOs, trusts, and OUs with authenticated and (where possible) unauthenticated access. Build a BloodHound graph and identify shortest paths to high-value targets (Domain Admins, Tier 0 assets, sensitive groups).

Kerberos attacks

AS-REP roasting accounts with pre-auth disabled, Kerberoasting service accounts with weak passwords, unconstrained delegation abuse, constrained delegation abuse, and resource-based constrained delegation (RBCD) takeover.

ADCS misconfigurations

Active Directory Certificate Services has dozens of well-known misconfigurations (ESC1 through ESC11+) that allow privilege escalation. Test certificate template permissions, enrolment rights, and CA configuration. Recover NTLM hashes via certificate authentication where possible.

Credential harvesting and movement

Look for cleartext passwords in GPOs, scripts, scheduled tasks, SYSVOL, file shares, and SCCM. Test for password reuse across local administrators, weak LAPS deployments, and stored credentials on jump hosts. Demonstrate lateral movement via WMI, WinRM, SMB, and PsExec where authorised.

Persistence and detection

Where the engagement allows, demonstrate persistence techniques (golden ticket, silver ticket, DCSync) at proof-of-concept depth and document whether the blue team detected each step. Persistence demonstrations should always be coordinated with the client to avoid contaminating production logs.

7. Privilege Escalation and Lateral Movement

Once a host is owned, escalate locally and pivot. Track each chain so the report shows the full attack narrative, not isolated weaknesses.

Local privilege escalation: missing patches, vulnerable services, unquoted service paths, weak permissions on binaries
Linux escalation: SUID binaries, sudo misconfigurations, kernel exploits, world-writable cron jobs, capability abuse
Container and Kubernetes escapes where applicable to in-scope clusters
Token impersonation, credential dumping (LSASS, SAM, DPAPI), and browser-stored credentials
Pivoting through multi-homed hosts to reach segmented networks
Demonstrating impact: read access to sensitive data, code repositories, backup systems, and identity providers
Documenting every chain step with command, output, and timestamp for the report

8. Wireless, VPN, and Edge Coverage

Where wireless or remote access falls in scope, give it dedicated time. These paths often bypass internal segmentation entirely.

Wireless: SSID discovery, WPA2/WPA3 testing, evil twin and rogue AP risk, guest segmentation
802.1X bypass paths: MAC authentication bypass, fake supplicants, abandoned exemptions
VPN concentrators: known CVEs, weak authentication, missing MFA, split-tunnel exposure
Remote access gateways: Citrix, RDP gateways, Jump hosts, Bastion configurations
Cloud egress and ingress: security group review, exposed management ports, misconfigured load balancers
Network device hardening: SSH/Telnet exposure, SNMP community strings, default credentials, firmware level

9. Reporting and Remediation

A list of findings without context is rarely actioned. Structure the deliverable so infrastructure, identity, and security teams can pick it up without needing the tester in the room.

Executive summary with business impact, attack narrative, and headline risk picture
Technical findings, each with reproduction commands, evidence, and CVSS score validated using the CVSS calculator
Attack chain diagrams showing how chained findings led to compromise (BloodHound paths, network maps)
Remediation guidance per finding, distinguishing root cause from compensating control
Mapping to compliance frameworks (PCI DSS 11.4, ISO 27001 A.12.6.1, SOC 2 CC4.1, NIST SP 800-115)
Delivery in a portal that supports retest workflows and persistent remediation status, not only PDF
Use CVSS plus EPSS plus asset context to set remediation order, not raw severity alone

SecPortal's findings management ships with templates for common network findings, AI-generated reports for executive and technical summaries, and a client portal for remediation tracking. See the report template for the full structure.

10. Continuous Coverage Between Tests

Annual penetration tests are necessary but not sufficient. New CVEs, configuration drift, and forgotten services appear weekly. Pair the periodic test with continuous coverage so the next assessment is not the first time anyone looked.

Schedule recurring external scans with continuous monitoring (daily, weekly, or monthly) and alert on new exposures
Run authenticated scans behind the perimeter to catch drift on patched-then-rolled-back hosts
Track trend lines: open ports per host, unique services, certificates expiring, CVE backlog age
Triage every change as a finding so the audit trail is unified, not split across tools
Treat scanner output as input to a human reviewer, never the final word

For programme-level structure, see building continuous security monitoring and the vulnerability management programme guide.

The Quick Checklist

A condensed version to use during the engagement.

Lock scope to exact CIDR ranges, accounts, and segments; document out-of-scope explicitly
Verify domain ownership and signed authorisation before any external packet
Build the external inventory (subdomains, cloud, shadow IT) before scanning
Run full TCP plus targeted UDP scans; capture banners, versions, and TLS posture
Validate every CVE manually; never report unconfirmed findings
Test default credentials and anonymous access on every management interface
From the internal foothold, test segmentation against every protected segment
Capture LLMNR/NBT-NS/IPv6 traffic and test SMB signing, NTLM relay, and ADCS
Build a BloodHound graph and identify shortest paths to Tier 0 assets
Demonstrate Kerberoasting, AS-REP roasting, and delegation abuse where present
Test ADCS templates against the ESC catalogue
Walk the attacker chain end-to-end and document every step
Cover wireless, VPN, and remote access where in scope
Score with CVSS, prioritise with EPSS plus asset context, deliver in a portal that supports retest
Schedule continuous external and authenticated scans between assessments

Frequently Asked Questions About Network Penetration Testing

Run network penetration tests with findings tracked, retested, and reported in one place

SecPortal gives security teams external scanning, authenticated dynamic coverage, attack surface management, CVSS scoring, AI-assisted reporting, and a branded client portal so network assessments reach engineering with everything they need to remediate. See pricing or start free.

Get Started Free