This is part 4 of a multi-episode series where the Offsec group at SecurIT360 dives into the details of various Offensive Security Tests, what they mean, what to expect, war stories and much more!
If you’re on to go, listen here or on your favorite podcast app: https://www.buzzsprout.com/1731753/12008269
Are you worried about your external security? Do you think you may have exposed administrative interfaces or maybe even sensitive services like RDP open to the internet? Maybe you have public-facing web applications that were made in-house and aren’t secure? If you answered yes to any of these questions then I have a solution for you. You are in
dire need of an external penetration test. This is no run-of-the-mill vulnerability scan. External penetration tests cover a wide variety of items in organizations’ environments and they are tailored per client. In this blog post, we are going to cover what an external pentest is, what methodology we use, why you need a pentest, and then wrap up with a deep dive into how external pentests work.
What is an external pentest?
So, you’ve decided that your organization needs an external penetration test, but you’re asking yourself “What exactly is an external pentest?” That is a fantastic question! All of our penetration tests are executed in three primary phases, based on guidance from the Penetration Testing Execution Standard (PTES) methodology. The recon phases (active and passive) are used to discover resources and identify possible avenues of attack. This includes the discovery of credentials on the dark web and cloud resources. The attack phases include launching attacks against client resources like web applications or any ports that are enumerated. These attacks can include remote code exploits, credential stuffing, password spraying and more. This phase is intended to raise alarms and provide an avenue for infiltration into the target environment and exploitation. Finally, a reporting phase rounds out the testing. This document is the artifact produced in this phase.
Note that attacks that are likely to cause outages and attacks or that intentionally create Denial of Service (DOS) or Distributed Denial of Service (DDOS) conditions are not intentionally employed during any phase of testing.
The Penetration Testing Execution Standard (PTES)
The PTES methodology was briefly mentioned above, and since this is the methodology that we use at SecurIT360 I would like to give a deep dive into it. This is an industry-wide standard that defines how a pentest should be conducted and it includes seven parts. I’ll include brief descriptions for each in general terms to help clue everyone in on what each means.
- Pre-engagement interactions – Pertains to anything prior to the engagement starting, and includes things like kick-off calls and scoping agreements.
- Intelligence Gathering – Pertains to the Open Source Intelligence that is performed against an organization during the penetration test. This includes enumerating all information that can be found about an organization.
- Threat Modeling – When the pentester models the risk of a vulnerability or compromise to the organization they are testing for.
- Vulnerability Analysis – Analyzing any and all vulnerabilities that have been discovered throughout the test and noting how they can be used by an attacker.
- Exploitation – Leveraging vulnerabilities that were discovered and analyzed. This may include utilizing and/or making proof of concepts for the found vulnerabilities.
- Post Exploitation – Pertains to the penetration tester reverting all changes that were made as part of the testing and making sure the box is in the state it was when testing began.
- Reporting – Documentation surrounding the results of the testing. This document is responsible for highlighting and communicating all vulnerabilities discovered during testing.
This is a high-level overview of how the process looks. Different companies will utilize different tools and processes at each of these steps, however, the high-level methodology is used industry-wide.
Why your organization needs an external pentest
There are a multitude of reasons that organizations may need an external pentest. These can include compliance-based reasons, wanting to find out where the gaps are in your environment, or to get a grasp on your external footprint/exposure. By getting an external pentest you will not only be giving yourself peace of mind, but you will also be able to work to improve any gaps in your environment and be more secure externally.
External Pentest Process
Now that we have covered the basics of how an external penetration test looks and also why there are necessary, let’s dive into how our typical external pentest process will operate. All pentests will start with pre-engagement activities. This includes getting a date for testing on the calendar, scoping the pentest, and also introducing the client to our process. I also wanted to mention that the size of the organization and their scope typically determine the length of the engagement. The typical pentest ranges anywhere from 3-5 days. Once we have scheduled a date and confirmed the scope, we will send a reminder email the Friday before your engagement to confirm that the testing dates and scope that were previously agreed upon are still valid. Once we get the green light then we will start our work. We like to send out an email each day of the engagement to inform the client of the work that will be taking place each day. Below is an example of how a three-day penetration test would operate. To reiterate, engagements can be up to five days depending on the size of the organization.
Pentest Day 1
Day one looks the same for most organizations. This is where OSINT takes place as well as dark web reconnaissance. Day one is all about figuring out who we’re pentesting, what services they provide, if they use any SaaS products, what they have externally facing, things of that nature.
Pentest Day 2
During day two, all the information gathered during day one is leveraged. In all cases, a host list is produced with all the externally facing hosts and IPs, this information is then run through other tools to check for things like TLS health and vulnerabilities. During day two we also check DNS health, perform web application exploitation, and attempt to exploit anything that is discovered from our vulnerability discovery. This could be a result of open ports or vulnerable web pages. This also comes in the form of password spraying.
Pentest Day 3
Day three is when the engagement wraps up. We finish any running exploits and begin our reporting process. We like to get a draft report in the client’s hands within 24 hours of the engagement wrapping up. Reporting is a team sport in our mind. This means that we want to sit down with the client and make sure that they understand every finding in the report and agree with the severity rating of the findings as well. Once we have a post-engagement meeting and everybody is happy with the report, we issue the final report. After the final report has been sent out, we give clients a 30-day retest window for free. During these 30 days, any findings in the report that are remediated are marked accordingly in the report and then a new final report is issued.
The Value Add of An External Pentest
In summary, every organization is going to have public-facing assets, whether those assets are web applications or edge devices, or something else. An external penetration test is a great way to get a grasp on the security of those public-facing assets. By utilizing the PTES methodology, penetration testing firms should be able to identify and validate any security flaws that are discovered. Furthermore, they should be able to assist in identifying open ports, protocols, and services that you are unaware are open or available on the internet. The final result of an external penetration test is a report listing all vulnerabilities discovered with the purpose of helping to identify how your organization can be more secure. If your company is interested in getting an external pentest or wants more information on them feel free to email me at email@example.com or call me at (205)482-5907.