Together, passive and active reconnaissance identifies the attack surface of the target, that is, the total number of points that can be assessed for vulnerabilities. A server with just an operating system installed can only be exploited if there are vulnerabilities in that particular operating system; however, the number of potential vulnerabilities increases with each application that is installed.

Penetration testers and attackers must find the particular exploits that will compromise known and suspected vulnerabilities. The first place to start the search is at vendor sites; most hardware and application vendors release information about vulnerabilities when they release patches and upgrades. If an exploit for a particular weakness is known, most vendors will highlight this to their customers. Although their intent is to allow customers to test for the presence of the vulnerability themselves, attackers and penetration testers will take advantage of this information as well.

Other online sites that collect, analyze, and share information about vulnerabilities are as follows:

• The National Vulnerability Database, which consolidates all public vulnerability data released by the US Government, available at http://web.nvd.nist.gov/view/vuln/search
• Secunia, available at http://secunia.com/community/
• Packetstorm security, available at https://packetstormsecurity.com/
• SecurityFocus, available at http://www.securityfocus.com/vulnerabilities
• The Exploit database maintained by Offensive Security, available at https://www.exploit-db.com/
• For some 0-day vulnerabilities, penetration testers can also keep an eye on https://0day.today/

The Exploit database is also copied locally to Kali and it can be found in the /usr/share/exploitdb directory.

To search the local copy of exploitdb, open a Terminal window and enter searchsploit and the desired search term(s) in the command prompt. This will invoke a script that searches a database file (.csv) that contains a list of all exploits. The search will return a description of known vulnerabilities as well as the path to a relevant exploit. The exploit can be extracted, compiled, and run against specific vulnerabilities. Take a look at the following screenshot, which shows the description of the vs FTPd vulnerabilities:

A search of the local database may identify several possible exploits with a description and a path listing; however, these will have to be customized to your environment, and then compiled prior to use. Copy the exploit to the /tmp directory (the given path does not take into account that the /windows/remote directory resides in the /platforms directory).

Exploits presented as scripts such as Perl, Ruby, and PHP authentication are relatively easy to implement. For example, if the target is a Microsoft IIS 6.0 server that may be vulnerable to a WebDAV remote aupass, copy the exploit to the root directory and then execute as a standard Perl script, as shown in the following screenshot:

Many of the exploits are available as source code that must be compiled before use. For example, a search for RPC-specific vulnerabilities identifies several possible exploits. An excerpt is shown in the following screenshot:

The RPC DCOM vulnerability identified as 76.c is known from practice to be relatively stable. So, we will use it as an example. To compile this exploit, copy it from the storage directory to the /tmp directory. In that location, compile it using GCC with the command that follows:

root@kali:~# gcc 76.c -o 76.exe

This will use the GNU Compiler Collection application to compile 76.c to a file with the output (-o) name of 76.exe, as shown in the following screenshot:

When you invoke the application against the target, you must call the executable (which is not stored in the /tmp directory) using a symbolic link as follows:

root@kali:~# ./76.exe

The source code for this exploit is well documented and the required parameters are clear at execution, as shown in the following screenshot:

Unfortunately, not all exploits from the Exploit database and other public sources compile as readily as 76.c. There are several issues that make the use of such exploits problematic, even dangerous, for penetration testers, which are listed as follows:

• Deliberate errors or incomplete source code are commonly encountered as experienced developers attempt to keep exploits away from inexperienced users, especially beginners who are trying to compromise systems without knowing the risks that go with their actions.
• Exploits are not always sufficiently documented; after all, there is no standard that governs the creation and use of code intended to be used to compromise a data system. As a result, they can be difficult to use, particularly for testers who lack expertise in application development.
• Inconsistent behaviors due to changing environments (new patches applied to the target system and language variations in the target application) may require significant alterations to the source code; again, this may require a skilled developer.
• There is always the risk of freely available code containing malicious functionalities. A penetration tester may think that they are conducting a proof of concept (POC) exercise and will be unaware that the exploit has also created a backdoor in the application being tested that could be used by the developer.

To ensure consistent results and create a community of coders who follow consistent practices, several exploit frameworks have been developed. The most popular exploitation framework is the Metasploit framework.