External vs Internal Penetration Testing
Different threat models, different defensive evidence.
External and internal penetration tests answer fundamentally different questions about an organisation’s security posture, and confusing the two is one of the most common procurement mistakes we see. An external test asks: how exposed are we to attackers on the public internet? An internal test asks: once an attacker has a foothold inside, how far can they go? Most organisations need both, periodically, because the two threat models produce different evidence and protect against different attack patterns.
This article explains what each type of test covers, how they differ in methodology and findings, when each is most valuable, and how the two combine in a defensible testing programme.
What external penetration testing covers
External testing simulates an attacker on the public internet, starting from nothing. The threat model is the unauthenticated external attacker — the most common starting position for real-world incidents.
Typical scope includes:
- Public-facing infrastructure. Internet-routable IP ranges, edge devices, VPN endpoints, mail servers, DNS infrastructure.
- Internet-facing applications. Customer portals, public APIs, marketing sites, support portals, single sign-on endpoints.
- Cloud surface. Exposed cloud services, public storage, internet-reachable management interfaces, cloud-hosted applications.
- Perimeter authentication. Login portals, federation endpoints, OAuth flows, password reset flows.
- Discoverable assets. Subdomains, certificates, leaked credentials, OSINT-discoverable infrastructure that the defender may not know about.
Common findings in external tests:
- Exposed administrative interfaces (Jenkins, Kubernetes dashboards, database admin tools) that should never be reachable from the internet.
- Unpatched edge devices appearing on the CISA Known Exploited Vulnerabilities catalogue.
- Weak or misconfigured TLS — expired certificates, weak cipher suites, certificates owned by ex-staff.
- Authentication weaknesses on internet-facing applications — single-factor authentication for administrators, weak password reset flows, SSO misconfiguration.
- Cloud misconfigurations — public buckets, exposed Kubernetes API servers, assumable IAM roles.
- Forgotten assets — old marketing microsites, abandoned test environments, legacy applications no team currently owns.
External testing matters because almost all opportunistic ransomware attacks, and most targeted intrusions, begin from the outside. An organisation whose external surface is hardened buys time and forces attackers to work harder — which is often enough for them to look elsewhere.
What internal penetration testing covers
Internal testing operates from an assumed breach position. The threat model is the attacker who has already obtained a foothold inside the network — typically a compromised laptop, a phished user credential, a malicious insider or a contractor with legitimate access. The question is: starting from there, how much damage can they do?
Typical scope includes:
- Active Directory. Group memberships, ACLs, privileged accounts, service accounts, trust relationships, kerberoastable accounts.
- Internal network. Segmentation, lateral movement paths, internal application exposure, shared credential reuse.
- Identity infrastructure. Privileged access workstations, jump hosts, identity federation, certificate authorities.
- Server estate. Domain controllers, file servers, application servers, backup infrastructure.
- Internal applications. Apps that are not internet-facing but hold sensitive data or grant access to it.
Common findings in internal tests:
- Kerberoasting and AS-REP roasting — service accounts with weak passwords whose hashes can be cracked offline.
- Lateral movement paths — reused local administrator passwords, over-privileged service accounts, shared credentials across workstations.
- Privilege escalation chains — ACL misconfigurations on privileged groups, accounts with unconstrained delegation, shadow admin paths visible via BloodHound.
- Flat networks — minimal segmentation between user and server environments, accelerating ransomware impact.
- Over-privileged service accounts — accounts with Domain Admin equivalents that should not have them.
- Stale credentials and cached hashes on shared workstations.
Internal testing matters because once an attacker has any foothold, the time from initial access to enterprise-wide compromise in a typical Active Directory environment can be measured in hours rather than days. The controls that determine that outcome are almost entirely internal.
The categorical difference: starting position
External and internal tests are not variations on the same engagement. They are categorically different exercises with different starting assumptions:
- External: the tester has nothing — just the organisation’s name and any public information.
- Internal: the tester has a foothold — typically a low-privileged account, a workstation on the network, or a compromised laptop.
This shapes everything that follows. External tests spend much of their time on reconnaissance and discovery; internal tests spend much of their time on enumeration of privilege, group memberships and lateral movement opportunities. External tests typically surface a small number of high-impact perimeter findings; internal tests typically surface many small misconfigurations that combine into significant attack paths.
Methodology differences in practice
The two tests look different in execution:
- External: heavy reconnaissance, then targeted exploitation. Passive discovery, certificate transparency logs, subdomain enumeration, code repository review. By the time exploitation begins, the tester has a precise picture of the attack surface and a short list of high-value targets.
- Internal: faster discovery, then privilege and movement focused. Already inside, the tester begins with internal enumeration — BloodHound, network discovery, share enumeration, credential extraction. The volume of low-level findings is higher; the work is in chaining them into impactful paths.
- External: external attacker tooling. Public scanners, web application proxies, custom enumeration. No assumption of trusted access.
- Internal: insider tooling. Active Directory tooling, credential dumping (where authorised), lateral movement frameworks, persistence techniques.
Reporting differs too. External reports often focus on a small number of urgent findings on specific assets. Internal reports often focus on architectural and identity weaknesses with broader, more programmatic remediation.
When to test each, and how often
A typical mature cadence:
- External penetration testing: at least annually, ideally semi-annually, plus after material changes to internet-facing assets (new applications, acquisitions, cloud migrations). Continuous external attack surface monitoring sits between formal engagements to catch new exposure as it appears.
- Internal penetration testing: at least annually, or every 18 months for stable environments. Particularly important after material changes to identity infrastructure or Active Directory.
- Both after incidents. An incident that touched either the perimeter or the internal estate is a reason to test both, not just the one that failed.
Frequency should scale with risk. For organisations with sensitive data, regulated obligations or recent incident history, quarterly external testing and annual internal testing is increasingly the norm.
How the two combine
A complete assurance programme uses both, because they answer different questions and protect against different stages of the attack chain. The combination matters in several ways:
- External testing reduces the probability that an attacker gets in at all.
- Internal testing reduces the consequence if they do.
- Findings in external tests inform the scope of internal tests — if a particular perimeter weakness is confirmed, the internal scope should validate that compensating controls would slow an attacker who exploited it.
- Findings in internal tests inform priorities for external defence — if a single user credential leads to Domain Admin in three hours, the external defence against phishing and credential theft becomes more important, not less.
Some organisations also run purple team or adversary simulation exercises that bridge the two, simulating a full attack chain from external entry through to internal impact, often combined with detection validation. These build on external and internal testing rather than replacing them.
Frequently asked questions
Which test should I do first if I can only afford one?
External, in most cases — the perimeter is where almost all opportunistic attacks begin, and external findings are usually faster to remediate. Internal testing should follow as soon as resources allow.
Can an external test discover internal issues?
Only indirectly. An external test may surface a vulnerability that grants internal access, but it will not enumerate the internal environment unless the scope explicitly allows it.
Does internal testing damage our network?
Properly scoped internal testing rarely causes outages. Risky activities (active credential dumping, certain lateral movement techniques) are scoped explicitly and conducted with care.
What is the difference between internal pen testing and assumed-breach testing?
Internal pen testing is one form of assumed-breach testing. The terms are often used interchangeably, though “assumed breach” sometimes implies a more adversary-simulation-style engagement with specific objectives, where standard internal testing tends to be broader.