Organizing a penetration test

When we think about conducting a penetration test on an organization, we need to make sure that everything works according to the penetration test standards. Therefore, if you feel you are new to penetration testing standards or uncomfortable with the term Penetration Testing Execution Standard (PTES), please refer to http://www.pentest-standard.org/index.php/PTES_Technical_Guidelines to become more familiar with penetration testing and vulnerability assessments.

In line with to PTES, the following diagram explains the various phases of a penetration test:

Figure 1.2 – Phases of a penetration test

Important Note

Refer to http://www.pentest-standard.org/index.php/Main to set up the hardware and systematic stages to be followed when setting up a work environment.

Before we start firing sophisticated and complex attacks with Metasploit, let's understand the various phases of a penetration test and learn how to organize a penetration test at a professional scale.

Preinteractions

The very first phase of a penetration test, preinteractions, involves a discussion of the critical factors regarding the conduct of a penetration test on a client's organization, company, institute, or network of the client themselves. This phase serves as the connecting line between the penetration tester, the client, and their requirements. Preinteractions help a client get better knowledge of what is to be performed over their network, domain, or server.

Therefore, the tester will serve here as an educator to the client. The penetration tester also discusses the scope of the test, gathers knowledge on all the domains under the scope of the project, and gathers any special requirements that will be needed while conducting the analysis. These requirements include special privileges, access to critical systems, network or system credentials, and much more. The expected positives of the project should also be part of the discussion with the client in this phase. As a process, preinteractions involve discussions of the following key points:

• Scope: Scoping estimates the size of the project. The scope also defines what to include for testing and what to exclude from the test. The tester also discusses IP ranges, applications, and domains under the scope, 1 and the type of test (black box or white box) to be performed. In the case of a white box test, the tester discusses the kind of access and the required set of credentials with varying access levels; the tester also creates, gathers, and maintains questionnaires regarding the assessment. The schedule and duration of the test and whether to include stress testing or not are included in the scope. A general scope document provides answers to the following questions:

  --What are the target organization's most significant security concerns?

  --What specific hosts, network address ranges, or applications should be tested?

  --What specific hosts, network address ranges, or applications should explicitly not be tested?

  --Are there any third parties that own systems or networks that are in the scope, and which systems do they hold (written permission must be obtained in advance by the target organization)?

  --Will the test be performed in a live production environment or a test environment?

  --Will the penetration test include the following testing techniques: ping sweep of network ranges, a port scan of target hosts, a vulnerability scan of targets, penetration of targets, application-level manipulation, client-side Java/ActiveX reverse engineering, physical penetration attempts, or social engineering?

  --Will the penetration test include internal network testing? If so, how will access be obtained?

  --Are client/end user systems included in the scope? If so, how many clients will be leveraged?

  --Is social engineering allowed? If so, how may it be used?

  --Are Denial-of-Service (DoS) attacks allowed?

  --Are dangerous checks/exploits allowed?

• Goals: This section involves the discussion of various primary and secondary objectives that a penetration test is set to achieve. The common questions related to the goals are as follows:

  --What is the business requirement for this penetration test?

  --Is the test required by a regulatory audit or just a standard procedure?

  --What are the objectives?

  Map out the vulnerabilities.

  Demonstrate that the vulnerabilities exist and test the incident response.

  Actual exploitation of a vulnerability in a network, system, or application.

  All of the above.

• Testing terms and definitions: This phase involves the discussion of basic terminologies with the client and helps the client understand the terms.
• Rules of engagement: This section defines the time of testing, timeline, permissions to attack, and regular meetings or updates on the status of the ongoing test. The common questions related to rules of engagement are as follows:

  --At what time do you want these tests to be performed?

  During business hours

  After business hours

  Weekend hours

  During a system maintenance window

  --Will this testing be done in a production environment?

  --If production environments should not be affected, does a similar environment (development or test systems) exist that could be used to conduct the penetration test?

  --Who is the technical point of contact?

  Important Note

  For more information on preinteractions, refer to http://www.pentest-standard.org/index.php/File:Pre-engagement.png.

Intelligence gathering/reconnaissance phase

In the intelligence gathering stage, you need to gather as much information as possible about the target network. The target network could be a website, an organization, or maybe a full-fledged Fortune 500 company. The most important aspect is to gather information about the target from social media networks and use Google hacking (a way to extract sensitive information from Google using specific queries) to find confidential and sensitive information related to the organization to be tested. Footprinting the organization using active and passive attacks can also be an approach you can use.

The intelligence-gathering phase is one of the most crucial aspects of penetration testing. Correctly gained knowledge about the target will help the tester simulate appropriate and exact attacks, rather than trying all possible attack mechanisms. It will also help the tester save a considerable amount of time. This phase will consume 40 to 60 percent of the total time of testing, as gaining access to the target depends mainly upon how well the system is footprinted.

A penetration tester must gain adequate knowledge about the target by conducting a variety of scans, looking for open ports, performing service identification, and choosing which services might be vulnerable and how to make use of them to enter the desired system.

The procedures followed during this phase are required to identify the security policies and mechanisms that are currently deployed on the target infrastructure, and to what extent they can be circumvented.

Let's discuss this using an example. Let's consider that we're performing a black box test against a web server where the client wants to perform a network stress test.

Here, we will be testing a server to check what level of bandwidth and resource stress the server can bear or in simple terms, how the server is responding to the DoS attack. A DoS attack or a stress test is the name given to the procedure of sending an indefinite number of requests or data to a server to check whether the server can handle and respond to all the requests successfully, or whether it crashes. A DoS can also occur if the target service is vulnerable to specially crafted requests or packets. To achieve this, we start our network stress testing tool and launch an attack toward a target server. However, after a few seconds of launching the attack, we see that the server is not responding. Additionally, the primary web page shows up, stating that the website is currently offline. So, what does this mean? Did we successfully take out the web server we wanted? Nope! In reality, it is a sign of a protection mechanism set by the server administrator that sensed our malicious intent of taking the server down and resulted in our IP address being banned. Therefore, we must collect the correct information and identify various security services at the target, before launching an attack.

A better approach is to test the web server from a different IP range. Maybe keeping two to three different virtual private servers for testing is the right approach. Also, I advise you to test all the attack vectors under a virtual environment before launching these attack vectors onto the real targets. Proper validation of the attack vectors is mandatory because if we do not validate the attack vectors before the attack, it may crash the service at the target, which is not favorable at all. Network stress tests should be performed toward the end of the engagement or in a maintenance window. Additionally, it is always helpful to ask the client for whitelisting IP addresses, which are used for testing.

Now, let's look at the second example. Let's imagine that we're performing a black box test against a Windows Server 2012 machine. While scanning the target server, we find that port 80 and port 8080 are open. On port 80, we see the latest version of Internet Information Services (IIS) running, while on port 8080, we discover that a vulnerable version of the Rejetto HFS Server is running, which is prone to a remote code execution flaw.

However, when we try to exploit this vulnerable version of HFS, the exploit fails. This situation is a typical scenario where the firewall blocks malicious inbound traffic.

In this case, we can simply change our approach to connecting back from the server, which will establish a connection from the target back to our system, rather than us connecting to the server directly. This change may prove to be more successful as firewalls are commonly configured to inspect ingress traffic rather than egress traffic.

As a process, this phase can be broken down into the following key points:

• Target selection: This consists of selecting the targets to attack and identifying the goals and the time of the attack.
• Covert gathering: This involves collecting data from the physical site, the equipment in use, and dumpster diving. This phase is a part of on-location white box testing only.
• Footprinting: Footprinting consists of active or passive scans to identify various technologies and software deployed on the target, which includes port scanning, banner grabbing, and so on.
• Identifying protection mechanisms: This involves identifying firewalls, filtering systems, network- and host-based protection, and so on.

  Important Note

  For more information on gathering intelligence, refer to http://www.pentest-standard.org/index.php/Intelligence_Gathering.

Threat modeling

Threat modeling helps in conducting a comprehensive penetration test. This phase focuses on modeling out actual threats, their effect, and their categorization based on the impact they can cause. Based on the analysis made during the intelligence gathering phase, we can model the best possible attack vectors. Threat modeling applies to business asset analysis, process analysis, threat analysis, and threat capability analysis. This phase answers the following set of questions:

• How can we attack a particular network?
• Which critical sections do we need to gain access to? Which approach is best suited for the attack?
• What are the highest-rated threats?

Modeling threats will help a penetration tester perform the following set of operations:

• Gather relevant documentation about high-level threats.
• Identify an organization's assets on a categorical basis.
• Identify and categorize risks.
• Mapping threats to the assets of a corporation.
• Modeling threats. This will help to define the highest priority assets with risks that can influence these assets.

Let's imagine that we're performing a black box test against a company's website. Here, information about the company's clients is the primary asset. It is also possible that, in a different database on the same backend, transaction records are also stored. In this case, an attacker can use an SQL injection to step over to the transaction records database. Hence, transaction records are a secondary asset. Now that we know about the impacts, we can map the risk of the SQL injection attack on the assets.

Vulnerability scanners such as Nexpose and the Pro version of Metasploit can help model threats precisely and quickly by using the automated approach. Hence, it can prove to be handy while conducting extensive tests.

Important Note

For more information on the processes involved during the threat modeling phase, refer to http://www.pentest-standard.org/index.php/Threat_Modeling

Vulnerability analysis

Vulnerability analysis is the process of discovering flaws in a system or an application. These flaws can vary from a server to web applications, from insecure application design to vulnerable database services, and from a VOIP-based server to SCADA-based services. This phase contains three different mechanisms, which are testing, validation, and research. Testing consists of active and passive tests. Validation consists of dropping the false positives and confirming the existence of vulnerabilities through manual validation. Research refers to verifying that a vulnerability has been found and triggering it to prove its presence.

For more information on the processes involved during the threat modeling phase, refer to http://www.pentest-standard.org/index.php/Vulnerability_Analysis.

Exploitation and post-exploitation

The exploitation phase involves taking advantage of the previously discovered vulnerabilities. This stage is the actual attack phase. In this phase, a penetration tester fires up exploits at the target vulnerabilities of a system to gain access. This phase will be covered heavily throughout this book.

The post-exploitation phase is the latter phase of exploitation. This stage covers various tasks that we can perform on an exploited system, such as elevating privileges, uploading/downloading files, pivoting, and so on.

Important Note

For more information on the processes involved during the exploitation phase, refer to http://www.pentest-standard.org/index.php/Exploitation.

For more information on post-exploitation, refer to http://www.pentest-standard.org/index.php/Post_Exploitation.

Reporting

Creating a formal report of the entire penetration test is the last phase to conduct while carrying out a penetration test. Identifying critical vulnerabilities, creating charts and graphs, and providing recommendations and proposed fixes are a vital part of the penetration test report. An entire section dedicated to reporting will be covered in the latter half of this book.

Important Note

For more information on the processes involved during the threat modeling phase, refer to http://www.pentest-standard.org/index.php/Reporting.