Organisations that contract specialist penetration testing services need not necessarily be concerned about which tools and techniques may be used to test their systems, as they are mainly interested in the test results. However, some knowledge of the tools and techniques used in penetration testing will assist managers in developing an awareness of threats and vulnerabilities, and will help them define an appropriate scope for the tests.

CONTEXT

There are organisations that publish guidelines on penetration test programmes. CREST, a not-for-profit organisation that offers assurance of processes and procedures for the technical information security industry, suggests a nine-step testing phase (CREST, 2017), while the Penetration Testing Execution Standard (PTES, 2017) defines seven main sections, and SANS defines five or six, dependent on whether ‘Cleaning Up’ should be included (Wai, 2002). The agreed scope of a penetration test will determine which stages are appropriate.

The type of penetration test undertaken should determine the amount of planning, co-ordination and communication between the testers and the client. In some cases, the client will have no knowledge of where, when or how the testers will operate, and no co-ordination is required. In other cases, activities will be restricted to a specific time and location, with a limited scope. Where penetration tests are conducted during normal business operations, specific activities may need to be excluded. Some tests may disrupt production services: for example large amounts of traffic from penetration probing on a network which is already saturated with organisational traffic could lead to a degradation of the network performance. Some systems are vulnerable to attacks which can cause them to fail. Penetration testing at critical or busy times for organisations should be avoided, unless this is the specific focus of the test.

In some cases, a genuine attack may take place at the time a penetration test is under way. If the penetration tester discovers this, they should immediately notify the organisational incident response team.

If the penetration testing uncovers evidence of prior penetration, such as backdoor accounts or ports open, then this information should also be passed to the appropriate team. Once a penetration test is under way, there should be a clear authority with the right to stop or change the test. This will avoid the situation where IT staff may attempt to influence the activities of a tester in order to avoid the exposure of vulnerabilities for which they will be held responsible. However, there may be genuine reasons to modify a test once under way, and the decision-making process should be clear before testing begins.

When selecting and agreeing tools for a penetration test, care should be taken over the integrity of all tools used. Whether downloaded from public internet sites or directly obtained from suppliers, tools must verified as identical to the originals as published by the creator, otherwise it is possible that the tools themselves could contain malicious code which deliberately introduces vulnerabilities for later exploitation. Storms (2006) suggests a number of ways of doing this including cryptographic hashes and digital signatures. Assuring the integrity and authenticity of penetration testing tools is particularly important as penetration testers are often given access to privileged or secure areas of a system.

Furthermore, some penetration testing techniques could involve the deliberate uploading of components to live servers, or modification of settings to enable particular exploits. Such procedures must be approved in advance, and any modifications made must be undone after the testing.

ASSESSING THE MOST APPROPRIATE PENETRATION TESTING TOOLS AND TECHNIQUES FOR THE PROGRAMME

Penetration test service providers will often have a specific suite of tools which their penetration testers are required to use.

However, some organisations may choose to conduct in-house tests and they will have a range of tools from which to choose. A combination of different tools can be used where each tool is specialised in operating in one or more of the penetration testing phases, for example, those defined by Chiem and Yan (2014): reconnaissance; enumeration; exploitation.

Some penetration test tools are free or open-source, and some proprietary. Proprietary tools may come in several versions, with free trial versions limited in some way such as update availability, number of targets to scan or operational time. While free or open-source tools may avoid initial purchase costs, they sometimes require a higher level of expertise to use or maintain.

Penetration test tools may also be available as frameworks rather than specific tools. These frameworks allow different combinations of exploits, payloads, delivery vectors and encoding mechanisms to be used to assemble a specialised attack tool. Such frameworks allow modules or add-ons to be written and incorporated as new vulnerabilities are discovered (Faircloth, 2016).

Penetration testers may also choose to build a complete operating system environment with all the tools installed and available to use. Such a system may be installed directly on hardware, but is more often deployed as a virtual machine (VM) on a laptop computer. Having a separate penetration testing VM on a laptop will allow a penetration tester to take their complete suite of testing tools into the testing environment, while still allowing their device to be used for normal computing requirements at other times.

The most widely used penetration testing environment is the Kali Linux distribution (Allen et al., 2014), which is preconfigured with a wide variety of penetration testing tools.

Reconnaissance tools

If the penetration test is of the black-box type, where little or no information is given to the tester about the internal structure of the network and target systems, then several open-source intelligence (OSINT) tools may be helpful before the actual penetration test begins. These tools will range from straightforward search engines to comprehensive applications that investigate DNS and IP records, social media and blogs. The goal of this early investigation is to find out as much as possible about an organisation, its structure, buildings, staff, systems and networks to determine which attacks are most likely to succeed.

If the penetration test is of the white-box type, where the internal structure of the network and systems, or even the hosts and applications are known to the tester, then such tools are not needed, and the target hosts or networks can be investigated directly.

If the scope of the penetration test is not limited to a fixed set of systems, then one of the first tasks may be to find hosts, services, applications and ports available as potential targets. The tool of choice for this is Nmap (Kaur and Kaur, 2017). Nmap is a powerful scanning tool which can be used in different ways, from sending simple ICMP echo requests to a range of IP addresses, to ‘host fingerprinting’, which is attempted by crafting specialised TCP/IP packets which are outside of the normal range encountered (for example, having SYN(chronise), ACK(nowledgement) and RST (reset) flags all set), and using the responses obtained to determine information about the target.

Different operating systems or protocol stacks generally respond differently to such unusual packets, enabling fingerprinting of the system. In addition, Nmap has an in-built scripting language which allows development of scripts to control its behaviour. Other tools among many in this category, also included in the Kali Linux distribution, are Sparta, a scanning and enumeration tool; p0f, an operating system fingerprinting tool; and snmp-check, a tool which can retrieve detailed host information using the SNMP protocol.

Enumeration tools

Once IP addresses, protocols and ports have been identified, a penetration tester can move to more detailed vulnerability assessment tools. At this point, a penetration tester needs to be able to identify particular vulnerabilities that may be used to gain access to systems. CVE (common vulnerabilities and exposures) lists are lists of known vulnerabilities in systems (Mell and Grance, 2002).

Organisations supplying and maintaining software code, including both open-source and proprietary systems, need to update their software with security patches for any discovered vulnerabilities, and will maintain public lists of vulnerabilities and patches. Many such lists exist, and CVE is a centralised list of known exposures from more than 150 organisations covering over 300 products, described by Tripathi and Singh (2010, p. 382) as ‘a universally accepted dictionary of common vulnerabilities and exposures’. It is useful for penetration testers to be able to relate the results of their tests to items in the CVE list. Several vulnerability scanners offer this capability.

Nessus is a widely used tool for testing potential vulnerabilities. Although the application is sometimes described as ‘open-source’, a key must be purchased from its vendor Tenable in order to download the latest plug-ins. Nessus developers constantly monitor CVE lists and develop plug-ins that enable Nessus to identify the latest vulnerabilities, test for their presence on target systems, give an indication of the severity of the problem and suggest remediation.

A number of other vulnerability scanners are available which perform this function. Some are integrated into wider ‘Vulnerability Management’ solutions. Other notable tools of this nature are available from BeyondTrust, Qualys, Rapid7 and Tripwire (Barros and Chuvakin, 2015; Holm, 2012). Given a list of hosts and ports to test, these tools will generally perform an automated test for vulnerabilities and produce a report detailing the results.

Identity spoofing, misconfiguration, password guessing tools

Even if systems have no known vulnerabilities from published CVE lists, they may still be vulnerable if misconfigured or if passwords or encryption techniques are weak. Password and encryption cracking applications have several ways of attempting to break into systems. One way is to use brute force, attempting every possible key within a given keyspace.

A quicker alternative is a dictionary attack which uses a list of strings commonly used for passwords, or a list of passwords extracted from previously compromised systems. Many systems will force a minimum number of seconds between login attempts, and will lock a user out if more than a given number of incorrect passwords are attempted. If these measures are not in place, compromise can occur.

In the case of encrypted communication, if a system uses a weak cipher, or a key that is too short, then encrypted traffic which is intercepted can be decrypted. This is particularly true for wireless communication systems. The use of distributed or cloud-based systems to provide the computational power to brute force complex passwords (Yong-Lei and Zhi-Gang, 2015) means that encryption systems previously considered secure can now be cracked for a relatively small financial outlay.

Tools which target wireless communications, such as Aircrack-ng, are available in the Kali Linux distribution. The interception and decryption of network communication may reveal login accounts and passwords which can then be used to gain access to systems. The most widely used tool for intercepting and analysing network traffic is Wireshark. Wireshark can capture live traffic or display previously captured traffic. If the appropriate private key is installed, Wireshark can also decrypt traffic from encrypted HTTPS or SSL sessions.

Password attacks may also be done offline. If a file containing encrypted passwords can be obtained, then this may be subjected to an offline attack, which does not involve the original system from which the encrypted password was obtained. This enables the password cracking to proceed undetected. Examples of files which contain encrypted passwords are the Linux /etc/shadow or /etc/passwd files, Microsoft SAM (Security Account Manager) registry hives and Cisco configuration files. ‘John the Ripper’ is a password cracking tool included in Kali Linux.

Application vulnerability testing tools

As more services become internet-enabled and ubiquitously available, the number and complexity of these services increases. Online systems often involve complex client-side scripting and on the server side have access to executable code, databases and authentication systems. As this complexity increases, so does the likelihood of the introduction of vulnerabilities.

A number of categories of tools exist which may help the penetration of online applications. Proxies, such as Web Scarab, intercept requests and may intercept, display and modify data between the client and the server. Web crawlers or ‘spiders’ can discover and list or copy the entire contents of a web application, and analysers such as nikto or w3af will test for known vulnerabilities.

The Open Web Application Security Project (OWASP) is an open community focused on improving the security of software. OWASP maintains a list of the Top 10 most critical web application security risks, which it describes as ‘a broad consensus about the most critical security risks to web applications’ (OWASP, 2017). These risks are generalised – for example, at the time of writing, OWASP risk A1 is ‘Injection’, which describes a generic process of introducing unexpected data to an interpreter, which may trick the interpreter into breaching normal security. OWASP itself provides an open-source framework which tests for these vulnerabilities: the Zed Attack Proxy (ZAP).

Burp Suite from PortSwigger Web Security is a similar commercial tool. Such tools may be configured for passive scanning, which will not attempt to modify requests or responses, and should therefore be safe to use in a penetration test of a production environment. Active scanning will attempt to use known injection attacks against targets, and may potentially disable or cause unexpected behaviour in the target systems. Many penetration tests will specifically exclude such attacks from their scope. However, being restricted to passive scanning may severely limit the ability of the test to expose vulnerabilities.

One of the most prevalent vulnerabilities is that of SQL injection (Clarke and Clarke-Salt, 2009) in which an attacker enters SQL statements and characters where the application is expecting a normal text response from the user. This code is passed by the web application to the database system, where its successful execution can cause the output of data not normally available to web users, or even the manipulation of tables and data within the database system. Web application tools differ in their level of automation and use. Some tools require only a URL, and will automatically investigate and test all embedded links within the web application responses from that URL. Other tools may require the tester to select links and choose the tests and probing strings manually.

One penetration testing technique which can be used in a wide variety of situations is ‘fuzzing’: this is the process of sending intentionally invalid data to a product in the hopes of triggering an error condition or fault. These error conditions can lead to exploitable vulnerabilities (Sutton et al., 2007). Fuzzing can be used against protocols, applications and services, and may range from simply hitting random characters on a keyboard, to sending data generated by a tailored application. Peach,¹ Spike (distributed with Kali) and Protos (a suite developed by Oulu University Secure Programming Group) are examples of software designed specifically for fuzzing (Baker, 2014). As fuzzing may cause failures in the target system, it is likely to be determined as out-of-scope in testing of production systems. If such tests are determined necessary, they could be performed against a test copy or dummy system, so that production systems are not harmed.

Comparison, evaluation and rating of penetration testing tools

Studies cited in Holm (2012) compare vulnerability scanners, but as there is a wide range of penetration testing tools for different purposes, it is difficult to achieve a clear comparison of tools. Penetration testing tools may be selected according to computer magazine ratings – for example, Cyber Defense Magazine (CDM) publishes a list of around 100 companies and products as their ‘Infosec Award Winners’ (CDM, 2017), but the large number of magazines, products and evaluations available makes this a difficult task. Market penetration or sales statistics may also give an indication of which tools to choose, although such statistics are difficult to find.

Companies such as NCC Group (www.nccgroup.trust) or Info-Assure (www.info-assure.co.uk) offering penetration test services will often also provide white papers, technical advisories or research papers, which may help in the selection of penetration testing tools. They may also publish information about the tools they use on sites such as LinkedIn (NCC, 2017).

While tools may automate many of the tasks involved in penetration testing, there is always scope for the creative individual to perform manual testing. A fully automated tool-based attack is unlikely to discover all vulnerabilities, and Austin et al. (2013) found systematic manual testing was most effective at finding design flaw vulnerabilities. The engagement of credible and certified penetration testing organisations brings the valuable experience of the penetration testers, who have applied their craft in a variety of contexts, and who bring a wealth of knowledge to the test which goes well beyond the ability to run a particular testing tool.

SUMMARY

This chapter has described some of the tools and techniques that can be used for penetration testing. Different tools and techniques are used in the reconnaissance, enumeration and exploitation phases of a penetration test. The scope of a penetration test should determine whether active or passive techniques may be used, bearing in mind that passive-only scanning may severely limit the effectiveness of a penetration test. Tools and techniques include port scanning, vulnerability scanning, password cracking, decryption, web crawling, code injection and fuzzing. Comparison of tools is difficult, and many testers and testing organisations will use a suite of tools with which they are already familiar.

REFERENCES

Allen, L., Heriyanto, T. and Ali, S. (2014) Kali Linux: Assuring Security by Penetration Testing. Birmingham, UK: Packt Publishing Ltd.

Austin, A., Holmgreen, C. and Williams, L. (2013) ‘A comparison of the efficiency and effectiveness of vulnerability discovery techniques’. Information and Software Technology, 55 (7), 1279–1288.

Baker, S.D. (2014) ‘Fuzzing: A solution chosen by the FDA to investigate detection of software vulnerabilities’. Biomedical Instrumentation & Technology, 48(s1), 42–47.

Barros, A. and Chuvakin, A. (2015) A Comparison of Vulnerability and Security Configuration Assessment Solutions. G00290479. Stamford, CT: Gartner Inc.

CDM (2017) Infosec Award Winners. Cyber Defense Magazine. Available at: www.cyberdefensemagazine.com/2017-cdm-infosec-award-winners/

Chiem, T.P. and Yan, W.Q. (2014) ‘An overview of penetration testing’. International Journal of Digital Crime and Forensics (IJDCF), 4 (6), 50–74.

Clarke, J. and Clarke-Salt, J. (2009) ‘What is SQL injection?’ In SQL Injection Attacks and Defense. Burlington: Elsevier. 1–26.

CREST (2017) A Guide for Running an Effective Penetration Testing Programme. Available at: https://www.crest-approved.org/wp-content/uploads/CREST-Penetration-Testing-Guide.pdf

Daintith, J. and Wright, E. (2008) Computer Misuse Act 1990. In A Dictionary of Computing, 6th edn. Oxford, UK: Oxford University Press.

Faircloth, J. (2016) Penetration Tester’s Open Source Toolkit. Rockland, MA: Syngress.

Holm, H. (2012) ‘Performance of automated network vulnerability scanning at remediating security issues’. Computers & Security, 21 (2), 164–175.

Kaur, M.G. and Kaur, N. (2017) ‘Penetration testing: Reconnaissance with NMAP Tool’. International Journal of Advanced Research in Computer Science, 8 (3), 844–846.

Mell, P. and Grance, T. (2002) Use of the Common Vulnerabilities and Exposures (CVE) Vulnerability Naming Scheme. NIST Special Publication 800-51. Gaithersburg, MD: National Institute of Standards and Technology.

NCC (2017) NCC Group, June 2017. Available at: https://www.linkedin.com/company/ncc-group

OWASP (2017) OWASP Top 10–2017: The Ten Most Critical Web Application Security Risks. Available at: https://www.owasp.org/images/7/72/OWASP_Top_10-2017_%28en%29.pdf.pdf

PTES (2017) The penetration testing execution standard. Available at: www.pentest-standard.org/index.php/Main_Page

Storms, A. (2006) ‘Don’t trust your vendor’s software distribution methodology’. Information Systems Security, 14 (6), 38–43.

Sutton, M., Greene, A. and Amini, P. (2007) Foreword. In Fuzzing: Brute Force Vulnerability Discovery. London: Pearson Education.

Tripathi, A. and Singh, U.K. (2010) ‘Towards standardization of vulnerability taxonomy’. 2nd International Conference on Computer Technology and Development (ICCTD), 2010. IEEE, pp. 379–384.

Wai, C.T. (2002) Conducting a Penetration Test on an Organization. Bethesda, MD: Sans Institute Information Security Reading Room.

Yong-Lei, L. and Zhi-Gang, J. (2015) ‘Distributed method for cracking WPA/WPA2-PSK on multi-core CPU and GPU architecture’. International Journal of Communication Systems, 28 (4), 723–742.