Entries in Nmap (3)


Nimbus Protocol Enumeration with Nmap

CA Unified Infrastructure Management, previously known as Nimsoft, is a powerful IT monitoring solution that allows for management of numerous servers across a Nimsoft domain. This solution communicates using a closed source protocol known as “nimbus”. The complexity of a Nimsoft domain can be high, but the basic idea is to deploy Robots (the software agent) on all of the servers you want to be part of the Nimsoft domain in order to remotely manage them. Additionally, the following terminology might help familiarise yourself with the solution…

Domain - The Nimsoft domain is the logical descriptor that makes up many servers formed in a hierarchical structure. The domain is made up of Hubs and Robots.

Robot - Every managed server that has Nimsoft installed on it will be known as a Robot. The Robot manages all Probes that can be configured.

Hub - As part of a hierarchical architecture, a Hub is also a Robot but has the ability to manage child Robots in a tree-like structure.  A Hub manages a group of Robots and maintains central services.

Probe - The specific program created that runs on a Robot. For example, there is a Hub probe that turns a Robot into a Hub.

Primary Hub - This is the first choice Hub for a given Robot. A Robot can have many parent Hubs, and the Primary is where most messages get sent.

(For additional Nimsoft terminology see:

When a Robot is installed, the service listens on TCP port 48000 by default. This high port is used for communication within the Nimsoft message bus, using the nimbus protocol. The protocol is quite complex, but what we will be looking at is what might be revealed to an unauthenticated user on the local network.

I’ve created an Nmap enumeration script that executes 4 commands with the nimbus protocol in order to gather as much relevant information as possible about the Nimsoft Robot and Domain.

  • get_info - This command reveals details about the hostname, IP address, and Nimsoft domain. In addition, the specific details on the operating system, including the Service Pack, and architecture are also disclosed.

  • _status - This command is used to acquire the specific software version of the Robot running on the server, and includes specific details regarding the SSL implementation and version.

  • gethub - This command can be used to map out the network and identify the Hub that the Robot is communicating with. It also displays information such as the IP address and name of the Primary Hub. It can be useful for mapping out a Nimsoft Domain and internal network.

  • probe_checkin - This request is similar to the “gethub” request and reveals detailed information about the Robot including its name, SSL mode, and Hub information. It also includes details of the Primary Hub.


When this script is run against a target host running a Robot, Nmap is able to fingerprint the target server quite effectively. The collected information includes:

  • Operating system (including service pack)

  • Server architecture

  • Server hostname

  • Nimsoft domain name

  • Nimsoft network information, including the IP addresses of the parent Hub and Primary Hub

Below is an example run against Nimsoft Snap, the lightweight trial edition, running on Windows Server 2012 R2 (I’ve also successfully tested on Windows XP SP3, and Windows 7 SP1).

$ nmap —script nimbus-info -n -Pn -p 48000
Starting Nmap 6.46 ( ) at 2015-01-11 13:24 GMT
Nmap scan report for
Host is up (0.00045s latency).
48000/tcp open  unknown
| nimbus-info:
|   status:
|     [..Nimbus Enumeration Details..]

Nmap done: 1 IP address (1 host up) scanned in 0.09 seconds

Adding this Nmap script is quite simple. It can be copied either to your local directory and executed there or to the Nmap scripts directory. If you are running Kali, that is located within the /usr/share/nmap/scripts directory. Once this is finished, the new script will automatically be added when Nmap is executed with the —script argument. For reference, the Nmap search path for executing script is as follows:

  • —datadir


  • ~/.nmap (not searched on Windows)

  • the directory containing the nmap executable

  • the directory containing the nmap executable, followed by ../share/nmap


  • the current directory.

(See for more information)

The source code is available for download at the following URL: 

Hopefully this was of interest and helps you on your nimbus network enumeration!


NTLM Information Disclosure: Enhanced Protocol Support

Expanding on our previous blog post detailing NTLM information disclosure over HTTP, we’ve released six additional Nmap scripts to support this method among other common protocols that support NTLM authentication.  The new supported protocols include MS-SQL, SMTP, IMAP, POP3, NNTP, and Telnet.

Similar to the HTTP NTLM information disclosure script, these function with identical behavior and provide the same output.  The example below demonstrates usage of the MS-SQL script which leverages the MS-TDS protocol:

$ nmap –p1433 ––script ms-sql-ntlm-info

Nmap scan report for
Host is up (0.040s latency).
1433/tcp open ms-sql-s
| ms-sql-ntlm-info:
|  Target_Name: ACTIVEDB
|  NetBIOS_Domain_Name: ACTIVEDB
|  NetBIOS_Computer_Name: DB-TEST2
|  DNS_Domain_Name:
|  DNS_Computer_Name:
|  DNS_Tree_Name:
|_ Product_Version: 6.1 (Build 7601)
Service Info: OS: Windows; CPE: cpe:/o:microsoft:windows

Utilizing such information is useful for network reconnaissance as the information disclosed may be used as part of more complex attacks, such as leveraging domain information for brute forcing accounts, identifying internal hostnames during external to internal pivoting activities, or determining end-of-life operating systems.

These scripts have been tested against all current/past versions of Microsoft SQL, SMTP, IMAP, POP3, NNTP, and Telnet.  The HTTP NTLM script (http-ntlm-info.nse) has been committed into the Nmap source.  All other scripts have been submitted and are awaiting commitment.

The scripts along with documentation have been published on the GDS Github repository at the following location:


HTTP NTLM Information Disclosure

Remote enumeration of host/service details is a core activity of any penetration test. In support of such activities, we’ve released a new Nmap script that anonymously enumerates remote NetBIOS, DNS, and OS details from HTTP services with NTLM authentication enabled.

NTLM authentication is supported over HTTP, and is often used to protect application content and resources from unauthorized access. As part of the HTTP NTLM authentication process, a series of challenge-response messages are exchanged. By analyzing the encoded NTLMSSP information contained within specific messages, potentially sensitive information can be enumerated from remote hosts.

Host information can be enumerated using NTLM over HTTP in a manner similar to NTLM authentication over SMB, in which remote host information can be enumerated by sending anonymous credentials. By sending a NTLM authentication request with null domain and user credentials (passed in the ‘Authorization’ header), the remote web server will respond with a NTLMSSP message (encoded within the ‘WWW-Authenticate’ header) and disclose information including NetBIOS, DNS, and OS build version.

While this is not an active exploit, it’s extremely useful for network reconnaissance: the information disclosed may be used as part of more complex attacks, such as leveraging domain information for brute forcing accounts, identifying internal hostnames during external to internal pivoting activities, or determining end-of-life operating systems.

Lets see how this works using the script we’ve written for Nmap:

#nmap -p443 —-script http-ntlm-info

Nmap scan report for
Host is up (0.040s latency).
443/tcp open https
| http-ntlm-info:
|  Target_Name: ACTIVEWEB
|  NetBIOS_Domain_Name: ACTIVEWEB
|  NetBIOS_Computer_Name: PRODWEB001
|  DNS_Domain_Name:
|  DNS_Computer_Name:
|  DNS_Tree_Name:
|_ Product_Version: 5.2 (Build 3790)

Service Info: OS: Windows; CPE: cpe:/o:microsoft:windows

Since this script is considered default/safe, it will also run automatically when the ‘-sC’ or ‘-A’ flags are utilized.

During penetration testing such configurations are often encountered, and unfortunately are often passed over by many due to a lack of understanding the protocol and the type of information that can be anonymously enumerated. So how common are such web server configurations? Utilizing Shodan, below quantifies the number of internet facing web servers supporting NTLM authentication over HTTP and HTTPS:

Web Server Type HTTP HTTPS
Microsoft-IIS/5.0 (Windows 2000 Server) 4,342 1,067
Microsoft-IIS/5.1 (Windows XP) 1,945 151
Microsoft-IIS/6.0 (Windows Server 2003) 70,784 42,768
Microsoft-IIS/7.0 (Windows Server 2008) 13,790 8,241
Microsoft-IIS/7.5 (Windows Server 2008 R2) 47,235 34,493
Microsoft-IIS/8.0 (Windows Server 2012) 6,934 2,591
Microsoft-IIS/8.5 (Windows Server 2012 R2) 883 533
Microsoft Other (e.g. WinCE, etc.) 1,352 28
Unknown & Open Source Implementations 3,438 2,111
Total 150,703 91,983

*Note, does not account for hosts with both anonyous and NTLM authentication enabled

Currently, outside of disabling NTLM authentication over HTTP, there is no method to mitigate leaking such information under Microsoft IIS — all versions are affected by design.

This script, ‘http-ntlm-info’, has been tested against all current/past Microsoft IIS versions and open source HTTP NTLM implementations. It can be obtained here or via the current Nmap Subversion repository (r32706 or higher).

Note: If adding the script manually, the ‘nmap —script-updatedb’ command will need to be issued (as root/admin) to update the local script database.