To perform DoS attacks using the exploit database, follow the given steps:

1. Prior to using the exploit database to perform DoS testing, we will need to identify which DoS exploits are available. The total exploit database can be found online at http://www.exploit-db.com. Alternatively, a copy is locally stored in the Kali Linux filesystem. There is a files.csv file within the exploitdb directory that contains a catalog of all the contents. This file can be used to grep for keywords to help locate usable exploits:

2. In the example provided, the grep function was used to search the files.csv file for any exploit database contents that could be identified by the word SMB. It is also possible to narrow down the search even further by piping the output to another grep function and searching for an additional term:

3. In the example provided, two independent grep functions are used in sequence to search for any DoS exploits that are related to the SMB service:

4. We can continue to narrow down the search results to be as specific as possible. In the example provided, we have looked for any Python DoS scripts for the SMB service, but we looked for those that are not for the Windows 7 platform. The -v option in grep can be used to exclude content from the results. It is usually best to copy the desired exploit to another location to not modify the contents of the exploit database directories:

5. In the example provided, a new directory is created for the script. The script is then copied from the absolute path that can be inferred by the directory location of the exploit database and the relative path defined in the files.csv file. Once relocated, the script can be read from top to bottom using the cat command and then piping the content of the script over to the more utility:

6. Unlike the NSE scripts and Metasploit auxiliary modules, there is no standardized format for scripts within the exploit database. As such, working with the exploits can sometimes be tricky. Nonetheless, it is often helpful to review the contents of the script briefly for comments or explanation of usage. In the example provided, we can see that the usage is listed in the contents of the script and is also printed to the user if the appropriate number of arguments is not supplied.
7. After evaluation, the script can be executed as follows:

8. However, after attempting to execute the script, we can see that problems arise. As a result of the lack of standardization and because some of the scripts are only proofs of concept, adjustments often need to be made to these scripts:

9. After the script errors out, we will need to return to the text editor and attempt to determine the source of the errors. The first error indicates a problem with the location of the Python interpreter that is listed at the beginning of the script. This must be changed to point to the interpreter in the Kali Linux filesystem:

10. It is often a good idea to attempt to run a script again after each problem is resolved, as sometimes fixing a single problem will eliminate multiple execution errors. In this case, after changing the location of the Python interpreter, we are able to successfully run the script:

11. When the script runs, several messages are returned to identify the progress of the script execution. The final message indicates that the malicious payload was delivered and that the server should have crashed. The success of the script can be verified by referring back to the Windows server, which has now crashed and is displaying a BSOD: