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. Which in my case, for the community college where I'm watching the AAD, is resulting in something like this for last week: | render columnchart // paint a pretty picture | extend targets=array_length(IDs) // count how many | summarize IDs=make_set(Identity) by IPAddress,TimeBin // attempted usernames per source IP and time bucket
| extend TimeBin=bin(TimeGenerated,2h) // in 2h interval buckets | where ResultType != 0 // failed logins only 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: It isn't exactly cheap, but if you don't go overboard with the volume or retention period, you'll find it useful. 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. AAD is usually "internet-facing", and if there is any chink in your armor, the miscreants will find it eventually. You still should look at them logs though, because. 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.
The and repositories are sharing some samples, many of which are outdated, but in general, the documentation is still kinda thin.
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.Īs was the case with Active Directory, Microsoft isn't really making huge strides in sharing the knowledge needed to keep Azure AD safe, either. Some of the old on-premises AD body of knowledge in detection and defense still applies, but most is obsolete. Increasingly though, we all find our Active Directory slowly (or quickly) migrating into the Cloud, and becoming an Azure Active Directory (AAD). 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. Chances are, you are quite familiar with the logs of your on-premises Active Directory (AD) domain controller.
0 kommentar(er)
