Network Penetration Testing Checklist: Internal and External

A network penetration test has two halves that fail in different ways. The external half asks what an attacker on the internet can reach and get through. The internal half assumes that attacker already has a foothold, one phished laptop or one network drop, and asks how far they move from there. This network penetration testing checklist covers both, in the order a tester actually works, so you can prepare for a test, self-check before one, or hold a vendor’s methodology against a real yardstick.

Use it as a working document. Copy the sections that apply, treat each line as a question to answer rather than a box to tick, and be honest about the items you cannot check yourself, because those are usually where the findings are. It pairs with our full network penetration testing guide, which explains the why behind each phase, and the broader penetration testing checklist that also covers web and API work.

The network penetration testing checklist on one page

Phase	External	Internal
Scope	Public IP ranges, domains, cloud edges agreed in writing	Assumed foothold agreed: standard user, workstation, or drop
Discovery	Every live host, port and service found, not just your list	Every subnet and VLAN mapped, including ones nobody listed
Authentication	VPN, webmail and portals tested for weak passwords and missing MFA	LLMNR, NBT-NS and mDNS poisoning; SMB signing and NTLM relay
Identity	Password spray within lockout limits, breached-credential reuse	Active Directory: Kerberoasting, AS-REP roasting, ADCS, ACL abuse
Movement	Exposed management interfaces, edge device CVEs	Lateral movement, credential reuse across hosts, path to Domain Admin
Boundaries	TLS, DNS, email authentication, subdomain takeover	Segmentation between zones tested, not read from a diagram
Proof	Each finding exploited or shown reachable, with evidence	Each finding chained to real impact, with evidence
Close	Report, severity ratings, remediation, free retest	Report, severity ratings, remediation, free retest

The rest of this guide expands each row.

1. Scope and rules of engagement

Most engagements that disappoint were scoped badly, not tested badly. Settle these before anyone runs a tool.

• Define the test type. External, internal, or both. They answer different questions and most mature programs run both, because a clean perimeter says nothing about what happens after the first laptop falls.
• List the targets precisely. For external, every public IP range, domain, and cloud edge you own. For internal, the sites, subnets, and domains in scope. Name what is explicitly out of scope, such as a third-party SaaS platform you do not control.
• Agree the internal starting position in writing. An assumed-breach internal test usually starts from a standard domain user account, a managed workstation, or a physical network drop. Agree which, because it changes what the test proves.
• Set the rules of engagement. Testing windows, permitted techniques, whether denial-of-service and social engineering are in or out, and an escalation contact for a critical finding found mid-test.
• Confirm authorization. Written permission from someone who owns the systems. For cloud-hosted infrastructure, also check the provider’s penetration testing policy, because each cloud sets its own rules on what you may test without asking first.
• Decide the perspective. Black box, grey box, or white box. Grey box, where the tester gets some context and credentials, usually gives the best value because it skips the parts an attacker would eventually brute-force anyway.

2. External network checklist

The perimeter is what the internet sees. The goal is to find everything reachable, including the assets you forgot, then prove what an attacker can do with them.

Check	What good coverage looks like
Footprint discovery	Every public IP, domain and subdomain found, including shadow assets missing from your list
Ports and services	All TCP ports and the key UDP services on every live host, not just the top 1,000
Management interfaces	RDP, SSH, admin panels, and database ports that should never face the internet, flagged and tested
Edge devices	Firewalls, VPN gateways, and mail servers checked against known exploited vulnerabilities, with safe exploitation
Remote access	VPN, webmail, and portal logins tested for weak passwords, lockout gaps, and missing MFA
TLS and email	Weak protocols and ciphers, certificate problems, and missing SPF, DKIM, or DMARC recorded
DNS	Zone transfers, dangling records, and subdomain takeover checked
Firewall rules	What the rule set actually lets through from outside, compared with what it should
Proof	Each finding exploited or shown to be reachable, with evidence, not a scanner export

The external finding that matters most is often not an exploit at all. It is an asset nobody remembered: a forgotten staging server, an exposed admin panel, a VPN gateway missing a patch for a flaw on CISA’s Known Exploited Vulnerabilities catalog. Discovery matters more than exploitation, because you cannot defend what you did not know was exposed. Where a login page or management interface turns up, the exposure question becomes a firewall penetration testing question: should this be reachable from the internet at all?

3. Internal network checklist

An internal test starts where the external test usually cannot reach: inside. From an assumed foothold, the tester works toward the assets that matter, and the path almost always runs through Active Directory.

Check	What good coverage looks like
Starting position	The assumed foothold is agreed in writing and set up before testing begins
Discovery	Every live subnet mapped, including VLANs that were not on the diagram
Name resolution	LLMNR, NBT-NS, and mDNS tested for credential capture
SMB and relay	SMB signing and NTLM relay paths tested across the estate
Active Directory	Kerberoasting, AS-REP roasting, delegation abuse, ACL abuse, weak Group Policy, and the paths to Domain Admin
Certificate services	AD Certificate Services templates checked for the escalation paths that turn a low-privileged user into a domain admin
Credentials	Password spraying within lockout limits, shared local admin passwords, and secrets left in shares and scripts
Lateral movement	Where one set of credentials works across hosts and protocols
Segmentation	Sensitive zones (cardholder data, OT, backups) tested from other zones, not taken on trust from the diagram
Legacy systems	SMBv1, end-of-life operating systems, and known exploited vulnerabilities

Two facts shape a modern internal test. First, name-resolution poisoning still works: a tool such as Responder answering an LLMNR or NBT-NS broadcast that nothing else answered can capture a user’s NTLM hash within minutes on a default network, ready to crack offline or relay. Second, the relay defense has finally moved. Microsoft now requires SMB signing by default on Windows 11 version 24H2 Pro, Enterprise, and Education (inbound and outbound) and on Windows Server 2025 for outbound connections. Before that, signing was only required by default for connections to the SYSVOL and NETLOGON shares and where domain controllers demanded it. That closes a relay path on new builds, but every older Windows host still needs signing enforced by policy, which is why missing SMB signing remains one of the most common internal findings. Work the Active Directory section against a real target list rather than a wish list: our Active Directory security checklist breaks the identity attacks down control by control.

Wireless is tested on site with its own equipment, so scope it as a separate wireless penetration testing engagement rather than folding it into the internal test. If only the domain needs review, an Active Directory security assessment covers that half on its own.

4. Segmentation testing

Segmentation is the control that decides how much one compromised host is worth. A flat network turns one foothold into the whole estate; a well-segmented one contains it. Test it, do not assume it.

• Test from the other side. Prove what a host in the user VLAN can and cannot reach in the server, cardholder, or OT zone. A firewall rule that looks right in the console is not evidence; a blocked connection attempt is.
• Check both directions. Segmentation often leaks on the return path or through a shared management network nobody counted as a boundary.
• Map it to the requirement. For PCI DSS, segmentation testing is explicit: requirement 11.4.5 asks everyone who relies on segmentation to test it at least every 12 months and after any change to it, and 11.4.6 raises that to every six months for service providers. Our PCI DSS penetration testing requirements guide covers the cadence, and a standalone network segmentation testing engagement handles the six-monthly re-validation on its own.

5. Exploitation and validation

• Prove real impact. Each finding should demonstrate exploitability, not flag a theoretical risk. “This service is out of date” is weak; “this service let us run code and reach the backup server” is a finding.
• Chain small issues. The best internal findings connect several minor weaknesses into one real path. Confirm your tester chains, not just enumerates.
• Test safely. Destructive checks are avoided or scheduled, and production is handled with agreed safeguards.
• Escalate criticals immediately. A domain-wide compromise should reach you the same day, not wait for the report.
• Document as you go. Reproduction steps, commands, and screenshots captured while the issue is live.

6. Reporting, remediation and retest

The engagement is done when the fixes are verified, not when the report lands.

• A report you can act on. An executive summary, technical findings with reproduction steps, severity ratings mapped to CVSS and to business impact, and prioritized remediation. See what a real one looks like on our sample report page.
• Compliance mapping where it applies. If the test supports PCI DSS, SOC 2, or another framework, findings should name the requirement they evidence, so the auditor can file them without a translation step.
• Fix at the root. Address the class of flaw, so the same finding does not return next year. Our guide to vulnerability remediation covers prioritizing and closing findings for good.
• Retest. A good engagement includes a free retest, so the final report shows verified fixes rather than an open list. Every Invadel network penetration test includes one, at a price fixed in writing before work begins.

Frequently asked questions

What is the difference between an internal and external network penetration test? An external test attacks your internet-facing perimeter from outside with no prior access. An internal test assumes an attacker already has a foothold inside and measures how far they move, usually through Active Directory toward Domain Admin. Most organizations need both. Our guide on internal vs external penetration testing covers the distinction in depth.

How is a network penetration test different from a vulnerability scan? A scan lists known weaknesses from a signature database. A penetration test proves which of them an attacker can actually exploit and chain, and finds the misconfigurations and access-control gaps a scanner never sees. The network vulnerability assessment checklist covers the scanning side; this checklist covers the test.

How long does a network penetration test take? A small single-site network is about a week of testing plus reporting; multi-domain estates take longer. At Invadel, onboarding begins within 24 hours of a signed proposal and testing usually starts within a week of scoping.

What access do you need for an internal test? Whatever the agreed assumed-breach starting point requires: usually a standard domain user account, a managed workstation, or a physical or virtual network drop. We agree the exact starting position during scoping, because it defines what the test proves.

How often should we run a network penetration test? At least annually, and after any significant change to the network, such as a new site, a cloud migration, or a major segmentation change. PCI DSS makes that explicit: internal and external tests at least every 12 months and after any significant infrastructure or application change.

Fixed price, fixed scope, free retest. Internal network testing from $6,000, external from $4,200. Scope your test and get a written price within one business day.