Introduction

The most crucial component of the overall engagement is proper planning and preparation for an impending penetration test.

Pre-engagement, active testing, and reporting are the three parts of a comprehensive penetration testing engagement. The planning, or pre-engagement, a portion of the penetration testing engagement will be the subject of this blog.

Failure to adequately prepare for an engagement in penetration testing may result in, at best, a bad engagement outcome and angry clients, and, at worst, penetration testers being stuck in legally problematic seas, if not prison.

We’ll also go through a few different penetration testing approaches, some of which have been around for a while and have been polished over time, and others of which are newer. These approaches give a foundation for pentesters to arrange their engagements correctly.

Penetration Testing Execution Standard

A group of security experts founded the Penetration Testing Execution Standard (www.pentest-standard.org) in 2009.

Due to a lack of consistency among pentesting practitioners, these security experts decided to address the gap by creating a standard that clients and pentesters could use to aid determine scope and comprehension during pentesting engagements.

PTES is organized into the following seven sections –

• Pre-engagement Interactions This part includes everything that happens before a single packet is transmitted, such as establishing the kind of test, defining scope, assembling a list of points of contact (POCs), and specifying payment conditions, to mention a few. The Pre-engagement section comprises numerous questions related to various kinds of penetration tests, which may be used during client talks to choose which sorts of penetration tests to undertake.
• Intelligence Gathering This section contains a comprehensive list of data that might be obtained about a target organisation during the pentest’s reconnaissance phase.
• Threat Modeling The threat modelling step, in which risks and vulnerabilities are mapped to a particular threat to an organisation, is described in this section. This section goes into further detail about asset threat modelling, which focuses on assessing risks by asset or asset group. This section also includes threat agent, or attacker, threat modelling, as well as adopting the attacker’s perspective and motive. Hacktivism (hacking for a cause), profit, enjoyment (LOLs), and dissatisfaction are all examples of reasons (e.g., employees or ex-employees with a grudge).
• Vulnerability Analysis This section covers the part of the testing process when the pentester starts interacting with the target systems. Open source and private (closed source) software applications may automate a major chunk of this step. nmap and Nessus, for example, are examples of these products. Vulnerability validation, which is simply ruling out false positives in automated scan findings, is a key aspect of this process. If false positives are included in a final report, a client may waste resources fixing vulnerabilities that do not exist, while exploitable weaknesses in the client’s infrastructure may go unnoticed.

• Exploitation The exploitation step of pentesting is what distinguishes a pentest from a vulnerability assessment, as described in this section. Vulnerability assessment focuses on identifying vulnerabilities and potential hazards, while pentesting aims to exploit such flaws and show real-world consequences. In a given environment, several exploitation pathways may exist, and it is the pentester’s task to find as many of them as feasible in the time allocated for testing. These exploitation routes might vary from buffer overflows to web application bugs that enable code execution. The vulnerability analysis phase of testing is crucial to the exploitation step.
• Post-Exploitation Everything that occurs following the first exploitation is detailed in this section. The objective of the post-exploitation phase is to demonstrate what might happen as a consequence of exploitation in the actual world. Pivoting (moving to another system from the first target), data exfiltration, and privilege escalation are examples of post-exploitation operations. The intelligence gathering/reconnaissance phase of testing must also be revisited after exploitation. The reconnaissance, on the other hand, is being carried out from inside the target area. The aim remains the same: acquire knowledge that will help you achieve your ultimate goal.
• Reporting This section addresses the most crucial aspect of a pentesting encounter, according to some. While both pre-engagement and reporting are critical parts of the process, the final report is the most significant product to your customer. Because your customer will refer to it throughout cleanup efforts, it is what will be remembered about you. The report should be polished and professional. That is how you will be remembered if it is hasty and full of grammatical and spelling faults.

Pre-Participation Tasks

All operations that take place before pentesters begin recon, testing, or transmitting a single packet are referred to as pre-engagement.

It’s where the pentesters meet with their customer to discuss what they’ll test, when they’ll test it, how they’ll test it, and what they’ll give to them.

It’s here that the ground rules are put out and agreed upon. During this phase of testing, it is critical to ensure that excellent communication channels are formed; here is when pentesters should build a rapport with customers, since communication lines must stay open throughout the testing.

Keep in mind that behaving ethically is essential not just during “hacking” operations during the engagement period, but also during pre-engagement interactions with the customer.

Testing Phases

As a pentester, when meeting with a client prior to engagement, you can structure your discussion of the testing phases based on one or more of the pentesting methodologies.

Each of the frameworks outlined in the first half of this chapter has a unique way of identifying the different phases of a penetration test.

Remember, though, that pre-engagement and reporting frame your overall test, and testing, or engagement, makes up everything in the frame.

	PTES	OWASP WSTG	ATT&CK	Penetration Testing Framework	NIST SP 800-115
Pre-engagement	Pre-engagement	N/A	N/A	Pre-Inspection Visit	Planning
	Intelligence Gathering
	Threat Modelling	Information Gathering and all testing objectives fall in the Engagement phase.	All ATT&CK tactics fall in the Engagement phase.	All tech and tools fall in the Engagement phase.	Discovery
Active Testing / Engagement	Vulnerability Analysis
	Exploitation				Attack
	Post-exploitation
Reporting	Reporting	Reporting	N/A	Final Report	Reporting

Rules of Engagement

The rules of engagement (RoE) govern how a pentester may interact with a client’s systems, services, and applications.

If the scope of the pentest includes social engineering, the RoE will also specify how the pentester is permitted to engage with client workers.

The RoE also specify the amount of time a pentester is permitted to test. Some customers may want after-hours or weekend pentesting to ensure that their everyday operations or services are not disrupted.

Some customers may want live-load testing (testing during normal business hours) to examine how an incident response team reacts to real-world threats or how systems respond to higher-than-normal traffic and service demands.

Pentesters and customers should agree on timetables and daily activity plans at pre-engagement meetings when establishing the RoE.

This provides the start and end dates and timings for pentesting. While these dates and times should be agreed upon, both the pentester and the customer should be aware that pentesting does not always fit neatly into a “banker’s hours” package.

During testing, things change often, sometimes many times each day. So that there are no surprises, pentesters should inform clients about this up front.

Business timetables are not always predictable, thus pentesters must be mindful of this. Testing may have to be postponed or temporarily halted due to new business mission requirements.

While this is not an ideal situation, it is one that all parties should be aware of. Modifications to the timetable should be recorded in the RoE, as well as the permissions necessary.

Status meetings are a fantastic method to make sure that all parties are on the same page and are up to date on any new information.

These sessions should not be comprehensive debriefings, and no presentations or reports should be required.

Instead, these should be casual gatherings that do not necessitate the attendance of all pentesters and client representatives; only important stakeholders from each team should be present to enable effective information flow.

A status meeting may also be a suitable moment to disclose any discoveries that need quick action, depending on the nature of the vulnerabilities discovered or exploited.

The target company may also report on whether or not pentesting has taken place. It’s important to keep in mind that security is a cat-and-mouse game.

It may be time to step up your game if the target company can tie the finding of certain actions to all of your TTPs as an attacker.

Defenders may test their security controls and alerting systems by talking about what they’ve tried and what they’re planning to do.

Scope of penetration testing

While the scope describes what will be tested, the RoE determines how and when it will be done. The scope of an engagement is determined by the type(s) of testing methods used and is agreed upon by both parties prior to the start of the engagement.

It is the pentester’s responsibility to assist customers in selecting the appropriate scope, which may involve restricting or increasing a scope requested by the client.

Depending on the scope’s complexity, it may be recorded as part of the RoE or as a distinct document that goes with the rest of the pre-engagement paperwork.

Both clients and testers will benefit from two crucial components that will help them concentrate on the right scope: the kind of test and the client’s areas of concern.

Types of Penetration Tests

Pentests of many forms may be performed to assess a client’s security posture.

For each particular engagement, you may be required to run any or all of these pentests, so familiarising yourself with the different sorts of pentests before pre-engagement and kick-off meetings is critical to ensure you’re asking your client the proper questions.

As noted earlier in the chapter, the Penetration Testing Execution Standard includes a number of pre-engagement questions that correlate to the different sorts of pentests you could be requested to do and can help you properly scope your engagement.

Because each engagement is different, you may be requested to complete any or all of the tests listed below, for which PTES questionnaires are accessible at www.pentest-standard.org/index.php/Pre-engagement#Questionnaires:

• Network penetration test
• Web application penetration test
• Client-side penetration test
• Wireless penetration test
• War-dialing penetration test
• Cryptanalysis test
• Stolen equipment test
• Product security test
• Physical penetration test
• Social-engineering test

Network Penetration Test A network penetration test is used to identify vulnerabilities or other misconfigurations in an organization’s network.

This sort of evaluation isn’t confined to networking equipment like routers and switches, however. Rather, the “network” notion comes from the test’s starting point.

If doing an internal pentest, pentesters may be given an IP address or a network drop; if conducting an external pentest, pentesters may be given an IP address range or domain name(s).

Web Application Penetration Test A web application penetration test focuses on online apps that can be accessed with a typical web browser.

This test might be performed alone or as an add-on service to a network pentest. Pentesters should be cautious when scoping web application pentests, since a variety of factors might exponentially extend the scope of the test.

Client-Side Penetration Test Penetration testing on the client side is often combined with social engineering testing.

Pentesters may be required to utilise phishing tactics to persuade users to click links that compromise software on their client devices, such as web browsers like Microsoft Edge and other widely used business products like Microsoft Office and Adobe Acrobat.

Wireless Penetration Test A wireless penetration test evaluates an organization’s wireless infrastructure’s security posture.

The amount of wireless networks, network segregation (i.e., employee network vs. guest network), rogue access point (AP) detection, and wireless man-in-the-middle (MiTM) attacks are all areas of concern when it comes to testing wireless networks.

War-Dialing Penetration Test War-dialing is a word that originated before the widespread usage of mobile phones and refers to the testing of phone systems that an organisation may utilise.

With the widespread use of Voice over IP (VoIP), war-dialing (also known as remote dial-up testing) has shifted from a POTS-centric method to a more network- and protocol-centric approach to testing.

However, don’t be astonished if you come across an enterprise that still employs modems and fax machines on your travels.

In general, obsolete technology represents a big attack surface, particularly in organisations that must be economically cautious, such as the public sector.

Cryptanalysis Test Cryptanalysis is the mathematical study and analysis of encryption and other codes with the goal of defeating or bypassing ciphertext.

The goal of a penetration test that includes cryptanalysis is to attempt to circumvent or break encryption techniques that protect data in transit or at rest.

This may be done by searching for flaws in the math underlying a particular encryption technique, or it could be done by looking for flaws in the tools’ implementation.

Stolen Equipment Test When a customer requests a stolen equipment test, you are simply being requested to run pentesting on a piece of equipment as if you had stolen it from the target company, with the goal of obtaining sensitive information that may be used to damage the target.

You are not being asked to steal the equipment physically, as you could be asked to do in a physical penetration test.

Product Security Test A product security test, often known as a shrink-wrap test, is performed on a piece of software or hardware as if the pentester were buying it off the shelf.

It’s made to identify faults in software, such as buffer overflows, or to assess a piece of hardware’s “physical” security.

The ability to readily connect a debugger to inspect sensitive information or the boot process are examples of specific hardware faults.

Physical Penetration Test A physical penetration test is used to evaluate the target organization’s physical security systems. Attempting to circumvent RFID badge readers by cloning badges, attempting to defeat automated door sensors, or lock picking are examples of this.

Dumpster diving or equipment theft may also be used by pentesters to obtain access to sensitive information.

Physical pentesting has its own set of risks that aren’t present in other types of pentesting. A pentester assessing the security of a government facility, for example, may come into touch with armed security personnel.

Physical damage to a tester doing a physical pentest is a very real possibility. As a result, adequate scoping, documenting of the scope of work, and the preparedness of emergency contacts are all critical.

Social-Engineering Test The art of social engineering is to persuade someone to provide sensitive information that they would not typically disclose or to perform something they would not normally do.

Social engineering competitions are held at security conferences, and it’s amazing to watch someone skilled at social engineering extract little bits of knowledge about a target to construct a whole image of a network.

Different Methods of Penetration Testing

Black-box, white-box, and gray-box testing are the three main types of pentesting, each dealing with the amount of information disclosed to the pentester prior to the engagement phase.

Each has a distinct goal and requires various amounts of investigation on the part of the pentester. Each method has a distinct price tag attached to it.

Clearly, the technique of testing that requires the greatest effort from the pentester is also the most expensive. Keep in mind that each client’s general goals and objectives for the pentest will be different as we explore each technique of testing.

This will help you and your client decide which approach is ideal for their unique engagement.

Black-Box Testing Black-box testing presume that the pentester has no previous or insider knowledge of the company before they begin an engagement.

This sort of interaction requires a large amount of time spent by the pentester in the reconnaissance phase of testing, obtaining information known as OSINT (open source intelligence).

This form of testing is often more expensive, since it requires a significant amount of effort and study on the side of the tester.

Domain names, subdomains, job postings, physical location(s), public IP addresses, corporate leadership profiles, and Human Resources (HR) or other employee contact information are just some of the types of information the tester may need to look for.

An outsider with limitless time and resources who is motivated to get into an organisation is one target threat model for a black-box test.

White-Box Testing The client organisation that the pentester is evaluating provides a vast quantity of information to a pentester who is doing a white-box test.

This is intended to make the testing process easier and less expensive. This form of test also has the additional advantage of ensuring that both the tester and the client adhere to the testing scope that has been agreed upon.

The client would offer some or all of the information stated in earlier sections (e.g., OSINT) that a tester would need to study, and if testing a web application, the tester would be given source code.

An insider with access to a big quantity of confidential information would be an example of a threat model for this sort of test.

Gray-Box Testing Gray-box testing aims to create a middle ground between white-box and black-box testing. The client may supply some information to the pentester, but it may not contain all essential documents.

A customer may give the tester with a domain name and application URLs, but not application source code, IP addresses, or other network architectural details.

The purpose of gray-box testing is to lower the cost of reconnaissance. Essentially, a client may prefer to furnish the tester with whatever information they reasonably anticipate the tester may unearth if given infinite time and resources.

This lowers the test’s total cost and duration while enabling the tester to focus on other areas of the test, such as exploitation.

Red teaming The natural next step after a vulnerability assessment is a penetration test. It validates and assesses a target’s vulnerabilities and threats in order to show the real-world consequences of a hostile user abusing certain attack vectors.

These tests may be run on any size or maturity level of organisation, and they’re meant to find as many exploitable vulnerabilities as possible in the time provided.

Pentests are often restricted in scope (for example, a subset of web applications on a particular subnet), although they might comprise many types of tests (e.g., wireless and network).

A red team engagement is a focused evaluation aimed to analyse the efficacy of the organization’s defences (or blue team) as well as how effectively the organisation reacts to an advanced adversary’s assault.

A major business firm that depends significantly on Windows and has a mature, effective security programme is frequently the focus for these sorts of audits. In most cases, the scope of these examinations is rather unrestricted.

Keeping the prior definitions in mind, there are no hard-and-fast rules stating that a penetration test must only utilise pentest TTPs or that a red team should not undertake a vulnerability assessment.

As a pentester, your goal is to leave the target organisation in a better shape than when you arrived. You must draw from other fields if this is to be accomplished.

Documentation for Other Pre-Engagement Situations

Paperwork is unavoidable, and both parties will create a lot of it during pre-engagement activities. All of it, however, is intended to safeguard the client, the pentesters, and any data created as a consequence of the pentesting.

It is critical to properly organise and safeguard any documents.

How can you expect your customers to follow a disaster recovery or business continuity plan if you as a security professional don’t?

The statement of work (SoW), nondisclosure agreement (NDA), and legal documents meant to protect you and your client should anything unforeseen arise during testing will also be created as part of pre-engagement efforts.

Permission from correct person

The most important output from the pre-engagement activities will be a document giving the pentesters permission to undertake the agreed-upon actions within the agreed-upon scope.

This should be a signed, tangible document that testers have with them at all times throughout the engagement, particularly if physical penetration testing is part of the scope.

When getting this form signed, double-check that the person or organisation giving you authorisation is the right one.

You might get into legal difficulties if you get authorisation from the wrong organisation. This document should include a list of all testers and points of contact that can assist in resolving any problems that may develop as a result of your testing.

Statement of Work

Though it may relate to the RoE and scoping documents, the statement of work (SoW) is a different document.

The SoW also assists in the definition of additional contract conditions, such as the project’s goal, payment methods, particular tasks, and deliverables.

It may also contain contract-specific information, such as the contract type (e.g., performance-based or cost plus fee). Consider the statement of work to be the back-end business component that drives and connects the technology jigsaw parts.

The SoW is typically more important to project managers than it is to testers. Testers, on the other hand, should have a fundamental awareness of the SoW’s unique deliverables and requirements.

They risk being in violation of contract if they miss a major delivery or deadline, which might result in them not being paid.

Nondisclosure Agreement

It is unavoidable that as a penetration tester, you may come across information that is confidential to your customer.

You will create testing data that your customer will most likely not want shared with anybody else, in addition to corporate secrets.

Usernames and passwords are often included in these results. All of this data, whether gathered via testing or “stumbled upon” during an encounter, should be properly safeguarded.

An NDA is part of that protection, and it basically says that as a tester, you will not reveal any sensitive information with anybody who isn’t permitted to have it.

In most cases, the NDA is for the client’s protection. An NDA will be required for very little, if any, information provided by the tester to the customer.

You want as much information as possible to assist your clients safeguard their settings. If you opt to differ from one of the open source formats, the only thing you may want to preserve as a tester is your report format. If you want to utilise any information in future testing, you must explicitly express this in both the RoE and the NDA.