Failed log on (Failure message: Account is locked because user tried to sign in too many times with

[Sean Kuchle]

My company has been experiencing an attack from China IP addresses (random) for a while and I can't seem to block them. I'm getting these errors "Failed log on (Failure message: Account is locked because user tried to sign in too many times with an incorrect user ID or password)" every few days on a few of my privileged users.
I've tried

Turning on Modern Authentication

In Azure AD Enabled Block legacy authentication

Turned off POP and IMAP access via exchange admin

Turned on MFA for the privileged users

The redacted (with *) source app connector data is below, I'm wondering if there is a way to block OrgIdWsTrust2:process or Unknown(CBAInPROD). Or if there is something else I can block to stop this.

Thanks for your help!

{
"UserName": "",
"MfaResult": null,
"DeviceInfo": "Unknown(CBAInPROD)",
"LoginErrorCode": 50053,
"DeviceTrustType": "",
"IsInteractive": false,
"Call": "OrgIdWsTrust2:process",
"LoginStatus": "Failure",
"MfaMaskedDeviceId": null,
"IpAddress": "182.38.105.229",
"UserTenantId": "****",
"EventType": "MCASLoginEvent",
"IsInteractiveComputed": null,
"ApplicationId": "***",
"CorrelationId": "***",
"ApplicationName": "Office 365",
"SasStatus": null,
"TimeStamp": "2019-07-02T01:11:36.4486831Z",
"HomeTenantUserObjectId": "***",
"MfaRequired": false,
"RequestId": "***",
"TenantId": "***",
"MfaAuthMethod": null,
"MfaStatusRaw": null,
"IsDeviceCompliantAndManaged": false,
"BrowserId": null,
"UserTenantMsodsRegionScope": "NA",
"DataSource": null,
"UserPrincipalObjectID": "***",
"Upn": "***",
"MsodsTenantRegionScope": "NA"
}

[#2]

Are you looking at the MCAS logs? Those arrive with some delay, best check directly against the Azure AD sign-in logs. The settings you've configured should be enough to prevent this type of attack, which is usually brute-forcing credentials via POP/IMAP.

[#3]

@Vasil MichevThank you for the follow up. Yes I am seeing the logs in MCAS, unfortunately we do not have a premium Azure AD subscription so I can't see the logs in there.

From my reading I thought is was through POP and IMAP as well but I've disabled that in the exchange mail boxes. Is there somewhere that needs to be set?

[#4]

Even without AAD Premium, you can see it on the corresponding user object's details page.

Disabling POP/IMAP will not affect these entries, blocking legacy auth should however, so check whether you missed something on that front.

[#5]

@Vasil Michev  Thank you for your continued help, I checked the Azure Ad logs (thank you for the tip) and saw that it was IMAP and SMTP, mostly SMTP.

These alerts were on 7-1 and 7-2

I ran this powershell script on all my users on 6-28

$Mailboxes = Get-Mailbox -ResultSize Unlimited

ForEach ($Mailbox in $Mailboxes) {$Mailbox | Set-CASMailbox -PopEnabled $False -ImapEnabled $False }

I checked the account in exchange and it seems like it is disabled, see below, although I don't see a way to disabled SMTP

[#6]

Again, disabling legacy auth is your best option here.

[#7]

@Vasil Michev I'm sorry for the delayed reply I've been working with Microsoft support in hopes of getting this resolved but have reached a dead end. I've blocked legacy access via AD conditional access policies. As per earlier I've blocked IMAP and POP.

Microsoft support is now telling me that the attackers are still able to try IMAP they are just not going to be able to get in. This is a problem to me as given enough time they will guess the password and have 1 factor to log in.

Does anyone know anything else I can do? It seems crazy Microsoft just allows someone to keep trying on IMAP even though it is disabled.

[#8]

Not sure what's happening in your scenario, but once I disabled legacy auth in my tenant I stopped seeing any such attempts. 

[#9]

@Vasil Michev  I have exactly the same problem for a client.  IMAP and POP are disable, but when external users try to brute force the account, the tries count for the lockout for a 30 minutes... the account get locked out even if the IMAP protocol is disabled for the user.  actually I'm trying to build conditional access policies to block connections from some countries (China...).  The user don't want (for now) to start using Outlook, and don't want to hear about anything else than iOS mail, which only support basic authentication, so for now I can't disable Basic authentication.  I'm getting out of ideas.

[#10]

CA policies and the protocol controls act *after* the login, that's why I suggested completely disabling legacy auth via authentication policies in Exchange above.

[#11]

@Sean Kuchle 

I have the same issue.

Did you get anywhere with a proper answer or solution ?

I have daily more than 500 login tries from China, US, Thailand etc. with failed login using IMAP.

Failure reason  "Account is locked because user tried to sign in too many times with an incorrect user ID or password."

IMAP disable in exchange and Block Legacy Cond. Access is applied, how can I tell if we are not in trouble if I still get 50053 error when service is disabled ?

thank you

[#12]

@LilleLars As @Vasil Michev said the CA policies are only being applied AFTER succesful authentication through basich auth protocols (POP3, IMAP, SMTP, etc.). That's why you're seeing this behaviour. 

To eliminate these spray attacks you need to disable basic auth in Exchange Online. Please have a look at the following article on how to do that: https://docs.microsoft.com/en-us/exchange/clients-and-mobile-in-exchange-online/disable-basic-authen...

[#13]

@Pavel Otych 

Thank you Pavel, im testing now and this tenant did not have any "authentication policies" already.

Ive done this:

New-AuthenticationPolicy -Name "Block Basic Auth"
Set-OrganizationConfig -DefaultAuthenticationPolicy "Block Basic Auth"

gives me below result which looks good.

I´ve waited  10 hours and stille I see IMAP error 50053 "account is blocked" in the Sign-ins log

Hope I did it correct?

AllowBasicAuthActiveSync : False
AllowBasicAuthAutodiscover : False
AllowBasicAuthImap : False
AllowBasicAuthMapi : False
AllowBasicAuthOfflineAddressBook : False
AllowBasicAuthOutlookService : False
AllowBasicAuthPop : False
AllowBasicAuthReportingWebServices : False
AllowBasicAuthRest : False
AllowBasicAuthRpc : False
AllowBasicAuthSmtp : False
AllowBasicAuthWebServices : False
AllowBasicAuthPowershell : False

[#14]

@LilleLars The steps you've done are correct and should be enough. If you're seeing this for a specific user account you can check he has the policy applied and run "Get-User -Filter "AuthenticationPolicy -eq..." (more info in the article) to make sure. But other than that I think you've done all that was needed and the basic auth should be blocked :( You might wait a bit longer and see if it works eventually. Maybe someone else has an idea.

[#15]

@Pavel Otych 

Hi Pavel, thank you !

Get-User -Identity user@domain.com | fl auth returns:

Authenticationpolicy :

Blank or null ?

it might be because its the default auth policy ? as I see in this uservoice:

https://office365.uservoice.com/forums/289138-office-365-security-compliance/suggestions/38070442-ge...

[#16]

It's normal you don't see it that way as you have added it as a default policy.

I have experienced the same and contact Microsoft for that.
They informed me that Authentication Policies are unreliable and CA should be used.

I don't like that response, but it's the one I got :)

I recommend adding the authentication policy and setting up CA to block the signins that aren't stopped by auth policies.

[#17]

@Thijs Lecomte

ok I will leave it as I´ve done now and follow the sign-ins log here.

Thank you all!

have a nice day