There are many reasons why penetration tests are necessary. Sometimes, a company may want to have a stronger understanding of their security footprint. Sometimes, they may have a compliance requirement that they have to meet. Either way, understanding why penetration testing is necessary will help you understand the goal of the company. Plus, it will also let you know whether you are performing an internal penetration test or an external penetration test. External penetration tests will follow the flow of an external user and see what they have access to, and what they can do with that access.

Internal penetration tests are designed to test internal systems, so typically, the penetration box will have full access to that environment, being able to test all software and systems for known vulnerabilities. Since tests have different objectives, we need to treat them differently; therefore, our tools and methodologies will be different.

One of the first tasks you need to complete prior to starting a penetration test is to have a meeting with the stakeholders and discuss various data points concerning the upcoming penetration test. This meeting could involve you as an external entity performing a penetration test for a client, or as an internal security employee doing the test for your own company. The important element here is that the meeting should happen either way, and the same type of information needs to be discussed.

During the scoping meeting, the goal is to discuss various items of the penetration test so that you have not only everything you need, but also full management buy-in with clearly defined objectives and deliverables. Full management buy-in is a key component for a successful penetration test. Without it, you may have trouble getting the required information from certain teams, or there may be scope creep, or general pushback.

This section goes over the various questions that I have used, and That I think are important for this type of engagement. These will help define clear and measurable objectives for the penetration tester.

Let's have a look at a questionnaire to determine the engagement criteria:

• What is the objective of this penetration test?
• What will be the deliverables required at the end of the penetration test?
• What is the length of the penetration test, and is there any period of time when the penetration test cannot happen? (For example, the customer may have a busy period during the day when they don't want anything to interrupt their business processes)
• During the penetration test, does the penetration test stop at finding vulnerabilities, or does it proceed to actively try to exploit these vulnerabilities? (This question is important because the stakeholder may not want systems to be taken down or potential data modified/deleted, so we want to make sure we know the boundaries) If exploiting systems is acceptable, do you want the penetration tester to try lateral movement within the environment after that?
• Will this be an internal penetration test, an external penetration test, or both?
• Who are the contacts within the company?
• Are there any compliance standards that the company needs to follow?

We will now see an example questionnaire for the scoping criteria. First, we will start with questions that will be derived from a white-box tester only to gain intimate knowledge of the network for testing:

• What are the subnets and/or IP addresses in the scope of this test?
• Are there any systems that are out of scope?
• Are there security devices within the network? (This is important because these devices may block access into an environment, and that will prevent testing the system correctly)
• Is there any type of important data held or transferred within the environment?

Finally, if the penetration tester is using more of a black-box mentality, then these questions will be relevant for them, as well as the white-box testers:

• Is guest access in scope as well?
• Which corporate SSIDs are in scope?
• What are the physical locations in scope for the test (if there are multiple locations)? Are all locations/networks dedicated, or are they shared with another company (for example, shared hosting or some cloud environments)?

Documentation is an important part of the planning and preparation phase. Sometimes, this information is not provided to you, and you must glean it yourself. In Chapter 2, Information Gathering, we will focus on getting some of this information as well, if it is not all provided.

But hopefully, you can get some information about the environment prior to jumping into the penetration test. There are different types of documentation that are great to have prior to starting a penetration test. In the next couple of sections, we will see some of the main types of documentation that we need during the preparation phase.

A network diagram of the systems and devices that are in scope is important to get a good understanding of the network so you can start working on your overall penetration plan. This documentation will allow you to see what systems are in scope, as well as the path through the network and devices that are involved. A lot of organizations struggle with this type of documentation, so use it strictly as a guide. One of the deliverables might end up being a more comprehensive network diagram for you, based on what is discovered during the penetration test.

Network diagrams come in all shapes and sizes. The important thing is to have it for the in-scope networks and to show the main network devices, security devices, and hosts, if at all possible. The following is a sample network diagram that I created. This will give you a good idea of what to look for:

Data flow diagrams are probably one of the most important documents a penetration tester/assessor/auditor can have. The job of a data flow diagram is to show the flow of important data within the organization. The data can be of different types, including credit card information, proprietary company information, or even personally identifiable information (PII). Understanding how this type of data flows in the network, and which systems it interacts with, will allow you to help the penetration tester understand where to focus. This is important as this is where the hackers will focus as well.

Some organizations do not typically have this type of documentation. We have seen many companies having to generate these data flow diagrams while going through an audit or assessment of some sort. But most organizations should have data flow diagrams within the organization for any important data flows.

A great outcome of the penetration test is that this type of documentation may end up being verified by the penetration tests to show its accuracy. Documentation is often a low priority at most companies, unfortunately, so being able to keep it up to date is important.

Here is an example of a data flow diagram of a sample company we created, showing credit card information flowing throughout the network:

You may be wonder why an organization chart is a valuable and required piece of documentation for a penetration test. But when you think about it, people in higher positions tend to get targeted because they have the power to transfer money, or have access to important items. Knowing the chain of command for all employees within an organization allows us, as penetration testers, to see other individuals that can be targeted with the hopes of getting all the way to the top. This information can help show the penetration tester whom to potentially target first. It may be easier for a hacker to get a junior accountant to click on a link and install the malware for the hacker to have remote access than it would be for them to try the same approach with the CFO. Now, we are pretty sure the CFO will have more access compared to the junior accountant, but once you have a foothold within an organization, moving around becomes a lot easier. Remember: People are typically the weakest link in security.

Here is a simple example of an organization chart:

With a clear understanding of expectations, deliverables, and scope, it is now time to start working on getting our penetration systems ready to go. For the hardware, I will be utilizing a decently powered laptop. The laptop is a Macbook Pro with 16 GB of RAM, a 256 GB SSD, and a quad-core 2.3 GHz Intel i7 running VMware Fusion. I will also be using the Raspberry Pi 3. The Raspberry Pi 3 is a 1.2 GHz ARMv8 64-bit Quad Core, with 1 GB of RAM and a 32 GB microSD. Obviously, there is quite a power discrepancy between the laptop and the Raspberry Pi. That is okay though, because I will be using both these devices differently. Any task that requires any sort of processing power will be done on the laptop. I love using the Raspberry Pi because of its small form factor and flexibility. It can be placed in just about any location we need, and if needed, it can be easily concealed.

For software, I will be using Kali Linux as my operating system of choice. Kali is a security-oriented Linux distribution that contains a bunch of security tools already installed. Its predecessor, Backtrack, was also a very popular security operating system. One of the benefits of Kali Linux is that it is also available for the Raspberry Pi, which is perfect in our circumstance. This way, we can have a consistent platform between the devices we plan to use in our penetration-testing labs. Kali Linux can be downloaded from their site at https://www.kali.org. For the Raspberry Pi, the Kali images are managed by Offensive Security at https://www.offensive-security.com. As for the various tools, we will talk about those as we use them in other chapters.

Even though I am using Kali Linux as my software platform of choice, feel free to use whichever software platform you feel most comfortable with. In this book, we will be using a bunch of open source tools for testing. A lot of these tools are available for other distributions and operating systems.

Setting up Kali Linux on both systems is a bit different since they are different platforms. Since this is an intermediate-level book, we won't be diving into a lot of details about the installation, but we will be hitting all the major points. This is the process you can use to get the software up and running.

We will start with the installation on the Raspberry Pi:

1. Download the images from Offensive Security at https://www.offensive-security.com/kali-linux-arm-images/.
2. Open the Terminal app on OS X.

3. Using the utility xz, you can decompress the Kali image that was downloaded:

xz-d kali-2.1.2-rpi2.img.xz

4. Next, you insert the USB microSD card reader with the microSD card into the laptop and verify the disks that are installed so that you know the correct disk to put the Kali image on:

diskutil list

5. Once you know the correct disk, you can unmount the disk to prepare to write to it:

diskutil unmountDisk/dev/disk2

6. Now that you have the correct disk unmounted, you will want to write the image to it using the dd command. This process can take some time, so if you want to check on the progress, you can run the Ctrl + T command any time:

sudo dd if=kali-2.1.2-rpi2.imgof=/dev/disk2bs=1m

7. Since the image is now written to the microSD drive, you can eject it with the following command:

disk utile ject/dev/disk2

8. You then remove the USB microSD card reader, place the microSD card in the Raspberry Pi, and boot it up for the first time. The default login credentials are as follows:

Username:root
Password:toor

9. You then change the default password on the Raspberry Pi with the following command to make sure no one can get into it:

Passwd<INSERTPASSWORDHERE>

10. Making sure the software is up to date is important for any system, especially a secure penetration-testing system. You can accomplish this with the following commands:

apt-get update
apt-get upgrade
apt-get dist-upgrade

11. After a reboot, you are ready to go with the Raspberry Pi.

Next, we will move on to setting up the Kali Linux install on the Mac. Since you will be installing Kali as a VM within Fusion, the process will vary compared to another hypervisor, or installing on a bare metal system. For me, I like having the flexibility of having OS X running so that I can run commands on there as well:

1. Similar to the Raspberry Pi setup, you need to download the image. You will do that directly via the Kali website. They offer virtual images for downloads as well. If you go to select these, you will be redirected to the Offensive Security site at https://www.offensive-security.com/kali-linux-vmware-virtualbox-image-download/.

2. Now that you have the Kali Linux image downloaded, you need to extract the VMDK. We used 7z via CLI to accomplish this task:

3. Since the VMDK is ready to import now, you will need to go into VMware Fusion and navigate to File | New. A screen similar to the following should be displayed:

4. Click on Create a custom virtual machine. You can select the OS as Other | Other and click on Continue:

5. Now, you will need to import the previously decompressed VMDK. Click on the Use an existing virtual disk radio button, and hit Choose virtual disk. Browse the VMDK. Click on Continue. Then, on the last screen, click on the Finish button. The disk should now start to copy. Give it a few minutes to complete:

6. Once completed, the Kali VM will now boot. Log in with the credentials we used with the Raspberry Pi image:

Username:root
Password:toor

7. You need to then change the default password that was set to make sure no one can get into it. Open up a terminal within the Kali Linux VM and use the following command:

Passwd<INSERTPASSWORDHERE>

8. Make sure the software is up to date, like you did for the Raspberry Pi. To accomplish this, you can use the following commands:

apt-get update
apt-get upgrade
apt-get dist-upgrade

9. Once this is complete, the laptop VM is ready to go.

Now that we have reached the end of this chapter, we should have everything that we need for the penetration test. Having had the scoping meeting with all the stakeholders, we were able to get answers to all the questions that we required. This included engagement questions and scoping criteria. A deliverable from the stakeholders after the scoping meeting should have included any documentation that you would find beneficial for the penetration test. We typically require a network diagram, organization chart, and any important data flow diagrams.

Once we completed the planning portion, we moved onto the preparation phase. In this case, the preparation phase involved setting up Kali Linux on both the Raspberry Pi as well as setting it up as a VM on the laptop. We went through the steps of installing and updating the software on each platform, as well as some basic administrative tasks.

In Chapter 2, Information Gathering, we will start diving into the information gathering task. In this task, we will look at the various types of information to investigate, and where to look for additional information. We can't always rely on the stakeholder documentation being correct, and there may even be undocumented systems that even they don't know about. It is our job to find those systems. We will use various tools to get this information in order to help us understand the security and systems in place so that we know where to start the penetration tests later.