External and Internal Network Penetration Testing

Network penetration testing covers two different exercises under a single name. Buying the wrong one is the most common mistake in this part of the market.

External: what the internet can reach

The tester starts outside your perimeter with no access and works out what is exposed and what can be done with it.

Discovery comes first. 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 a deliverable in itself. On a first external test it is often worth more than the vulnerability list.

Once the surface is mapped, the test covers:

• Remote access: VPN concentrators, RDP and SSH exposed directly, remote management tooling. Edge appliances are a persistent source of serious, widely exploited vulnerabilities. Their patch level matters more here 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 still work more often than they should.
• 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. From there they work as someone who has already got in: a phished credential, a compromised laptop, an unattended socket in a meeting room.

Getting in is taken as given. The test measures how far that position can be extended and what it reaches.

Findings that recur across 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, not just 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

This is a separate exercise, and in some cases a requirement. 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 claim reduced scope on the basis of segmentation, the claim is only as good as its most recent test.

Scope it explicitly. An internal test does not cover it by default.

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 where network scoping most often goes wrong. It is also the error that carries 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. Pick one before the test starts.

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. To a network test, an application on port 443 is one host running one service. An application test spends the whole engagement on it. If your risk concentrates in a customer-facing application, the exercise you want is web application penetration testing.

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.

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