Note from the Editor: This blog is part 5 of a 10-part series on Everything you need to know about an Internal Penetration Test. To read the series from the beginning, please go to the blog, What is an Internal Penetration Test?
Internal penetration testing takes the perspective of a malicious individual that is connected to your organization’s corporate network. This style of penetration testing has a similar goal to external penetration testing (find sensitive data, take administrative control of the network, etc.), but provides a completely different attack surface for the assessment team to analyze. An internal penetration test also involves giving someone access to your network by placing a testing system somewhere in the environment, which can be scary. It’s a good idea to have an understanding of what’s going to happen on your internal network during the course of a penetration test, as this can help alleviate that fear of the unknown as well as prevent potential problems during the test. So let’s dive into an overview of our attack team’s internal penetration testing methodology.
Internal Penetration Test Methodology 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
Tools commonly used during an Internal Penetration Test
- Burp Suite Pro
- Dirbuster/Dirb/GoBuster
- Nikto
- Sqlmap
- Nessus
- Responder
- Metasploit Framework
- Nmap
- Hydra
- Bettercap/Ettercap
- Hashcat/John the Ripper
- Custom Scripts
Internal Penetration Test Methodology Process
Our internal penetration testing methodology can be broken into 3 primary stages, each with several steps.
Planning
1. Gather Scoping Information
After initiating the project, we will collect scoping/target information. In the case of internal penetration testing, this information will include all network ranges in scope, compromise goals to help us focus our attacks, and information that can help us prevent issues, such as your 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, we send a start notification to the client. The first phase involves passive intelligence gathering, which will include sniffing the network and analyzing the traffic we can see. Additionally, we perform some open source intelligence gathering to determine information such as user accounts, software information, etc. The goal of this phase is to identify any sensitive information that may help during the following phases of testing.
Tools may include: Wireshark, TCPDump, GHDB, 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 internal penetration test is to emulate an attacker who has already gained access to the internal network or a malicious insider. As such, during this stage we will evaluate the targets in scope and determine an attack path that follows real-world attacks.
Tools may include: nmap, responder, Wireshark
3. Vulnerability Analysis
The vulnerability analysis phase starts with the active enumeration of all in-scope targets/applications. For each service discovered, automated and manual techniques will be used to attempt to find vulnerabilities on those hosts. The engineer attempts to identify the version of the service and identify any previously published vulnerabilities. The engineer will also test the unauthenticated portion of any web applications discovered. Each service will be tested for default credentials, misconfigurations will be identified, and the attack surface will be prioritized ahead of the exploit phase.
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. That attack team focuses on using the identified vulnerabilities to reach the compromise goals laid out for the assessment, which usually involve accessing/exfiltrating sensitive data and/or taking administrative control of the corporate network.
Additionally, for an internal penetration test, there are attacks that take advantage of being on the same local network as in-scope targets. These include NBNS Spoofing, LLMNR Spoofing Attacks, ARP Cache Poisoning, etc. During the exploitation stage, the test team will try to gather credentials throughout the environment in various ways. For each login prompt discovered, password attacks will be attempted to try to gain access to in-scope systems.
Tools may include: Metasploit Framework, Responder, Bettercap, Hashcat, BurpSuite Pro, custom scripts
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. Our engineer will attempt to elevate their permissions and eventually achieve domain administrator, or top level permissions on the domain. Once permissions are elevated, the test team will demonstrate the risk by identifying sensitive information such as credit cards, protected health information, internal communications, etc. We’ll use the information collected here in the prioritization and criticality ranking of identified vulnerabilities.
Tools may include: Metasploit Framework, Burp Suite Pro, ExploitDB, 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 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
This blog was an overview of our internal 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.
If you’d like to learn how we can help keep your institution with an internal penetration test, please contact us today.
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. Matt can be found on twitter @InfoSecMatthew.
