Note from the Editor: This blog is the 2nd installment of an 8-part blog series entitled, “Everything you need to know about an External Penetration Test.” To read series from the beginning, start at “What is an External Penetration Test?”
One of the primary questions we get from clients is about our external penetration testing methodology. This is a great question, and usually is an indication that our potential customer is doing their due diligence. After all, you are about to let someone hack your perimeter, it would probably be good to at least ask how they plan to do that. We also love to go over our external penetration testing methodology as it gives us a chance to explain what to expect. It also helps us to prevent problems from occurring during testing.
While every institution is different and therefore the external penetration testing will be different, our methodology is standard. This blog will cover said methodology at a high level. And, cover the most common questions.
External Penetration Test Methodology Standards?
To ensure we are maintaining industry guidelines, we base our external penetration testing methodology on the following standards:
Open Web Application Security Project (OWASP) Testing Guide
Technical Guide to Information Security Testing and Assessment (NIST 800-115)
The Penetration Testing Execution Standard (PTES)
Payment Card Industry (PCI) Penetration Testing Guidance
External Penetration Testing Tools?
We use the following tools to execute our external penetration testing:
- Burp Suite Pro
- Dirbuster/Dirb/GoBuster
- Nikto
- Sqlmap
- Nessus
- Recon-ng
- Metasploit Framework
- Nmap
- Custom Scripts
- Hydra
- GHDB
- theHarvester
What’s the Process?
Our external penetration testing methodology can be broken into 3 primary stages, each with several steps.
Planning
1. Gather Scoping Information
After initiating the project, we collect scoping/target information from the client. In the case of external penetration testing, this information will include any applicable IP addresses and URLs in scope, compromise goals to help us focus our attacks, and information that can help us prevent issues, such as account lockout policy and any web forms to avoid.
2. Review Rules of Engagement
This process involves a brief meeting to review and acknowledge the penetration testing rules of engagement, confirm project scope and testing timeline, identify specific testing objectives, document any testing limitations or restrictions, and answer any questions related to the project.
Execution
1. Reconnaissance
Once the test has officially begun, a start notification will be sent to the client. The first phase will involve open-source intelligence gathering, which includes a review of publicly available information and resources. The goal of this phase is to identify any sensitive information that may help during the following phases of testing, which could include email addresses, usernames, software information, user manuals, forum posts, etc. Additionally, this step will include searching for sensitive information that should not be publicly available, such as internal communications, salary information, or other potentially harmful information.
Tools may include: Recon-ng, Maltego, Google Hacking, Wayback Machine, custom scripts
2. Threat Modeling
For this assessment, the threat modeling phase serves to evaluate the types of threats that may affect the targets that are in scope. The types of attacks and likelihood of these threats materializing will serve to inform risk rankings/priorities that are assigned to vulnerabilities throughout the assessment. This phase of the assessment should also include host and service discovery, combining the passive methods of detection from step 1 with active enumeration. The ultimate goal of an external penetration test is to emulate an attacker on the Internet trying to break into your network. As such, during this stage we will evaluate the targets in scope and determine an attack path that emulates real-world attacks.
Tools may include: nmap, Burp Suite Pro, custom scripts
3. Vulnerability Analysis
The vulnerability analysis phase will encompass the discovery and enumeration of all in-scope targets/applications. For each service discovered, automated and manual techniques will be used to attempt to find vulnerabilities with the in-scope targets. The engineer will attempt to identify the version of the service and investigate for previously published vulnerabilities. The engineer will also test the unauthenticated portion of web applications discovered for vulnerabilities listed in the OWASP Top 10. Finally, each service will be manually inspected and tested for default credentials, or other vulnerabilities that might be missed in an automated scan.
Tools may include: Nessus, nmap, Burp Suite Pro, Metasploit Framework, netcat, dirb, SSLscan
4. Exploitation
This phase will involve taking all potential vulnerabilities identified in the previous phases of the assessment and attempting to exploit them as an attacker would. This helps to evaluate the realistic risk level associated with the successful exploitation of the vulnerability, analyze the possibility of exploit/attack chains, and account for any mitigating controls that may be in place. Additionally, we’ll identify any false positives during this activity. Triaxiom will exploit automatically identified vulnerabilities and evaluate issues requiring manual identification and exploitation. Finally, for each login prompt discovered, default passwords and other password attacks will be attempted to try to gain access to in-scope systems.
Tools may include: Metasploit Framework, Hydra, Burp Suite Pro, Sqlmap, ExploitDB
5. Post Exploitation
After successful exploitation analysis will continue, including infrastructure analysis, pivoting, sensitive data identification, data exfiltration, and identification of high-value targets/data. We’ll use the information collected here in the prioritization and criticality ranking of identified vulnerabilities.
Tools may include: Metasploit Framework, Burp Suite Pro, custom scripts
Post-Execution
1. Reporting
After completing the active potion of the assessment, we will formally document the findings. The output provided will generally include an executive-level report and a technical findings report. The executive-level report is written for management consumption and includes a high-level overview of assessment activities, scope, most critical/thematic issues discovered, overall risk scoring, organizational security strengths, and applicable screenshots. The technical findings report, on the other hand, will include all vulnerabilities listed individually, with details as to how to recreate the issue, understand the risk, recommended remediation actions, and helpful reference links.
2. Quality Assurance
All assessments go through a rigorous technical and editorial quality assurance phase. This may also include follow-ups with the client to confirm or deny environment details, as appropriate.
3. Presentation
The final activity in any assessment will be a presentation of all documentation to the client. We will walk the client through the information provided, make any updates needed, and address questions regarding the assessment output. Following this activity, we’ll provide new revisions of documentation and schedule any formal retesting, if applicable.
Conclusion
Hopefully this helps explain our external penetration testing methodology. Of course this does not account for every scenario our engineers may encounter during the test, but it does provide the broader steps that our engineers will take when evaluating your perimeter. Our goal is to provide you with a holistic view of your risk by emulating the process an attacker would take. Please let us know if you have any questions.
About the Author
Matt is Director of Penetration Testing at SIG. He currently has his PCI QSA, CISSP, OSCP, C|EH, GSEC, GCIH, and CISA certifications. You can find Matt on Twitter @InfoSecMatthew.
