External Network Penetration Testing Guide: Scope, Method, Evidence and Retest

Most intrusions still start at the internet edge, through a VPN portal, a remote access gateway or an exposed service that nobody remembered was there, and an external network penetration test is the controlled way to find those openings before someone else does. This guide goes deeper than the general Penetration Testing Guide on one test type: the perimeter test run from the internet against your public address space, domains and remote access services. It covers how to build a scope that matches your real attack surface, what a sound method looks like phase by phase, how to handle cloud providers' testing rules, what evidence and report content to demand, and how to turn findings into closed exposure. It is written for security managers who commission tests, for in-house testers, and for the engineers who own the edge.

Key takeaways

• Scope from attack surface data, not the CMDB. Seed the target list from DNS, certificate transparency, cloud accounts and an attack surface management feed, then have asset owners confirm ownership before testing.
• Remote access is the priority target. VPN, virtual desktop and remote management portals are where stolen passwords become network access, so test authentication strength and MFA coverage on every one.
• Cloud and hosted assets carry the provider's rules. Testing your own resources is usually allowed, but denial of service, flooding and certain DNS or takeover tests are prohibited by the providers' policies.
• Demand evidence, not scanner output. A useful report shows each finding with proof of exploitability, affected hosts, timestamps and source addresses that let your SOC match the activity.
• The test is a point in time. The NCSC describes penetration testing as assurance for your vulnerability management, not a replacement for it; retest fixes and keep continuous external scanning between tests.

What an external network test covers

An external network penetration test simulates an attacker with no prior access, working from the internet. The tester's goal is to find which internet-reachable services can be used to gain a foothold, read data or reach internal systems, and to prove it with controlled exploitation inside agreed rules. It differs from an external vulnerability scan, which lists likely weaknesses without proving them, and from a red team, which pursues a business objective with stealth across people, process and technology.

Typical targets are the organisation's public IPv4 and IPv6 ranges, registered domains and subdomains, mail gateways, DNS servers, VPN and secure access gateways, remote desktop and virtual desktop portals, file transfer services, exposed management interfaces, and internet-facing hosts in cloud accounts. Web applications found on the perimeter are usually enumerated and given a light review, while a full application test is scoped separately (see the API Penetration Testing Guide for APIs).

See the Attack Surface Management Guide for the discovery side and the Exposure Management and CTEM Guide for how tests feed a continuous programme.

Building the scope

The NCSC recommends that scoping involves the risk owners, technical staff who know the systems and a representative of the test team, and that you share your current vulnerability assessment so the test can check its accuracy. For an external test the most common scoping error is an incomplete target list: the CMDB lists what IT built, not what marketing, a subsidiary or a developer exposed last month.

1. Collect candidate assets: registered domains, DNS zones, certificate transparency results for your names, allocated IP ranges from your regional internet registry record and ISP contracts, public IPs and load balancers in every cloud account, SaaS custom domains, and the output of your attack surface tool.
2. Confirm ownership: every IP and hostname must be owned or explicitly authorised by its owner. Shared hosting, CDN edges and SaaS platforms are not yours to test even when they serve your domain; record them as out of scope or get the provider's written terms.
3. Classify by risk: mark remote access gateways, identity endpoints (SSO, federation, legacy authentication), file transfer, mail and management interfaces as priority targets.
4. Set the knowledge level: black box tests discovery as well as exploitation; grey box (you hand over the asset list and perhaps a low privilege account) spends the budget on depth. Many organisations run a grey box test with a short black box discovery phase to measure what an outsider can find.
5. Agree the rules of engagement: testing windows, source IP addresses of the testers, excluded hosts, whether password guessing is allowed and at what rate, whether exploitation may go beyond proof of access, data handling, and emergency contacts on both sides.
6. Get written authorisation: signed by someone with authority over every asset in scope, including any third party hosting provider whose terms require notice.

The Penetration Test Scoping Checklist gives a reusable list of scoping questions, and the Penetration Testing Policy Template sets who may approve tests.

Cloud provider rules

Providers are listed alphabetically. Each publishes its own rules, and they change, so re-read them before every test.

• Amazon Web Services: the AWS penetration testing policy lists services customers may test without prior approval, including EC2, Elastic Load Balancing, CloudFront, API Gateway and Lambda. It prohibits denial of service and simulated denial of service, port, protocol and request flooding, DNS zone walking through Route 53 hosted zones, and S3 bucket and subdomain takeover testing. Simulated events such as red team exercises need a form submitted at least two weeks in advance.
• Microsoft Azure: the Microsoft Cloud penetration testing rules of engagement allow customers to test their own tenant and assets, for example port scanning and vulnerability assessment of their own Azure virtual machines. They prohibit denial of service testing, using credentials that are not yours, and network intensive fuzzing, and require vulnerabilities found in Microsoft services to be reported immediately.

For other providers and SaaS platforms, read the acceptable use policy and service terms, and get written confirmation where they are unclear. See the Cloud Penetration Testing Guide for testing inside cloud accounts.

Method: the phases of an external test

NIST SP 800-115 describes testing as planning, discovery, attack and reporting. An external test follows the same shape, and each phase maps to attacker behaviour recorded in MITRE ATT&CK, which helps the SOC check what it saw.

Services that deserve the most attention

• Remote access gateways: SSL VPN, IPsec (IKE on UDP 500 and NAT traversal on UDP 4500), virtual desktop and Citrix style portals. Ask the tester to confirm every login path enforces MFA, including legacy or secondary portals. The Change Healthcare breach began with a stolen password on a remote access portal that did not require MFA. See the VPN Security Guide.
• Management interfaces: firewall and VPN admin pages, RDP (TCP 3389), SSH (TCP 22), SNMP (UDP 161), out-of-band management such as IPMI (UDP 623), hypervisor and storage consoles. None of these should answer from the internet; a finding here is usually high severity even without an exploit.
• File and data services: managed file transfer, SMB (TCP 445), FTP, database ports and exposed object storage endpoints.
• Mail and DNS: open relay tests, SPF, DKIM and DMARC posture, recursive resolvers open to the internet, and dangling DNS records that point to released cloud resources. See the Subdomain Takeover and Dangling DNS Guide.
• TLS configuration: protocol versions, weak cipher suites, expired or mismatched certificates. These are often low severity alone but signal unmanaged hosts. See the TLS Server Configuration Baseline Guide.

Where identity fits

Most external findings that lead to real access are identity findings: a portal that accepts a password alone, a legacy authentication protocol that bypasses Conditional Access, a default credential on an appliance, or an API key or token found in public code that still works. The SonicWall SSL VPN account compromises in 2025 show the pattern: the attackers appear to have held valid credentials for more than 100 VPN accounts (see the SonicWall VPN account compromises).

• Password guessing in scope: agree a rate below your lockout threshold, a list of accounts or a test account set, and a window when the SOC is told. Uncontrolled guessing locks out real users. See the Password Spraying and Credential Stuffing Defence Guide.
• Secrets found during reconnaissance: if the tester finds keys or tokens in public repositories, the rules of engagement should say whether they may validate them. Revoke and rotate anything found, whether or not it was tested.
• Credentials given to testers: grey box accounts are real accounts. Create them for the engagement, scope them minimally, and disable them on the last day.

See the Remote Access Identity Guide for the controls these tests should confirm.

Choosing the approach

Small vs large organisations: a small organisation with a handful of public IPs gets most value from one grey box external test a year plus a retest, combined with continuous external scanning. A large organisation with many ranges, subsidiaries and cloud accounts should split the perimeter into risk-ranked segments tested on a calendar, rotate suppliers to avoid blind spots, and feed results into exposure management. UK public sector and critical national infrastructure bodies can use companies under the NCSC CHECK scheme. See the Penetration Testing Provider Buyer's Guide.

Implementation: running one test well

1. Six to eight weeks before: build the asset list, confirm ownership, read cloud and hosting provider terms, and choose the supplier.
2. Two to four weeks before: sign the rules of engagement and authorisation, submit any provider notifications, create time-limited test accounts, and give the SOC the testers' source IPs and window.
3. The week before: confirm backups and change freezes for fragile services, agree a stop word and escalation path, and check that logging on edge devices is working so the test leaves evidence you can review.
4. During the test: hold a short daily check-in. Ask for immediate notification of critical findings, such as an exposed management interface or a working credential, rather than waiting for the report.
5. Stopping and rollback: if a service degrades, the stop word halts testing; the service owner restores from the pre-test configuration backup, and testing resumes only after the cause is understood.
6. After the test: disable test accounts, remove any artefacts the tester placed, hold the debrief, and record findings in your tracker with owners and dates (see the Penetration Test Remediation Tracker Template).
7. Retest: agree the retest window in the contract, typically within 30 to 90 days, and retest every high and critical finding.

Evidence and reporting

The NCSC expects a report to explain each issue, the risk it poses and how to fix it, and to give an opinion on how accurate your own vulnerability assessment was. CHECK reports rate findings HIGH, MEDIUM, LOW or INFORMATIONAL, and CVSS may be added but not used instead. Ask the supplier for:

• Executive summary: overall exposure, the attack paths that worked, and what to fix first.
• Per finding: affected host and port, description, proof (screenshots, request and response, redacted data), severity with reasoning, CVE and CVSS where applicable, and a fix that is specific to the product and version. See the CVSS v4 Guide.
• Activity log: tester source IPs and timestamps for each phase, so the SOC can match alerts to test activity and spot gaps.
• Discovered assets: anything found outside the confirmed scope, listed but not tested, so you can assign owners.
• Raw data: port scan results in a machine-readable format for comparison with the next test.

The NCSC also advises that risk decisions stay with you: consider alternatives to the suggested fix, such as removing the service, restricting it by source address or adding monitoring.

Detection and measurement

An external test is also a free detection exercise. Compare the tester's activity log with what the SOC saw from firewall, VPN, web application firewall and identity provider logs. See the VPN and Firewall Log Detection Guide.

• Unknown asset rate: share of tested assets that were missing from the inventory before the test. It should fall test on test.
• Exposed management interfaces: count of admin, RDP, SSH, SNMP or IPMI services reachable from the internet. Target zero.
• MFA coverage on internet-facing login endpoints: percentage of endpoints that refuse a password alone. Target 100%.
• Time to remediate: median days from report to verified fix for high and critical findings, against your policy target.
• Repeat findings: findings that reappear in the next test, a sign of process failure rather than technical difficulty.
• Detection rate: share of test phases (scanning, password guessing, exploitation) that produced an alert or a SOC ticket.

Framework mapping

The CIS Control 18 Penetration Testing Guide and the Penetration Testing Requirements Map list the wider compliance triggers.

Common failure patterns

• Scope copied from last year: the test covers ranges you no longer own and misses new cloud load balancers. Rebuild the asset list for every test.
• Wrong or unconfirmed targets: an IP typed wrongly or a hostname that resolves to someone else's server puts the tester outside authorisation. The Meta Muse Spark evaluation incident shows how a test configured with a real third party's website as its target caused real harm; confirm every target before the first packet.
• Remote access left out: secondary VPN portals, old Citrix gateways and vendor support portals are excluded because they are "managed by the supplier". They are still your attack surface.
• Testing blocked by the perimeter: the tester's IPs are blocked by an intrusion prevention system on day one, so the report describes the block rather than the services. Decide in advance whether you want to test the services or the blocking, and allowlist if it is the services.
• Report filed, nothing closed: findings without owners and dates repeat in the next test. Track them like any other vulnerability. See the Vulnerability Management Guide.
• Test accounts left active: grey box credentials remain enabled after the engagement and become a standing entry point.

Practitioner checklist

• Build the target list from DNS, certificate transparency, cloud accounts and attack surface data, and have owners confirm each asset.
• Read the hosting and cloud providers' testing rules and file any required notifications.
• Sign rules of engagement covering windows, source IPs, password guessing limits, exploitation depth, data handling and a stop word.
• Put every remote access and identity endpoint in scope and ask the tester to confirm MFA on each.
• Give the SOC the testers' source IPs and decide whether the test is announced.
• Require per-finding evidence, an activity log with timestamps, and raw scan data in the report.
• Close internet exposure of management interfaces immediately rather than waiting for the report.
• Disable test accounts and remove artefacts on the last day.
• Track every finding to closure with an owner and date, and retest highs and criticals.
• Run continuous external scanning between tests and compare results with the test output.

Standards and references

• NIST: SP 800-115 Technical Guide to Information Security Testing and Assessment
• NCSC: Penetration testing
• NCSC: CHECK penetration testing
• NIST: SP 800-53 Rev. 5 (CA-8, RA-5, CM-8)
• CIS: Control 18 Penetration Testing
• Amazon Web Services: Penetration Testing policy
• Microsoft: Microsoft Cloud Penetration Testing Rules of Engagement
• MITRE ATT&CK: Exploit Public-Facing Application

Related NHI Mgmt Group resources: Penetration Testing Guide · Attack Surface Management Guide · Penetration Test Scoping Checklist · Remote Access Identity Guide · Vulnerability Management Guide