External and Internal Network Penetration Testing

Network penetration testing splits into two exercises that share a name and almost nothing else. Buying the wrong one is the most common mistake in this part of the market.

External: what the internet can reach

The tester works from outside your perimeter with no access, and establishes what is exposed and what can be done with it.

The first phase is discovery, and it is frequently the most valuable part of the engagement. The tester enumerates your address ranges, domains and subdomains, and finds what is actually listening. This routinely produces hosts nobody in the organisation knew were reachable — a development server stood up for a project that ended, a management interface exposed when a firewall rule was widened for a migration, an appliance that came with a public interface enabled by default.

The corrected inventory is an output in its own right, and on a first external test it is often worth more than the vulnerability list. You cannot defend what you did not know you had.

What gets examined once the surface is mapped:

• Remote access — VPN concentrators, RDP and SSH exposed directly, remote management tooling. Edge appliances are a persistent source of serious, widely exploited vulnerabilities, and version currency here matters more than almost anywhere else in an estate.
• Services that should not be public — databases, caches, message queues, container and orchestration APIs, backup interfaces.
• Authentication on anything exposed, including default credentials, which continue to work far more often than anyone expects.
• Transport security — protocol and cipher configuration, certificate validity and coverage.
• Subdomain takeover, where a DNS record still points at a cloud resource that has been released and can be claimed by somebody else.

Internal: what an intruder does once inside

The tester is placed on your internal network — on site, or through a device or virtual machine you host — and works from the position of someone who has already got in, whether through a phished credential, a compromised laptop, or an unattended socket in a meeting room.

The question is not whether they can get in. It is assumed. The question is how far the position can be extended, and what it reaches.

Findings that recur in a large proportion of internal engagements:

• Credential reuse across the estate — one local administrator password shared by every workstation turns a single compromised machine into all of them.
• Name resolution poisoning — legacy broadcast protocols that can be answered by an attacker, capturing authentication material from machines that asked politely for directions.
• Missing SMB signing, which allows captured authentication to be relayed onward rather than merely collected.
• Service accounts with weak passwords and high privilege, recoverable offline once a ticket has been requested for them.
• Directory misconfiguration — excessive delegation, accounts exempt from pre-authentication, permissions granted years ago for a reason nobody remembers.
• Unpatched and end-of-life systems kept alive because one application depends on them.
• Overly permissive file shares, which is where credentials in spreadsheets and scripts are found.
• Exposed hardware management interfaces, which sit below the operating system and are frequently outside the patching process entirely.

An internal test almost always produces more findings than an external one, because internal networks were built for people who were trusted.

Segmentation testing

A distinct exercise, and one that is sometimes a requirement rather than a choice. The tester sits in one network segment and attempts to reach another — proving that the boundary you have documented is the boundary that exists.

Under PCI DSS v4.0, where segmentation is used to reduce the scope of the cardholder data environment, those controls must be tested at least once every twelve months (requirement 11.4.5), and at least once every six months for service providers (11.4.6). If you are claiming reduced scope on the basis of segmentation, that claim is only as good as its most recent test.

It is worth scoping explicitly, because it is easy to assume it is included in an internal test and find that it was not.

What the tester needs

• Address ranges in scope, and ranges explicitly out of it. This matters more than in application testing, because network ranges contain things nobody remembers putting there.
• Written confirmation for anything you do not own. Cloud providers have their own testing policies; a hosting provider's equipment is not yours to authorise. This is the single most common scoping error in network work, and it is the one with legal consequences.
• Connectivity for internal testing — a network drop, a virtual machine, or a device shipped to site, decided in advance.
• A named contact reachable during testing, and agreement on what happens if something falls over.
• A decision on whether your monitoring team is told. Telling them tests the network. Not telling them also tests whether anyone notices — which is useful, and needs deliberate agreement rather than being discovered halfway through.

What it does not answer

A network test examines the infrastructure. It does not assess your web applications beyond the fact that they are listening — an application on port 443 is a host with a service to a network test, and a whole engagement to an application test. If your risk concentrates in a customer-facing application, a network test is not the exercise that will find it, and web application penetration testing is.

It also stops short of a red team exercise. A network test enumerates and demonstrates within an agreed scope and timeframe; a red team pursues a specific objective by whatever route works, including people and physical access, and measures whether you detect it. Different questions, different budgets.

For where network testing sits within a wider engagement, see what a VAPT actually is.