Level: intermediate. This is a self-directed walkthrough of network penetration testing against a network you own or a deliberately vulnerable lab you built. Every step is gated on written authorisation, and the honest position is that step 1 is the only one that cannot be improvised. Skip it and nothing afterwards is lawful, however technical it looks.
The eight steps below follow the shape a professional engagement takes, scaled down to a home network or two virtual machines. Validation stays at the smallest demonstration that proves a point, because a network you built should still work when you finish.
Step 1 is authorisation. Before you run a command, write down what you are authorised to do, who authorised it, and when it expires. On your own home network you are the owner, so the authorisation is a signed note to yourself setting out scope, the test window, and the rule that anything you break you fix. That is not pedantic, because the moment a guest joins the network, their data is inside the scope too.
For a friend’s business or a volunteer audit, the same note does the real work. Name the ranges or hostnames, the permitted test types, the dates and hours, what happens if you break something, and who to call. Get it signed by whoever owns the system. NIST SP 800-115 puts planning and authorisation ahead of technique for the same reason.
Step 2 is scope, and it is narrower than authorisation. Authorisation says yes, scope says where. The classic failure is testing something you do not own: your provider’s equipment, a cloud edge, a payment gateway, the update server of a device you bought. Permission to test your web server is not permission to test the network in front of it, and traffic aimed at a third party is aimed at a third party regardless of intent.
| Scope item | Example for a home lab | Why it is written down |
|---|---|---|
| In scope | 192.168.56.0/24 lab range, three VMs | Defines the boundary of every later step |
| Out of scope | Gateway, internet, any public address | Stops traffic reaching a third party |
| Services excluded | Outbound mail, update services | Testing these creates noise you cannot read |
| Intensity limit | No load, no flooding, default rate or slower | Protects availability of what you are testing |
| Stop condition | Stop if a service becomes unresponsive | Gives you a defined abort trigger |
| Data handling | No personal data viewed or copied | Keeps you inside data protection law |
| Evidence | Screenshots and output with timestamps | A report is worthless without it |
For a lab, the private address ranges described in RFC 1918 are the obvious choice, because they cannot be routed on the public internet. Write the table before you start: twenty minutes now makes everything after it defensible.
Step 3: Asset Discovery
Passive discovery, first and always
Passive discovery touches nothing. Look at what is already published about your own estate: router configuration pages, DHCP leases, DNS records, and any asset register. For a lab you built that means your own notes, which is why a real assessment usually begins by listing systems nobody wrote down. The CISA advisories and threat bulletins show which weakness classes to prioritise rather than assume.
Active discovery, with care
Active discovery sends traffic and is the first thing your logs will show. That is expected on a network you own. Nmap is the standard starting point and Wireshark shows you exactly what it emits. Record every command, because the log is part of the evidence.
You want a list: what answers, which ports are open, which services replied, and which addresses said nothing. Hosts that dropped every packet are as informative as hosts that answered. Network Service Discovery in MITRE ATT&CK describes the same behaviour from the defender’s view, which helps when you explain results.
Step 4: Enumeration, the Core of Network Penetration Testing
Enumeration turns “port 445 is open” into something actionable, and it is where most of the useful work in network penetration testing happens. A port number is a lead, not a finding. The IANA service names and port numbers registry says what a number means, and the banner usually says more.
| Service | Typical ports | What enumeration should establish |
|---|---|---|
| Name resolution | 53 | Which servers are authoritative, and what they answer for |
| Remote administration | 22, 3389, 5900 | Which hosts accept it, and from where |
| File sharing | 445, 139 | Whether shares are exposed or guest readable |
| Web services | 80, 443, 8080 | What runs, which version, what it leaks |
| Databases | 3306, 5432 | Whether they are reachable from segments they should not be |
Two questions do most of the work. Can a host on another segment reach this service when it should not? Does the service leak a version or an error that narrows the attack surface more than it should? The NIST guidelines on firewalls and firewall policy describe the intended boundary, so you can measure the real one.
Step 5: Analysis
Now you have data, and the temptation is to run everything you can find. Resist it. Analysis sorts observations into three piles: confirmed weaknesses, things to check, and things irrelevant here. Raw tool output is not a report, and this step is what separates network penetration testing from running scanners.
Rank by reachability before severity. A weakness on a host reachable from a user workstation is a different problem from the same weakness on an isolated appliance, and the CVSS base score from FIRST gives a shared language for technical severity. A templated check is a hypothesis.
Step 6: Safe Validation
Validation proves a finding is real. It does not prove you are clever, and the standard is the smallest demonstration that answers the question. If a banner suggests an outdated version, confirming that version against the vendor’s documentation is validation. If a service allows anonymous access, listing the top-level items is validation. Neither changes state.
Four rules keep validation safe. Confirm rather than exploit: capture the evidence a fix needs, not the maximum access you can get. Never alter data, install anything, or change a credential. Avoid persistence unless agreed in writing, because a back door left in place is a legal problem, not a technical one. And if a service becomes unresponsive, stop and report it rather than pushing further.
Validate with the smallest question you can, and limit any weak credential testing to your own accounts. MITRE ATT&CK’s initial access tactic gives a structured way to record how a chain would progress, which makes findings easier to act on. Our methodology guide covers this phase in full.
Steps 7 and 8: Reporting, Remediation and Retest
The report is the deliverable, and on a home network the audience is you, six months from now, trying to remember what you changed. Keep it simple: a one-page summary of what was tested and when, then one entry per finding with evidence, impact, fix and a retest result.
Specific remediation is the difference between a useful report and a frustrating one. “Restrict SMB to the local segment” beats “improve network security”, because the first can be done on a Tuesday. Our router security guide and IoT security guide cover the fixes home networks need most.
Retest is step 8, and it is the one people skip. Repeat the exact validation against the same host, in the same conditions, and record pass or fail with a date. Without it you have a claim rather than a result. Fixes regress and configurations drift, so retest is the only evidence that anything changed.
Where the Line Sits
Some limits are absolute. Do not test any address outside your written scope, including ones that answer a ping on a network you were not invited to. Do not test third-party services or rented infrastructure you do not control. Do not attempt access to personal accounts or seek another person’s data. Do not degrade availability, however interesting the result. And report findings only to the owner.
The legal position is not flexible. Section 1 of the UK Computer Misuse Act 1990 makes unauthorised access an offence in its own right, and section 1030 of title 18 of the US Code, published by Cornell’s Legal Information Institute, does comparable work. In Nigeria, the Cybercrimes (Prohibition, Prevention, Etc.) Act 2015 and its amendments cover unauthorised access and interference with computer systems. None of this is legal advice.
Frequently Asked Questions
Can I run network penetration testing on my own home router?
Yes. You own it, so you are the authorising party, and a written note to yourself setting out scope and rules is enough. Keep the test on your own segment, avoid anything that sends traffic outside your network, and expect some devices to behave oddly for a few minutes afterwards.
Is a home network worth testing?
For learning, yes, and it is the safest place to learn. For realism, no: a home network has few hosts and few services, so it will not teach you segmentation. Add a virtual attacker and a deliberately vulnerable target instead.
How do I know whether a finding is a false positive?
Check the vendor’s documentation for the version you found, and whether the affected feature is enabled on your system. If you can establish neither, report it as unconfirmed. An honest uncertain finding is useful, and a confident wrong one costs more trust than it earns.
Should I hire someone instead of learning this?
If the network holds business data, is internet reachable, or handles money, yes. A qualified tester gives you a defensible report, insurance value and a retest you cannot produce yourself. Learning it yourself complements that rather than replacing it, and our toolkit guide shows what the job involves day to day.
Key Takeaways
- Written authorisation is step 1 and it is not a formality. No permission, no testing.
- Scope is narrower than authorisation. Third-party services are never in scope by default.
- Passive discovery first, active discovery second, and log every command you run.
- A port number is a lead, not a finding. Enumeration turns it into something actionable.
- Validate with the smallest demonstration that answers the question, and never alter data.
- Remediation must name the specific change, because “improve security” helps nobody.
- Retest in step 8 with a pass or fail result and a date, or you have a claim, not a result.
For the tools behind steps 3 to 6, read our guide to 15 penetration testing tools beginners should learn first. For the professional version of this sequence, see penetration testing methodology.
Sources: NIST SP 800-115; NIST SP 800-40 Rev 4, firewalls and firewall policy; RFC 1918, private internet address allocation; IANA service names and port numbers; MITRE ATT&CK; Nmap; FIRST, CVSS.
0 Comments