Browser support for Defender for Endpoint URL/Domain Indicators

I’ve been doing a bit of work recently with URL/Domain Indicators in “block execution” mode and thought it might be usefult to share my experience here. I found a website that isn’t blocked in Chrome and I suspect that my experience may not be unique. This article briefly covers how to use Indicators to block user access to specific websites and then describes the issue I have come across.

Using Indicators to prevent access to specific URLs is useful if you encounter websites that contain malicious content or which are in some other way deemed risky or undesirable.

You can create an Indicator directly within the Microsoft Defender portal. Go to Settings -> Endpoints -> Indicators -> URLs/Domains -> Add item.

The steps from there are wizard-driven and straightforward, including the ability to create alerts and target specific (Defender for Endpoint) device groups. For the best browser support for the “block exection” action, enter a domain FQDN rather than the full URL (for reasons outlined in this article).

Once you have created your Indicator, it will take a some time for the block to become effective. In my experience, this is typically about 30 minutes or so.

Another method by which you can create an Indicator is to mark an app as “Unsanctioned” in Microsoft Defender for Cloud Apps. In the Microsoft Defender Portal browse to Cloud apps -> Cloud app catalog. From there, select the app, click the ellipsis (…) and select Unsanctioned.

Once the app is unsanctioned, you will see the asscociated Indicator appear in the portal within a few minutes. In fact you might see more than one Indicator appear for the app as there are sometimes multiple URLs or domains associated with the app.

One thing to be aware of is that you must have MDE integration enabled in the Cloud Apps settings to allow Indicators to be created from Unsanctioned apps. Here’s the setting:

When you have your Indicator(s) in place, you will be able to test the effect by attemping to reach the URL from different browsers. The technology used to apply the block is different when using Edge to other browsers. This is because Edge leverages Smartscreen to present more meaningful information to the user. Here’s an example:

If you use a different browser to Edge, the access should still be blocked but the message displayed is less useful (and can vary). This is because the block is applied by network protection (a feature of Exploit Guard). Here’s an example from Firefox.

And now we come to the issue that I found with Chrome. It’s only happened with one website in my experience, so it may be a rare occurence but it’s nonetheless worth pointing out in case you notice it with other sites. I can successfully access the website https://polymath.how despite having a block Indicator in place for it using the FQDN polymath.how. Here’s how it looks in Chrome:

[It’s worth pointing out that I am only using the polymath.how website as a random example. The site is completely benign and the content actually looks really useful!]

The weird thing about the site loading in Chrome is that my device thinks it has been blocked. For example, if I look at the device timeline in the Defender portal, I see this:

Obviously, the fact that the block doesn’t appear to behave consistently across all browsers detracts from its usefulness and doesn’t inspire confidence in the Indicator feature. If you’ve also come across similar issues, it would be good if you could leave a comment.

In summary, URL/Domain Indicators can be useful for blocking user access to undesirable websites. The feature is straightforward to configure, either directly in the Defender for Endpoint settings, or by marking an app as Unsanctioned in Defender for Cloud Apps. Be aware that there are differences in the user experience between browsers and that occasionally Chrome might still load the page even with the block in place.