Importance of signing in Windows environments, (Fri, Jan 20th)

Windows logo - 2012
File:Windows logo – 2012.svg

NTLM relaying has been a plague in Windows environments for many years – and we have witnessed many exploits that rely on the fact that it is possible to relay NTLM authentication attempts to various target services.

While there are many potential targets here, in most red team engagements my colleagues and myself are relaying credentials to other SMB, LDAP or HTTP(S) services (especially on AD CS server, used for issuing certificates). So one of the mandatory “health check” activities should be to verify if your systems really have signing enabled. Here are two *very simple* ways on how I do it when I encounter large number of internal assets.

(1) Nmap for help

For verifying status of SMB services, nmap is really all you need (and my previous students of SEC542 can witness on me being a big fan of nmap scripts). While there are quite a bit of SMB scripts that we can use, the one we want is the smb2-security-mode.nse script, which will check SMBv2 security settings (if you are still running SMBv1 then you have another set of problems: disable it).

Running this script is amazingly easy on any size of target network(s), simply scan target assets on ports 139 and 445 and verify the results.

Here is one well configured server:

$ nmap -sT -p 139,445 --script smb2-security-mode
Starting Nmap 7.80 ( ) at 2023-01-19 21:31 CET
Nmap scan report for
Host is up (0.015s latency).

139/tcp open  netbios-ssn
445/tcp open  microsoft-ds

Host script results:
| smb2-security-mode: 
|   2.02: 
|_    Message signing enabled and required

This one not so much (almost there, but notice that signing is not required):

$ nmap -n -v -Pn -p 139,445 --script=+smb2-security-mode
Nmap scan report for
Host is up (0.0014s latency).

139/tcp open  netbios-ssn
445/tcp open  microsoft-ds

Host script results:
| smb2-security-mode: 
|   2.02: 
|_    Message signing enabled but not required

(2) Testing HTTP/S on AD CS server

While there could be other cases to abuse with HTTP/S servers and NTLM relaying, in this diary I’ll just limit testing to the AD CS server, since it is the most often abused target service. Testing in this case is quite simple and can be performed even with the curl command.

You need to find the AD CS server and them simply issue a request to the http://adcs/certsrv URL. You need to use the -v flag to display response headers as we will want to see which authentication mechanisms are supported:

$ curl -v -k http://adcs/certsrv
*   Trying
* Connected to adcs ( port 80 (#0)
> GET /certsrv HTTP/1.1
> Host: adcs
> User-Agent: curl/7.68.0
> Accept: */*
* Mark bundle as not supporting multiuse
< HTTP/1.1 401 Unauthorized
< Content-Type: text/html
< Server: Microsoft-IIS/8.0
< WWW-Authenticate: Negotiate
< WWW-Authenticate: NTLM
< Date: Thu, 19 Jan 2023 20:16:35 GMT
< Content-Length: 1293

401 - Unauthorized: Access is denied due to invalid credentials.

body{margin:0;font-size:.7em;font-family:Verdana, Arial, Helvetica, sans-serif;background:#EEEEEE;}
fieldset{padding:0 15px 10px 15px;}
h3{font-size:1.2em;margin:10px 0 0 0;color:#000000;}
#header{width:96%;margin:0 0 0 0;padding:6px 2% 6px 2%;font-family:"trebuchet MS", Verdana, sans-serif;color:#FFF;
#content{margin:0 0 0 2%;position:relative;}

401 - Unauthorized: Access is denied due to invalid credentials.

You do not have permission to view this directory or page using the credentials that you supplied.


The two important lines here are the following (also highlighted above):

< WWW-Authenticate: Negotiate
< WWW-Authenticate: NTLM

< indicates that this is a response header and as we can see, this server is supporting both NTLM and Kerberos authentication. A properly configured server should not have the second line in the response (WWW-Authenticate: NTLM).

Can it be simpler than this? So why aren’t you testing your systems already? Here’s a nice weekend project ?

Next time we’ll go over myriad of LDAP settings, which is another channel that gets abused quite often.


(c) SANS Internet Storm Center. Creative Commons Attribution-Noncommercial 3.0 United States License.

Reposted from SANS. View original.

Alex Post