What is external penetration testing?
An external penetration test simulates a real-world attack from the outside in, assuming the attacker starts with zero prior access. This assessment tests your public-facing assets to show exactly how an adversary could exploit weaknesses to find a path into your environment. Its counterpart, internal penetration testing, assumes an attacker already has a foothold and tests what they can exploit from within.
Both belong to the broader penetration testing framework: a time-boxed, authorized security assessment that discovers vulnerabilities and validates their real-world exploitability. The core distinction between external and internal is simply the attacker's starting point.
Where vulnerability scanning produces a list of CVEs and misconfigurations, external pen testing reports validate which of them are actually exploitable and demonstrate attack paths from reconnaissance to business impact.
Vulnerability Management Buyer's Guide
This buyers guide will not only help you objectively choose or replace a vulnerability management solution, but also provide insights on how your organization can work together to own the responsibility of security as one team.
External pen test vs. vulnerability scanning vs. red teaming
The differences between penetration testing, vulnerability scanning, and red teaming boil down to the goals, testing modes, and adversarial fidelity.
| Differentiation criteria | Vulnerability scanning | External pen testing | Red teaming |
|---|---|---|---|
| Goal | Get a prioritized list of all vulnerabilities and misconfigurations in the stack | Determine which risks in internet-facing assets are exploitable | Test detection logic and response posture against realistic attacks |
| Testing mode | Continuous automated scans to spot CVEs | Semi-automated, attacker-driven validation of the external attack surface | Objective-driven adversary emulation combining multiple attack vectors |
| Adversarial fidelity | Low fidelity: finds risk, exploitable or not | Medium–high fidelity: tests exploitability to varying degrees | Maximum fidelity: evaluates adversary ability to exploit risks while evading detection |
| Starting point | Authenticated/unauthenticated scanning | Varies by engagement model, from zero (black-box) to full (white-box) environmental visibility | Zero knowledge or assume breach |
| Output | Prioritized vulnerability inventory plus remediation suggestions | Verified attack paths, business impact, remediation guidance | Detection gap and blue team readiness assessment |
What counts as your external attack surface today?
Many teams define their external attack surface as the IP ranges and domains they control. But that model was incomplete a decade ago. Today, it misses the ephemeral, identity-driven cloud and AI assets that attackers routinely discover through internet-wide enumeration, OSINT, and exposed trust relationships. The categories below cover the most commonly overlooked components of the modern external attack surface:
Ephemeral subdomains: Automated CI/CD pipelines generate TLS certificates for feature-branch and preview deployments. Even after DNS records and servers are torn down, these subdomain names are permanently recorded in public Certificate Transparency (CT) logs, giving attackers a map to forgotten or abandoned services.
Development and staging environments: Dev and staging environments are routinely excluded from testing scope, yet they frequently contain production database snapshots, valid OAuth tokens, service accounts, and overly permissive configurations, making them high-value entry points.
Cloud storage: Misconfigured S3, Azure Blob, and GCS buckets frequently inherit insecure defaults or bypass standard provisioning controls. Wiz reports publicly exposed PaaS databases in 72% of cloud environments; any meaningful external pen test must enumerate these.
APIs and leaked identity artifacts: API keys, OAuth tokens, service account credentials, and secrets routinely surface in Git repositories, client-side JavaScript, and commit history. Wiz Research found verified public repository secret leaks in 65% of Forbes AI 50 companies. These leaked artifacts provide attackers with authenticated access that’s often difficult to discover, making them high-priority external pen test assets.
AI inference endpoints and vector databases: Public-facing LLM inference endpoints, RAG backends, and vector databases increasingly lack authentication or proper access controls, creating new avenues for asset exposure and data exfiltration. Wiz Research documented the DeepSeek ClickHouse exposure: an unauthenticated database exposing chat history, API keys, and sensitive operational data. It shows why external pen tests must include visibility into inference endpoints and their configurations.
What is application penetration testing?
Application penetration testing is a simulated cyberattack against a software application designed to identify exploitable security vulnerabilities before malicious actors do.
もっと読む
How to handle assets that change before the test starts
Traditional pen testing treats assets as fixed, but in cloud-native architectures, they aren't. Auto-scaling groups replace instances, ephemeral containers appear and disappear, and IP ranges go stale before the test clock starts.
For external testers, this means three things:
First, replace IP-based scoping with DNS wildcard enumeration. Use CT logs (crt.sh) and aggressive subdomain brute-force tools (puredns, massdns) to discover *.api.your-domain.com.
Second, modern single-page apps embed dynamic API routes in client-side JS bundles. Use automated crawlers to parse these to discover routes that never appear in static IP scans or public DNS.
Third, external testers can query Shodan/Censys for domain SSL certificates and map the associated netblocks. This ensures all publicly exposed assets under a cloud provider's prefix are enumerated, even when new instances spin up post-scoping.
How does an external pen test actually work?
External pen tests commonly follow the Penetration Testing Execution Standard (PTES), which defines core phases for pre-engagement interactions, intelligence gathering, threat modeling, vulnerability analysis, exploitation, post-exploitation, and reporting.
Before the first packet: Pre-engagement and intelligence gathering
Pre-engagement finalizes rules of engagement (ROE), confirms scope, tests emergency contacts, and verifies written authorization. Intelligence gathering then uses OSINT sources such as LinkedIn, GitHub, Certificate Transparency logs, and the Wayback Machine to collect passive reconnaissance without sending packets to the target. Testers mine LinkedIn and job postings for employee and infrastructure data, GitHub for exposed secrets and Terraform/Troposphere configs, and the Wayback Machine for historical API endpoints.
CT logs are the external pen tester's goldmine: Every TLS certificate issuance is recorded, revealing every subdomain ever certified, including feature-branch hosts and orphaned infrastructure from acquisitions. Cloud-native OSINT goes further, uncovering public bucket listings, indexed cloud console URLs via Google Dorking, and IAM policies exposed through misconfigured OIDC providers or overly permissive role trust relationships.
DAST vs pen testing: Key differences explained
Traditional pen testing was purely manual and periodic. Modern approaches increasingly incorporate automation, AI-assisted tooling, and penetration testing as a service (PTaaS) models that offer more frequent engagements.
もっと読む
Finding and validating vulnerabilities
Active testing begins with threat modeling to prioritize attack paths. External pen testing maps public‑facing assets (APIs, load balancers, web apps, storage buckets), determining which are most exploitable, in what sequence, and their potential blast radius. The resources scanned in this vulnerability analysis phase are determined by the focus of the external pen testing engagement.
Robust pen testing exercises combine traditional enumeration (Nmap, Nuclei) with cloud‑specific probes such as:
API gateways and serverless functions: To test for unauthenticated method invocation, excessive permissions, and environment variable exposure
Containerized workloads: To scan for publicly exposed container registries, misconfigured image tags, and writable volumes
Managed databases and storage: To verify bucket ACLs, enable versioning checks, and test for public snapshots or replica endpoints
Identity and access: To validate OIDC/JWT trust relationships, role assumption policies, and service account token lifetimes
Once the external attack surface is mapped, findings are manually validated, eliminating false positives and confirming exploitability under engagement conditions.
Exploitation, post-exploitation, and the report
In pen testing, exploitation is controlled. Testers use the minimum foothold needed to demonstrate impact, rather than racing to maximize damage. Still, confirming exploitability means proving impact, not just reachability.
In cloud-native external penetration testing, that could mean achieving remote code execution (RCE) in a container or serverless function, bypassing API authentication, accessing misconfigured cloud storage, abusing overprivileged IAM roles, and ultimately demonstrating at post-exploitation what assets an attacker can reach from an established foothold.
Can the tester reach a cloud metadata endpoint, such as an instance still allowing IMDSv1, to harvest temporary credentials, extract sensitive data, or access logging buckets that store audit trails?
The pen test report produces a documented attack chain from initial reconnaissance through exploitation to demonstrated impact. Each finding is supported by evidence and reproduction steps. The report includes an executive summary for leadership and prioritized technical findings for the engineering team, with each finding followed by an actionable fix.
Watch 12-min demo
Learn about the full power of the Wiz cloud security platform. Built to protect your cloud environment from code to runtime.
How to prioritize and act on findings
CVSS measures theoretical severity in isolation, assuming attackers can always reach the vulnerability. It does not account for network paths, exploit availability, or downstream impact. Three real-world variables give a more accurate picture:
Reachability: Is the asset internet-accessible? A vulnerability behind a VPC boundary, WAF, or firewall that actually blocks public access is not your first priority.
Exploitability: Does a working exploit exist? Check EPSS for exploitation probability in the wild. A 90th-percentile EPSS score indicates that the vulnerability ranks in the top 10% for likelihood of exploitation within the next 30 days.
Blast radius: What can an attacker access from the foothold? RCE in a read-only logging service is less urgent than an auth bypass in front of your payment database.
Consider this example: Finding A is RCE (CVSS 8.9) but sits behind an effective WAF, internet-unreachable. Finding B is an auth bypass on port 443 (CVSS 6.5), publicly exposed, has a public PoC, and sits in front of production data. Fix B first. When an engineer pushes back on a "medium" finding, walk them through the network path, exploit complexity, and what the service has access to. The path convinces; the score doesn't.
Remember: A pen test report provides real strategic value only when it drives active remediation. Clear prioritization and seamless engineering handoffs are where that security value translates into actual protection for your environment.
Tracking findings and remediation SLAs
Some teams auto-remediate via policy as code (OPA rejecting open S3 buckets, AWS Config auto-reverting security group changes) or hotfix criticals on the spot. Others generate tickets in Jira or Linear before applying fixes. Whichever approach, three outcomes are non-negotiable: the finding is tracked, the risk is fixed, and the fix is validated. Getting all three requires tracking the following metadata:
Affected asset: Resource ID, hostname, or specific endpoint
Finding summary: What was vulnerable and why?
Reproduction steps: Numbered and tester-verifiable, so an engineer who has never seen the finding can follow them and reproduce the issue
Remediation action: What was changed?
Owner: Exact name of the engineer or specific team
Validation timestamp: Who confirmed the fix and when?
SLA deadline: In ticket-driven workflows, setting practical remediation SLAs means findings don’t get buried in reports. For example, your SLA baseline may look like this:
| Severity | Owner assignment | Remediation window |
|---|---|---|
| Critical | 24–48 hours | 30 days |
| High | 72 hours | 30 days |
| Medium | 1 week | 90 days |
SLA windows are informed by PCI DSS 4.0 patching conventions and serve as a practical baseline, not a universal compliance requirement.
How often should you run external pen tests?
Annual testing is the regulatory minimum. PCI DSS 4.0 (Requirement 11.4) requires annual external penetration tests plus retests after significant infrastructure or application changes. SOC 2 (CC7.1, CC4.1) implies expectation of regular pen testing, though it never explicitly mandates it. ISO 27001:2022 (Annex A Controls A.8.8 and A.8.29) expects risk-driven testing. The common thread: at least annually.
Compliance aside, significant changes such as cloud migrations, new external APIs, M&A integrations, and authentication changes warrant a retest. But even annual and out-of-cycle tests won’t cover the inference endpoint that shipped last week, the bucket made public yesterday, or the secret committed this morning. In other words, enterprises must treat pen testing as a snapshot, not a shield, and prioritize comprehensive coverage between tests.
How Wiz strengthens your external penetration testing program
An external pen test gives you something automated tools cannot: a skilled human chaining real exploits against your perimeter to prove what an attacker could actually reach. The tradeoff is that the engagement captures a point-in-time snapshot, and in cloud environments where auto-scaling and ephemeral workloads reshape the external attack surface by the hour, that snapshot needs continuous context to stay actionable.
That’s why Wiz works alongside your testing program on both sides of the engagement.
Before the test, Wiz keeps your external attack surface continuously visible:
Continuous external discovery and validation: The Wiz Attack Surface Management (ASM) Scanner continuously discovers externally reachable assets across cloud, AI, on-prem, and SaaS. It validates which exposures are actually exploitable and produces concrete proof, including screenshots of exposed services and confirmed remote code execution.
Attack-path context: The Wiz Security Graph correlates exposures with identity permissions, network reachability, and proximity to sensitive data, surfacing the toxic combinations that form real attack paths rather than isolated weaknesses.
AI-driven validation between tests: The Wiz Red Agent performs adaptive exploitation against web apps and APIs, discovering shadow APIs and chaining multi-step attacks that automated scanning misses.
After the test, Wiz makes sure the findings don’t expire in a report.
With Wiz Penetration Test Findings, you upload and parse reports from third-party pen testers, pull in bug bounty results through the HackerOne integration, and track internal red-team work in a single view enriched by the Security Graph.
Each finding is mapped to the underlying cloud resource and its owner, with the screenshot of the exposed asset, network paths, and code-to-cloud mapping attached. This lets you prioritize by real impact, set remediation SLAs, and fix issues at the source.
The result is a sharper program: Your testers walk in with the highest-risk paths already surfaced, and their findings flow into the same context-rich view as the rest of your cloud risk, staying relevant long after the report is delivered.
Want to see how your external attack surface looks through the Security Graph? Get a demo to connect your environment in minutes, visualize real attack paths to critical assets, and turn pen test findings into a continuously validated remediation workflow.
Uncover Vulnerabilities Across Your Cloud
Stop chasing alerts—Wiz maps your entire cloud to find and prioritize real risks immediately.
