This is a cross-post from the Black Hills Information Security blog. You can read it here: http://www.blackhillsinfosec.com/#!Password-Spraying-Outlook-Web-Access-How-to-Gain-Access-to-Domain-Credentials-Without-Being-on-a-Targets-Network-Part-2/c1592/56c1f10e0cf2365fef58cce1

This is part two of a series of posts (See part 1 here) where I am detailing multiple ways to gain access to domain user credentials without ever being on a target organization's network. The first method involves exploiting password reuse issues where a user might have reused the same password they used for their corporate domain account on another external service. The second method is what I think is a far more interesting way of gathering user credentials that involves discovering a target organization's username schema, followed by password spraying user accounts against an externally facing service that is hosted by the target organization (for example an Outlook Web Access portal). Other methods will follow these posts.

In part 2, I will detail how an attacker can discover a target organization’s username schema and perform password spraying attacks against an externally facing service. 

The Dangers of Metadata and Publicly Facing Authentication Services 

Very commonly on assessments we tend to look for documents that are hosted by a target organization, and are publicly available to download. The reason we do this is because we find that very commonly organizations do a very bad job of scrubbing the metadata attached to the items they post publicly. Some very interesting things can be found in the metadata that gets attached to files.

For example, if you take a photo with your cell phone and you have GPS enabled, many times that GPS location information will be attached to the picture itself. From an operational security perspective if you were to take a photo of a secure location and have GPS enabled, then posting that picture online might reveal the actual coordinates of the location you took the photo.

When we look at analyzing metadata of Word documents, Excel files, PDFs, PowerPoint  presentations, and more that organizations post publicly,  we find very often that we can actually gain access to computer names, folder structures, as well as user names of those that created the files themselves. A great tool for quickly finding metadata and analyzing it in publicly available files of a target organization is called FOCA.

You can download FOCA here: https://www.elevenpaths.com/labstools/foca/index.html

FOCA simply performs Google and Bing searches with the “filetype” parameter. You can provide Google with a search like the following to search for all of the PDF files associated with the “targetorganization.net” domain: “site:targetorganization.net filetype:doc”. If you provide FOCA a target domain it starts with the top level domain and will subsequently find other subdomains where potential files are located. FOCA will then download any of these files and analyze the metadata attached to the files.

On a recent engagement I ran FOCA against the domain of the target organization that I was testing. When I looked at the metadata that FOCA was able to gather from the files that were being hosted publicly I found a large number of what appeared to be user names. In fact, I was able to discover what appeared to be their actual naming convention. This naming convention did not appear to be a random or hard to guess at all. What I mean by that is that I was able to very easily craft a list of every possible combination of their username schema.

For example, imagine a username schema that starts out each username with the word ‘emp’, and then simply appends the three letter initials of the employee (abc). So a possible full username would be ‘empabc’. The total number of three-character permutations of the letters ‘a’ through ‘z’ is 17,576. So, to hit every possible username combination from ‘empaaa’ through ‘empzzz’ is 17,576. I generated a list containing each of the possible permutations.

Password Spraying Outlook Web Access

So, now that I had a list of possibly every username combination for the target organization what could I do next as an external attacker? Next, an external attacker would have to locate some sort of external service that performs domain-based authentication. One such service that does this that we find very often is Microsoft’s Outlook Web Access (OWA). Organization’s provide the ability for their employees to access their email remotely through services like OWA. The authentication that happens when a user logs into OWA is typically domain-based, meaning that the credential used to authenticate is checked against the domain for validity.

After locating an external OWA portal an attacker could brute force passwords, but will quickly lockout accounts if a lockout threshold is in place. A far more superior way of performing password attacks is called password spraying. Password spraying involves attempting to login with only one (very strategically chosen) password across all of the domain accounts. This allows an attacker to attempt many more authentication attempts without locking out users. For example, if I were to attempt to login to every account with the password ‘Winter2016’ it is very likely that someone at the target organization used that password and I will now have access to their account.

Some things to consider when performing an external password spray attack:

I once again used Burp Suite’s Intruder functionality to submit one login attempt for each possible username using one password. Performing a password attack in this manner limits the risk of locking out accounts as only a single login attempt is performed for each account. For example BHIS submitted the userID ‘targetorg\empaaa’ with a password of ‘Winter2015’. After this attempt the same password would be tried with ‘targetorg\empaab’, and continue on all the way to ‘targetorg\empzzz’.

To do this I first setup Burp Suite to intercept all of the requests leaving my browser. I attempted to login to the OWA portal with a userID of ‘targetorg\test’ and a password of ‘Testing123’. The POST request to the OWA portal looked like the following:

I then sent this request to Intruder. For this first example we will leave the attack type as ‘Sniper’. In Burp Intruder I specified only one payload position. The username is all that is going to change during the attack so this is where we add the payload position. The password will remain ‘Testing123’ or whatever you set it to be (I highly recommend season and year like ‘Winter2015’).

On the payloads tab I now imported the list of probable usernames I generated.

One thing I noticed was that Outlook Web Access responds to the POST request by simply setting a cookie in the browser and redirecting to the root “/” page. OWA did this for every login attempt regardless of whether the login was valid or not. So, in order for Burp to follow through with the authentication process we need to set one more setting before launching the attack. On the Options tab of Burp Intruder at the very bottom select the option to “Follow redirections” for “On-Site only”. Also, click the checkbox to “Process cookies in redirections”.

Starting the attack now one can see where Burp Intruder is following each of the redirects that occur during the authentication process to OWA. The only thing left to do is to sort by the length of the response as valid authentication attempts responded with a shorter response length. In the screenshot below OWA redirects four times before hitting a page indicating a successful login.

I ultimately was able to gain access to a large number of accounts via this technique. As can be seen in the screenshot below the requests that generated a response length of around 4371, and 1630 were valid user credentials. The requests that generated a response length of 12944 were failed login attempts.

In the scenario I’ve demonstrated above I was utilizing the ‘Sniper’ functionality in Burp. This was mainly to avoid account lockout and only change the userID field. Being in close contact with my target organization I knew what the actual lockout threshold was as well as the observation window. In order to maximize the effectiveness of my password spraying I utilized Burp Intruder’s “Cluster Bomb” attack. With the Cluster Bomb attack you can specify two payload positions. I selected the username and password fields as my payload positions.

Cluster Bomb will also allow you to specify two lists to use with each payload position. So I left the username position the same as previously with my list of potential users. I then crafted a list of 10 or so passwords that I thought would work nicely to password spray with.

 The Cluster Bomb attack will now iterate through all of the usernames with one of these passwords at a time. Once the spray is done for one password it will move onto the next. For example the spray would go through the entire username list with a password of Winter15, then after that spray is finished it would move onto Winter16. With my list of 17575 usernames the time it took to spray the entire list with one password was far out of the observation window in terms of lockout so I didn’t have anything to worry about there.

In the example I gave above I was currently assigned to perform an external network assessment and an internal pivot assessment for the target organization. After password spraying externally over the weekend before I was scheduled to begin the internal pivot assessment I gained access to a total of 130 valid user credentials. The target organization did not detect any of the password spraying activity through their external portal. It is probably safe to say that an attacker could password spray for weeks on end gaining access to many more accounts via this technique.

In this post I focused on password spraying against OWA specifically. There are many other services that this same type of attack could apply to. For example, an attacker can perform password spraying attacks against Microsoft RDP servers, SMTP servers, SSL VPN’s, and more. A great tool for doing this against most of these services is called Patator and can be found here: https://github.com/lanjelot/patator

Just to recap, the steps of this approach to gathering user credentials follow:

Recommendations: