If you’re running Microsoft Exchange Server your also quite likely to have the Outlook on the web (previously: Exchange Web Connect, Outlook Web Access (OWA), Outlook Web App) interface up and running to enable your users to use Exchange ActiveSync and access their email, calendars and contacts over an easy-to-use web interface accessible over the Internet.
This is just as relevant if you’re managing your own Exchange Server or if it is a hosted Exchange at a service provider. If your provider doesn’t have a solution for this, you may find yourself in a very difficult situation one day as explained further down.
Since Outlook on the web is reachable and visible over the Internet, this also means that anyone is able to try to log in to your Exchange server over the same interface. They may not succeed to login but they may try to overload your server by sending lots of login request or have your users undergo a Distributed Denial of Service-attack (DDoS attack).
Brute force attacks used as Denial of Service attacks
The Outlook on the web in itself (or does Windows Server for that matter) does not have any brute force prevention mechanisms built into it but the actual user validation is done within the Active Directory (AD) infrastructure by your domain controller(s). Within the Microsoft line of products this is actually true for most of them such as Terminal Server (RDS, Remote Desktop), Sharepoint, SQL Server and so on and also for Citrix since user validation is done in the same way.
For instance, if you have set up Account Lockout Policies to disable a user account after 5 failed attempts, anyone with knowledge of your name standards (e.g.email address, AD login) can run a script against the server. Using a specific username (or hundreds of them) and deliberately using wrong passwords, will lock the legitimate users account and disabling them from logging in. I.e. they can not login to anything that uses the Active Directory validation, not even their own office workstations.
If such an attack is made from a single IP address, it is fairly easy to block it manually. (You (simply block the attack in either the external firewall or the local firewall of the Exchange server).
In reality though, this is not how such an attack occurs. Should someone really want to disrupt your services, they will do this from hundreds or thousands computers at the same time and making it impossible to block manually.
Prevention and countermeasurements
Brute force protection software can monitor the Windows Server logs for failed login requests. If an IP address tries to login against your servers and fails (e.g. 5 times within 30 minutes), the IP address is automatically blocked from communicating at all with the affected server on any level. Thus, if you are running additional services, the intruders will not be able to target them either once blocked.
The accounts will be locked during a specific time, or until manually unlocked by an administrator. This is the most direct and apparent way to block a brute-force attacks.
Each attack is not only blocked, but traced, and reported. In Syspeace, via an email that contains the source IP address, the username used, country of origin and previous attacks from the same IP address.
Here is an example of how the email notification in Syspeace looks like (with IP address and domain name intentionally removed):
Rule used (Winlogon):
Name: Catch All Login
Trigger window: 4.00:30:00
Lockout time: 02:00:00
Previous observations of this IP address:
2015-01-14 16:44:50 ****lab
2015-01-14 16:44:52 ****labroator
2015-01-14 12:53:44 ****ron
2015-01-14 12:53:46 ****demo
2015-01-14 12:53:48 ****canon
It is easy to think that this will happen to other companies, not yours. But that is simply not true. Brute force attacks are on the rice – you need to prepare yourself!