Get Started

External Pentest: What Attackers Find on Your Perimeter

On 14 May 2026, CISA added a CVSS 10.0 authentication bypass in Cisco Catalyst SD-WAN to its Known Exploited Vulnerabilities catalog, with active exploitation already confirmed in the wild. That single advisory landed in the same month as the 2026 Verizon DBIR, which reports for the first time in nineteen years that exploiting vulnerabilities has overtaken stolen credentials as the most common breach entry point. An external attack surface penetration test is the practice that translates those two headlines into a clear answer for your own perimeter: not what could go wrong in theory, but what an attacker would actually get if they pointed their toolkit at your public IP space tomorrow.

This piece walks through what the test actually looks like from the outside in, what categories of findings a real engagement surfaces that a scanner cannot prove, and how the cadence is changing as perimeters change faster than annual audits can track.

The Attacker’s View of Your Perimeter

Before a real attacker writes a single payload, they spend hours mapping what an organisation has exposed to the internet. The team approaches each engagement the same way: passive reconnaissance first, then active probing of every IP, hostname, and edge service that traces back to the client’s name in WHOIS records, certificate transparency logs, and DNS history.

Internet-facing services enumeration is the part that surprises clients most. Even mature organisations underestimate how much has accumulated on their perimeter after a few years of cloud migration, M&A activity, and the occasional rushed product launch. A typical external pentest scope covers:

The April 2026 Censys FTP exposure brief observed just under 6 million hosts running at least one internet-facing FTP service. That number is a useful sanity check on the size of the problem: legacy plaintext protocols are still everywhere, and most of the organisations running them stopped tracking them years ago.

What a Real External Pentest Surfaces

A scanner tells you a port is open. A pentest tells you whether the service behind that port can be used to gain a foothold in the environment. The distinction matters because the report a board reads is not a list of open ports; it is a list of attack paths with the steps an attacker would have used.

In practice, the team’s findings cluster around a handful of recurring categories:

The full list is longer, but the pattern is consistent: most exposure on a real perimeter is not exotic. It is ordinary, accumulated, and invisible until somebody enumerates it from the outside.

Scanner Flags vs. Proven Exploitability

A common board question after a CVE makes the news is whether the organisation already has this covered through its existing vulnerability scanner. The shortest honest answer to the vulnerability scan vs penetration test question is this: a scanner lists what exists; a pentest proves what an attacker can do with it.

The difference shows up in three concrete ways.

First, false positives. Scanners flag every service version that matches a known CVE signature, including patched builds that vendors backported privately. The team’s job is to reach the service, attempt the exploit in a controlled way, and confirm whether the issue is actually present.

Second, chained exploitation. A scanner reports three medium-severity issues on three different hosts. The team reports that those three issues, chained together, give an unauthenticated attacker code execution on the VPN concentrator and an administrative session in the directory service it integrates with. The chain is the finding; the individual CVEs are the building blocks.

Third, business context. Scanners cannot tell you that the exposed staging environment shares credentials with production, or that the orphaned subdomain points to a forgotten bucket that still holds last year’s customer export. The team can, because the engagement is built around understanding what each compromise would actually mean for the client.

For organisations evaluating what a third-party security assessment covers ahead of a procurement or board reporting cycle, the scope of a real pentest is the closest equivalent to having an attacker walk the perimeter for you on a fixed timetable.

From Perimeter Foothold to Internal Access

A successful external exploit is the start of the engagement, not the end. The next question every CISO asks is what the blast radius looks like: from the compromised edge device, how far into the internal estate could an attacker reach before detection?

In a typical engagement, the team chains an exposed VPN appliance CVE to an internal foothold, uses the resulting credentials to enumerate the Active Directory, and reaches a service account with rights over a sensitive share. None of the steps require novel exploitation, and none of them generate alerts at the volume threshold most security operations centres are filtering for. That same pattern is part of why EDR alone won’t stop the breach: identity-aware detection on the inside has to assume the perimeter has already failed, because in most modern breaches it has.

The lesson is not that perimeter testing replaces detection. It is that the two work as a single picture. A real perimeter test tells you which doors are open and how far they lead; identity-aware detection tells you what happens once somebody walks through one.

How Often the Perimeter Needs Looking At

The traditional cadence for testing the external perimeter is annual, often anchored to a compliance cycle. That cadence made sense when perimeters changed twice a year. It does not match how organisations actually shipped in 2025 and 2026.

Cloud migrations, M&A activity, new appliance deployments, and the steady drip of CVEs against perimeter vendors all change the external attack surface continuously. CTDefense recommends a layered approach: a deep, human-led external attack surface penetration test on the standard annual cadence, paired with continuous validation between engagements that re-tests every exposed asset whenever the perimeter changes or a new high-severity CVE drops. For organisations that need that cadence without tripling their engineer headcount, an autonomous AI pentest platform like PentX runs the same enumeration-to-exploitation chain in hours, on every perimeter change, with the human team still owning the deep annual engagement and any novel architecture review.

That layering is also where compliance regimes are heading. NIS2 penetration testing requirements treat regular testing of network and information systems as a baseline operational practice, not a once-a-year audit deliverable; DORA does the same for financial entities. Annual is still the floor; continuous is increasingly the expectation.

Where This Leaves the Conversation

The 2026 DBIR has made perimeter vulnerability exploitation a board-level conversation, and the Cisco SD-WAN advisory has given that conversation a concrete name. The question peers across the same sectors are asking this quarter is not whether to test the external perimeter, but how to keep testing it at the cadence the threat now demands.

CTDefense continues to deliver External Network Security Audit engagements for mid-market and enterprise organisations across finance, manufacturing, critical infrastructure, and technology. Similar organisations that have recently undergone a cloud migration, an M&A event, or a peer-breach scare are the ones for whom a perimeter test now, rather than at the next annual slot, tends to surface the most.

Leave a Reply