Network Penetration Testing: Process, Tools and Checklist

Last updated: August 2026. Written by Josh Hutcheson, OnlineCourseing editor. Every tool named below was confirmed actively maintained against its source repository before publication. See our review methodology.

QUICK VERDICT

Network penetration testing is the oldest discipline in offensive security and still the one most organisations buy first. It is also the one where the gap between an automated scan and a real assessment is widest: a scanner can tell you a host is missing a patch, but only a tester can tell you that the missing patch leads, through three hops nobody had mapped, to the domain controller.

This guide covers the process end to end — the external and internal variants, the phases in the order they run, the current tooling for each, and a checklist you can work through. For the general engagement structure that sits above this, see our penetration testing methodology; this page is the network-specific layer inside it.

What network penetration testing is

Network penetration testing is an authorised assessment of an organisation’s network infrastructure — the hosts, services, protocols, trust relationships and segmentation between them — carried out by attempting to compromise it the way an attacker would. The target is the infrastructure itself rather than any single application running on it.

That distinction matters because it determines what counts as a finding. A web application test asks whether one application can be abused. A network test asks a broader question: given a starting position, how far can someone get, what can they reach when they get there, and would anyone notice.

External and internal tests are different engagements

This is the single most useful distinction in the discipline, and scoping documents routinely blur it.

The practical implication for scoping: an external-only test that comes back clean is a genuinely good result, but it says nothing about what a phishing email would lead to. Most organisations get more value from an internal or assumed-breach test, and are surprised by how much more.

A word on the assumed-breach model, since it is increasingly the default and the name confuses people. It does not mean the perimeter was found to be weak. It means the engagement deliberately skips the break-in and starts the tester on the inside, on the reasoning that a determined attacker will eventually phish someone regardless of how good the perimeter is. Granting that assumption buys the engagement several days it would otherwise spend proving a point everybody already accepts, and spends them on the internal questions instead — which is where the findings that change architecture live.

Learn network penetration testing properly →

The phases, and what each one means on a network

Phase 1: Scoping and authorisation

Agree the IP ranges and hostnames in scope, the testing window, and — critically for network work — what is explicitly excluded. Networks contain things that should never be touched: industrial control systems, medical devices, legacy hosts that fall over when scanned. Ask directly whether any exist, because the answer is often yes and rarely volunteered.

Also agree who owns the addresses. Cloud-hosted infrastructure sits on a provider’s network, and the major providers publish their own rules on what customers may test. Your client cannot authorise you to attack somebody else’s hardware.

Phase 2: Host discovery and reconnaissance

Establish what actually exists. Externally that means resolving the organisation’s address space from DNS records, certificate transparency logs and WHOIS data, then confirming which hosts respond. Internally it means sweeping the local ranges directly.

Nmap is the standard, and remains actively developed. Host discovery first, then port scanning against what responded — the common error is scanning everything at maximum intensity and spending a day on addresses nothing is listening on. Scope tightly, then widen.

Phase 3: Service enumeration

Turning open ports into an understanding of what is running. Version detection, banner grabbing, and protocol-specific enumeration: SMB shares and their permissions, LDAP directory data, SNMP community strings, NFS exports, database instances, and any management interface exposed where it should not be.

This phase produces most of the material the rest of the test uses. An anonymously readable SMB share, an LDAP service that permits null binds, or an SNMP device still using the default community string are each both a finding in their own right and a source of the information that makes the next phase possible.

Phase 4: Vulnerability analysis

Automated scanning gives breadth. Nessus is the commercial standard; Greenbone’s open-source vulnerability management is the free alternative.

NAME CHECK

The discipline that separates a test from a scan is validation. Scanner output is a list of hypotheses derived largely from version banners; a meaningful proportion will be false positives, and the ones that are real still need their exploitability confirmed in context. A report that is a re-branded scanner export is the clearest sign of a test that was not really performed.

Phase 5: Exploitation and credential attacks

On networks, exploitation is more often about credentials than memory corruption. The three that consistently work:

• Poisoning and relaying. Responder answers LLMNR, NBT-NS and mDNS broadcasts that Windows hosts emit when name resolution fails, capturing authentication material. Relayed onward to a host without SMB signing, that becomes access without ever cracking a password.
• Password reuse and spraying. A single valid credential, sprayed carefully across the estate, frequently opens several machines. NetExec is the tool for testing credentials at scale across SMB, WinRM, LDAP, MSSQL and SSH.
• Protocol abuse. Impacket is a collection of Python classes for working with network protocols directly, and its example scripts implement most of the standard Active Directory attacks — Kerberoasting, AS-REP roasting, secrets dumping and remote execution.

Metasploit Framework remains the exploitation framework for the cases where a service genuinely is vulnerable to a public exploit, and its post-exploitation modules are useful well beyond the initial compromise.

Phase 6: Active Directory and lateral movement

On any internal test in a Windows environment, this is where the engagement actually lives. Active Directory’s value to an attacker is not its vulnerabilities but its relationships: which accounts can administer which machines, which groups nest inside which other groups, which service accounts hold privileges nobody remembers granting.

BloodHound — whose tagline is “Six Degrees of Domain Admin” — collects that relationship graph and computes the shortest path from a starting principal to a high-value target. It regularly finds paths that no administrator knew existed, because they are emergent properties of years of individually reasonable permission grants.

That is why the headline finding of an internal test is a path rather than a vulnerability. “Standard user to domain administrator in three steps” is the sentence that changes a security budget, and no single item in that chain would rate as critical on its own.

Phase 7: Reporting

A network report needs two things a scanner cannot produce: the attack paths, drawn out step by step with the evidence captured at each hop, and a remediation order that reflects which fixes break the most paths. Fixing thirty medium-severity findings in an arbitrary order is far less valuable than fixing the four that sit on every route to the domain controller.

Distinguish clearly between what was tested and found sound, and what was never tested. Readers assume silence means safety, and on a network test the excluded ranges are usually the interesting ones.

The network penetration testing checklist

A working checklist for an internal or external engagement. It is a coverage aid, not a substitute for judgement — the point is that nothing is skipped by accident.

The tools, and their current status

Every open-source entry below was checked against its repository on 30 August 2026 — commit history, not the “last pushed” field, which can be years newer than the newest actual commit.

WHY THERE ARE NO AFFILIATE LINKS ON THIS PAGE

The ports and services that actually matter

A full port scan returns a lot of noise. In practice a small set of services accounts for most of what a network test acts on, because they either carry credentials, expose administrative control, or reveal the structure of the estate.

UDP deserves a deliberate decision rather than an omission. Scanning all UDP ports is slow enough that it rarely fits an engagement, but skipping it entirely misses SNMP and NFS — both reliable sources of findings. Scan a targeted UDP list rather than all of it or none of it.

Did anyone notice? Detection is part of the deliverable

A network test measures two things at once: whether the estate can be compromised, and whether the organisation would know. The second is frequently more actionable than the first, and it is routinely left out of the report.

The mechanism is simple. Record timestamps for the noisy actions — the first port sweep, the first authentication failure burst, the first successful lateral movement — and after the engagement, sit down with whoever runs monitoring and compare your timeline against their alerts. The output is a straightforward table: what you did, when, and whether it produced an alert, a log entry nobody saw, or nothing at all.

That comparison regularly finds that the tooling generated the right telemetry and no one was watching the queue it landed in, which is a very different remediation from buying more tooling. It costs almost nothing to produce, needs to be agreed at scoping so the monitoring team expects the conversation, and turns a test that “only” confirmed the network is hard into one that still improved the organisation.

How often to test, and what retesting is for

Annual testing is the common baseline and is usually driven by a compliance requirement rather than by risk. The more useful trigger is change: a new external service, a network redesign, a merger that joins two directories, or a migration to a new hosting provider each alter the attack surface far more than twelve months of ordinary operation.

Retesting is a separate, smaller exercise and worth budgeting for explicitly. Its purpose is to confirm the specific findings were actually fixed rather than closed in a ticketing system, and it is the only mechanism that tells you whether the previous test produced any change at all. A remediation programme with no retest is an assumption.

Keep the reports. The comparison between two tests a year apart — which findings recurred, which classes disappeared, whether the shortest path to domain administrator got longer — is a better measure of a security programme than either report on its own.

Findings that come up on almost every network test

The same handful of issues account for most internal-test reports, and all of them are configuration rather than software flaws — which is why patching alone does not fix them.

1. SMB signing not enforced. The precondition for relay attacks. Enforcing it removes an entire attack class in one setting.
2. LLMNR and NBT-NS still enabled. Legacy name-resolution fallbacks that broadcast authentication attempts to anyone listening. Rarely needed on a modern network; disabling them removes Responder’s primary route.
3. Password reuse across privilege tiers. A local administrator password shared across workstations turns one compromise into all of them.
4. Over-privileged service accounts. Accounts with domain privileges, non-expiring passwords and a service principal name are the standard Kerberoasting target.
5. Flat internal networks. Segmentation that exists on the architecture diagram but not in the switch configuration. Verify it from a compromised host, not from documentation.
6. Forgotten legacy hosts. The unpatched appliance nobody owns is on almost every engagement, and it is usually reachable from everywhere.

The legal position

Everything on this page is lawful with written authorisation naming the systems and the testing window, and a criminal matter without it — the Computer Fraud and Abuse Act in the United States, the Computer Misuse Act 1990 in the United Kingdom, or the local equivalent. Network testing carries two risks that application testing does not, and both belong in the scope document rather than in an apology afterwards.

• Address ranges drift. Scanning an address that has been reassigned since the scope was written means testing somebody else’s system. Re-verify ownership at the start of the window.
• Some devices break when scanned. Industrial control systems, medical equipment and old appliances can fail under ordinary port scanning. Identify and exclude them explicitly.

Learning to run one

Network testing rewards depth in a small number of areas: knowing what a protocol should look like so you notice when it does not, understanding Active Directory well enough to read a BloodHound graph, and being able to justify a severity rating to somebody who disagrees with it. None of that comes from tool tutorials.

We rank and review the options: the best penetration testing courses covers the hands-on end and the certifications employers recognise, while ethical hacking courses and cyber security courses suit an earlier stage.

For the surrounding tooling see our guides to penetration testing tools, Kali Linux tools, WiFi penetration testing and Windows pentesting tools.

Compare pentesting courses and certifications →

Browse cyber security courses →

Frequently asked questions

What is the difference between an external and an internal network penetration test?

An external test starts from the public internet with nothing but a scope, and assesses whether the perimeter can be crossed at all — VPN gateways, mail, web front ends, remote access. An internal test starts from a foothold already inside the network and assesses what happens next: blast radius, segmentation, privilege escalation and lateral movement. They have different attack surfaces and usually produce very different reports, with the internal one far longer.

How long does a network penetration test take?

It scales with the number of live hosts and the depth agreed, not with the size of the address range. A small external perimeter can be covered in a few days; an internal Active Directory engagement across a mid-sized estate typically runs one to two weeks including reporting. Scoping by live host count rather than by CIDR block gives a far more accurate estimate.

Is Nmap enough for a network penetration test?

No. Nmap is the discovery and enumeration layer and it is excellent at that, but it does not perform credential attacks, map Active Directory relationships or validate exploitability. A realistic internal engagement pairs it with a vulnerability scanner for breadth and with Responder, NetExec, Impacket and BloodHound for the work that actually produces findings.

Is OpenVAS still called OpenVAS?

Not as a product. The product is now Greenbone Vulnerability Management (GVM), and OpenVAS survives as the name of the scanner component inside it. Similarly, CrackMapExec has been succeeded by NetExec. Guides still naming the old products are pointing at software that no longer ships under those names.

What is BloodHound used for?

Mapping attack paths through Active Directory. It collects the relationships between users, groups, computers and permissions, then computes the shortest route from a starting account to a high-value target such as domain administrator. Its value is that these paths are emergent — they arise from years of individually reasonable permission grants, so they are rarely visible to the administrators who created them.

What is the most common finding on an internal network test?

Configuration issues rather than missing patches. SMB signing not enforced, LLMNR and NBT-NS still enabled, local administrator password reuse across workstations, over-privileged service accounts with service principal names, and internal segmentation that exists on the diagram but not in the switch configuration. All five are settings, which is why patching alone does not resolve them.

Do I need permission to scan a network I have access to?

Yes, and access is not authorisation. Written permission must name the ranges and the testing window, and it must come from someone entitled to grant it. Two network-specific traps: address ranges get reassigned, so ownership should be re-verified at the start of the window; and cloud-hosted infrastructure sits on a provider’s network, whose own testing rules your client cannot waive on their behalf.

Should a network penetration test be run against production?

Usually yes, because a staging environment rarely reproduces the trust relationships, legacy hosts and accumulated permissions that produce the real findings. The safeguards are in the scope document rather than in the environment choice: identify fragile devices and exclude them, agree an escalation contact reachable during the window, and rule out denial-of-service techniques explicitly.

Related reading: penetration testing methodology · penetration testing tools · Kali Linux tools · WiFi penetration testing · web application pentesting tools · best penetration testing courses