← Back to blog

Network Penetration Testing: Internal and External

NIMR Security Team
network securitypenetration testingVAPT

Network penetration testing gets less attention than web testing, which is exactly why it keeps finding things. The perimeter is probed nightly by attackers, and internal segmentation is where most real breaches stall or succeed. This post covers external and internal tests, what each produces, and how to run them without breaking your own environment.

External testing: what attackers see

An external test starts from the internet and works the way a remote attacker would: enumerate hosts, fingerprint services, and look for something reachable and exploitable.

  • Service exposure: RDP, SMB, SSH, and databases on the internet with default or weak credentials (CWE-1188, insecure default credentials).
  • Patch status: unpatched and end-of-life software is the easiest win for attackers and the most common critical finding.
  • Application-layer entry points: VPNs, email gateways, and self-service portals that are really web applications in disguise.

The test validates whether any of it can be exploited from outside, and whether a foothold on one host leads anywhere else. External findings are usually configuration and patching problems, which makes them cheap to fix and expensive to ignore.

Internal testing: the post-breach view

An internal test starts from the assumption that an attacker got in: through phishing, a compromised endpoint, or a partner connection. The question is what happens next.

  • Segmentation: can a compromised machine on the office network reach production, HR, or the payment systems? Flat networks fail this test instantly.
  • Credential attacks: LLMNR and NBT-NS poisoning, Kerberoasting and AS-REP roasting against Active Directory, and pass-the-hash movements that turn one password into many.
  • Active Directory attack paths: tooling like BloodHound maps privilege paths from a low-privileged account to domain admin, showing exactly which misconfiguration to fix first.
  • Privilege escalation and data access: once elevated, what can be read, and can the tester prove it without touching production data?

The test environment and tools

External tests run from the tester's own infrastructure, using Nmap for enumeration and vulnerability scanners such as Nessus or OpenVAS for detection, followed by manual validation of everything that looks exploitable. Internal tests run from a vantage point inside the network with the same tools plus credential-focused ones: Responder for name-resolution poisoning, BloodHound for Active Directory attack paths, and Metasploit for post-exploitation proof. The tooling matches what real attackers use, which is the point: the test validates the paths a real breach would take.

What internal tests usually find

The pattern is consistent: flat networks with no segmentation, legacy protocols still enabled, weak service accounts with domain privileges, unpatched internal servers, and over-privileged users. None of it is exotic. All of it is how breaches actually spread.

Cloud and hybrid estates

The network is no longer a rack in a server room. Cloud environments shift the test to the identity layer: IAM roles and permissions, exposed storage buckets, misconfigured security groups, and public snapshots. A modern network assessment covers the cloud estate alongside the on-premises network, with the same question: what can a foothold reach? Cloud scope also includes container registries, Kubernetes configurations, and CI/CD pipelines, where a compromised build step is the modern equivalent of a backdoor.

What the report contains

The report should separate verified findings from noise, score each with CVSS 3.1, map it to CWE, and describe the business impact: which systems, data, and privileges each path leads to. For internal tests especially, the report should include a narrative of the attack path, because the path is the finding. Remediation guidance names the configuration, policy, or architecture change that closes it, and the retest confirms the fix.

Running it safely

Internal tests can disrupt production, so the rules of engagement matter. Define the testing window, agree on the techniques in advance (credential attacks and password changes should be explicit), and keep an emergency contact who can stop the test immediately. A maintenance window is often the right container for the noisy parts.

Takeaways

  • External tests find exposure and patching gaps; internal tests find segmentation and identity problems.
  • Flat networks and weak Active Directory hygiene are how breaches spread.
  • Include the cloud estate in scope; the identity layer is the new perimeter.
  • Agree on the testing window and techniques before the engagement starts.
  • Close the loop: findings to remediation to retest.
  • Treat CI/CD and containers as part of the network attack surface.

NIMR's mobile and network security testing covers external, internal, and cloud networks with manual validation on top of scanning. Request an assessment, or see what a VAPT program costs before you budget.