51,59 €
Employ the most advanced pentesting techniques and tools to build highly-secured systems and environments
This book is for anyone who wants to improve their skills in penetration testing. As it follows a step-by-step approach, anyone from a novice to an experienced security tester can learn effective techniques to deal with highly secured environments.
Whether you are brand new or a seasoned expert, this book will provide you with the skills you need to successfully create, customize, and plan an advanced penetration test.
The defences continue to improve and become more and more common, but this book will provide you with a number or proven techniques to defeat the latest defences on the networks. The methods and techniques contained will provide you with a powerful arsenal of best practices to increase your penetration testing successes.
The processes and methodology will provide you techniques that will enable you to be successful, and the step by step instructions of information gathering and intelligence will allow you to gather the required information on the targets you are testing. The exploitation and post-exploitation sections will supply you with the tools you would need to go as far as the scope of work will allow you. The challenges at the end of each chapter are designed to challenge you and provide real-world situations that will hone and perfect your penetration testing skills. You will start with a review of several well respected penetration testing methodologies, and following this you will learn a step-by-step methodology of professional security testing, including stealth, methods of evasion, and obfuscation to perform your tests and not be detected!
The final challenge will allow you to create your own complex layered architecture with defences and protections in place, and provide the ultimate testing range for you to practice the methods shown throughout the book. The challenge is as close to an actual penetration test assignment as you can get!
The book follows the standard penetration testing stages from start to finish with step-by-step examples. The book thoroughly covers penetration test expectations, proper scoping and planning, as well as enumeration and foot printing
Sie lesen das E-Book in den Legimi-Apps auf:
Seitenzahl: 468
Veröffentlichungsjahr: 2016
Copyright © 2016 Packt Publishing
All rights reserved. No part of this book may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, without the prior written permission of the publisher, except in the case of brief quotations embedded in critical articles or reviews.
Every effort has been made in the preparation of this book to ensure the accuracy of the information presented. However, the information contained in this book is sold without warranty, either express or implied. Neither the authors, nor Packt Publishing, and its dealers and distributors will be held liable for any damages caused or alleged to be caused directly or indirectly by this book.
Packt Publishing has endeavored to provide trademark information about all of the companies and products mentioned in this book by the appropriate use of capitals. However, Packt Publishing cannot guarantee the accuracy of this information.
First published: May 2012
Second edition: March 2016
Production reference: 1210316
Published by Packt Publishing Ltd.
Livery Place
35 Livery Street
Birmingham B3 2PB, UK.
ISBN 978-1-78439-581-0
www.packtpub.com
Authors
Lee Allen
Kevin Cardwell
Reviewer
S Boominathan
Commissioning Editor
Kartikey Pandey
Acquisition Editor
Subho Gupta
Content Development Editor
Mayur Pawanikar
Technical Editor
Murtaza Tinwala
Copy Editor
Charlotte Carneiro
Project Coordinator
Nidhi Joshi
Proofreader
Safis Editing
Indexer
Rekha Nair
Graphics
Jason Monteiro
Production Coordinator
Aparna Bhagat
Cover Work
Aparna Bhagat
Lee Allen is currently the vulnerability management program lead for one of the Fortune 500. Among many other responsibilities, he performs security assessments and penetration testing.
Lee is very passionate and driven about the subject of penetration testing and security research. His journey into the exciting world of security began back in the 80s, while visiting BBSs with his trusty Commodore 64 and a room carpeted with 5 ¼-inch floppy disks. Over the years, he has continued his attempts at remaining up to date with the latest and greatest in the security industry and the community. He has several industry certifications, including OSWP, and has been working in the IT industry for over 15 years. His hobbies include validating and reviewing proof-of-concept exploit code, programming, security research, attending security conferences, discussing technology, writing, and skiing.
He lives in Ohio with his wife, Kellie, and their 6 children, Heather, Kristina, Natalie, Mason, Alyssa, and Seth.
Kevin Cardwell currently works as a freelance consultant and provides consulting services for companies throughout the world, and as an advisor to numerous government entities in the USA, Middle East, Africa, Asia and the UK. He is an instructor, technical editor, and author for computer forensics and hacking courses. He is the author of the Center for Advanced Security and Training (CAST) Advanced Network Defense and Advanced Penetration Testing courses. He is a technical editor of the Learning Tree course, Penetration Testing Techniques and Computer Forensics. He has presented at the Black Hat USA, Hacker Halted, ISSA, and TakeDownCon conferences, as well as many others. He has chaired the cybercrime and cyber defense summit in Oman and was the executive chairman of the oil and gas cyber defense summit. He is the author of Building Virtual Pentesting Labs for Advanced Penetration Testing and Backtrack – Testing Wireless Network Security. He holds a BS in computer science from National University in California and an MS in software engineering from the Southern Methodist University (SMU) in Texas. He developed the strategy and training development plan for the first Government CERT in the country of Oman, which was recently rated as the top CERT in the Middle East. He serves as a professional training consultant to the Oman Information Technology Authority and developed the team to man the first Commercial Security Operations Center in Oman. He has worked extensively with banks and financial institutions throughout the Middle East, Europe, and the UK in the planning of a robust and secure architecture and implementing requirements to meet compliance. He currently provides consultancy to commercial companies, governments, federal agencies, major banks, and financial institutions throughout the globe. Some of his recent consulting projects include the Muscat Securities Market (MSM), Petroleum Development Oman, and the Central Bank of Oman. He designed and implemented the custom security baseline for the existing Oman Airport Management Company (OAMC) airports and the two new airports opening in 2016. He created custom security baselines for all of the Microsoft Operating Systems, Cisco devices, and other applications as well.
S Boominathan is a highly professional security expert with 4 plus years of experience in the field of information security, malware analysis, vulnerability assessment, and network and wireless pentesting. He is currently working with a bellwether of an Indian-based MNC company and is privileged to be doing so. He possesses certifications and knowledge in N+, CCNA, CCSA, CEHV8, CHFIV4, QCP (QualysGuard certified professional), and wireless pentesting expert.
I would like to thank my parents, Sundaram and Valli, my wife, Uthira, and my brother, Sriram, for helping throughout this book. I would like to thank the author and Packt Publishing for providing me with the opportunity to review this book.
Did you know that Packt offers eBook versions of every book published, with PDF and ePub files available? You can upgrade to the eBook version at www.PacktPub.com and as a print book customer, you are entitled to a discount on the eBook copy. Get in touch with us at <[email protected]> for more details.
At www.PacktPub.com, you can also read a collection of free technical articles, sign up for a range of free newsletters and receive exclusive discounts and offers on Packt books and eBooks.
https://www2.packtpub.com/books/subscription/packtlib
Do you need instant solutions to your IT questions? PacktLib is Packt's online digital book library. Here, you can search, access, and read Packt's entire library of books.
This book is dedicated to Loredana and her support during the many hours required for research. Without her support, this book would not have been possible.
--Kevin CardwellDefenses continue to improve and become more and more common, but this book will provide you with a number of proven techniques to defeat the latest defenses on networks. The methods and techniques contained will provide you with a powerful arsenal of best practices to increase your penetration testing success. Many of the chapters end with a challenge to the reader that is designed to enhance and perfect their penetration testing skills.
Chapter 1, Penetration Testing Essentials, discusses why an essential element of penetration testing is planning, and a key component of this is having a methodology that emulates and matches the threat that we are portraying.
Chapter 2, Preparing a Test Environment, deals with the test environment, compares a number of different platforms, and prepares the reader for the foundation of building an advanced range for testing.
Chapter 3, Assessment Planning, talks about the test environment and how to evaluate the different platforms for your environment. The process of documenting and recording your testing results is covered, as well as methods to automate the process.
Chapter 4, Intelligence Gathering, reviews some of the tools and focuses on how to use the information to ensure your penetration tests are efficient, focused, and effective.
Chapter 5, Network Service Attacks, discusses how to successfully penetrate a secured environment and how to analyze what you are facing. The enumeration data gathered will assist in determining target prioritization and how to choose which targets are ideal candidates for your initial attacks.
Chapter 6, Exploitation, reviews the basics of exploitation and then moves on to the more interesting techniques and methods that will let us understand the true security posture of the network environment we are testing. Additionally, you will see the challenges of writing exploits today in 64-bit architectures.
Chapter 7, Web Application Attacks, explores various methods of testing web applications using freely available tools such as your web browser, w3af, WebScarab, and others. Methods of bypassing web application firewalls and IDSs are discussed as well how to determine if your targets are being load balanced or filtered.
Chapter 8, Exploitation Concepts, investigates methods that assist us in testing the effectiveness of a corporation's security awareness training and client-side protection mechanisms. The research performed during the information gathering stages of your testing will finally be used to the fullest extent. Furthermore, we look at some of the techniques and tools used by security researchers and crafty attackers to bypass even those system controls that at first glance seem theoretically sound.
Chapter 9, Post-Exploitation, covers the methods of conducting post-exploitation once you have compromised a machine and established a foothold in the environment. The process of extracting credentials, gathering data, and scraping the environment once access is gained is covered in detail.
Chapter 10, Stealth Techniques, reviews the challenges of penetrating firewalled environments, and methods of evading detection and blocks from the different endpoint protection mechanisms that may encounter during your testing.
Chapter 11, Data Gathering and Reporting, introduces the usage of tools and techniques that can make documenting the testing progress less painful and report writing easier, which is an essential but often overlooked component of penetration testing.
Chapter 12, Penetration Testing Challenge, allows you to put some of the information that has been covered throughout the book to work and bring it into perspective. The chapter provides preparation specifications for the practice environment and presents a challenge to the reader to perform a penetration test of this fictional company.
You can use a virtual software platform of your choice, but the examples throughout the book use VMware Workstation Professional, the Kali 2.0 Linux distribution, and a number of other prebuilt virtual machine images, such as the Kioptrix and OWASP distributions. The iso images for pfsense firewall, Ubuntu 8, 14.04, Debian 4.0, CentOS 5.0, FreeBSD, and Windows Server 2003.
This book is for anyone who wants to improve their skills in penetration testing. As it follows a step-by-step approach, anyone from a novice to an experienced security tester can learn effective techniques to deal with highly secured environments.
Whether you are brand new or a seasoned expert, this book will provide you with the skills you need to successfully create, customize, and plan an advanced penetration test.
In this book, you will find a number of text styles that distinguish between different kinds of information. Here are some examples of these styles and an explanation of their meaning.
Code words in text, database table names, folder names, filenames, file extensions, pathnames, dummy URLs, user input, and Twitter handles are shown as follows: "Aside from Oracle, another port of interest is the port 3306."
A block of code is set as follows:
When we wish to draw your attention to a particular part of a code block, the relevant lines or items are set in bold:
Any command-line input or output is written as follows:
New terms and important words are shown in bold. Words that you see on the screen, for example, in menus or dialog boxes, appear in the text like this: "Once you verified your settings, click on Apply | OK."
Warnings or important notes appear in a box like this.
Tips and tricks appear like this.
Feedback from our readers is always welcome. Let us know what you think about this book—what you liked or disliked. Reader feedback is important for us as it helps us develop titles that you will really get the most out of.
To send us general feedback, simply e-mail <[email protected]>, and mention the book's title in the subject of your message.
If there is a topic that you have expertise in and you are interested in either writing or contributing to a book, see our author guide at www.packtpub.com/authors.
Now that you are the proud owner of a Packt book, we have a number of things to help you to get the most from your purchase.
We also provide you with a PDF file that has color images of the screenshots/diagrams used in this book. The color images will help you better understand the changes in the output. You can download this file from https://www.packtpub.com/sites/default/files/downloads/AdvancedPenetrationTestingforHighlySecuredEnvironmentsSecondEdition_ColoredImages.pdf.
Although we have taken every care to ensure the accuracy of our content, mistakes do happen. If you find a mistake in one of our books—maybe a mistake in the text or the code—we would be grateful if you could report this to us. By doing so, you can save other readers from frustration and help us improve subsequent versions of this book. If you find any errata, please report them by visiting http://www.packtpub.com/submit-errata, selecting your book, clicking on the Errata Submission Form link, and entering the details of your errata. Once your errata are verified, your submission will be accepted and the errata will be uploaded to our website or added to any list of existing errata under the Errata section of that title.
To view the previously submitted errata, go to https://www.packtpub.com/books/content/support and enter the name of the book in the search field. The required information will appear under the Errata section.
Piracy of copyrighted material on the Internet is an ongoing problem across all media. At Packt, we take the protection of our copyright and licenses very seriously. If you come across any illegal copies of our works in any form on the Internet, please provide us with the location address or website name immediately so that we can pursue a remedy.
Please contact us at <[email protected]> with a link to the suspected pirated material.
We appreciate your help in protecting our authors and our ability to bring you valuable content.
If you have a problem with any aspect of this book, you can contact us at <[email protected]>, and we will do our best to address the problem.
In this chapter, we will discuss why an essential element of penetration testing is planning, and a key component of this is having a methodology that emulates and matches the threat that we are portraying. We will discuss the following:
If you have been performing penetration testing for some time and are very familiar with the methodology and concept of professional security testing, you can skip this chapter, or just skim it; however, you may learn something new or at least a different approach to how you approach penetration testing.
What exactly is a methodology? This is a term that we use often in the Information Technology (IT) world, but what exactly does it mean? As you might expect, there are a number of different interpretations of this term that usually is dependent on whom you ask. If we use the search capability of the Internet, we can possibly get a better idea of what the term means. From the Wikipedia website, at https://en.wikipedia.org/wiki/Methodology, we see that the term is defined as a systematic, theoretical analysis of the methods applied to a field of study. This definition is a bit too vague for our purposes, so we will look at another source. The site at http://www.wisegeek.com defines the term as "a set of practices." This term may be used to refer to practices, which are widely used across an industry or scientific discipline, the techniques used in a particular research study, or the techniques used to accomplish a particular project."
This definition is closer to what we are looking for, but as with most definition sources, we will use their information as guidance and define the term in our own words. For the concept of this book, we look at a methodology as a "systematic approach to professional security testing that follows a structured process based on the motives of a potential attacker when targeting an organization."
In this section, we will take a look at a number of the testing methodologies that exist for us to use. This is by no means an exhaustive list, and you are encouraged to research the different references with respect to a methodology that exists. Additionally, we will not explore the methodologies in detail; for more, refer to the links that are listed with reference to each approach. The first methodology we will look at is the penetration testing framework.
Before we discuss the framework, we will look at the Pre-site Inspection Checklist that is contained at the site that hosts the framework; this assessment consists of the following main steps:
An example of the web page for the framework is shown in the following image:
The framework starts with the identification of the network footprint to gather as much information as possible for the selected network. As with most methodologies, the step is broken down into two types, active and passive. The framework defines the active part of the reconnaissance as being intrusive and involves attempting zone transfers and other types of activity that will be detected and/or blocked by the Intrusion Detection System (IDS) and Intrusion Prevention System (IPS), respectively. Additionally, passive refers to the nonintrusive approach of testing. The framework lists a number of sites to assist with gathering the information. Many of these are covered by others, so we will not focus on them here; however, we will look at one site that combines a number of different tools: the http://www.centralops.net website. An example of this is shown in the following image:
As the image shows, there are a number of tools at the site, and you are encouraged to research them and identify the ones that you want to use as part of your professional security testing work. Two of the tools that you might want to take a look at are Domain Dossier and Email Dossier. Both of these tools will allow you to glean some important information about a domain and also an e-mail address. The following image is a cropped example of Email Dossier:
As with any of the sites within this chapter and throughout the book, there are a number of examples for you as the reader to explore and make decisions on your own as to which ones you want to use or not use. The important thing is to have a plan and practice it. This is so that, when you do go against targets, you have practiced it and examined how the different tools work and can recognize patterns when you are performing your testing; when you reach a point where there is something you do not recognize, take a break and think about it, and try harder to get past it. This is all the process of testing.
Another item that is useful in the framework is the examples for input validation. If you try and follow the link provided, it will result in a 404 error; but the examples that are in this section, are very good to follow and get information from. A brief example of this is shown in the following image:
This is just one example of many of the references and usage examples that are contained within the framework. Another area of interest is the section on how to create your own bash connect-back shells from machines; these are provided by the team at Neohapsis and GNUCITIZEN, and there usually is good information on these sites, so you might want to visit them at http://www.neohapsis.com and http://www.gnucitizen.org, respectively.
Another section of interest is on application/server tools, and there are a number of tools you might want to explore, specifically the tools that are related to Joomla, an open source content management system; this is because this has become such a popular application you are almost sure to encounter it. A tool from the list that is also in the Kali Linux distribution is joomscan. This tool is no longer actively deployed, but still offers lots of benefits for a tester. An example of information about the tool from the Kali website is shown in the following image:
One of the best parts of the framework is the breakdown of tools based on the discovered port. This helps when you build your custom methodology; consequently, you want to build your lab environment, practice the discovered tools, and build your own library of tools and steps for the ones that work and do not work. The challenge with any of these tool listings is finding the ones that are still active and available. Once you have done that, then you want to narrow the list down to the ones that work for you, and then become proficient with the tool. This is why we build lab ranges and practice the skills over and over before we ever do any testing.
An example from the framework for a discovered port 1521 (Oracle) is shown in the following image. As a reminder, some or maybe all of the tools might not exist, or might have changed since the writing of this book, so keep that in mind when you look at the tools from the list. Even one good tool for Oracle makes it worth performing the research. There are a lot of Oracle databases out there and it is good to know how to test them.
Aside from Oracle, another port of interest is the port 3306 (MySQL). Since there continues to be a large movement to the cloud, many solutions don't use commercial software versions, because of the cost involved or because they prefer the control you can have in a Linux or open source application. Since this is the case, it has become more common for the attackers to start looking at the open source systems and applications more. This has been confirmed with the latest attacks as of this writing against OpenSSL. An example of the recommended techniques when the port is discovered open is shown in the following image:
As we mentioned previously, you are encouraged to explore these techniques and build your own custom methodology. There is no perfect solution, so you will have to come up with the best one you can to meet the needs of the test that you are performing. An example of this would be for you to take all of the tools you work with and test them and make some form of a chart. A common technique is a decision flow chart that identifies whether authentication is required or not. Then, if it is an external test, the authentication more than likely will not be provided from the client or the requesting entity so that the tool would only be used if you have some form of credentials for it. It is possible that you have obtained these credentials from other means, but for the most part, an external test would not have credentials associated with it, so you would not use that tool or the command switch of the tool that requires credentials as part of your test. However, if the test is internal and you will have credentials as part of the scope of work, then you would use that tool or switch as part of your testing. This is the challenge we all face as testers; we have to identify where and when to apply the tool within the methodology. Furthermore, we have to know what the tools do when we use them and how to use the tool properly. Since such a wide variety of these methods are available to us, we have to carry out our research and select the components that work well for us.
The last thing we will cover from the framework before moving on is the section on port 5060 (Session Initiation Protocol). Since there are so many Voice Over IP (VOIP) configurations across the enterprise, there is a good chance you will encounter SIP in your testing. An example from the framework of this is shown in the following image:
As we indicated, there are a number of things that we can use as references for our testing and to establish our process and methodology. From here, you are encouraged to research the framework on your own and build your listing of what tool does what for each of the protocols that you may encounter. We will now move on to another standard for penetration testing.
Penetration Testing Execution Standard (PTES) provides technical procedures that can be used in a penetration test. The standard consists of seven main sections, and these are as follows:
The standard does not provide the technical guidance to execute a penetration test, but there is a technical guide that can be used to provide this type of information to those who want it. This reference can be found at http://www.pentest-standard.org/index.php/PTES_Technical_Guidelines. This supplement provides examples of the methods to use to carry out each step of the methodology; when you combine it with the standard, it provides a comprehensive plan for penetration testing. The brief explanation that is found at the website is shown in the following image:
Within the standard, there are a number of important items for when you are planning a penetration test. We will not discuss each and every one since you can get this information by reading the standard; we will, however, look at some of the more essential items. The first item that we want to look at is the scope, this is something that is very important before a test can begin, and often it is not planned as well as it should be. From experience, it is very easy to not properly identify the scope and as such spend much more time than what you expected to on a test. This is speaking from experience, and while some scope "creep" is expected, it is imperative that when planning a test you try to get the scope as close to correct as possible. As mentioned in the standard, it is a key fact that the testing group can and often does underestimate the work, especially in black box testing when the size of the organization is not well known; consequently, not charging the correct amount is something that often does happen. Although it may be part of human nature to do less than a complete job when this happens, a professional tester will provide the same level of service regardless of the cost. The essential component of this is the fact that, as a professional, when we agree to an amount for a contract, we should abide by it. This does not mean that, when a client gives us information that is not adequate, and requires more time than estimated, we ignore it. In these situations, it is imperative that the team requests a meeting, resolve the conflict, and come to a mutual agreement as to a potential contract modification that revises the original agreement. This will benefit both parties in the end. There is a good set of example questions within this section of the document that can assist in determining the scope, and it is worth reviewing.
The standard takes the approach of using and defining levels when it comes to categorizing the types of intelligence gathering. They state that this is done in three categories and provides a means to clarify the expected output with respect to the typically encountered constraints of time, effort, and access. The levels are as follows:
The exact details of the levels are beyond the scope of the book and readily available from the website. We will discuss one more component of this: exactly what intelligence gathering is as defined in the standard. It is based on the well know concept of Open-Source Intelligence (OSINT). We use this to explore potential entry points to an organization. It is important to note that the entry points can be physical, electronic, and human with respect to social engineering.
OSINT is further divided into three forms within the standard, these forms are as follows:
We will conclude this section here; as with the other methodologies, you are encouraged to explore these further.
Threat identification is extremely important in a penetration test. This is because a more structured and sophisticated threat will require a significant amount of time to emulate. In most cases, this level of threat is not selected when testing, and the simple fact of this is it is too time-consuming. A reason for this is the fact that you have as part of this threat the requirement to reverse-engineer binaries and look for weaknesses there. For those of you reading this who are not aware, this is a time-consuming process and very rarely asked for in most tests.
Part of this is planning for the "what if" scenario that surrounds the loss of any assets that are identified as part of the modeling process. This value is defined as the asset's net value, its intrinsic value, and other directly incurred costs associated with an event that causes a loss to the business. When you are testing a financial corporation, their critical assets will be different than those of a defense contractor. As a tester, we want to know what it is that the customer is most concerned with having compromised. The standard goes on to define high-level threat modeling process, and this consists of the following:
The standard also states there are a number of tools that are available to assist in this process. As before, the reader is encouraged to explore the different tools that are available outside of the book.
The standard explains that vulnerability testing is the process of looking for flaws in the targets we are testing. This is one of the challenges in testing, and that is the depth we are going to test. The decision for this should be based on the requirements of the scope of work. As stated in the standard, this process is highly dependent, not only by the scope, but also on the type of component being tested. Having said this, the standard correctly goes on to discuss the key principles that are part of vulnerability analysis. The standard breaks the vulnerability analysis into two high-level categories, and they are as follows:
Within the standard, each of these areas is explained in great detail, and the information there is very beneficial as you build your plan and testing methodology. One of the challenges with these references is determining what is viable for validation and exploitation. One of the key components of this is to research a number of different types of resources and select one or two and frequent them often. This is another section of the standard that you are recommended to review; however, one important thing remains before we move on, and that is the reality of vulnerability scanning while penetration testing. First, we have to consider if we are on a flat network or have a filtering device to pass through to get to the target of interest. The other thing we must consider is the fact that vulnerability scanners are somewhat limited with respect to determining client side vulnerabilities without credentials. A part of the scope of work should be a discussion on the preferred method for the vulnerability scanner; furthermore, whether there will be testing with or without credentials.
Additionally, it needs to be determined if the test consists of credentials for a normal user as well as a privileged one. The standard completes this section by explaining the need for what it termed as private research and the importance of establishing a robust and complete lab environment; for more on building your penetration testing labs, you can refer to Building Virtual Pentesting Labs for Advanced Penetration Testing.
The standard explains that this phase focuses solely on establishing and gaining access, and that it directly relates to how well we perform our vulnerability analysis. Another way to look at this is considering it as a validation of the vulnerabilities you have discovered; as the standard explains, we want to identify the main entry point into the organization and identify the targets of interest. This is another step that is completely dependent on what the scope of work is and the Rules of Engagement that have been established. For many in the testing industry, this is 10 minutes of fun, while the rest can be seen as 10 boring hours. This is not really the case when it comes to professional security testing as each component of testing is very important to the outcome: a professional report. The thing to remember is that the job of the testing team is to provide the client that engaged you with a report that can help them improve their security process and enterprise security posture. The standard lists countermeasures within this section and explains the importance of when you are testing, assessing the measures in place, and enumerating them before attempting the exploit. This does make sense when you are testing; it is recommended.
The standard also includes the act of evasion, and this is not something that is often part of penetration testing, but it is important to assess the control, so if it is an Intrusion Prevention System or another type then we can identify the threshold. Within this section, evasion is explained as the technique used to evade detection during your penetration testing. One of the components that is discussed, customizing of exploits, is something that the majority of testers will not experience. There are many excellent exploit writers in the industry, and for most of us we can use something that someone else has created. For those of you who do want to explore the writing of your own exploits, the topic was covered in the first edition of this book as well as a number of references. Finally, the process of fuzzing is explained within this section. Fuzzing is the ability to modify or change the data being sent to an application in hopes of identification of vulnerability. The process has quite a following, and there are entire books written on this subject.
The standard describes this phase in line with the way that most do, and that is the concept is to while remaining within the scope of work maintain access, we want to plant some form of backdoor that will allow us to maintain access. During the assessment, ideally the backdoor will include an end-of-testing date at which time it will clean or remove itself; otherwise, the enterprise or testing team will have to clean it up. Once we have accessed the machine, we also want to determine what the machine's role is on the network. If we are lucky and on a domain controller in a Microsoft Windows-centric enterprise, we can attempt to recon the active directory; of course this will be highly dependent on the level of access that we gained and the number of defenses the system administrator has deployed. An excellent website for performing this type of reconnaissance can be found here: https://github.com/PyroTek3/PowerShell-AD-Recon. An example of this is shown in the following screenshot:
Since post-exploitation is such a significant thing to be doing on a client's machine due to the possibility of sensitive information, it is imperative that you get this confirmed as a part of the Rules of Engagement. From the standard, a recommended list of limitations is as follows:
The third item is not one that will usually be part of any scope of work, but since it is a possibility we included it as a reference and it is listed within the standard. The critical element of this is that all actions have to be well documented and detailed. That is, when you take additional actions against an already compromised system, ensure you detail and explain everything that was done while in the compromised system; furthermore, the Rules of Engagement have to be considered when extracting information from a compromised machine since this can consist of users passwords and other sensitive information. It is the responsibility of the tester to maintain the protection of this sensitive information, and if it is used to escalate or penetrate deeper into the system, to ensure it is well documented. Having said this, the passwords, even in encrypted or hashed form, are never part of any report.
The section on reporting within the standard is similar to others, at a high level and without a lot of detail. This is another area that is often overlooked. Having said that, the standard does explain that the report is very important, and it is recommended that the tester develop their own customized and branding format. The basic criteria for a report are discussed within this section. These criteria are as follows:
As discussed earlier, this is a basic criterion and the standard contains an expansion on each of these topics, for those of you who want to learn more.
We will now take a look at some of the information that is contained within the technical guidelines. One of the sections on the guidelines, which is not always part of a standard or methodology, is information for wireless testing. An example of this is shown in the following image:
This is a good list of reference tools for wireless testing, and each one of these is expanded on within the document. You are encouraged to review them as part of your research and preparation. The next thing we want to look at is the section on external foot printing; moreover, the component listed there is for Border Gateway Protocol (BGP) looking glasses. This is due to the predominant protocol within the Internet, which is BGP and as such it is always good to get information about it. An example of one of the looking glass references is shown in the following screenshot:
Also indicated in the screenshot is the listing of the five Regional Internet Registries (RIR) across the globe. This is another reference that we can use with our information gathering endeavors.
There are many different technical guidelines available within the standard; this combined with the framework we first discussed can assist you in building your own custom and robust testing framework and/or methodology. The next thing we will look at is the section on detection bypass. Although it is not always a part of the scope of work, as we continue on through the book it is a part of the advanced penetration concept. There are a number of techniques referenced in the standard; the one we want to take a closer look at is the VPN Hunter. The link for this can be found at https://labs.duosecurity.com/vpnhunter/. This site will allow you to enter a domain and then it will search for VPNs for that domain, an example of this is shown in the following screenshot:
The next thing we will look at is the section on invasive or altering commands. Many times when we get access to a machine via a shell, we need to remember our administrator syntax. This section has a nice list of some commands that we need to use. An example of this is shown in the following screenshot:
A very important part of the screenshot is the box in red, and that is to ensure your binaries are vetted. This is something many, including me, do not always do a good job with; however, it is essential that we validate and verify any binaries we plan on running before we actually run them in our testing.
The last thing we will look at from the standard is the section on the Social Engineering Toolkit (SET). This is an exceptional tool that has taken what used to take more than an hour to carry out and reduced it to taking just a few minutes due to the interface. If social engineering is part of your scope of work, then the SET is an essential tool you should become very familiar with. An example of the home page for SET is shown in the following screenshot:
This is another tool that you are recommended to research and gain experience with.
As mentioned previously, we concentrate on a process and apply that to our security components when we go about security testing. For this, we describe an abstract methodology here:
A simple abstract methodology consists of the following steps:
The goal is to develop your process and select a minimum of two tools for each process, which provides the means for you to achieve the desired outcome at each step. Once you have done this, then you can add additional tools as required. The essential component is to have at least two tools to start professional security and penetration testing. For more on this abstract reference, refer to Building Virtual Pentesting Labs for Advanced Penetration Testing.
It is essential that you have a professional security testing plan and methodology before you start your penetration testing; furthermore, the more time you spend planning, the easier the test will be to perform. Without these essential elements, your testing will be unstructured and mostly ad hoc. This is something we want to avoid when it comes to performing penetration testing for a client who has hired us. We have briefly covered a number of methodologies here, and these are only provided as a reference. You are encouraged to build and develop your own methodology; the more time you spend on this, the more you will be rewarded in the end.
In this chapter, we discussed the need for a methodology when it comes to penetration testing and how it is essential when it comes to building skills as a professional penetration tester. Following this, we reviewed two sample methodologies. We reviewed the penetration testing framework and described the components within the standards, to include the process to follow based on the ports that are discovered during your assessments. The next methodology we discussed was the PTES, and although there is no technical guidance as part of the standard, there is a reference for the technical information that is available. We provided a reference for that, along with a number of examples on how to perform the testing for each step. The last methodology we looked at was a high-level abstraction that shows the potential components of a professional security test.
In the next chapter, we review the steps required to build the range that we will use throughout the rest of the book. At the end of the next chapter, we will have a complete range that allows us to practice virtually all testing methods against any of the targets that we may encounter.
