Importance of signing in Windows environments

Published: 2023-01-20. Last Updated: 2023-01-20 09:29:29 UTC
by Bojan Zdrnja (Version: 1)

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 10.0.10.10 --script smb2-security-mode Starting Nmap 7.80 ( https://nmap.org ) at 2023-01-19 21:31 CET Nmap scan report for 10.0.10.10) Host is up (0.015s latency).

PORT STATE SERVICE 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 10.12.99.9 Nmap scan report for 10.12.99.9 Host is up (0.0014s latency).

PORT STATE SERVICE 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 10.0.10.5:80... * TCP_NODELAY set * Connected to adcs (10.0.10.5) 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 < <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> <html xmlns="http://www.w3.org/1999/xhtml"> <head> <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"/> <title>401 - Unauthorized: Access is denied due to invalid credentials.</title> <style type="text/css">  </style> </head> <body> <div id="header"><h1>Server Error</h1></div> <div id="content"> <div class="content-container"><fieldset> <h2>401 - Unauthorized: Access is denied due to invalid credentials.</h2> <h3>You do not have permission to view this directory or page using the credentials that you supplied.</h3> </fieldset></div> </div> </body> </html>

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.

--
Bojan
@bojanz
INFIGO IS

Keywords:

1 comment(s)