Local User Account Brute Attack with EOP

[Jeff Harlow]

Have a Hybrid scenario with Exchange 2010 on-premise.  I have a program that monitors user account lockouts.  Recently we have noticed several user accounts being locked out, which appears to be a brute attack originating from our Exchange Server.  The User accounts are not being locked out from the O365 side and user accounts are protected with MFA.  The logs from the program point out that the attack is from our on-premise Exchange server.   My question is, the setup on this server has remained the same since we migrated to the cloud (ports, services, etc.)  Microsoft support which is limited when it comes to Hybrid scenarios only would tell me that all of the services and ports are necessary to keep the Hybrid operational.    So with that, is there any other recommendations to reduce these account lock outs.  Thanks. 

[#2]

Hello Again Jeff!

It is always rough when you have the problem/attack coming from you on-prem, as you do need to keep that open and communicating with O365 to ensure a smooth coexistence. I will say I think your solution is going to have to live outside of that, as you will struggle when you try to mess with the federation/coexistence. As such I would look at this as a security issue on prem not through the hybrid connection.

1. The most obvious is to put in place measures to watch/monitor the on-prem exchange better. Putting in place IP blocklists, or using your local firewall to try to keep specific ips/locations out may be best. Everything else is going to be somewhat half measures as they will block stuff through o365 but not through a direct login/access to your on-prem.

from there:

2. I would probably approach this from an identity/access stand point.

Standing up claims rules in ADFS would probably work best, you can just block login access from unknown places. Azure AD can do this somewhat, as well. I am unsure if you would need your onprem server in there (but blocking AzureAD probably doesn't block the direct access to the exchange on prem).

Hope this atleast helps gets ideas flowing.
Adam

[#3]

Thanks for the response. I am waiting for it to happen again and see if I can tie the instance in with active IP addresses.  We do not have a lot in place for monitoring as we are a small business. I was hoping MS would provide a reasonable solution like to enable direct IPs for their services only to connect to our Exchange server, but that was not the case.  We will not get our local AD out of this equation fast enough...   We do not have ADFS in place. The goal is to get all of our services/servers in Azure and remove the local premise servers. 

[#4]

Makes sense, you will also have problems doing any just whitelisting of O365, they have sooooooooooooooooooooooooooo many servers (https://support.office.com/en-us/article/office-365-urls-and-ip-address-ranges-8548a211-3fe7-47cb-ab... - its a huge list) that update constantly, anytime I have tried to deploy a solution that whitelisted them but was more secure on others it seemed like a headache.

I think you are correct that moving forward to be cloud based is probably the best way to **bleep** this in the butt, and get on top of the problem.

Goodluck!

Adam

[#5]

As you are hybrid, you cannot remove your Exchange Server on-premises as you need that to manage your AD recipients you have in the cloud. But if all your mailboxes are in Exchange Online and AutoDiscover points to Exchange Online directly then you do not need to publish the on-premises server to the Internet for user access. Therefore stop https inbound to the server. This will stop bad login attempts to the on-premises server and so stop account lockout. Also ensure your account lockout is not to low as well so that users are locking themselves out a well

[#6]

All of our mailboxes are cloud only, yes.  We still use the on-premise to handle on-boarding users (that whole GGUID, or something like that) and we use on-premise for routing mail between servers, which is slowly changing. But otherwise, yeah, all MX records, Cnames, etc point to EOP.   So it is safe to block https on the firewall at this point ?  Seems risky and odd that MS did not offer this but if it works, I am all for it. 

[#7]

Great - so where does autodiscover.yourdomain.com point to - it should now point the autodiscover.outlook.com as per the DNS settings in the tenant.

Where do users to to for OWA - if they go to mail.yourdomain.com (or whatever it was) they get told to use outlook.com/owa/yourdomain - as long as they go there first and not to your on-premises server then good. You could configure an automatic redirect on a website or load balancer to keep doing this, you dont need it to point to Exchange Server anymore.

So now you can stop HTTPS access to your Exchange Server(s) from the internet.