Network penetration testing is one of the most commonly requested types of assessments for medium-to-large organisations. Pentesting is not a vulnerability scan. It is a methodical, consultant-led exercise to identify security weaknesses.
Here we explain what a network penetration test is, how it differs from a vulnerability scan, and what you can expect from a typical engagement.
External and internal testing: what’s the difference?
Network penetration testing comes in two flavours: external and internal. Both are designed to identify exploitable vulnerabilities in your network, but they start from different positions and have different objectives.
External network testing targets the systems and services your organisation exposes to the internet: firewalls, remote access services such as VPN, RDP, and SSH, mail servers, and any other internet-facing infrastructure. An external test starts from the same position as any unauthenticated attacker on the internet, with no access or credentials provided upfront.
Internal network testing simulates an attacker who has already gained a foothold inside your network, whether through a phishing email, a compromised VPN credential, or a vulnerable publicly accessible service. The tester is placed on the internal network and looks for ways to escalate privileges, move laterally between systems, and reach sensitive data or infrastructure.
If this is your first network test, an external assessment is usually the right starting point, since the majority of attack vectors originate at the network perimeter. Once you have confidence in your perimeter, testing your internal posture gives you a realistic picture of what an attacker could do if they breach it.
If you are ready to scope either, our guide to scoping a network pentest covers what you will need to prepare and what to expect from the scoping conversation.
How it differs from a vulnerability scan
A vulnerability assessment uses automated tooling to identify known CVEs, missing patches, and misconfigurations across a set of targets. It produces a report based on version signatures and known issues in a database. To get the most out of a vulnerability scan, you’ll need to run this as an authenticated scan with credentials for the systems being tested. This allows the scanner to review the local configuration for each system, extracting the software and driver versions, installed packages, and configuration files to identify known vulnerabilities.
A network penetration test goes further, but will usually have some element of vulnerability scanning for completeness. The tester manually validates which vulnerabilities are exploitable in your specific environment, chains lower-severity issues together to demonstrate realistic attack paths, and discovers weaknesses that automated scanners may not be able to identify.
The practical difference is between “this service is running a version with a known CVE” and “here is how we used that CVE, alongside a misconfigured service account, to reach your domain controller.”
Most compliance frameworks that require penetration testing specify that it must go beyond automated scanning. PCI DSS requirement 11.4 requires evidence of manual penetration testing, and ISO 27001 auditors typically expect more than a scan report as evidence of independent assurance, though ISO 27001 does not mandate penetration testing specifically.
What happens during a network penetration test
Testing follows a structured methodology, with the aim of identifying exploitable vulnerabilities and demonstrating what an attacker could achieve. The methodology is agreed in advance in a rules of engagement document, which defines the scope, duration, and any limitations on testing.
Reconnaissance and enumeration
Testing begins by mapping the target environment. For an external assessment, this means identifying which services are exposed to the internet, the ports that are open, and the software versions running on each service.
Passive reconnaissance also covers DNS records, certificate transparency logs, and open-source intelligence. Certificate transparency logs in particular often reveal subdomains the client had not flagged for testing: legacy admin portals, staging servers, and development environments that may not have been hardened to the same standard as production. These are worth raising before active testing proceeds.
For an internal assessment, this phase involves discovering devices on the network, mapping subnets, identifying domain infrastructure, and understanding the environment before moving into active exploitation.
Vulnerability identification
With the environment mapped, the tester identifies potential weaknesses through manual analysis and targeted tool usage. This includes checking identified software versions against known CVEs, testing authentication services for weak or default credentials, reviewing service configurations for common mistakes, and probing for service-specific issues that automated scanners miss.
For external tests, the focus is on what an unauthenticated attacker can access and exploit. For internal tests, the focus is on what an attacker could do from a position of initial access, so the tester looks for privilege escalation opportunities, misconfigurations that allow lateral movement, and paths to sensitive systems or data.
A scanner may flag dozens of potential issues across a target range; manual review determines which are genuinely exploitable in your specific environment and which are false positives or negligible in context.
Exploitation
Where vulnerabilities are identified, the tester attempts to exploit them to validate whether they are false positives. This is not destructive testing as the aim is to demonstrate what an attacker could achieve and not to cause damage. Each step is documented with command output, screenshots, and timestamps, so findings can be independently verified and reproduced from the report.
For an external network test this might mean gaining access to a server through an unpatched service, or authenticating to an exposed management interface using default credentials.
With internal network testing, exploitation is often more complex and may involve chaining multiple vulnerabilities together to demonstrate a path to domain compromise. One key example is the scenario where NTLM hashes can be captured through local network traffic and then used to authenticate to other systems. This provides a path to lateral movement and privilege escalation that may not be immediately obvious from a vulnerability scan.
How far exploitation is taken is agreed in a rules of engagement document before the test begins. The tester will not attempt to access sensitive data or critical systems without explicit permission, and will stop short of any activity that could cause disruption or damage.
Post-exploitation
Internal engagements include a post-exploitation phase after initial access is established. The tester looks for routes to escalate privileges, move laterally across the network, and reach sensitive systems or data from the compromised position.
Active Directory environments are a central focus here, as domain-level misconfigurations frequently provide a fast path from a standard user account to full domain compromise. Tooling such as BloodHound can be used to trivially graph AD relationships and identify these paths. The aim is to understand what an attacker could do from a position of initial access, not just whether they could get in.
For external network tests, post-exploitation is more limited by the scope and rules of engagement. Some organisations may want the tester to pursue their foothold if they’re able to gain remote access to a server, whilst others may prefer to stop at the point of initial access. This is something to clarify during scoping to ensure the engagement meets your needs and risk appetite.
Reporting
Every engagement concludes with a written report. Technical findings are documented with severity ratings, evidence, steps to reproduce, and specific remediation guidance. An executive summary covers the overall risk picture and key actions, written for leadership and board-level audiences alongside the technical detail.
See our guide to writing a penetration testing report for more detail on what a report includes and how a good report is structured.
What testers commonly find
The specifics vary with every environment, but certain categories come up consistently in network penetration tests.
Unpatched services with known CVEs. Internet-facing services running outdated software give attackers a documented path to exploitation. An exposed web service running a version with a published exploit is a frequent starting point for external assessments.
Weak or default credentials on exposed services. RDP, SSH, VPN concentrators, and network management interfaces with weak or factory-default passwords can lead to immediate compromise.
Services that have no business being internet-facing. SMB, WinRM, and administrative interfaces that are accessible from the internet. These services should be firewalled or restricted to internal networks, but are sometimes exposed due to misconfiguration.
Active Directory misconfigurations. Kerberoastable service accounts, pass-the-hash opportunities, excessive domain privileges, and misconfigured delegation are consistent findings in internal tests. Many of these persist in environments that have been in production for years without ever being tested from the inside.
Penetration testing deliverables
Once testing is complete, your team will receive a written report that includes:
- Executive summary: a non-technical overview of the perceived security posture, and the most significant findings that are suitable for board review or a compliance submission.
- Technical report: every finding is documented with a severity rating (including CVSS where applicable), evidence of vulnerabilities, steps to reproduce or discover the issue, and specific remediation guidance for your team to fix the issues identified.
- Debrief: a call with the testing consultant to walk through findings, answer questions, and help your team prioritise remediation.
- Attestation of testing: a signed and dated document confirming the engagement was completed in accordance with the agreed rules of engagement.
Clients at Exploitr also receive access to the Attack Surface Center platform to track findings and manage remediation progress throughout and after the engagement.
Getting a network penetration test
Before a scoping conversation you will want to note down a rough idea of what you need or want to include in scope. You do not need everything mapped precisely at this point, but having a rough idea of the following will help scoping an accurate engagement:
- your domain names and an IP address count or range for an external test
- the scale, size, and structure of your internal network for an internal assessment
Typical external tests run for 3 to 5 days depending on the amount of targets that are in-scope for testing. Internal engagements vary with network size and complexity, but on average are completed within 5 to 7 days.
For an overview of what network penetration testing costs, see our penetration testing pricing guide . When you are ready to move forward, you can request a quote and we will scope the engagement and return a fixed price within one business day.
