Blog

Archive for September 30th, 2020

Making sense of Azure AD (AAD) activity logs, (Thu, Oct 1st)

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:

SigninLogs
| 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.

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

Reposted from SANS. View original.

Posted in: SANS

Leave a Comment (0) →

Scans for FPURL.xml: Recognizance or Not?, (Wed, Sep 30th)

A reader has been reporting an increase in scans for “FPURL.xml” against their IIS server. The file did not exist in this case, and the server returned a 404 error. Checking our honeypots, we found little to no requests for this URL. But our honeypots are currently not emulating IIS servers. These scans have been hitting IIS servers for a while, according to some other reports I found.

FPURL.xml is used as part of Microsoft’s federated identity system. It can be used to implement “Windows Hello for Business.” With Windows Hello for business, users can authenticate to Azure AD using two-factor authentication, and you can leverage this authentication for your applications. A client taking advantage of this authentication mechanism will load FPURL.xml to learn the parameters needed to authenticate. Here is a typical FPURL.xml file:

(I abbreviated some of the Base64 encoded strings to make this more readable)

MicrosoftOnline.com
https://clientconfig.microsoftonline-p.net









7Dl3OtA9+LvTX7P6gpBbsMe70U4=


hCHLON..5mTQ==


MIIDBTCCAe2gAw...vMqm9ndL7




The file describes a “Federation Provider” that can be used to authenticate. In this case, the Federation Provider is MicrosoftOnline.com, and the file describes algorithms and certificates to use.

This file has some recognizance value. An attacker may now, for example, know that they can phish users for MicrosoftOnline credentials to get access to the resource. It could also be used for simple fingerprinting. There is a possibility that some of the requests you see for this file are just caused by clients that check if you are supporting this authentication method. 

If anybody has additional input on these scans: Please let me know below or via our contact page.


Johannes B. Ullrich, Ph.D. , Dean of Research, SANS Technology Institute
Twitter|

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

Reposted from SANS. View original.

Posted in: SANS

Leave a Comment (0) →