August 24, 2016 | Posted in Red Teams by Barrett Adams
One of the staples of any external penetration test is a single-password brute force attack against single-factor remote access portals. To start, we gather a list of likely usernames or emails (whatever the targeted portal requires) and use a single password such as “Summer2016” or the client name to make one login attempt per username. This style of attack helps mitigate against accounts being locked out from incorrect guesses and surprisingly goes under the radar of most detection rules.
Compiling the list usually involves pulling names from sites such as LinkedIn, Data.com and Google, then formatting those names to match the target company’s username or email format. Email addresses end up all over the place, so email formats are usually easy to find. Usernames can be harder—our go-to source is document meta-data. Unless every single pdf and Office document is sanitized when published, some usernames will make it into the meta-data. Just go to File > Info in Office, or File > Properties in Adobe Reader to see if any usernames are listed. There is also a quick Chrome plugin PDF Meta Data that can help or many ways to script this type of information gathering.
During a typical engagement, we will gather a list of perhaps a couple hundred usernames and maybe 1-5 of those will have the common password we guessed. The accounts we gain access to may not have much access to company resources; our main goal being remote access portals that provide internal network access such as Citrix or a VPN. This is where extracting the Global Address List (GAL) from Office365 or OWA comes in. Almost all employees are going to have access to a corporate email account, and lots of companies use Microsoft’s OWA. If we can pull the entire list of company users from OWA and run another brute force attack, we will have a much better chance of gaining access to an interesting account.
Figure 1 – Global Address List (GAL) found in Office365 or OWA
One might assume that there’s an export feature somewhere, but no such luck here. This is where some creativity is required. In Burp Proxy, we can see a request with the parameter action=FindPeople. The response is a section of the contacts list.
Figure 2 – “action=FindPeople” found in Burp Proxy (click image to enlarge)
This request has 2 parameters that are particularly interesting: Offset:0 and MaxEntriesReturned:50. A quick glance at the response confirms that this is the beginning of the users list and that 50 users are returned. So if we change MaxEntriesReturned to 1000? Then we get 1000 users back. Now we can just iterate through Offset values in steps of 1000 until the app doesn’t return any more users.
It’s worth mentioning that sometimes this request data gets sent in a header like above, and other times it will land in the actual POST body. The parameters are exactly the same either way, however.
Burp will export responses as a folder of text files, as which point a little bit of Python will pull out all the data we want:
The most obvious recommendation is to not have singlefactor logins to sensitive resources on the Internet. Multi-factor authentication (MFA) should be enabled for access of O365 and OWA as well as any other employee portals especially VPNs or Citrix. Without a place to log in, credentials are worth a whole lot less to an attacker.
Next is monitoring and defensive controls. In order to detect this type of an attack, the logs from OWA or O365 should be monitored with IDS/IPS or sent to a centralized SIEM. Conducting a quick purple team exercise that simulates this type of single-password guess attack and then developing the proper rulesets within your SIEM to alert based on this type of anomalous behavior. It may take some tuning depending on your toolsets, but worth the effort especially if an MFA upgrade is still on the roadmap.
We also recommend implementing a password blacklisting solution that prevents users from choosing the most easily guessable of passwords. This means preventing passwords like “Spring2016” which would otherwise meet typical Active Directory complexity requirements.