Forum Discussion

hhbadarin's avatar
hhbadarin
Brass Contributor
Aug 18, 2023
Solved

Thousands of login attempts from external IPs

Hi all,

I'm the Global admin of an education tenant in the largest school district in my country, I administer over 90k Microsoft 365 accounts for students and educators.

Recently, Azure AD logs started showing consistent failed logins for over 90% of the users in my tenant, most of them coming from external IPs located in countries like China and Russia. I deployed a conditional access policy (location based) that has been working perfectly for over a week now. However, I still have the following two questions and i'd appreciate your answers: 

  1. How do attackers identify the UPNs of users in my tenant so they are able to deploy such large scale attacks( login attempts).
  2. Is there another way (other than CA) to stop those failed logins before they even originate? I mean to block attackers at the instant time they enter the UPN and before they try to guess the user password (based on their location). As you know the current scenario with CA is that It only blocks users after they enter the UPN and a password (I tested this using a VPN). 

Simply put: Is there a way to avoid those huge logs of failed login attempts?Thanks in advance 

  • Not really, after all M365 is a public cloud service and the login page is available from anywhere. UPNs themselves can be tried at random (you will not see any attempt for non-existent UPN in the logs), or guesstimated from the email address, etc.
    As for blocking them, CA is an easy way, unfortunately it only triggers only after the credentials have been validated. Only Exchange Online allows you to block login attempt on the pre-auth layer, via the so-called Authentication policies: https://learn.microsoft.com/en-us/exchange/clients-and-mobile-in-exchange-online/disable-basic-authentication-in-exchange-online#authentication-policy-procedures-in-exchange-online
    That said, most such attempts to leverage the Exchange protocols, so this approach might help in your case. If you need to exert further control, you only option would be to redirect the login process to an external system (on-premises AD FS farm or federation provider), where you can apply restrictions as needed.

5 Replies

    • haitham's avatar
      haitham
      Copper Contributor
      Would appreciate some details, keep in mind we are talking about students and teachers.
  • Not really, after all M365 is a public cloud service and the login page is available from anywhere. UPNs themselves can be tried at random (you will not see any attempt for non-existent UPN in the logs), or guesstimated from the email address, etc.
    As for blocking them, CA is an easy way, unfortunately it only triggers only after the credentials have been validated. Only Exchange Online allows you to block login attempt on the pre-auth layer, via the so-called Authentication policies: https://learn.microsoft.com/en-us/exchange/clients-and-mobile-in-exchange-online/disable-basic-authentication-in-exchange-online#authentication-policy-procedures-in-exchange-online
    That said, most such attempts to leverage the Exchange protocols, so this approach might help in your case. If you need to exert further control, you only option would be to redirect the login process to an external system (on-premises AD FS farm or federation provider), where you can apply restrictions as needed.
    • haitham's avatar
      haitham
      Copper Contributor

      Thanks VasilMichev 

      Our users are in a fully cloud-based enviroment. I went through the docs in the link you attached and managed to turn off basic authentication for a test account, which i assume should block login attempts on the pre-auth layer, however i still see an option to enter password when i try to login using this account! Am i doing somthing wrong or did i miss something in your reply?

      • That's the expected behavior, currently there is no way to disable password login altogether. But assuming the attacker tries to login via any of the methods you blocked via auth policy, they will always see a generic 401 error and have no way of confirming whether a given password is valid or not.

Resources