Hey everyone! I'm dealing with a situation where several users are experiencing account lockouts due to brute-force attacks targeting Azure PowerShell. Although the attack attempts are unsuccessful, their accounts keep getting locked out. I've asked the users if they've connected any consent applications in the past, but they told me no. I checked the logs which indicate LoginState errors from a token request. It seems this is related to some potentially malicious activity coming from a Google Cloud Platform IP. We have MFA and other conditional policies in place, but I'm unsure if blocking Microsoft Azure PowerShell via Conditional Access will actually mitigate the issue. I also got a suggestion to block certain IPs through our WAF or Azure firewall, but I'm not convinced since those tools aren't typically used for PowerShell. Any advice would be appreciated!
3 Answers
Where did you find these reports? Are the users even developing in Go?
You're right about Smart Lockout triggering before your Conditional Access policies, which is likely why MFA isn't doing much here. Those IP hits from `Go-http-client/2.0` point to a basic password spray tactic, which has been noted in some recent security reports. To manage this immediately, you should adjust Azure PowerShell permissions in Entra ID’s Enterprise Applications by requiring assignments and disabling user sign-ins. Additionally, blocking the app ID through your CA policy for non-admins will curb the attack potential even though it won’t eliminate the lockout alerts. And while lowering Smart Lockout thresholds may offer some relief, be cautious about how far you go with that.
Thanks for the tips! I didn’t realize that adjusting those settings could help so much. I'll look into the CA policy and see if it makes a difference.
It sounds like you're experiencing typical noise from these attacks, especially if you're not federated with ADFS or PTA. Conditional Access only kicks in once a user is authenticated, so it won’t stop these pre-authentication attempts. Error 50053 usually means the attempts come from a malicious IP, and that could confuse attackers since their methods don't make them aware if an account is locked or if they're being blocked.
I saw these events in the MS 365 cloud app activity logs where the failed logons are recorded.