Debug Nikto Scans for Troubleshooting

Introduction

Nikto is a popular open-source web server scanner that performs comprehensive tests against web servers for multiple items, including over 6700 potentially dangerous files/programs, checks for outdated versions of over 1250 servers, and version-specific problems on over 270 servers.

While Nikto is powerful, scans can sometimes fail, produce unexpected results, or require deeper investigation. In these situations, Nikto's debugging features are invaluable. They allow you to see the exact HTTP requests being sent and the responses received, helping you pinpoint network issues, server misconfigurations, or problems with the scan itself.

In this lab, you will learn how to use Nikto's debugging options to effectively troubleshoot and understand your web vulnerability scans.

Run a scan with the -debug option

In this step, you will perform a basic Nikto scan using the -debug option. This option provides a highly verbose output, showing the full details of every request sent by Nikto and the corresponding response from the server. This is the first and most crucial step in troubleshooting any scan.

First, ensure you are in the ~/project directory. We have already set up a simple web server running on 127.0.0.1 at port 8000 for you to scan.

Execute the following command to run Nikto with the -debug option against the local web server:

nikto -h http://127.0.0.1:8000 -debug

You will see a large amount of output scroll by. This is the debug information. It includes the standard Nikto scan results mixed with detailed request and response data.

A small portion of the output will look similar to this, showing the raw HTTP communication:

- Nikto v2.5.0
---------------------------------------------------------------------------
+ Target IP:          127.0.0.1
+ Target Hostname:    127.0.0.1
+ Target Port:        8000
+ Start Time:         ...
---------------------------------------------------------------------------
+ Server: SimpleHTTP/0.6 Python/3.10.12
+ The anti-clickjacking X-Frame-Options header is not present.
+ The X-Content-Type-Options header is not set. This could allow the user agent to render the content of the site in a different fashion to the MIME type
+ No CGI directories found (use '-C all' to force check all possible dirs)
DEBUG: User-Agent is 'Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/114.0.0.0 Safari/537.36'
DEBUG: Request -> 127.0.0.1:8000
GET / HTTP/1.1
Host: 127.0.0.1:8000
User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/114.0.0.0 Safari/537.36
Accept-Encoding: gzip,deflate
Accept: */*


DEBUG: Response -> 127.0.0.1:8000
HTTP/1.0 200 OK
Server: SimpleHTTP/0.6 Python/3.10.12
Date: ...
Content-type: text/html; charset=utf-8
Content-Length: 36
Last-Modified: ...

DEBUG: Received: <h1>Welcome to the Test Site</h1>

... (many more lines) ...

This detailed view is essential for understanding exactly what Nikto is testing.

Observe the detailed request and response information

In this step, you will take a closer look at the output generated in the previous step. The sheer volume of debug information can be overwhelming, so it's helpful to use a pager tool like less to review it.

Let's run the command again, but this time we will pipe the output to less. This allows you to scroll through the output one page at a time.

nikto -h http://127.0.0.1:8000 -debug | less

Once the output appears in less, you can use the following keys to navigate:

Arrow keys or j/k to scroll up and down.
Page Up/Page Down or spacebar to move by pages.
q to quit and return to the command prompt.

As you scroll, pay attention to these key parts of the debug output for each test:

DEBUG: Request ->: This section shows the exact HTTP request being sent, including the method (GET, POST, etc.), the URI, and all headers.
DEBUG: Response ->: This shows the server's response headers, including the HTTP status code (e.g., 200 OK, 404 Not Found).
DEBUG: Received:: This shows the body of the HTTP response from the server.

By examining this information, you can verify if the server is responding as expected, if a firewall is blocking requests, or if Nikto is interpreting a response correctly.

Press q to exit less when you are finished observing.

Redirect the debug output to a file for later analysis

In this step, you will learn how to save the verbose debug output to a file. For long or complex scans, analyzing the output in real-time is impractical. Saving it to a file allows for offline analysis, searching, and sharing with team members.

Nikto's debug information is sent to the Standard Error (STDERR) stream, while normal results go to Standard Output (STDOUT). To capture everything, you must redirect both streams to a file.

Use the following command to run the scan and save all output to a file named debug_output.txt:

nikto -h http://127.0.0.1:8000 -debug > debug_output.txt 2>&1

Let's break down the redirection part:

>: This is the standard output redirection operator. It sends STDOUT to debug_output.txt.
2>&1: This redirects STDERR (file descriptor 2) to the same place as STDOUT (file descriptor 1), which is our file.

After the command finishes, verify that the file has been created:

ls -l debug_output.txt

You should see the file listed in the output:

-rw-r--r-- 1 labex labex ... ... debug_output.txt

Now you can examine the contents of the file using cat or less:

less debug_output.txt

You now have a permanent record of the scan and its debug information for detailed review. Press q to exit less.

Use -dbcheck to check the syntax of scan databases

In this step, you will use the -dbcheck option. This is a diagnostic tool that doesn't perform a scan but instead checks the syntax of Nikto's internal databases and plugins. If Nikto is crashing, failing to start, or behaving erratically, running a database check is a good first step to ensure its own files are not corrupted.

The databases contain the definitions for all the vulnerability checks Nikto performs. A syntax error in one of these files could cause tests to fail silently or the entire program to crash.

To perform the check, run the following command:

nikto -dbcheck

Nikto will parse its plugin files and databases. If everything is correct, the output will confirm that no errors were found.

- Nikto v2.5.0
---------------------------------------------------------------------------
+ DBCheck: Parsing database '/var/lib/nikto/plugins/db_variables'
+ DBCheck: Parsing database '/var/lib/nikto/plugins/db_tests'
... (many more lines) ...
+ DBCheck: 0 error(s) found in database.

If errors were found, the output would point to the specific file and line number, which would help you fix the issue (or reinstall Nikto if necessary). This simple command can save a lot of time when troubleshooting the tool itself.

Troubleshoot a failing scan using the debug output

In this step, you will apply what you've learned to a practical troubleshooting scenario. We will simulate a common problem: a scan that fails because the target host is unreachable. Without debug output, the cause might not be immediately obvious.

We will attempt to scan a non-existent IP address on the local network, 10.255.255.1. We will also use -maxtime 10s to ensure the scan terminates quickly.

Run the following command:

nikto -h 10.255.255.1 -maxtime 10s -debug

Observe the output carefully. Because the host does not exist, Nikto will not be able to establish a connection. The debug output will clearly show these connection attempts and failures.

You will see error messages like this scattered throughout the debug log:

- Nikto v2.5.0
---------------------------------------------------------------------------
+ Target IP:          10.255.255.1
+ Target Hostname:    10.255.255.1
+ Target Port:        80
+ Start Time:         ...
---------------------------------------------------------------------------
+ Server: No banner retrieved
DEBUG: Request -> 10.255.255.1:80
GET / HTTP/1.1
Host: 10.255.255.1
User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/114.0.0.0 Safari/537.36
Accept-Encoding: gzip,deflate
Accept: */*


+ ERROR: Cannot connect to 10.255.255.1:80 (No route to host)
...

The key message here is ERROR: Cannot connect... (No route to host). This immediately tells you that the problem is not with the web server's configuration or a bug in Nikto, but a fundamental network connectivity issue. The scan is "failing" because the target is unreachable. This demonstrates how the -debug option provides the necessary context to quickly diagnose the root cause of a problem.

Summary

In this lab, you have learned the essential techniques for debugging and troubleshooting Nikto web server scans.

You started by using the -debug option to view verbose request and response data, giving you a clear picture of the scanner's actions. You then learned how to manage this output by redirecting it to a file for offline analysis. You also used the -dbcheck utility to verify the integrity of Nikto's own database files, a crucial step when troubleshooting the tool itself. Finally, you applied these skills to a real-world scenario, quickly identifying a network connectivity issue as the cause of a failing scan.

With these skills, you are now better equipped to diagnose and resolve issues, ensuring your Nikto scans are both effective and reliable.

Debug a Nikto Scan for Troubleshooting