RSS Feed

Entries in Pentesting (8)


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:


BadSamba - Exploiting Windows Startup Scripts Using a Malicious SMB Server

May 6, 2015 Update 

It looks like the guys over at Metasploit have put in some hard work and integrated “BadSamba” into the Metasploit Framework. Now known as “Group Policy Script Execution From Shared Resource”, you can find it under the Windows SMB modules as “group_policy_startup” (which rolls off the tongue a bit better!). 

Additional improvements to Metasploit, introduced in March, include a new mixin that simplifies hosting of files on SMB shares for exploit modules. This greatly simplifies writing exploits that require any form of SMB share to store files, and as you can see from the module changes, it makes it much more elegant.  

Find the latest updated module on GitHub: 


Windows Group Policy can be used to configure startup scripts that will execute each time the operating system starts up. These scripts execute with a high-level of privilege, the NT AUTHORITY\SYSTEM account, per the TechNet documentation:

“Startup scripts are run under the Local System account, and they have the full rights that are associated with being able to run under the Local System account.”

The scenario for this post includes a startup script running from a remote server using an SMB share. Typically it is not possible for an attacker to control the SMB share—if that were the case this post wouldn’t exist! But if an attacker is able to perform any form of man-in-the-middle attack or traffic redirection, such as DNS spoofing, it is possible to host a SMB server that will serve up malicious files in order to gain remote command execution as NT AUTHORITY\SYSTEM.

Finding Local Startup Scripts

As part of any post-exploitation process or host review, all startup scripts should be reviewed to determine the possibility for an elevation of privilege. One technique is to use the autoruns utility, part of the Sysinternals suite. This will also display Group Policy startup scripts which is our focus here.

In the lab setup, we have a Windows 7 (SP1, x86) machine that has a startup script, startup.vbs that is run each time the system boots. As part of this demonstration no DNS spoofing will be performed (for simplicity) so the script will point directly to a remote SMB share located at, a Kali Linux machine.

In the image below, we can see that the startup script is configured to run from a remote network share. Note that even though it indicates “File not found”, the system will still attempt to run the script when Windows starts. 

Introducing BadSamba

After seeing a similar scenario wherein a script was being run from a remote SMB share, this got me thinking… Would it be possible to spoof the SMB server? If the client asks for startup.vbs could I then send it evil.vbs of my choosing? Could I then further accept any form of authentication in order to trick the Windows system?

From this idea the concept of BadSamba was born, a simple malicious proof-of-concept SMB server that is built to exploit this very scenario in order to gain remote command execution as SYSTEM.

BadSamba has the following two requirements:

  • Accept any form of authentication - anonymous, domain, blank password, non-existent accounts. It will allow any user to connect to the SMB server and access any share.

  • File spoofing - serve the same file regardless of what file was originally requested, and regardless of which SMB share the client is connected to. If the user requests foo.vbs we will send them evil.vbs instead.

With these requirements, I have created an auxiliary Metasploit module to demonstrate this proof-of-concept that allows for any authentication, connection to arbitrary SMB shares, and reading files from the SMB server.


Within the Windows 7 system (, we have already identified that the startup.vbs script will execute from the remote SMB share when the operating system starts up.

Start Metasploit on Kali ( and load the BadSamba server, setting the FILE to notepad.vbs. This file simply executes notepad.exe in order to demonstrate that the commands being executed are in fact being run in the context of NT AUTHORITY\SYSTEM.

notepad.vbs file:

Dim oShell

Set oShell = WScript.CreateObject (“WScript.Shell”) “C:\windows\system32\notepad.exe”


After running the module and once the Windows 7 machine is restarted it successfully authenticates and connects to the malicious SMB share. A request for startup.vbs is then made, and we serve up our notepad.vbs. This is downloaded and executed by the target machine under the NT AUTHORITY\SYSTEM account as can be seen by inspecting the running tasks within the operating system.

Now that we have verified the module works, and that we can execute privileged commands, let’s create another VBScript file that will add a user account, also added to the Administrators group.

evil-user-add.vbs file:

Dim oShell

Set oShell = WScript.CreateObject (“WScript.Shell”) “cmd.exe /c net user hacker Password123 /ADD && net localgroup Administrators hacker /ADD”

Again we set the FILE setting to our malicious script, run the exploit server and restart the Windows 7 system.

As we can see the file was successfully downloaded by the target machine. Now to verify it executed successfully:

The hacker account has been created and added to the Administrators group!


  • BadSamba has been tested using .bat and .vbs remote script includes. The file extension does seem to matter, so if it’s requesting a .bat, serve up a .bat.

  • In the lab environment, testing has been against Windows 7 SP1 (English) for the proof-of-concept. Different versions of Windows may react differently, but the principal concepts should remain the same.

  • It’s not currently possible to “Browse” the files within the SMB share. This is due to the complexity of the SMB protocol, and adding this functionality would greatly increase the complexity of the module.

  • The protocol is quite noisy, and so it can be difficult to determine if the file was successfully downloaded or if it was download and executed.

  • Currently there is no exclusive lock on files being requested, and this allows for the file to be downloaded multiple times. In my experience, it only gets executed once, but it does make for noisy output within the module.

Lessons Learned & Tips

  • The SMB protocol is one of the noisiest protocols I’ve ever looked at. The number of requests required just to establish a connection to a share and download a file is much higher than I would have ever anticipated! This module requires 9 distinct request/responses, granted some of those are very simple such as an SMB ping.

  • When running multiple commands in VBScript, the most consistent way I have found is to execute cmd.exe and use the && operator instead of multiple .run commands.

  • When setting up an SMB server, pay special attention to the “capabilities” bits that are sent during the negotiation phase. For similar modules, I recommend:

0x0080000d # UNIX extensions; large files; unicode; raw mode

  • When working with SMB, use the Wireshark dissector to determine what is being parsed accurately. I’ve included resources for the protocol below, but Wireshark was essential to building this module.

  • Every version of Windows, and different tools or commands, use the SMB protocol differently. When testing with Windows XP, and Windows 7, even the “type” command of a remote share was different than using the Windows Run dialog, and even the Windows Explorer Address bar. Keep this in mind when playing with Windows SMB, as you have to target specific environments and functionality.

  • This almost goes without saying, but do try your scripts out on the local test environment before attempting to execute them remotely. VBScript and Batch don’t necessarily have the most intuitive syntax.

References & Resources

Source Code


Introducing Windows Exploit Suggester

February 22, 2017 Update

This post provides an update on two topics regarding Windows Exploit Suggester—a best usage guide and some minor updates/changes recently made to the script.

Exploit References

I’ve now added information about specific exploits (where applicable) directly in the command output. This data was always present for more recent vulnerabilities, but required the user to view the source of the Python script to find it. I’ve finally added this so that it can save a bit of time when looking for references to current exploits. This is the default, but it can be removed with the —quiet/-q flags.

Hardcoded MS11-011

Second, MS11-011 is now hard-coded to be ignored for the following versions of Windows. This is due to the bulletin database not being updated when the web bulletin was updated.
“V1.2 (March 18, 2011): Added Windows 7 for 32-bit Systems Service Pack 1, Windows 7 for x64-based Systems Service Pack 1, Windows Server 2008 R2 for x64-based Systems Service Pack 1, and Windows Server 2008 R2 for Itanium-based Systems Service Pack 1 to Non-Affected Software. This is an informational change only. There were no changes to the security update files or detection logic.”

Reduce Output

Moving on to some general usage. A couple things that create the idea of false-positives are that the script assumes EVERYTHING is installed on a Windows system. So, it will flag .NET vulnerabilities, Telnet, WebDAV, IIS, etc. even though they aren’t present in the system. This is the nature of parsing the database and one way to narrow this down is to use the —local/-l and —remote/-r flags to identify exploits that you actually care about and want to use.

Patch Validation

Finally, sometimes a client states they already have a patch installed. This is usually in reference to a specific bulletin, for example, MS16-075. Now we can actually just get a list of relevant security update numbers by using the -p/—patches flag.

$ ./ -d 2017-02-09-mssb.xls -p ms16-075
[*] initiating winsploit version 3.2…
[*] database file detected as xls or xlsx based on extension
[*] searching all kb’s for bulletin id MS16-075
[+] relevant kbs [‘3164038’, ‘3163018’, ‘3163017’, ‘3161561’]
[*] done

We can use these KB number to cross-reference with the patchlist provided in the systeminfo output to validate a false-positive.This still assumes that the output from the systeminfo command is accurate, and in reality this is not always the case. You can feed in the “wmic qfe list full” command output in with the —hotfixes flag to manually force a list of hotfixes that might otherwise not appear in the systeminfo output.

Any questions, let me know!

Introduction (July 11, 2014)

Privilege escalation is an art form that revolves around information gathering, and enumeration of the target host. The idea is to find the quickest, and easiest way to escalate from a local user account to that of an Administrator. A common method for escalating is using a known exploit to target a vulnerability exposed on the unpatched host. This method is probably the fastest, and with the right information and toolkit of precompiled exploits and Metasploit modules, it is a quick win during any engagement. 

Let’s assume you have access as a local user to a partially patched Windows 7 Service Pack 1 machine. Are there any public exploits available? Which one do you run? Which exploits work with 32-bit and 64-bit architecture? Are there any Metasploit modules available to gain that coveted Meterpreter session? These questions can all be answered by manually reviewing the missing patches, and comparing that to the public exploits. Unfortunately, that is exceedingly time-consuming and thus unrealistic, this is why I sought to automate the process.

After searching online for a Window’s “exploit suggester” tool, I was surprised to find that none existed! Without further ado, I introduce “Windows Exploit Suggester” or for short “winsploit”, a tool created to automate the privilege escalation exploitation process targeting unpatched systems. This script takes, as input, the Microsoft Security Bulletin Database which is available free to download and is updated constantly by Microsoft.

It also needs the “systeminfo” command output on a target Windows host. Typically a low-privilege user is able to execute the “systeminfo” command, and when assessing the patch levels of a target host, it can provide a wealth of information (including hotfixes applied!).

Finally, it cross-references the previous information to that of a static list of Metasploit modules and publicy available proof-of-concept exploits for each bulletin number. When this information is combined, the end result is the ability to quickly analyse whether or not a target Windows host is vulnerable to many publicly available exploits.

Setup & Usage

You can find this tool on GitHub under the Windows-Exploit-Suggester repository. The tool is written in Python 2.7 and requires the xlrd library (for Excel spreadsheet parsing). This is most easily installed using pip.

$ pip install xlrd –upgrade

Alternatively, it can be downloaded from the website directly ( I was unable to use the version in the Ubuntu 12.04 repositories as it was incompatible, so had to use pip directly. 

Once the dependencies have been met, we will download the Microsoft Security Bulletin Database using the —update flag. This flag just scrapes the bulletin database from Microsoft and saves it as a local Excel file and will serve as our local bulletin database.

Once we get the local database file downloaded, we will need some “systeminfo” command output from our low-privilege user. I am using an example build from a Windows 7 Service Pack 1 32-bit machine in this scenario. Once I’ve gathered this data, I’ll run the tool against it, and include the Microsoft Bulletin database file.

Looking at the raw output, there are plenty of exploits to pick from! We can weed through the client-side attacks, assuming we’re not interested in Internet Explorer bugs at this time, and focus in on MS13-053. This exploit is quite reliable, and is better known as the pprFlattenRec exploit ( The best thing about it is that it’s in Metasploit!

Everything this tool does could be done manually, but it has the ability to act as a quick solution when escalating privileges on a Windows host. I have found it helpful in many instances, especially when new bulletins come out and new Metasploit modules get released.

This tool also has the ability to tell you about any exploits possible about a target operating system. For example, lets say we want to know all of the public exploits available for a Windows 2008 R2 Server Itanium. This can be achieved with the —ostext flag, which is a loose representation of the operating system, service pack, and architecture (defaults to 32-bit).

This feature is really useful when you are able to fingerprint a target’s operating system and want to know if any Remote Code Execution bugs exist. Although not necessarily privilege escalation, it is a relevant feature to the tool.


As with any automated tool, there are always limitations. These are some that I have identified through the use of the tool and it’s capabilities.

1 DAY ONLY — Of course this relies on known bulletins, exploits, and bugs but for an unpatched host it is a quick-win that can speed up the effectiveness of privilege escalation. It requires an entry to be present within the Microsoft Security Bulletin database, and with unsupported software (XP), these entries won’t exist! 

FALSE POSITIVES — The command output also assumes that you have every feature in Windows. For example, it will flag vulnerabilities relating to IIS even if IIS is not present on the machine! It assumes that it is a fully-featured Windows installation with all services so some intelligent manual filtering will have to be made when looking for an exploit.

INACCURATE SYSTEMINFO — There is also the presence of “File 1” entries in the ‘systeminfo’ command output which will skew the results because it cannot detect the relevant hotfixes. If there are “File 1” entries, additional commands will have to be executed to gather the hotfix data (querying the system registry directly, or using wmic). Once this data is collected it can be fed into the tool using the —hotfixes flag.


In summary, targeting an unpatched host is but one method of privilege escalation, and this tool makes that process much faster for Windows hosts. Time is essential when performing assessments, so any edge can really help. Please feel free to contact me regarding any bugs, comments, concerns, or feature requests so that I can take a look at them and make the tool even better! 


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.