Enhance Azure Sign-In Security...

Question

Enhance Azure Sign-In Security...

KM 0

I audit the Azure sign-in on a daily base and I see a lot of attacks that are password spray and brute force. All of our users are always located in certain location, use MFA and they always use specific way to log in.

I see the sign-in error codes and failure reasons. But the Failure reasons are just inaccurate, vague and not specific.

What I've noticed, the patterns the attackers are using:

IP addresses outside of our geo location.
Microsoft Azure CLI
Azure Active Directory Powershell,
and Microsoft Azure Active Directory connect.

My question is, is there a way for Microsoft Azure and Defender to integrate public Real Time Block Lists such as AbuseIPDB, URLSCAN.IO, SpamCop, Spamhause, and others to do lookup, check if found to be those db, and reject them straight up? And Possibly update the Failure reason as "malicious sign in attempts"

Also, would be nice if we could conditional block just the Microsoft Azure CLI and/or Azure Active Directory Powershell, cause NONE of our users uses that to sign in. Attackers obviously using Microsoft's own infrastructure to attack other people's infrastructure. Which, of course, puts Microsoft in a liability position cause the Attackers are literally using Azure to attack.

If there was a way we can do this, will eliminate over 90% of the intrusion attempts, spam and phishing.

0 comments

1 answer

Your answer

Answer 1

Microsoft uses its own block lists, as well as multiple other mechanisms to block suspicious activity, "risky" sign-in attempts, and so on. Still, given the nature of the service, everyone can brute force logins, and the tools you listed above are simply some of the easiest to automate in this regard. The best thing you can do is make sure all your users are protected by MFA, or even better, some passwordless method.

With regards to Conditional access, it only triggers after the initial authentication, therefore you cannot use it to block brute-force attempts. You can still use it to block access to specific apps, but attackers can in theory still validate credentials, even with CA in place.