One of the most interesting phases of any penetration test (pentest) is the actual exploitation of the discovered vulnerabilities. Exploitation is used not only to verify that the vulnerability exists (rather than a false-positive), but is also a stepping stone to gaining visibility and access to hosts or data not initially accessible.
In any pentest, it is important to scope the environment under investigation, and address the bounds of any possible exploitation. This is often driven by the technical understanding of the client's nominated contact and their level of "ownership" of the environment.
Clients need to understand clearly that exploitation is the single most dangerous part of a pentest and has the highest probability of crashing or adversely affecting the performance of the host under investigation. One of the most common "unexpected" causes of systems being damaged during a pentest, prior to the exploitation phase, is through standard port scanning procedures. It doesn't happen often, but can stop a service from operating or even crash the host or networking appliance.
Given the dangers, it is crucial that appropriate procedures are established between the client and the pentesters to control when, where and what type of exploitation may take place. In most cases, vulnerability exploitation would only be required against high or critical risk vulnerabilities. Having discovered such a vulnerability in earlier phases of the pentest (such as service enumeration or vulnerability probing), my standard procedure would be to contact the client's technical contact. If exploit material is available for the vulnerability, the consultants will explain how exploitation would occur and detail the consequences of exploitation.
For many classes of vulnerability, exploitation simply involves altering standard data submissions and gaining non-interactive access to host data (such as directory recursion of file paths and URLs to pull back copies of the password file). The impact on host stability is minimal and, in the worst cases, exploitation might create temporary files on the host that must be removed by a system administrator after the pentest.
However, one class of vulnerability represents the greatest security threat to the host – "buffer overflows." These often enable attackers to inject their own code into the service and spawn other processes, such as interactive command shells. Exploit code used by consultants is often designed to create an interactive command shell with administrator level permissions and is used both to investigate the file system of the compromised host and prepare the host as a jump point into other areas of the networked environment.
I therefore always inform clients of the likely dangers to service integrity and discuss any previously agreed limitations on the exploitation. In most cases, exploitation is scheduled for out-of-hours or against test systems. Mutually agreed post exploitation limitations often include no installation of tools on the compromised host, no access to private and confidential client data on the host, and no creation of backdoors or additional user accounts.
While all pentesters enjoy "rooting the box," care must be taken to identify all the other vectors that a malicious attacker could use to compromise the environment's integrity. Some pentesters spend days trying to get one piece of exploit code to work against a particular host – totally neglecting all the other hosts within their scope.
If the consultant is lucky, the test will dig up some interesting information that can be used to compromise further hosts (such as gaining access to the password file and discovering accounts and passwords). Regardless of what the test exposes, both the consultant and the client should evaluate the value of the time needed to exploit a particular vulnerability versus enumerating additional attack vectors.
One last word of advice for pentest clients – evaluate the skills of the pentesters to understand and evaluate the exploit code they intend to use. For many consultants, their primary hunting grounds for exploit material are popular hacking websites or forums. It is not uncommon for such sources of material to contain hidden elements such as backdoors and Trojans. Too often, pentest consultants lack the development experience and familiarity of assembler languages to identify safe "shell code" from malware.
