Last Updated: 2020-10-01 00:02:37 UTC
by Daniel Wesemann (Version: 1)
Chances are, you are quite familiar with the logs of your on-premises Active Directory (AD) domain controller. The corresponding Event IDs have been well documented over the years (though not thanks to Microsoft), and many blog posts have been written about how to use AD logs to detect Pass-the-Hash, brute force attempts, Kerberoasting, and more.
Increasingly though, we all find our Active Directory slowly (or quickly) migrating into the Cloud, and becoming an Azure Active Directory (AAD). Some of the old on-premises AD body of knowledge in detection and defense still applies, but most is obsolete. And - brave new world - AAD is usually exposed to the Internet in some form or fashion, so it is subject to all the noise that all the miscreants on the planet can fire against the IP address that happens to be yours.
As was the case with Active Directory, Microsoft isn't really making huge strides in sharing the knowledge needed to keep Azure AD safe, either. The https://github.com/MicrosoftDocs and https://github.com/Microsoft repositories are sharing some samples, many of which are outdated, but in general, the documentation is still kinda thin.
If you are like many small businesses or institutions who use AAD, but can't afford the full-fledged Microsoft offering with Sentinel, Azure ATP (now called Microsoft Defender for Identity) and other $$$-gadgets, you are kinda on your own.
You still should look at them logs though, because ... as mentioned above ... AAD is usually "internet-facing", and if there is any chink in your armor, the miscreants will find it eventually.
Rather than to stream your AAD logs back to on-premises into your existing ELK or Splunk or what-have-you, I'd suggest you look into connecting your AAD into a LogAnalytics space in Azure. It isn't exactly cheap, but if you don't go overboard with the volume or retention period, you'll find it useful. More info how to set it up, here: https://docs.microsoft.com/en-us/azure/active-directory/reports-monitoring/howto-analyze-activity-logs-log-analytics
Once you have this in place, you can use the Kusto Query Language to run quickfire analysis queries like this one, to look for failed logins that originate from the same IP, and hit several user IDs:
| where ResultType != 0 // failed logins only
| extend TimeBin=bin(TimeGenerated,2h) // in 2h interval buckets
| summarize IDs=make_set(Identity) by IPAddress,TimeBin // attempted usernames per source IP and time bucket
| extend targets=array_length(IDs) // count how many
| render columnchart // paint a pretty picture
which in my case, for the community college where I'm watching the AAD, is resulting in something like this for last week:
which in turn provides ample incentive to drill down further, and to also look into how to deploy some kind of automatic responder that bans this kind of nonsense, by pushing a temporary block rule to zap the offending IPs.
If you know of useful resources on how to monitor Azure AD, please let us know, or share in the comments below.