"It is a new standard designed to provide both businesses and security service providers with a common language and scope for performing penetration testing (i.e. Security evaluations)."
The goal of PTES is to create standards for every aspect of the penetration test (pentest). The Standard outlines the different sections that make up a pentest, from pre-engagement interactions to reporting. The technical guidelines (the focus of this compliance package) instead focus on the actual execution of the pentest.
The technical guidelines cover four phases of testing. Each section is summarized below. For more details on any of the phases of testing or the specific tasks performed within each phase, please visit the PTES technical guidelines.
During this phase, the tester gathers as much information about the target as possible. This includes information about technological components but also about employees, facilities, products, and future plans. The information gathered in this phase will vary depending on what is relevant to the target but will always be used to guide the tester in further phases of testing.
The tester searches for any available Open Source Intelligence (OSINT) by checking public sources of information. Most of the information gathered in this phase is found by searching the internet. The tester gathers information on the corporate structure or legal entity. Then, they look at the physical locations of the target and gather as much detail on the property. The tester narrows in even more on any target data center locations and starts to gather broad data about the people who work there. The tester identifies everything from important dates for the company to the structure of the organization to relationships with other organizations and just about everything in between. The goal of this phase is to understand at a high level how the company functions so that this information can guide later stages of testing.
During this phase, the tester looks mostly at the social media profiles of the target company's employees. The tester is looking for everything from friendships and relationships to behaviors and interests that can be exploited later. Thanks to the explosion of social media sites, there is usually a huge amount of data available to the tester, often including geolocation data.
Now it's time to gather publicly-available data about the target infrastructure. The company likely has information like email addresses listed somewhere online. Collecting information like this can help the tester exploit systems later in the testing process. The activities from the previous section (Individuals) is also continued as the tester collects usernames, personal domain names, and personal published materials from individual employees. This step may seem unnecessary but if the tester (or an attacker) can find a username for an employee using these methods, they are halfway to knowing the employee's username and password combination!
Any tester with a secret dream to be a spy will love this phase of testing. The tester goes on-location to gather information about the target by acting like an attacker would. They canvass the entire building and document details on sercuity guards, badge usage, locks and alarm systems, and more. The tester also rifles through the trash and goes "dumpster diving" for potentially exploitable information. Then, they scan radio and wireless frequencies and identify any radios or antennas being used. The actual steps in this phase may depend on the local laws and the details of the engagement to ensure that no laws are broken and that the tester remains safe.
This phase looks at the responses when the tester interacts with the target directly from an external perspective. They are looking at things like IP ranges, WHOIS information, DNS, port scans, and more.
Now, the tester interacts with the target directly, but from an internal perspective. The tester is still focused on the response results but instead is looking at identifying live systems (ping sweeps), port scans, SNMP sweeps, packet sniffing, and more.
When following the PTES guidlines, every vulnerability needs to be identified (discovered) and then validated to make sure that only the true vulnerabilities are reported (removing "false positives").
Active testing uses automated scanning tools to test the target for known security vulnerabilities. Common scanners include OpenVAS, Nessus, NeXpose, Retina, and Qualys. During this active phase of testing, the network and specific web applications are all scanned for vulnerabilities. Then, passive testing is performed to gather even more information about the target. Much of passive testing focuses on fingerprinting and packet analysis. The entire goal of this phase is to identify as many potential vulnerabilities as possible. Remember, they're still potential vulnerabilities at this point, we need to validate them next.
Each of the potential vulnerabilities identified in the testing phase needs to be validated or confirmed. And, if exploits are availave, these also must be validated.Importantly, vulnerabilities that would result in a Denial of Service (DoS) would not be validated unless the scope of the engagement allows for them. During this phase of testing, the tester also checks to see whether any known default passwords are being used and gathers detailed data on all of the targets.
This phase of testing builds on the information gathered in previous phases (especially the Fingerprinting and Vulnerability Testing phases) to identify all of the potential sources of attacks on the target. The tester uses all of this information to create an attack tree: a conceptual diagram showing all of the possible methods that could be used to attack the target. In this phase, the tester also detects (and bypasses or subverts) network-based or host-based protection systems.
The concept of vulnerability exploits was first mentioned in the Vulnerability Validation phase where each exploit was validated. Validation is essentially removing "false positive" results so that only true vulnerabilities are left. Exploitation involves showing how the vulnerability can be used by an attacker. Before exploitation, the potential impact on a business is often theoretical. The exploitation helps move the impact of the vulnerability from theoretical to measurable.
Many times, the "grand finale" of a penetration test is to simulate an attacker in a simulated attack against the target organization. As an example, a tester could create a email campaign with embedded attacks. This is one of the phases of testing where the tester needs to rely heavily on the information they have already gathered on the company, the employees, and the technologies to craft an effective precision strike. There is no quick and easy formula to follow to create a precision exploit, the key is to precisely tailor the exploit to match the information about your target.
Unsurprisingly, this is another phase of testing that is highly customized to the information already gathered about the specific target. The tester might use fuzzing, sniffing, brute-force attacks, or other methods. Or, the tester may find a way to completely customize the exploit by using a custom avenue to access the target or using custom code.
During the Covert Gathering phase, the tester scannned radio frequencies to determine which ones were in use. During this phase, the tester uses the information they gathered to gain accesss to any of the in-use radio frequencies. The tools and methods used during this phase will vary depending on the information gathered in earlier phases.
The scope and details of the engagement may or may not allow for attacks against users. Attacking the user is usually accomplished by leveraging or creating rogue wireless access points to entice the user to connect or log in.
During this phase of testing, the tester looks at whether virtual private netowrks (VPNs) are being used as well as the security (like two-factor authentication) that is being used on these networks.
During this phase of testing, the tester detects and identifies all of the network protocols, network-level proxies, and application-level proxies in use. The tester also looks at the layout of the entire network with a special focus on high-value or high-profile targets.
In the context of penetration testing, pillaging refers to gathering (usually sensitive) data from targets. Depending on the engagement or the information previously gathered, this pillaged data may include credit card information or personal information.
The entire phase can be summed up by the following paraphrase of the PTES testing guide:
What makes the business money?
Steal it.
Again, the tester draws on the information they gathered in previous phases like the OSINT phase. At this point, the tester should have a firm grasp how the business functions and what "thing" (technology, service, product, etc) is vital to their bottom line. During this phase of testing the goal is simple: steal that thing!
This phase starts the cleanup process in more ways than one. First, the tester performs more testing to get further into the infrastructure if possible. These tests may include botnets, linux commands, or examining history and log files. Then, the tester starts the literal cleanup process. The goal of the penetration tester is to leave no trace of their activities by removing data, cleaning up after themselves, and restoring backups where necessary.
Is the title of this phase self-explanatory? In most engagements, the tester need to draw from their own internal strengths and tenacity to identify, validate, and exploit vulnerabilities. Don't worry, this phase doesn't just instruct the tester to "keep trying!" In this phase of testing, the tester looks at other options like autostart malware, rootkits, backdoors, implants, and more.
These activities are conducted once a system has been exploited or compromised and naturally, the actual activities will vary depending on the specifics of the system that has been exploited.
When dealing with a Windows system, after exploiting it, there are some specifics steps that the tester can take. For example, the tester can pull blind files, perform binary planting, uninstall software, or a carry out host of other actions.
Again, for a Windows system, after it is exploited, there are two general methods to extract the password hashes so that they can be cracked. Option A is to use Local Security Authority Subsystem Service (LSASS) Injection. Option B involves extracting the passwords from the registry.
Community Edition package |
Professional Edition package |
|
|---|---|---|
| Methodology templates | ||
| Project templates | ||
| Sample project | ||
| HTML report template | ||
| Word report template | ||
| Issue, Evidence, and Note templates | ||
| Issue, Evidence, and Note templates | ||
| Download now | Download now |
Detailed versions of these instructions are also available in the instructions.txt file in your Compliance Package.
Filename:
There are four separate methodology files, one for each phase of testing. The tasks for Intelligence Gathering, Vulnerability Analysis, Exploitation, and Post-Exploitation are all listed in order. Check off the completed tasks and track your progress throughout the engagement.
templates/methodologies/ folder of your local install.See the Using Methodologies page of the Working with Projects guide.
Filename:
This full project is ready for you to export and test. The project comes pre-populated with multiple Notes that you can customize with details about your test. The project also 4 Issues (1 Critical, 1 High, 1 Medium, and 1 Low), each with 1(+) instances of Evidence associated with it.
See the Importing and Exporting Projects page of the Working with Projects guide.
(Pro): Use the dradis-full-word-project-export.zip file when working with the Word report template and use the dradis-full-html-project-export.zip file when working with the HTML template.
Filename:
These project templates are intentionally blank so that you can use them to pre-populate your projects with content like Notes or Node structure before adding findings or uploading tool output.
The blank project templates come with Note placeholders and project properties defined but no Issues or Evidence.
The methodology project template contains the Node structure that corresponds with the PTES Methodology templates. If your team is using the PTES methodologies but not the Word report template, this project template can pre-populate your projects with just the content that corresponds to the methodologies.
dradis-blank-project-template-html.xml or methodology-project-template.xml as Dradis::Plugins::Projects::Upload::Template.dradis—blank-project-template-word.xml file when working with the Word report template and use the dradis-blank-project-template-html.xml file when working with the HTML template. The methodology template file does not correspond with any specific report template.See the Project templates page of the Working with Projects guide.
Filename: dradis_html_template-ptes.html.erb
This HTML template will generate a report with the following sections:
Place the HTML report template in the templates/reports/html_export/ folder of your local install.
See the Creating HTML Reports guide for more details.
dradis_html_template-ptes.html.erb template and click Export.See the Report templates page of the Administration manual or the Creating HTML Reports guide for more details.
Filename: dradis_template.ptes.docm
Your custom Dradis Word report template is organized into Executive Summary and Technical Report sections. In the Executive Summary section, document properties populate static text with client-specific details, Notes pull in paragraph content like the Recommendation Summary from Dradis, and tables and graphs offer a high-level overview of the findings. Then, the Technical Report section gives details on each of the four phases of testing, then gives details on each vulnerability in the project which are organized by risk rating.
Upload the Word report template to Dradis using the instructions on the Report Templates page of the Administration guide
Filenames: issue-template.txt, evidence-template.txt, note-template.txt, project_properties-template.txt
Use the templates to configure the Plugin Manager so that you can quickly and easily integrate external tool data (Nessus, Burp, Qualys, etc) to match the format of this report template. Or, add any of the templates to your instance as Note templates to painlessly pre-populate manually-created findings with the correct field names.
Filenames: issue-##.txt, note-##.txt
Use the sample Issues and Notes when building your own projects or project templates so that you can generate a report right away.
Copy/paste the content of these samples into Dradis when building a project or creating an Issue or a Note manually.
Your email is kept private. We don't do the spam thing.