Internal vs External Penetration Testing: Which One Do You Need?

Internal and external penetration tests sound similar, but they answer two very different questions. External testing asks: what can an attacker do from the internet, with no access? Internal testing asks: what happens once an attacker is already inside? Buying the wrong one, or only one when you needed both, leaves a real gap. Here is how each works, when you need which, and how they fit together.

External penetration testing: the view from the internet

An external test targets everything you expose to the public internet: web and mail servers, VPN gateways, firewalls, cloud endpoints, and any forgotten staging box. The tester starts with zero access and works exactly like an opportunistic attacker, mapping your perimeter and probing each exposed service for weaknesses.

The first phase is always discovery. On your own assets, you can run the same reconnaissance we do to see what you are exposing:

bash

# Discover live external hosts and their services (run only against assets you own)
subfinder -d example.com -silent | httpx -silent -title -status-code -tech-detect

# Service and version discovery on your public range
nmap -sV -Pn --top-ports 1000 203.0.113.0/24 -oA external-scan

From there, an external test looks for exposed admin panels, weak or default credentials, missing patches on internet-facing services, misconfigured TLS, and web application flaws. The deliverable answers a board-level question: if someone targeted us from the outside today, could they get in?

Internal penetration testing: assume the breach

An internal test starts from a different assumption: the attacker is already inside. That is realistic, most serious incidents begin with a phished laptop or a compromised supplier, not a heroic firewall breach. We plug into your network (or a segment of it) with the access a regular employee or a compromised device would have, then see how far that gets us.

Internal testing is where segmentation and identity hygiene are really tested. In a Windows estate, that means Active Directory: can a standard user find a path to Domain Admin? We enumerate the network and map those relationships.

bash

# Map internal hosts and exposed services from a foothold
nmap -sn 10.0.0.0/16 -oA internal-hosts        # live-host sweep
nmap -sV -Pn -p 445,3389,5985,88,389 10.0.0.0/24

# Map Active Directory attack paths with BloodHound's collector
# (run against your own domain during an authorized test)
bloodhound-python -d corp.example.com -u svc_audit -p '***' -c All -ns 10.0.0.10

From a foothold, an internal test looks for privilege escalation, weak service-account passwords, over-permissive shares, missing segmentation between user and server networks, and paths to your crown-jewel data. It answers the question that keeps CISOs up at night: if one laptop falls, does the whole domain fall with it?

Which one do you need?

They are stronger together

The most useful engagements combine the two. An external test finds the way in; an internal test shows what that initial access is worth. A single exposed service that leads to a foothold, which leads to an unsegmented network, which leads to Domain Admin, is a story only a combined test can tell. For compliance frameworks like PCI DSS, both are explicitly required.

Not sure which fits your risk and budget? Our network penetration testing service covers both perspectives, and you can read what each typically costs before you decide. When you are ready, book a free scoping call and we will recommend the right starting point.