PTES Technical Guidelines

Penetration Testing Execution Standard (PTES) Compliance Package

"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.

Learn more about PTES

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.

Intelligence Gathering

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.

Internet Footprint

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!

Covert gathering

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.

External Footprinting

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.

Internal Footprinting

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.

Vulnerability Analysis

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").

Vulnerability Testing

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.

Vulnerability Validation

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.

Attack Avenues

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.

Precision strike

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.

Customized Exploitation

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.

RF Access

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.

Attacking the User

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.

VPN detection

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.

Route detection, including static routes

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.

Business impact attacks

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!

Further penetration into infrastructure

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.

Post Exploitation

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.

Windows Post Exploitation

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.

Obtaining Password Hashes in Windows

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.

The above is a condensed overview of the PTES Technical Guidelines, visit the PTES website for more details.

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.

Methodology templates


  • ptes_intelligence-gathering.xml
  • ptes_vulnerability-analysis.xml
  • ptes_exploitation.xml
  • ptes_post-exploitation.xml

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.


Dradis CE
Place the Methodology templates in the templates/methodologies/ folder of your local install.
Dradis Pro

See the Using Methodologies page of the Working with Projects guide.

Full Project Export


  • (Pro)

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 file when working with the Word report template and use the file when working with the HTML template.

Blank Project Templates


  • dradis-blank-project-template-html.xml
  • methodology-project-template.xml
  • (Pro) dradis—blank-project-template-word.xml

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 CE
  1. In the header, click Upload output from tool
  2. Upload dradis-blank-project-template-html.xml or methodology-project-template.xml as Dradis::Plugins::Projects::Upload::Template.
  3. Add Issues and Evidence!
Dradis Pro
  1. If you are using a blank project template, decide whether you are going to be exporting a Word report or a HTML report. Use the 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.
  2. Create a new (blank) project.
  3. In the header, click Upload output from tool and upload the blank project XML file as Dradis::Plugins::Projects::Upload::Template.
  4. Add Issues and Evidence! Don't forget to use the Issue and Evidence templates to ensure that your project is ready to export into your report.

See the Project templates page of the Working with Projects guide.

HTML Template

Filename: dradis_html_template-ptes.html.erb

This HTML template will generate a report with the following sections:

  • Introduction: general overview of the testing and the technical scope of the test.
  • Intelligence Gathering: including details on passive intelligence, active intelligence, corporate intelligence, and personnel intelligence.
  • Vulnerability Assessment: details on the vulnerabilities discovered during testing including a description of the vulnerability and supporting evidence.
  • Exploitation/Vulnerability Confirmation: full attack details including targets, attacks, success/fail ratio, level of access granted, and remediation details.
  • Post Exploitation: details on the business risk and countermeasures for each vulnerability.
  • Risk/Exposure: details on the likelihood, impact, and risk associated with each vulnerability.


Dradis CE

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 Pro
  • Sign in as an Administrator and navigate to Templates > Reports in the header.
  • Navigate to the HTML tab and upload the report template.
  • From the Projects page, open the PTES project you created using the blank project template or full project export.
  • Click Export Project in the header and open the HTML export tab
  • Select the 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.

(Pro) Word Report Template

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.


Dradis Pro

Upload the Word report template to Dradis using the instructions on the Report Templates page of the Administration guide

(Pro) Issue, Evidence, Note, and Project Properties Templates

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.


Dradis Pro
Upload the templates to Dradis as Note templates using the instructions on the Note Templates page of the Administration guide.

(Pro) Sample Issues and Notes

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.


Dradis Pro

Copy/paste the content of these samples into Dradis when building a project or creating an Issue or a Note manually.

Streamline InfoSec Project Delivery

Learn practical tips to reduce the overhead that drags down security assessment delivery with this 5-day course. These proven, innovative, and straightforward techniques will optimize all areas of your next engagement including:

  • Scoping
  • Scheduling
  • Project Planning
  • Delivery
  • Intra-team Collaboration
  • Reporting and much more...

Your email is kept private. We don't do the spam thing.