Internal and external network testing: findings and fixes
In short: External network tests check what an attacker on the internet can reach; internal tests start from inside and show how far an intruder could spread. The same findings appear again and again, and most have straightforward fixes in configuration, patching and segmentation.
Two different questions
A network penetration test asks one of two questions. An external test asks: what can someone on the internet see and break? An internal test asks: if an attacker gets in, perhaps through a phishing email, how far can they go? Internal tests are often called "assumed breach" tests, because initial compromise is realistic for any organisation.
External testing
Testers enumerate the client's public IP ranges and domains, then examine every exposed service: VPN gateways, email servers, web servers, remote access portals and any administrative interfaces.
| Common external finding | Fix |
|---|---|
| Admin interfaces (firewall, router, hypervisor) reachable from the internet | Restrict to a management network or VPN |
| Outdated VPN or edge appliance firmware | Patch quickly; subscribe to vendor advisories |
| RDP, SSH or database ports open to all | Close or gate behind VPN or zero trust access with MFA |
| Weak TLS versions or ciphers | Allow TLS 1.2 and 1.3 only, with modern ciphers |
| Forgotten test or legacy hosts | Decommission and update DNS |
Internal testing
Internal tests often start from a laptop plugged into a normal office port or from a standard user account. Testers look at name resolution, file shares, the directory service (often Microsoft Active Directory), legacy protocols and how well the network is segmented.
| Common internal finding | Why it matters | Fix |
|---|---|---|
| LLMNR and NBT-NS enabled | Lets an attacker on the network capture login hashes | Disable via Group Policy; rely on DNS |
| SMB signing not required | Allows captured logins to be relayed to other servers | Require SMB signing on clients and servers |
| Default or weak passwords on devices | Easy admin access to printers, switches, cameras | Change defaults; use a password manager |
| Service accounts with weak passwords | Their credentials can be cracked offline | Long random passwords or managed service accounts |
| Same local admin password everywhere | One cracked password opens every PC | Use Windows LAPS for unique local passwords |
| Flat network | Any host can reach servers and management | Segment with VLANs and firewall rules |
| Sensitive files on open shares | Passwords and data readable by all staff | Review share permissions; least privilege |
Defenders can check several of these on their own systems. For example, on Windows and in your own lab:
Get-SmbServerConfiguration | Select-Object RequireSecuritySignature, EnableSMB1Protocol
Get-SmbClientConfiguration | Select-Object RequireSecuritySignature
nmap --script ssl-enum-ciphers -p 443 192.168.10.20Turning results into improvement
- Fix the chain, not just one link: an attack path report shows which single change breaks the most paths.
- Apply secure baselines through Group Policy or configuration management, so fixes reach every machine.
- Check that detection worked: did the SOC see the tester's activity?
- Retest the high-risk findings and repeat internal tests yearly or after major changes.
Tip: many internal findings are old defaults that nobody turned off. A hardening baseline such as the CIS Benchmarks closes many of them before a tester ever arrives.
Practice
Why are internal tests sometimes called "assumed breach" tests?
What problem does Windows LAPS solve?
An external test finds the firewall management page reachable from the internet. What is the fix?
Key takeaways
- External tests examine internet exposure; internal tests measure spread after a breach.
- External findings often involve exposed admin services and unpatched edge devices.
- Internal findings often involve legacy protocols, weak credentials and flat networks.
- Fixes include disabling LLMNR, requiring SMB signing, LAPS and segmentation.
- Check whether the SOC detected the test, and retest key fixes.
Original content written by Mohamed Fayas for FM TecHub. © 2026 FM TecHub. You're welcome to share a link to this page; please don't copy the text elsewhere without permission.