Password Spraying Outlook Web Access – How to Gain Access to Domain Credentials Without Being on a Target’s Network: Part 2

Beau Bullock //

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 that 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 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). Organizations 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 log in 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:

• Be extremely mindful of lockout thresholds! If you submit too many bad passwords in a given amount of time you are going to lock accounts out. Without being on the target network it is impossible to know exactly what the domain account policy enforces.
• That being said, by default Windows default domain account policy does not enforce a lockout of any kind. This means that technically you could brute force any user’s password without locking them out. I have yet to run into an environment that does not have some sort of lockout policy. Very commonly I find that environments set their lockout policy to five (5) failed logins within a 30-minute observation window.
• Just use one password for spraying every two hours. This is a reasonable window that will likely not get you into a situation where you are locking out accounts.
• Be in close contact with your point of contact at the company to verify you are not locking anyone out.

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 VPNs, 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:

1. Locate publicly available files with FOCA on websites of the target organization.
2. Analyze the metadata from those files to discover usernames and figure out their username convention.
3. Craft a list of their entire possible username space.
4. Password spray against an external system that performs domain authentication (like Outlook Web Access) using the username list you generated.
5. Profit?

Recommendations:

• Analyze all of the documents your organization is hosting publicly for information leakage via metadata.
• Implement policies and procedures to scrub the metadata from anything that is going to be posted publicly.
• Watch your OWA and any other external authentication portals for multiple failed login attempts and password spraying activity.
• Create stronger password policies beyond the default 8 characters (we typically recommend 15 or more).
• Force users to use two-factor authentication. In the event someone does password spray a user if two-factor authentication is enabled they won’t gain access to much.