Introduction

Any offensive security operator will tell you that guessing employee credentials is key to compromising your customer’s network – and subsequently highlighting vulnerabilities during penetration testing engagements. The thing is, it’s easier said than done as companies increasingly continue to transition to cloud services such as Microsoft Office 365 (O365) – all of which provide multi-factor authentication (MFA) and other auxiliary security controls.

It used to be easy to compromise a user's account while targeting Microsoft Exchange. All an operator had to do was discover a client’s Exchange server, enumerate usernames, and password spray until their heart was content. This isn't nearly as easy as it used to be, however.

The new, but old methodology

New Technology LAN Manager (NTLM) authentication over HTTP endpoints are at the core of password spraying attacks. As testers and cyber-security pros, we need to dial in new and old but not defunct ways to compromise networks through this channel. We’re going to break down exactly how to do that.

First, let’s make sure we’re on the same page. NTLM over HTTP allows an employee to authenticate to internal Active Directory infrastructure. These NTLM endpoints are unseen and often forgotten about when reviewing the external attack surface of an organization.

Many Microsoft products unintentionally expose NTLM authentication endpoints in the form of web services. We want to look for these so we can avoid having to password spray Microsoft services (O365), bypass security controls, and ultimately show value to our clients.

Why NTLM over HTTP is a risk

At best, NTLM authentication endpoints over HTTP allow users and services to authenticate to internal Active Directory infrastructure to access company resources. The hosts that are often exposing NTLM over HTTP authentication endpoints include email services, restricted web portals, and many other Microsoft applications.

It’s common to find NTLM over HTTP authentication endpoints on the following web applications frameworks:

  • Microsoft RDPWeb
  • Microsoft Exchange
  • Microsoft ADFS
  • Microsoft Skype for Business

Companies routinely leave these services exposed to the world, either as part of their business needs or as a forgotten aspect of infrastructure they once used. Microsoft and federated identity providers (IdP) most commonly refer to those services/apps as legacy authentication endpoints. They call them that for a reason. Security controls can’t easily protect them and are an exposed risk for an organization.

How to identify NTLM over HTTP

We have quite a few tools at our disposal that allow us to discover NTLM over HTTP endpoints. I’m going to focus on one in particular that has been reliable throughout the years, ntlmrecon.

GitHub - pwnfoo/NTLMRecon: Enumerate information from NTLM authentication enabled web endpoints
A fast and flexible NTLM reconnaissance tool without external dependencies. Useful to find out information about NTLM endpoints when working with a large set of potential IP addresses and domains. NTLMRecon is built with flexibilty in mind.

https://github.com/pwnfoo/NTLMRecon

This tool provides us, as operators, with an easy way to scan multiple web applications collected during reconnaissance. The NTLMRecon author has collected a list of common endpoints. Here’s a snippet of this list:

/dialin
/ecp/
/Etc/
/EWS/
/Exchange/
/Exchweb/
/GroupExpansion/
/HybridConfig
/iwa/authenticated.aspx
/iwa/iwa_test.aspx


As an operator all we have to do is point this tool at a list of URLs and fire away using a command similar to the one below:

ntlmrecon -I urls.txt --outfile ntlmrecon.csv


The resulting CSV file contains not only discovered endpoints but also auxiliary information about internal Active Directory infrastructure we’ll need for password spraying attacks. An example of the output taken from the tooling itself is below:

https://contoso.com/EWS/,XCORP,EXCHANGE01,xcorp.contoso.net,EXCHANGE01.xcorp.contoso.net,contoso.net


Launching your attack

After you’ve identified a susceptible NTLM authentication endpoint, you’re free to start targeting it and attempting to guess valid user credentials. Note that modern authentication security controls – such as those listed below – don’t protect NTLM authentication over HTTP thoroughly.


Prior to launching your password-spraying attack, you’ll need to collect a list of usernames to use. Check out "Reliable Username Enumeration: A step-by-step guide," to learn more.

If you find an Exchange server, you can target OWA, ActiveSync and Autodiscover endpoints to validate the usernames you collected.



Take a deep dive into Spraycharles

We have a few tools at our disposal to use for password spraying attacks. My favorite is spraycharles.


GitHub - Tw1sm/spraycharles
Low and slow password spraying tool, designed to spray on an interval over a long period of time - GitHub - Tw1sm/spraycharles: Low and slow password spraying tool, designed to spray on an interval over a long period of time.

https://github.com/Tw1sm/spraycharles


Spraycharles is insanely powerful and very well written. It allows you to do the following:

  • Target EWS and other NTLM over HTTP authentication endpoints with simple modifications to the Ews.py file included with the project
  • Ensures you’re setting delay periods between sprays that lockout accounts
  • Looks for outliers in authentication attempt responses to determine if a valid login occurred
  • Easily proxy your traffic to evade IP-based security controls and rate-limiting

Looking at the EWS module

Navigating to the targets folder in the spraycharles project, we find the file Ews.py. The file contains code we’ll use to password spray a discovered NTLM authentication endpoint. Let’s take a look at the first 25 lines of code:

import requests
from requests_ntlm import HttpNtlmAuth
import csv

class Ews:

    def __init__(self, host, port, timeout, fireprox):
        self.timeout = timeout
        self.url = f'https://{host}:{port}/ews'

        if fireprox:
            self.url = f'https://{fireprox}/fireprox/ews'

        self.headers = {
            'User-Agent': 'AppleExchangeWebServices/814.80.3 accountsd/113',
            'Content-Type': 'text/xml; charset=utf-8',
            'Accept-Encoding': 'gzip, deflate, br',
            'Connection': 'keep-alive',
        }

        self.data = {
            'username': '',
            'password': ''

        }


Line seven of the code contains the endpoint we’ll target. As needed, feel free to change the /ews directory to whatever you’d like.

I’m working on a command line flag that let’s you specify this path on runtime but haven’t fully implemented it yet.



Following the specification of the URL the tooling crafts a request to mimic login attempts made by the Apple Mail application. Variables such as host, port, username and password are all specified on the command line at runtime, so don’t worry about that until later. If we skip further down into the file, we’ll find where the real magic happens. On line 51, we see the following code:

# post the request
response = requests.post(self.url, headers=self.headers, auth=ntlm_auth, timeout=self.timeout)#, verify=False, proxies=self.proxyDict)
return response


Using the library imported at the beginning of the script (requests_ntlm) we craft an NTLM authentication POST request and issue it to the specified server. Templated code later in the script then returns and parses the response. Note that all failed login attempts will result in a 401 Unauthorized error code and successful authentication will most often respond with a 500 error code.

The beauty of Spraycharles is we don’t have to worry about the response codes we receive. Instead, the tooling after completing a spray against a list of users looks for statistical anomalies in the output. That tooling then notifies you of any anomalies that stand out. Let’s see this tool in action to hopefully better show off its capabilities.

Spraycharles in action

Let’s get everything set up before we start our siege on NTLM. First, clone the project, and install dependencies using the command below. Note that pipenv is required for this install method.

git clone https://github.com/Tw1sm/spraycharles.git && cd spraycharles
pipenv --python 3 shell
pip3 install -r requirements.txt


Once the tool is installed, I like to create a directory named “client,” where I can store target-specific usernames and potential passwords. For the sake of demonstration, let’s create a client named ACME:

mkdir -p client/ACME


Copy the usernames you collected earlier and place them in a file titled “usernames.txt” in the ACME directory. Additionally, create a file named “passwords.txt” in the same directory containing passwords you want to use for your attack.

Getting a list of common passwords can be tough. Check out the file make_list.py and list_elements.json in the spraycharles project for help.


After you create the necessary files and install the project, you need to collect the following information:

  • Your target hostname or IP address
  • The Active Directory domain name collected using ntlmrecon earlier in this article

With that information, you can craft a command similar to the one shown below:

python3 spraycharles.py -H mail.acme.com -d ACME -m ews \
        -u ~/client/acme/usernames.txt -p ~/client/acme/passwords.txt \
        -t 500 -a 1 -i 45 --analyze 


I recommend you set an interval of at least 45 minutes between password sprays to prevent account lockouts.



Check out the tools documentation for details on what each command-line flag used means. Once you’re sure everything looks right, kick off spraycharles, approve the secondary prompt and you’re off to the races. What you see next should look something like this:

How to bypass MFA - Spraycharles

If, and when, a successful login occurs, you’ll see something similar to the following:

How to bypass MFA - Spraycharles Successful Login



Using Your Access: An Example

As outlined earlier, once you guess credentials using an NTLM authentication endpoint, you often have completely bypassed MFA solutions in use. My first step following account compromise is to attempt to dump the global address list (GAL) of the target organization. My go-to tool for completing this task is thumbscrew-ews:

https://github.com/sensepost/thumbscr-ews
A wrapper around the amazing exchangelib to do some common EWS operations. thumbscr-ews is a small Python utility used with Exchange Web Services.

https://github.com/sensepost/thumbscr-ews



How to Dump the GAL

This tool is extremely powerful and allows us to target both on-premise Microsoft Exchange servers and O365. For example, craft a command similar to the following to dump the GAL from an organization’s Exchange server:

thumbscr-ews -u sprocket@acme.com -p "Password1" -o --exch-host mail.acme.com gal -d


This command extracts a list of every user. You can then leverage those users to continue password spraying. This is important as the more accounts you compromise, the more likely it is you’ll find an account with greater permissions or information that could lead to internal network access.

Let’s say, however, you encounter an error:

How to bypass MFA - Dump the GAL

Error handling in this tool can be a little cumbersome and confusing. But, we get an interesting piece of information here that you can see at the bottom of the screenshot above:

exchangelib.errors.ErrorNonExistentMailbox: No mailbox with such guide.


This means the account doesn’t have a mailbox stored in Exchange and likely only uses Office 365 for mail services. Thankfully, thumbscrew-ews has you covered. Simply modify your command to look something like the following:

thumbscr-ews -u sprocket@acme.com -p "Password1" -o --exch-host outlook.office365.com gal -d


With this command, we can target O365 directly instead of Exchange. More often than not, this works even if an MFA solution is in place for O365. Note that one of everyone’s favorite MFA solutions on the market is vulnerable to this bypass:

How to bypass MFA - DUO


Following this, parse your GAL output and again start your password spray. This almost always leads to additional account compromise in our experience.

Bringing it together

The attack outlined above is one of many that involve NTLM authentication endpoints. In later articles, we’re going to outline other attacks you can perform and how you can leverage compromised credentials to show impact.

So, wrapping it up, what are the key takeaways?

  • Legacy authentication endpoints are dangerous and expose your organization to unwanted risk.
  • MFA bypasses are possible even in the modern security landscape.
  • Disable unused authentication endpoints to reduce your attack surface wherever possible.

If you’re concerned about the possible exposure of legacy authentication endpoints, or the ability to bypass MFA at your organization, reach out any time.





About the Author

Nicholas Anastasi, penetration tester

As an Offensive Security Certified Professional (OSCP), Nicholas is focused on pushing the boundaries of clients’ networks, ensuring they are protected against the latest attacks and vulnerabilities. He joined Sprocket in early 2019 and has a particular interest in cloud technologies and DevOps. Email him at nanastasi@sprocketsecurity.com