Preface

This book is dedicated to the use of Kali Linux in performing penetration tests against networks. A penetration test simulates an attack against a network or a system by a malicious outsider or insider. Unlike a vulnerability assessment, penetration testing is designed to include the exploitation phase. Therefore, it proves that the exploit is present, and that it is accompanied by the very real risk of being compromised if not acted upon.

Note

Throughout this book, we will refer to "penetration testers," "attackers," and "hackers" interchangeably as they use the same techniques and tools to assess the security of networks and data systems. The only difference between them is their end objective—a secure data network, or a data breach.

Most testers and attackers follow an informal, open source, or proprietary-defined testing methodology that guides the testing process. There are certain advantages of following a methodology:

• A methodology identifies parts of the testing process that can be automated (for example, a tester may always use a ping sweep to identify potential targets; therefore, this can be scripted), allowing the tester to focus on creative techniques to find and exploit vulnerabilities
• The results are repeatable, allowing them to be compared over time or to cross-validate one tester's results against another, or to determine how the security of the target has improved (or not!) over time
• A defined methodology is predictable in terms of time and personnel requirements, allowing costs to be controlled and minimized
• A methodology that has been preapproved by the client, protects the tester against liability in the event there is any damage to the network or data

Formal methodologies include the following well-known examples:

• Kevin Orrey's penetration testing framework: This methodology walks the tester through the sequenced steps of a penetration test, providing hyperlinks to tools and relevant commands. More information can be found at www.vulnerabilityassessment.co.uk.
• Information Systems Security Assessment Framework (ISSAF): This comprehensive guide aims to be the single source for testing a network. More information on this can be found at www.oissg.org.
• NIST SP 800-115, technical guide to information security testing and assessment: Written in 2008, the four-step methodology is somewhat outdated. However, it does provide a good overview of the basic steps in penetration testing. You can get more information at http://csrc.nist.gov/publications/nistpubs/800-115/SP800-115.pdf.
• Open Source Security Testing Methodology Manual (OSSTMM): This is one of the older methodologies, and the latest version attempts to quantify identified risks. More details can be found at www.osstmm.org.
• Open Web Application Security Project (OWASP): This is focused on the 10 most common vulnerabilities in web-based applications. More information on this can be found at www.owasp.org.
• Penetration Testing Execution Standard (PTES): Actively maintained, this methodology is complete and accurately reflects on the activities of a malicious person. You can get more information at www.pentest-standard.org.
• Offensive (Web) Testing Framework (OWTF): Introduced in 2012, this is a very promising direction in combining the OWASP approach with the more complete and rigorous PTES methodology. More details can be found at https://github.com/7a/owtf.

Unfortunately, the use of a structured methodology can introduce weaknesses into the testing process:

• Methodologies rarely consider why a penetration test is being undertaken, or which data is critical to the business and needs to be protected. In the absence of this vital first step, penetration tests lose focus.
• Many penetration testers are reluctant to follow a defined methodology, fearing that it will hinder their creativity in exploiting a network.
• Penetration testing fails to reflect the actual activities of a malicious attacker. Frequently, the client wants to see if you can gain administrative access on a particular system ("Can you root the box?"). However, the attacker may be focused on copying critical data in a manner that does not require root access, or cause a denial of service.

To address the limitations inherent in formal testing methodologies, they must be integrated in a framework that views the network from the perspective of an attacker, the "kill chain."