We all know that end users hate complex passwords and having to change passwords often leads them to use the same password but add a number or character at the end of it. Password complexity is just one of the problems.
The next problem is information disclosure such as leaving a default Outlook on the Web page details showing (Domain\Username) as the login or exposing the Exchange Admin Center (EAC) to the internet.
In my lab, I created a bunch of users, User1 to User10 with passwords that are used everyday such as “Fall2020”, “Password1”, “P@ssword12” and others to show you how easy these are to attack. This lab was put together to assume enumeration was done, usernames and/or naming convention found and now just a case of brute forcing the accounts will provide a successful combination.
Even though I had the passwords, I still used the “rockyou.txt” wordlist that probably had these (lots of lines in the file) in Kali that successfully cracked the account passwords. I also performed the same kind of attack using BurpSuite, Msfconsole with the owa_login and owa_ews_login modules.
Let’s go through each one to show the options and the outcome.
Msfconsole
We will look at the owa_login auxiliary module, there are a few things that need to be set for it to work:
- use auxiliary/scanner/http/owa_login
- set RHOST tlab.local
- set USER_FILE /usr/share/wordlists/users.txt
- set PASS_FILE /usr/share/wordlists/rockyou.txt
- run
What we are doing is loading the module that we want to use which is “auxiliary/scanner/http/owa_login”. After that we need to set the RHOST and then the Username/Password options and point them to the files we want to use, below is a screenshot of the options:
Even though this module is for OWA_2013 and 2016, it works well with OWA_2019 (Exchange 2019).
Once we happy with all the options set, we can run the module, it took a little while to go through all the users but the passwords were cracked, here is a snippet of the output:
Let’s move onto the other module which is “owa_ews_login”. The same options were set except this one had an RHOSTS option and not RHOST but you can just check the options to see what needs to be set. The output shows that an NTLM service was found for the domain at /ews and again it successfully logged in after a while:
One thing to take note of here is that this is very noisy, meaning it will flag the security event logs on the server as you can see below:
The Workstation Name is random, each EVENT ID 4625 has a different value in. Let’s move onto BurpSuite.
BurpSuite
In BurpSuite, we enable out proxy to capture the traffic and ensure that our browser has FoxyProxy configured and running and then we intercept the traffic and once that is done, we send the request to the Intruder Module as shown below:
Here we choose the Attack Type of “Cluster Bomb” as we want to specify two payloads: Username and Password. The two fields highlighted in green will be the placeholders to insert the information we define.
For Payload 1, we load all the usernames and for Payload 2, all the passwords and then we attempt to attack it.
As you can see below, the information we define will be attempted against each account multiple times until we get a hit. We can see that tlab\user1 Length is large meaning it has more data in and this shows us a few things such as Server, Cookie, X-Owa-Version, FEServer etc.
The information above looks promising, so if we open up OWA and use the first set of credentials, we can login successfully.
You can see that an unsuccessful login has a different Length with less information in:
You may think, well these are just user accounts. Yes they are and with this information at hand, we can elevate our privileges, eventually leading to domain compromise, data theft, etc.
These are just some of the ways in which you can brute force accounts, others including Hydra can be used as well.
Conclusion
Information disclosure, weak passwords, re-used passwords, open URL’s such as the Exchange Admin Center gives attackers an opportunity to gain access to your environment. Password complexity, VPN, Captchas, MFA etc. should all be taken into consideration to ensure that your environment and users are protected.
Hope it helps.
