Password Spraying- Common mistakes and how to avoid them
When password spraying attacks are executed properly, coordinated and scoped properly during an authorized engagement — they can identify and illustrate the dangers of weak passwords and how extremely dangerous, even one legacy Internet facing endpoint can be.
Password spraying can lead to domain administrator before lunch. Remember you can password spray Windows hosts, and domain controllers internally too!
The SprayingToolkit is extremely powerful when targeting Microsoft services.
Password Spraying is a delicate form of brute forcing that has to be quiet to be effective without alerting the Blue Team, locking out accounts, or setting off security alerts.
But when used properly it can help you breach the perimeter.
Why is it still not working? I’ve followed all the steps!!! Not one single user has Winter2019 as a password?
- Stale Accounts
Maybe you have credentials but they can not do anything on the external VPN. You can spray a legacy endpoint, but if the user has no access to any external services the account might be close to worthless
2. Username/Endpoint Incorrect
Check your usernames — is the format correct? Are you sure you have the right format, the correct UPN and AD Domain? Are you targeting the right endpoint? The right VPN group or realm ?
3. Complex Passwords Enforced
It is possible, though highly statistically unlikely that proper password polices are unilaterally enforced and March2019 and P@ssw0rd can’t be used. This rarely extends to all Internet facing endpoints. Sometimes you just can’t spray with basic passwords and win.
4. MFA (Multi-Factor Authentication) Implemented
You have credentials now, but web mail is using MFA? OKTA? Duo? All legacy protocols might be no longer in use. You may need more than working credentials to log into the VPN.
Is WiFi in scope? Remember you have a working domain user and password which may work on a WPA2-EAP MSCHAPv2, credential only based wireless network.
Can you use those credentials to leverage any more of a foothold somewhere else on the network that’s not on the Internet?. Sometimes the answer might be no, it’s not in scope or it’s simply not possible with a username and password.
In closing it’s easy to supply a penetration tester a tool. We all know that Red Teaming and Penetration Testing is all about lateral thinking. The recent articles have been written by my peers serve as some of the cornerstone documentation and tooling when it comes to password spraying.
Through decades of experience I’ve found that with the content, tools, and know-how you still may run into environments where things aren’t working as intended.
Sans Guidelines for mitigating Password Spraying:
1. Web-based mailbox authentication sessions can remain active for up to 24 hours (ActiveSync, OWA for Mobile, OWA, EWS). Changing a user’s password may be ineffective if those protocols are still active. You have to disable those protocols to fully cut off attacker access.
2. Attackers with user credentials can enable forwarding to external addresses AND add delegate permissions to mailboxes. Be sure to review and reset these on any suspect mailboxes.
3. EWS mailbox access does NOT appear to be logged. Consider disabling EWS for all user mailboxes, except where required for programmatic (REST API) mailbox access.
4. Don’t count on getting any forensically-useful data from the activity audit logging. If you had access to your Exchange server’s IIS logs in the past, you could almost re-create the fully user activity story; Office 365 Activity Audit Logging doesn’t give you enough detail to do that.
5. Check out the Azure Active Directory admin center. The “Risky sign-ins” report may help you with early identification of suspicious activity.
There will always be vulnerable services, insecure software and human error. It’s our job to educate the users, and show the stakeholders through exploitation, that these vulnerable and legacy services must be decommissioned. Thanks for reading, and be responsible.
