How can I make nmap run the HTTP-scripts on ports that are unusual for HTTP, say TCP port 123? On something like nmap -n --script="http* ..." -p123 target nmap does nothing except to check that port 123 is open and runs no scripts against the port. (I verified that with nmap's tracing options.)

Is it HTTP? The version scan does not recognize the nature of the service but the fingerprint output is very clear about that:

  • What does nmap tell you if you launch an application version scan (-sV) toward this port? As far I can see in the provided fingerprint, the HTTP server (if it is really one) is not very verbose (to say he least) since he does not seem to disclose any relevant information in its headers... Apr 28, 2015 at 9:47
  • 1
    Nmap says 123/tcp ntp?. Browsing to http://target:123 (after convincing the browser to do so) shows indeed that there is a web server. Apr 28, 2015 at 9:52

5 Answers 5


The other answers here are very good. However, there are a couple ways to do what you want that will work without editing the scripts:

  1. You can teach Nmap to recognize this service. Nmap's service fingerprints are in the nmap-service-probes file. Nmap already recognizes some versions of MiniShare with this match line, added in Nmap 6.00:

    match http m|^HTTP/1\.1 200 OK\r\nContent-Type: text/html\r\n\r\n.*<title>MiniShare</title>\r\n.*<td class=\"total\" colspan=\"2\">Total: (\d+) files</td><td class=\"totalsize\">([^<]+)</td></tr>\r\n</table>\r\n<hr><p class=\"versioninfo\"><a href=\"http://minishare\.sourceforge\.net/\">MiniShare ([\d.]+)</a>|s p/MiniShare http interface/ v/$3/ i/$1 files, $2 shared/ o/Windows/ cpe:/o:microsoft:windows/a

    But your service responds a little differently, and does not match. Please follow the instructions Nmap provides to submit this service fingerprint so that other users will benefit. In the meantime, you can construct a similar match line so that the service will be identified as "http" with -sV and the script will run.

  2. As a general rule, you can try updating to a newer version of Nmap. At the time of this writing, 6.47 was the latest version, so this won't help you, but it may help someone reading this answer later.

  3. You can force NSE scripts to run against all open ports by prepending a "+" to the script name. For example, --script +http-title will try to request a page and retrieve the title for every open service on the target. This can be dangerous and slow because the scripts were not written to be run against arbitrary services, and may time out or crash the target services.

One final warning: requesting --script http* will try to run a lot of scripts that you may not intend, including (in the development version): 23 "exploit", 1 "dos" (denial of service), 51 "intrusive", and 10 "external" category scripts. A better way to specify this would be --script "http* and safe" or --script "http* and default"

  • 1
    I am aware of the point of your warning. Usually I use something like http* and not (brute or dos or external). +1 and accept for +. Apr 28, 2015 at 13:09
  • I just tried that out: --script='(+http* and not ...)' works as desired! Apr 28, 2015 at 13:15

Simply use the + character before the script name to force execution of a script. Emphasis mine:

There are two special features for advanced users only. One is to prefix script names and expressions with + to force them to run even if they normally wouldn't (e.g. the relevant service wasn't detected on the target port). The other is that the argument all may be used to specify every script in Nmap's database. Be cautious with this because NSE contains dangerous scripts such as exploits, brute force authentication crackers, and denial of service attacks.

So if I run the command

# nmap -p 22 --script=+http-title.nse -d

this will force the "http-title" script to run against port 22:

NSE: Starting runlevel 1 (of 1) scan.
NSE: Starting http-title against
Initiating NSE at 14:14
NSE: Finished http-title against
Completed NSE at 14:14, 0.03s elapsed
Nmap scan report for localhost (
Host is up, received localhost-response (0.000089s latency).
Scanned at 2015-04-28 14:14:07 BST for 0s
22/tcp open  ssh     syn-ack
Final times for host: srtt: 89 rttvar: 5000  to: 100000

In your last test result, the question mark ("ntp?" instead of "ntp") tells that nmap was not able to recognize the running service. He therefore guess NTP only relying on the kind of service usually associated to this port number, but without any confidence at all (hence the question mark).

The headers sent by this service are very minimalistic:

HTTP/1\.1 400 Bad request
Content-Type: text/html

And that's it. On real web server, you would find a bunch of header telling the date, server's name, cache parameters, etc. Here, there is just nothing.

My guess is that you are therefore not facing a full fledged web server, but either:

  • A specifically crafted web server, like a remote administration interface embedded in some device,
  • An obfuscated web server (following our discussion in the comments below),
  • Another service relying on HTTP protocol (a web service, a WebDav server, etc.), trying other HTTP requests than the usual GET may trigger interesting behavior in such cases.


To answer more precisely your question, Nmap is a general tool, its scripts are mainly useful against non obfuscated servers as an easy way to get basic information.

Here, the admin did specific effort to obfuscate his server aiming precisely to hide the information needed by such general tools. It is therefore required to go a step further and use more specific tools.

From a technical point of view, nmap scripts are designed to be run only when necessary. HTTP related script will only be executed when a service is identified as HTTP by nmap. This is done by the portrule= statement you will find in the beginning of the scripts, here are a few example coming from random HTTP nmap scripts:

portrule = shortport.http    
portrule = shortport.port_or_service( {80, 443}, {"http", "https"}, "tcp", "open")

 A dirty way for instance would be to edit these script to force their execution... but with no guaranteed result. Better use the right tool for the right task.

  • I tell you, there is a webserver, the admin just had funny ideas... Apr 28, 2015 at 10:11
  • Well, if the admin is funny, you will have to funnier... httprint is a tool designed to fingerprint obfuscated web servers, you can also find advices on dedicated web page on the OWASP project. Do not hesitate to tell us the results ;) Apr 28, 2015 at 10:18
  • I know httprint and what it does. But this was not the question. The question was whether I can invoke nmap scripts for a certain service on ports that are usually not even remotely associated with this service. Apr 28, 2015 at 11:12
  • OK, to avoid a length comment I will edit my answer, stay tuned ;) ! Apr 28, 2015 at 11:23
  • Ahh... now we're getting somewhere. +1 Apr 28, 2015 at 11:49

This is the same as what hitting the port directly in a browser will give you, it's a text/html document! with stylesheet and a 400 status code, transmitted over HTTP 1.1.

400 Bad Request
    The server cannot or will not process the request due to something that is perceived to be a client error (e.g., malformed request syntax, invalid request message framing, or deceptive request routing)

If you wanted to find out more information about what it's running, i'd go directly there with a browser and see what other information you can gleam. Maybe from just after where you've snipped it at


There are quite a few HTTP scripts you could run from here, depending on what info you want to get about the web server, in the format of:

nmap --script http-enum -p 123 x.x.x.x

Source: https://nmap.org/nsedoc/scripts/http-enum.html

Edit: Given that it's referencing minishare.css style sheet, you'd probably want to start finding out if it's this: http://minishare.sourceforge.net

  • Your suggested nmap invocation has no noticeable effect. Nmap still "believes" that there must be some ntp service running as nmap's answer is 123/tcp ntp?. Apr 28, 2015 at 9:59
  • N.B. The 400 HTTP response is due to nmap's service discovery attempts which are taylored to NTP, not HTTP. As I told in a different comment, there is a webserver running. Apr 28, 2015 at 11:08

Set "portrule = shortport.http"

Open http-enum.nse to find the relevant line.

Read the documentation here: https://nmap.org/nsedoc/lib/shortport.html

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .