Category: Nmap

BlueTeam, CredSSP, Information Security, Nmap, RDP, Windows

Using Nmap to extract Windows host and domain information via RDP

Posted on by Tom Sellers

I’ve recently spent some time in various code bases working on Windows RDP related discovery. This post is going to talk about using a new Nmap script, rdp-ntlm-info.nse, against RDP services to discover the target’s hostname, domain name, DNS name, and version.

3389/tcp open     ms-wbt-server Microsoft Terminal Services
| rdp-ntlm-info: 
|   Target_Name: W2016
|   NetBIOS_Domain_Name: W2016
|   NetBIOS_Computer_Name: W16GA-SRV01
|   DNS_Domain_Name: W2016.lab
|   DNS_Computer_Name: W16GA-SRV01.W2016.lab
|   DNS_Tree_Name: W2016.lab
|   Product_Version: 10.0.14393
|_  System_Time: 2019-06-13T10:38:35+00:00

This post was updated 2019.06.14 to reflect that the script had been committed to the official repo, update the usage instructions to reflect this, and include the NSEDoc link for the script.

This post was updated 2019.06.18 to indicate that users of 7.70 need updated nselib/datetime.lua as well.

Continue reading →

0
Information Security, LDAP, Nmap, RedTeam, TLS

Bypassing Active Directory restrictions against creating users over insecure LDAP connections

Posted on by Tom Sellers

In 2011 I spent a little time working on improvements [1] in Nmap’s LDAP code. At some point during the work I stumbled across a way to work around Active Directory’s requirement for a secure connection when creating users via LDAP. This may be useful when abusing testing an Active Directory environment where your only access is over LDAP without TLS support. I’d meant to write this up at the time but didn’t. I recently had to recreate the process so I thought I’d create a blog post as a form of documentation.

Continue reading →

0
Information Security, Nmap, SHA-1, SHA1, TLS

Using Nmap to find x509 (SSL/TLS) certificates that have SHA-1 and MD5 based signatures

Posted on by Tom Sellers

 

 

 

A couple of months ago there was quite a bit of press about Google and Mozilla becoming more aggressive about how they handle x509 (SSL/TLS) certificates that have SHA-1 based signatures. The background for this is linked in the references section at the end of this post. In short, the SHA-1 cryptographic hash algorithm is considered too weak to be safely used as part of the public web PKI.

The impact for site operators and network security teams is that over the next two years browser users will begin to see warnings that indicate that a site is secure but with errors when it uses a SHA-1 certificate that expires after January 1, 2016.  Sites will be flagged as insecure if the SHA-1 certificate expires after January 1, 2017. This is something that requires action now as certificates are generally bought or generated with at least a one year life but in many cases organizations are using 2, 3, or 5 year certificates.

Continue reading →

0