OWA accounts with 2FA enabled report Invalid creds even when password is correct
halfluke opened this issue · 4 comments
I'm testing the tool against my organization email address, hosted on Office365.
I know the password is correct but SprayingToolkit reports:
[*] Trying to find autodiscover URL
[+] Using OWA autodiscover URL:...............
... OWA domain appears to be hosted on Office365
[-] Error parsing internal domain name using OWA. This usually means OWA is being hosted on-prem or the target has a hybrid AD deployment
Do some recon and pass the custom OWA URL as the target if you really want the internal domain name, password spraying can still continue though :)
Full error: Input seems to be a non-valid base64-encoded string: 'Basic Realm=""'
....(Invalid credentials)
If I disable 2FA, credentials are reported as correct.
Interesting and good to know! From what I've seen there isn't a way to determine if a specific account has 2FA enabled from the server's response when authenticating to OWA (unlike S4B\Lync) which why it currently reports the password isn't correct.
That being said if someone knows if there is a way to determine this from the response, feel free to submit a PR.
I tested a little in the past few days and I noticed you get a status code 456 when 2fa is enabled, so I just added a line to owa.py to handle that case. But I also found out that 456 is returned in other cases, for example when an account is blocked (but still, the password is correct).
456 is different from the old office365enum.py, for example, which expected a 403 forbidden in case of 2fa (and it also uses a different endpoint for requests).
I noticed spraying toolkit uses the same endpoint as the "ruler" project, which is wirtten in Go, for the office 365 query.
It's just a couple of lines of python to handle the new case. As I'm going on vacation I can try to submit a PR in the next days if you wish
@halfluke that would be great! Thanks for the info!
Closing since #16 should now handle this.
Thanks again!