General penetration testing phases

A successful attempt takes place in phases in order to understand or replicate the same need to understand the core competent phases of penetration testing.

The process can be broken down as follows:

1. Gathering requirements
2. Preparing and planning (phases, objectives, approvals)
3. Assessing/detecting the devices and their vulnerabilities
4. Actual attack
5. Categorization/reporting of vulnerabilities
6. Threat management/asset risk rating
7. Reporting

Let's understand these processes in brief.

Gathering requirements

In this phase, we as much information as we can about our targets, such as identifying the IP address and the port details. Once this is done, more information can be gathered about the type of OS flavor it is running and the services running on the ports along with their versions. Also, mapping can be done for the firewall rules or network restrictions levied on the architecture.

As an attacker, we do the following:

• Ensure that all the IP addresses detected are identified in terms of OS and device type
• Identify the open ports
• Identify the services running on those ports
• Version details of those services, if possible
• E-mail ID disclosure, mail gateway disclosure, and more
• Mapping down the entire LAN/WAN network of the scope

Preparing and planning

A very phase of the entire activity is planning and preparing; minute deviations from this can be catastrophic. In order to understand the purpose of this, one needs to understand that penetration testing is an activity that consumes a lot of bandwidth of an underlying infrastructure. No organization would want to have their networks stalled in the middle of core business hours or peak activity of their business. Other factors could include excessive traffic causing network congestion and crashing. There are many other critical factors that need to be addressed before starting with the activity. A kickoff meeting should be called with the stakeholders and clear boundaries of testing should be determined as to where and in which areas the testing is to be done. Once that is concluded, it is feasible to draw the effective time to perform the activity so as to ensure that the network is not affected and business is not impacted. One should also consider the time taken to perform this activity; it is necessary to define a timeline because this impacts the financials and the availability of testers. Shortlisting the devices to be tested and audited should also be documented.

Discussing when to run the penetration tests for various shortlisted devices should be concluded in the meeting. Mapping down the servers to the non-critical ones and deciding their timeliness for performing tests so that business is not affected has to also be mutually agreed upon. A call should be taken by the organization as to whether they want to inform their team of an ongoing penetration test; doing so will ensure that the business is not impacted, however, the proactiveness of detecting an incident will go out of scope. Not informing the team about an ongoing penetration test can have its own perks and pitfalls; one being that if the network team detects an attack, it will follow the procedure and have a total lockdown of the network that could cause business loss and slow down the business functions leading to partial chaos.

If the organization plans to outsource the penetration activity, agreements should be signed that stipulate that all the information gained during the scope of tests and the confidential documents should not go outside the network, that the third party will abide by the confidentiality agreement of a non-disclosure, and that all the information retrieved and vulnerabilities identified will be kept within the organization.

Defining scope

Once the whole preparation and for the activity is done, the penetration tester can begin the entire activity described in the book. This book covers all parts of the process right from information gathering, vulnerability assessment, penetration testing, deep digging, and more. Once the vulnerabilities are discovered, a penetration testing plan should be put into motion.

Conducting a penetration test

Here, a penetration tester has to which systems are to be tested upon, like, say, for generalization, that there are n numbers of systems and m numbers of systems are desktops. Then, the testing should be focused on the n-m systems, for example, the servers. Here the tester can gain knowledge of what kind of devices they are and then the exploitation can begin. The exploitation should be a timed activity as the chances of the application or the device crashing might increase and the business can be impacted if the exploitation fails. A timeline should be drawn up as to how much time should be permitted to perform the entire testing activity once the count of vulnerabilities is identified.

Various tools can be used, as we have seen in this chapter. Kali provides an extensive resource of all the tools necessary to perform an activity successfully. One can also clarify with the organization whether social engineering is an agreeable aspect of the penetration testing; if yes, such methods can also be included here and put into execution.

Categorization of vulnerabilities

Mapping of all the and failed exploits should be done here, and they should be categorized as per critical, high, medium, and low ratings. This conclusion can be done with assistance to criticality of the affected device and the CVSS rating or the risk rating of the vulnerability. The risk is calculated taking into consideration many factors: Risk = Likelihood * Impact.

Asset risk rating

There are various that are taken into consideration for the following:

• Factors for estimating likelihood
• Factors for estimating risk

Here is a diagram from OWASP that helps understand the factors in estimating the likelihood:

And to understand the estimation of IMPACT of the vulnerability we refer to the following chart:

Reporting

This is the critical part the management to view, the entire hard work put in to penetration testing of the network is shown in the reporting. Reporting has to be done very carefully, should give all the details of the activity performed, and the report should cover and be understood by all levels: the development level, the management level, and the higher management level.

The report should cover the analysis done, and the vulnerabilities need to be shown as per the risk rating. It is always a best practice to report the vulnerabilities as per the risk rating with the critical at the top and the lowest at the bottom. This helps management get a better picture of the vulnerabilities and action can be taken as per the vulnerabilities' risk rating.

The contents of the report should include the following things:

• An index covering the entire gist of the report
• A list of top vulnerabilities that require attention
• A summary of all the findings
• Scope, as defined by the organization
• Any limitations or hindrances found during the audit phase
• Detailed lists of all the vulnerabilities
• A description of the vulnerabilities with their evidences
• Recommendations for fixing the vulnerabilities
• Alternatives for fixing the vulnerabilities
• Glossary