What an external penetration test is and how one is actually run

Exploiting a vulnerability has been the most common way attackers break in for six years running, 32% of intrusions in 2025 (Mandiant's M-Trends 2026), and those flaws sit on your internet-facing perimeter, the surface an external penetration test covers. A report captures it for one day, and by the time you read yours, a developer has spun up a staging box, marketing has pointed a new subdomain, and an acquisition has added servers nobody's seen, none of it in scope. This guide covers what an external penetration test really includes, how a tester runs it phase by phase, and why its asset list ages faster than the report itself.

What is external penetration testing?

External penetration testing is an authorized security assessment that attempts to gain access to an organization's network from the public internet, without credentials or prior access.

Penetration testing simulates real-world attacks against your external network to identify risks the way real-world attackers would, and to perform external penetration testing properly, a tester works only from what's reachable from outside.

The National Cyber Security Centre defines it as gaining assurance in your network security by attempting to breach it, using the same tools and techniques as an adversary might.

It covers everything reachable from outside your network, which is a wider set than most scope documents admit, running to public web applications, REST and GraphQL and gRPC APIs, mail and DNS records, VPN and single sign-on appliances, file transfer services, cloud object storage, forgotten staging hosts and internet-facing AI endpoints.

Two distinctions decide what you actually buy, and getting them wrong is the most common scoping mistake.

A scan hands you a list of possible problems. Pentesting goes further, and external network testing, in particular, turns those weaknesses into a working route in and proves it, which gives you a true picture of your external security posture rather than a to-do list. 

Phase 1: Scope and rules of engagement

Scoping decides what the engagement is allowed to look at, and it's the phase buyers spend the least time on. Two decisions are made here, and both shape how useful the engagement turns out to be. They are how much the tester is told up front, and whether you wanted a test or just a scan.

Step 1: Set the test basis and rules of engagement

The test basis is just how much you tell the tester before they start, and it comes with a trade-off. NCSC calls the external version opaque box or closed box testing, meaning the tester works from the outside with no inside knowledge, the same position a real attacker starts from.

Rules of engagement get settled in the same conversation, covering test windows, out-of-scope hosts, lockout thresholds, and a named contact reachable at short notice. Decide separately whether to tell your blue team, since an unaware team turns it into a detection test too.

Step 2: Decide whether you need a test or a scan

A vulnerability scan uses automated tools to tell you, quickly, whether the hosts you already know about carry potential vulnerabilities like a missing patch. A penetration test adds manual testing, identifying security weaknesses, stringing the exploitable vulnerabilities into a working way in, and then proving it works.

NCSC puts the position more sharply than most buyers expect, saying penetration testing should be viewed as "a method for gaining assurance in your organization's vulnerability assessment and management processes, not as a primary method for identifying vulnerabilities".

So if your once-a-year test is also where you first discover assets you'd forgotten about, your real gap is discovery, and no amount of testing depth will close it. You have to find the assets before anyone can test them.

Step 3: Enumerate the in-scope asset classes

Everything reachable from outside is in scope, including the REST, GraphQL, and gRPC endpoints that a single line item for "APIs" hides. The classes that matter most are the ones fronting critical systems, sensitive assets, and any critical infrastructure, and two of them cause the most damage precisely because scopes miss them.

• Acquired estates. An acquisition hands you a perimeter nobody on your side has ever mapped, with no change record behind it. It is the highest-risk class and the most often missed.
• Model-backed AI services. These carry a different attack taxonomy from ports and services, so scoping them in without changing the method doesn't cover them. NIST's adversarial machine learning taxonomy is the reference for what that class contains.

Both are discovery problems before they are testing problems, which is why Escape's external pentesting builds the asset list for you rather than asking you to provide one. It rebuilds your footprint from cloud accounts, DNS and IP ranges, keeps rediscovering it so the list never goes stale, and can map an entire external attack surface in under an hour, including one you inherited last week.

Phase 2: Reconnaissance and perimeter reconstruction

MITRE ATT&CK treats reconnaissance as a tactic in its own right, the active and passive information gathering that supports targeting. You and an attacker do almost the same work at this stage, and the only real difference is how much time each of you gets. Everything the later phases can find is limited by what you map here, so this is the phase to get right.

Step 4: Reconstruct the external footprint

A good tester won't just take your inventory at face value. They rebuild your internet-facing footprint from scratch and compare the two, because anything in one list but not the other is exactly what you want to catch. The rebuild uses three inputs, none needing a credential or an agent:

• Cloud accounts, which surface anything spun up outside the change process.
• DNS, where subdomain enumeration turns up delegations and records pointing at decommissioned infrastructure.
• Declared IP addresses and CIDR blocks, the external IPs that anchor the estate you believe you own.

The result reflects what's genuinely reachable, which an authenticated inventory can't tell you. Escape's external network pentesting works from those same three inputs and maps a perimeter in under an hour.

The same rebuild scales far past a single estate, and Escape put that to the test at real scale. For its State of Security of Vibe Coded Apps research, it pointed this exact method at roughly 5,600 live applications and turned up 34,232 vulnerabilities, close to 2,000 of them high impact, plus 400-plus exposed secrets and 175 separate leaks of personal data.

No human team covers that much ground, and the most common cause was not exotic, just misconfigured permissions a scanner signature would have walked straight past.

Step 5: Map the identity and credential surface

Once you know what's reachable, the next question is who can reach it. So identity reconnaissance collects employee names, the format your email addresses follow, and any portal that accepts a login, the same groundwork a social engineering attack would start from.

That email format matters more than it looks, since it quietly turns your public staff list into ready-made user accounts to feed password attacks, from password spraying to brute force attacks against weak passwords.

theHarvester is the reference tool here, gathering email addresses and hostnames from public sources and targeting people rather than infrastructure. Breach-corpus checking belongs in the same step, since a credential exposed elsewhere is the cheapest route in and requires no further exploitation.

Step 6: Sweep ports and fingerprint services

Before flagging anything, a good tester confirms it's genuinely reachable, which separates a real finding from scanner noise. Port scanning here reaches the roughly 4,000 TCP ports Escape sweeps on every host, not the top thousand, and the UDP sweep most testers skip is where DNS, SNMP and NTP exposures surface.

In practice, four kinds of exposed services are where most external estates spring a leak:

• Web services, the part your scope probably already covers.
• Databases, where a single exposed instance with default credentials ends the engagement early.
• Remote access protocols, SSH and RDP and their management interfaces.
• Message brokers, routinely exposed and routinely unauthenticated.

Service fingerprinting then turns a reachable port into a named product and version, and that version string is what makes the port list actionable. Escape matches detected versions against a CVE set of more than 170,000 entries rebuilt daily.

Step 7: Audit DNS and email records

DNS and mail records appear in nearly every scope document, yet hardly anyone tests them, making them a dependable source of quick wins in an established estate.

Four checks are worth running, each turning up a different finding:

Exposed cloud object storage belongs in the same pass, since public buckets are enumerable from outside and do not appear in any port scan.

Phase 3: Exploitation and proof of access

The earlier phases produced a map of your perimeter. Now the tester actually tries the doors, focusing on the few that an external estate really exposes. The aim is to walk away with a working proof your team can reproduce, so you know a weakness is genuinely exploitable rather than just theoretical.

This is also where the gap between tools is most evident. In Escape's in-depth benchmark, the same top model found roughly four times as many real issues once wrapped in Cascade's testing harness, at a zero percent false-positive rate across the benchmark’s validated findings. The harness around the model matters more than the raw model, because it is what reliably turns a plausible-looking lead into a proven exploit.

Step 8: Get past single sign-on and MFA login flows

From the outside, you tend to see the same handful of login points, from webmail and Citrix and remote desktop gateways to VPN portals, SharePoint and single sign-on. This is exactly where automated testing tends to give up, because a scanner that can't get through a modern login just tests the login page itself, finds nothing, and cheerfully reports your estate as clean.

Getting through that login is the difference between a tool that just lists your assets and one that actually tests them behind the door. Escape gets in where scanners give up, with ready-made support for the login flows an external estate typically uses and a custom authentication procedure you can build when none fit. It covers:

• OAuth in three variants: authorization code, client credentials, and resource owner password credentials.
• MFA, including time-based one-time passwords.
• CAPTCHA, with allowlisting in test environments as the primary method.
• Browser Agent and Browser Actions, for flows that only complete in a real browser.
• Cognito, GraphQL, Digest, Headers and cURL Sequence for the rest.
• Agentic Mode, where the login flow is worked out live rather than scripted in advance.

Under the hood, a custom procedure pulls a value out of a response body, header or cookie and drops it into the next request using Jinja templating, which is how session management, token refresh and OAuth code exchange get handled automatically instead of breaking the test.

Often, the most important thing you'll write down here is a gap in your access controls: a portal that accepts a valid password without a second factor. For an attacker holding a leaked credential, that is the whole game.

Step 9: Cross versions against known-exploited vulnerabilities

The joint 2023 Top Routinely Exploited Vulnerabilities advisory from CISA, the FBI and the NSA runs heavily to internet-facing edge products, not the applications a scope centers on.

Citrix NetScaler, Cisco IOS XE, Fortinet SSL-VPN, MOVEit Transfer and Barracuda appliances all sit in its top fifteen, exactly the shadow-IT class your scope is least likely to name.

The same advisory found that most of those vulnerabilities were first exploited as zero-day exploits, so identifying weaknesses in edge products early matters, and attackers tend to have the most success within two years of disclosure.

CISA's Known Exploited Vulnerabilities catalog turns that into a targeting method, because the bar for inclusion is evidence of exploitation in the wild, not a severity score. Cross your fingerprinted version list against it to flag outdated software running a known-exploited CVE, before spending a single exploitation hour.

Step 10: Test default credentials, then chain to impact

Default and reused credentials on exposed databases and SSH get checked first, before anything more sophisticated, because they need no exploit and end engagements early. Escape only flags one when it has actually logged in, so what reaches your report is a confirmed way in, not a guess someone still has to go and verify.

The serious findings almost always come from chaining a few smaller ones together, in which the route itself is the finding. The example below is built entirely from what the earlier phases already turned up:

1. Step 7 flags a subdomain takeover on a decommissioned marketing host.
2. Step 5's breach-corpus check surfaces a reused password for an employee whose address format Step 5 already derived.
3. That credential opens the VPN portal from Step 8, which accepts it without a second factor.
4. Inside, an exposed database from Step 6 shares the same default credential.

On its own, not one of those four steps is critical. Put together, they're a successful attack, a full external compromise with privilege escalation into sensitive data of the kind behind most data breaches, and that chain is what belongs in the report, meaning the exact request sequence, the accounts involved, and the impact you could observe. Written that way, your own engineer can reproduce it without the tester in the room, which is what makes a finding something you can actually fix.

Phase 4: Continuous validation and remediation

The three phases so far all assume you already have a good list of what to test. The trouble is that the list starts going out of date the day the engagement ends, and a single test can't fix that. This last phase is about keeping that list alive between tests, which is where a lot of programs quietly fall behind.

Step 11: Account for scope decay between tests

NCSC states the limit of its own instrument plainly, noting that a test only validates that your systems aren't vulnerable to known issues on the day of the test, and that a year or more often elapses between tests.

The drift it's written against is ordinary rather than exotic, and it's what keeps your exposure to evolving threats moving, from new hostnames and staging that outlive its sprint to expired DNS delegations and an acquired company's whole perimeter arriving in a week.

The federal floor puts a number against the discovery half of that gap. BOD 23-01 requires automated asset discovery every 7 days across the entire IPv4 space an agency uses, plus vulnerability enumeration across all discovered assets every 14 days. Deep testing on a longer cycle is defensible, blind discovery on a longer cycle is not.

That drift quietly widens the entry points into your organization's systems and the sensitive information behind them, and model-backed AI services are the newest class on that list. Escape's attack surface management detects unauthenticated exposed Model Context Protocol (MCP) endpoints as ordinary internet-facing assets, discovering and flagging them rather than actively testing them, a distinction worth keeping straight when you scope.

Step 12: Reserve specialist tooling for what it does best

A discovery and validation platform handles the broad, continuous coverage. Even so, three jobs still need a penetration tester doing manual testing with specialist or proprietary tools, and it's a short list your testing team keeps close:

Step 13: Attribute, route and retest every finding

Finding the exploit is only half the job, because a fix nobody owns just sits in a report gathering dust. So a good test also produces a detailed report that says which team stood each host up in the first place.

Escape does this for you, mapping every host to its team or brand, routing a tailored code fix to those owners, and pushing every exposed asset into Wiz with its owner, type, and exposure level attached.

Retesting matters just as much, because a fix you never re-run is really just a hope that it worked. Escape's Cascade handles the deeper checks an automated sweep can't, holding several user identities at once to see whether one person can reach another's data.

Every finding it proves in that AI pentesting work becomes a regression test DAST re-runs on every build, so the proof keeps working long after the engagement ends.

Conclusion

A yearly pentest still matters, but the report is only as good as the asset list behind it, and that list starts drifting the day the tester logs off. Escape keeps that list live, rebuilding your perimeter from the outside every day, proving the findings that matter with a real exploit rather than a severity score, and rerunning each proof on every deploy. If you'd rather see your real attack surface than guess at it, book a demo and we'll rebuild yours live.

FAQs

What is the difference between internal and external penetration testing?

The key differences come down to where the tester starts, and external testing works from the public internet with no access, measuring your perimeter security by asking whether an attacker gets in at all. Internal tests start from internal access, an assumed foothold on the internal network, and ask how far they reach across internal systems, closer to the damage an insider threat or a phished employee could do. Plenty of teams run both to get a complete security picture, since one checks external defenses and the other checks the security controls behind them.

How much does an external penetration test cost?

The price of an external pen test is driven by the number of in-scope hosts and services, the test basis you choose, and whether a retest is included. A scope of unknown size is what makes quotes incomparable, so ask what discovery produced the asset list before you compare numbers.

How long does an external penetration test take?

Duration is set by the size of the reachable surface and by how much of the window reconnaissance consumes. A larger unknown estate spends more of the engagement on discovery and less on exploitation, so an accurate asset list buys you depth.

Is an external penetration test the same as an external vulnerability scan?

A scan enumerates known issues across assets you already know about, while a test chains those issues and demonstrates their impact. NCSC's position is that penetration testing provides assurance over your vulnerability assessment and management processes, rather than being the primary way to find vulnerabilities.

How often should you run an external penetration test?

In any sensible cybersecurity strategy, how often you run a deep test and how often you discover new assets are two separate decisions, and a lot of programs get into trouble by treating them as one. CISA's BOD 23-01 uses 7-day automated asset discovery and 14-day vulnerability enumeration as its cadence, so running deep tests less often is reasonable as long as discovery underneath is always on. Set that split in your security policies and give your security experts the continuous discovery they need to act on it.

What tools are used in an external penetration test?

Specific products change faster than the categories they sit in, so it's worth answering at the category level. A discovery and validation platform carries the continuous breadth work; ffuf handles content discovery; testssl.sh produces cipher and protocol findings, Metasploit covers network-service exploitation, and theHarvester maps the identity surface.

Do AI endpoints and MCP servers belong in an external pentest scope?

They fall within scope as soon as they're internet-reachable, and MITRE ATT&CK now includes a reconnaissance technique for querying public AI services. These endpoints carry a different attack taxonomy from ports and services, so scoping them in without adjusting the methodology doesn't actually cover them.

Sources

• Penetration testing - National Cyber Security Centre
• M-Trends 2026 - Mandiant
• 2023 Top Routinely Exploited Vulnerabilities - CISA, FBI and NSA
• Known Exploited Vulnerabilities catalog - CISA
• BOD 23-01, Improving Asset Visibility and Vulnerability Detection - CISA
• Reconnaissance, TA0043 - MITRE ATT&CK
• AI 100-2 E2025, Adversarial Machine Learning - NIST