So, this post is inspired by some very interesting research done by @mubix that you can read about here, as well as this amazing post by Tim Medin here. After reading Mubix’s post, I was whipped into a frenzy and purchased several domains. I realize that these posts are both several years old, but this idea has been kicking around in my head since 2016, sometimes it takes a while to work things out.

Before I go into details, I also want to be sure to say this: 

I DID NOT ATTEMPT ANYTHING MORE THAN LOGGING AGAINST ANY OF THE DOMAINS I REGISTERED FOR THIS RESEARCH, EXCEPT FOR SCENARIOS WHERE ALL MACHINES WERE MY PROPERTY.

From Mubix’s research it became obvious to me that in a network that allowed Server Message Block (SMB) to egress, this was a huge problem in its own right, but what about all of the other networks that didn’t allow SMB to egress. In addition, some ISPs that drop that traffic since Conficker. I came up with several scenarios that I will detail, but first, one quick bit to add to Mubix’s post and in general: If you need to know a Domain Controller in an environment from an external context, you can look no further than sniffing an NTLM authentication request from their Exchange Web Services (or any other NTLM endpoint, there are lots). As an example:

nmap
-p 443 --script http-ntlm-info --script-args
http-ntlm-info.root=/EWS/Exchange.asmx <base OWA URL>

Sometimes, various controls might filter on the nmap user-agent, or you may want to see the full decode of the NTLM authorization header yourself. I’ve posted some quick and dirty python scripts to Github that can help with that, you can find those here.

Attack Scenario 1 – WSUS

So, the setup for this scenario is a machine in a network with a predictable WSUS server hostname. Microsoft’s WSUS documentation uses WSUS01, so that was the domain that I picked up, but it could really be anything. I understand that this is a pretty niche attack, and that getting your hands on an internal WSUS hostname from an external network context might be a bit tricky, but it can be done. If the machine were set up to use WSUS01 as its update server, I wondered what the DNS lookups looked like when that machine was off the corporate network and was looking for the WSUS01 host. It turns out that the issues identified in Mubix’s and Tim’s posts back in the day show up here. Logging the DNS requests for WSUS01.com, I started to see things like this:

At this point, I configured my personal WSUS server and established a group policy to set the WSUS server to a hostname that I controlled. I then denied network access to the actual WSUS server. Once that was complete, I set up an HTTP listener to see if any web requests would result from a successful DNS response, which resulted in seeing this:

This opened up something interesting. Could you respond to the web request with an NTLM authentication challenge and gather credentials? Here is the result:

It turns out, you can. If you are planning to try some of this on your own, you can use responder to provide the NTLM authentication request, but you will want to make some modifications so that it can listen on multiple ports. Make your Responder.py Browser Listener section the same as below and you should be all set.

I’m not sure what conditions affect the following change, but on occasion I have observed that the NTLM challenge could result in the presentation of the machine account’s hash, which I am guessing is because of the Windows Update client operating under the SYSTEM account’s context.

The impact of these findings would be the exposure of a password hash that would be subject to offline attack. Privilege escalation possibilities exist should the machine account hash be passed without signing, or if NTLMv1 was negotiated, an attacker could leverage a service such as this to obtain the NTLM hash. An attacker could then create a Kerberos ticket for various services on that victim host.

Further Research

There are several other scenarios where this condition can be leverage by an attacker. Those conditions will by detailed in future blog posts. Hopefully sooner than 3 years from now.   

Microsoft Disclosure Timeline

To ensure that due diligence was performed, this issue was disclosed to Microsoft.

• Initial Disclosure: 9/8/19
• Initial Response: 9/12/19
• Case Closed: 9/20/19

Their response was, “Our engineers have completed their analysis of your report, and while this doesn’t meet our bar for servicing with an Update Tuesday security release, the team will look to improve the design of WSUS and the Windows Update client.”