will also want to be sure to determine the external IP addresses and domain names of systems to pentest. This is critical to verify as you do not want to try to exploit an external address not owned by the customer.
First-party versus third-party hosted
As I mention earlier in this chapter, you need to verify where the targets are being hosted, whether by the customer (first party) or by an outside company (third party). If systems are hosted by a third-party company such as an ISP or cloud provider, you need to get authorization from the third party to perform the pentest on those assets.
Other targets
When performing a penetration test, in addition to identifying the IP addresses of the hosts you are going to perform the penetration test on, you should also identify the following resources:
Applications: Determine what applications and services are in scope of the penetration test. Some common applications and services may be the intranet site, Internet site, email services, remote desktop services, file transfer protocol (FTP) service, internal websites, and external websites.
Physical security controls: Determine if testing the physical security controls is in scope of the pentest. This includes social engineering attacks on security guards, exploiting surveillance equipment, and testing locking systems with a lock pick or bump key.
SSIDs: Determine if there are wireless networks that you are authorized to exploit. Make sure you find out what wireless networks, or SSIDs, are owned by the company that are in scope of the pentest.
Users: Determine what user accounts are in scope for password cracking. Be sure to determine if you are allowed to attempt to compromise administrative accounts as well.
Target considerations
When working on exploiting target systems, applications, and services, you must make different considerations when conducting a white box test versus a black box test. With a white box test, the company will grant the pentester access to the system by allowing the pentester to pass through any security controls, but with a black box test, the pentester will need to figure out how to bypass the security controls as part of the test.
Here are some considerations to keep in mind when performing the pentest on the identified targets:
Whitelisted versus blacklisted: As a pentester you can seek to have your system whitelisted by security controls so that the system is not blocked when performing the assessment. A blacklisted system, which is a system that is blocked by a security control, can slow down the assessment dramatically.
Security exceptions: You can add the pentester’s IP address or account to security exceptions within security controls so that the pentester is not blocked. For example, on a firewall you can add the pentester’s IP address to the firewall exception list so that the pentester’s traffic can pass through the firewall.
IPS/WAF whitelist: You can add the pentester’s IP address to the whitelist on the intrusion prevention system (IPS) and the web application firewall (WAF) so that it is not blocked and the pentester can test the web application.
NAC: The customer may have network access control (NAC) features implemented that only allow devices in a secure state to connect to the network. As a pentester, this could affect your capabilities to connect to the network and perform the pentest. You may have to be placed on an exception list so that you can access the network from your pentest system.
Certificate pinning: Certificate pinning refers to the process of associating a host with the expected server it will receive certificates from. If the certificate comes from a different system, the communication session will not occur. You may need to disable certificate pinning on the network to allow communication.
Company’s policies: You should review the company security policy to determine if there are any policies in place that would put limits on the actions the penetration testers can take.
Technical constraints: Be aware of any technical constraints that may limit your capabilities to perform the penetration test. For example, there may be firewalls blocking your scans during discovery of targets or there may be network segments controlling communication.
Environmental differences: When performing the penetration test, it is important to be aware of any differences in the environment, as any differences could change how the pentest tools respond. Be aware of export restrictions when it comes to crossing borders with any encrypted content and any other local and national government restrictions that may be in place with regard to encryption and penetration testing tools. When performing a pentest on large global companies, know that the laws are different in these different companies with regard to using pentest tools. Also, review any corporate policies so that you are aware of the pentesting rules.
Special scoping considerations: There may be other special scoping considerations that may arise during the pre-engagement phase, such as premerger testing and supply chain testing considerations. Premerger testing refers to assessing the security of a business the company is going to acquire. Supply chain testing refers to assessing the security of a supplying company, or multiple supplying companies, before the customer does business with those companies.
Verifying Acceptance to Risk
Earlier in this chapter, I discuss the importance of including a disclaimer in the SOW, and I want to stress again that as the penetration tester, you need to make the risk of performing a penetration test clear to the customer (in discussion and in the contract). Make sure the customer accepts those risks before starting the penetration test, as risk acceptance is critical to protecting yourself from legal action.
Some key points to communicate with the customer in relation to the acceptance of risk of the penetration test are:
Tools are used to try to compromise the security of the company’s systems.
Although you have tested the tools and are using tools that have not crashed your test systems, the tools could have unpredictable results in different environments due to different software and configurations that you may not have had in your test environment.
Stress that although you will not try to crash systems, the risk is there that systems may crash.
Verify that the customer has recent backups of the systems being assessed.
It is also important to verify the customer’s tolerance to the impact the assessment will have on the company’s systems. Here are some questions you can ask to verify the customer’s acceptance of the impact of the assessment:
Is the customer aware and okay with the fact that you are hacking into the company’s systems when performing the penetration test?
Does the customer accept that the system may fail if you run exploits against the system? If the customer is not willing to accept the crashing of a system, you may want to do a vulnerability assessment instead of a penetration test. The vulnerability assessment will review the configuration of the systems and run a vulnerability scan to determine how exposed the system is, but not actually try to hack the system.
If a system fails due to the penetration test, how long will it take to recover a failed system?
How long can the business survive without the asset or system in question? How much downtime is the customer willing to accept if it does occur?