External Pentesting with PTES Methodology
When assessing an organization’s external defenses, the goal is to simulate what a real attacker might attempt, starting from the public internet. Following a structured approach like the Penetration Testing Execution Standard (PTES) helps ensure a thorough and repeatable process. Below, I’ll walk through each step, describing what it entails and giving practical examples.
1. Pre-engagement Interactions
Before any actual testing starts, it’s critical to have clear communication and legal authorization. This phase sets expectations, defines the scope, and ensures both sides understand what will and won’t be tested.
Example:
A client provides two public IP ranges and access to three subdomains they own. They want a “black-box assessment”, meaning we won’t have any internal credentials or documentation. We agree on test dates, escalation procedures, and limits (e.g., “no denial-of-service attacks”). This avoids misunderstandings and keeps everything ethical and compliant.
2. Intelligence Gathering (Reconnaissance)
This step is about collecting as much publicly available information about the organization and its infrastructure as possible, without directly engaging the systems—at least initially. The idea is to build a map of potential targets and learn how the business presents itself online.
Example:
Use tools like `theHarvester` and `Recon-ng` to find employee email formats `first.last@example.com` and several public-facing subdomains like `test-api.example.com`.
Run `crt.sh` lookups to identify SSL certificates that expose even more hostnames.
Use Nmap to scan the IP ranges and discover services like an outdated Apache web server on `203.0.113.5`, and Remote Desktop Protocol (RDP) running on `198.51.100.10`.
This information shapes the rest of the test.
3. Threat Modeling
Analyze the data gathered during recon to prioritize systems based on risk and exposure. It’s a mental shift—from scanning to strategizing.
Example:
During the recon phase we find that `portal.example.com` is running Joomla 3.7.0, which has a known remote code execution (RCE) vulnerability (CVE-2017-8917). Meanwhile, an RDP server allows unlimited login attempts with weak passwords. These are immediate red flags—highly exposed and likely exploitable.
At this point, we know where to focus our efforts for the best risk coverage.
4. Vulnerability Analysis
Now it’s time to identify actual weaknesses in the systems that have been discovered. This means verifying version numbers, testing configurations, and looking for flaws that could be exploited.
Example:
Use a vulnerability scanner like `Nessus` or `OpenVAS` to analyze discovered services.
The Joomla instance is confirmed to be vulnerable to RCE.
A brute-force attempt against `mail.example.com` reveals that the HR mailbox uses `hr@example.com : Welcome123!`, a guessable password.
The RDP service accepts credentials without rate-limiting, which is a big red flag.
These findings now need to be validated and exploited to understand the real risk.
5. Exploitation
This is the phase where theory meets practice. we can attempt to exploit the confirmed vulnerabilities, while remaining within scope and being careful not to disrupt business operations.
Example:
Use Metasploit or a public POC to exploit the Joomla RCE vulnerability and successfully open a reverse shell.
Log in to the HR webmail account using the discovered credentials and can view inbox contents, which include confidential hiring forms.
Brute-force RDP login using `testuser:test123`, gaining desktop access to a production server.
The goal isn’t to “break” things, but to demonstrate the level of access a real attacker could achieve.
6. Post-Exploitation
Now that access is gained, we can analyze how far an attacker could go from this point. Could they move laterally, escalate privileges, or access sensitive data?
Example:
On the Joomla shell, we can access the `configuration.php` file and dump database credentials.
On the RDP server, we find a ZIP file labeled `vpn_keys.zip`—containing unencrypted VPN profiles.
With access to HR’s email, we find login credentials and password reset links for internal tools.
In most cases, we stop short of pivoting into internal systems unless explicitly approved, but document the potential thoroughly.
7. Reporting
Once testing is complete, create a detailed report tailored to both technical teams and executives. This includes a summary of findings, proof-of-concept screenshots, impact analysis, and actionable remediation steps.
Example:
Critical: Joomla RCE vulnerability exploited, full shell access gained.
High: Weak RDP credentials allowed access to production environment.
Medium: Sensitive information in mailbox increases breach risk.
Recommendations: Patch CMS software, enforce MFA on webmail and RDP, implement password complexity and lockout policies.
Deliver the report and, if requested, walk stakeholders through it in a debrief session, helping them understand what’s most important to fix first.
Final Thoughts
An external penetration test is more than just pointing a scanner at a few IPs. Done properly, it provides insight into how exposed an organization really is, and whether an attacker could exploit that exposure to gain access. Using a framework like PTES ensures nothing gets overlooked and that findings are based on real-world risk, not just theoretical vulnerabilities.
