Setting up the Lab539 hosted Microsoft Defender indicators feed
This post describes how to incorporate the Lab539 AiTM feed into Microsoft Defender using the Lab539 managed service.
Description
The Microsoft Defender indicators feed is a service operated by Lab539 which, in near real time, provides a feed of indicators directly into your Microsoft Defender indicators feed. Meaning that your users are protected from AiTM infrastructure the moment it is uncovered.
If you have Defender set up then this should be a trivial process, as long as you have enabled custom network indicators in your configuration.
Video Overview
Initial Enrolment
In order to utilise the service you must authorise a user. This can be done from within the “Microsoft Defender Indicators Management” section of the portal (https://portal.lab539.com). If you have not yet logged into the portal you can do so using the email address you specified during registration.
Configuring permissions for the service is done by clicking the icon in the top right that looks like a user with a cog. This will direct you to the Microsoft authentication service where you can select, or enter, the user account which you would like to use to authorise this service.
This user should have the ability to grant admin consent, and if successful this will register an enterprise app registration for you named “Lab539 Indicator Feed” which will have the application ID: “a63d9249-de0c-4ee1-940f-bd4e8b272306”.
Authorising the indicators feed will not result in any indicators being written, indicators can be enabled and disabled after this process has completed.
Permissions
When authorising the app registration you will be prompted with a consent screen, it will detail the permissions required by the application:
In order to function the indicators feed requires only one permission:
Ti.ReadWrite (“Read and write IOCs bellonging to the app”)
This permission “Allows the app to create IOCs and to read or update IOCs it created, on behalf of the signed-in user”. This is a very narrow and limited permission. It ensures that our service cannot read, write, or modify any indicators that it does not create itself. As this service runs in the background it also requires the ability to maintain access to this permission.
However, we also request the following permission:
CrossTenantInformation.ReadBasic.All (Read cross-tenant basic information)
This permission gives us access to a friendly name for your tenant which we’ll display next to feeds that have been set up (which is particularly helpful for users who manage indicators across multiple tenants). This permission is only required on initial setup, so you are welcome to revoke it after that if you wish:
The “Sign in and read user profile” permission is not something we request, but is something that Microsoft applies by default to any Microsoft logins.
If you wish to check the permissions then you can do from within the app registration. Browser to Enterprise applications within Azure, find the one named “Lab539 Indicator Feed” and then browse to “Security > Permissions”:
If you have not granted admin consent then this service will not function as intended. This should have been done during the registration process, but if not then you should click the “Grant admin consent” button to do so.
Revoking Permissions
You are always in control of all access you grant. Within the Lab539 AiTM-Feed portal you can toggle the feed on/off and also remove access. However, If at any point you wish to revoke permissions and disable this application from functioning you can do so from the application registration. Simply go to “Manage > Properties” and then hit “Delete”:
This will revoke all permissions, any future attempts to write indicators will now fail. We do recommend that if you wish to stop the service that you disable things from the portal before removing the app registration.
Enabling Indicators
Once set up you can enable indicators from within the portal by simply toggling the toggle switch for the relevant feed:
Once enabled the indicators will be written to and visible within your Defender/Security portal under “Settings > Endpoints > Rules > Indicators > URLs/Domains”: https://security.microsoft.com/securitysettings/endpoints/custom_ti_indicators?childviewid=url
Defender Configuration
In order for indicators to be distributed to endpoints running Defender “Custom network indicators” must be enabled within your configuration. If it is not already enabled it can be enabled in the “Advanced features” section under “Settings > Endpoints” within the Defender/Security portal: https://security.microsoft.com/securitysettings/endpoints/integration
Testing Detections
If indicators are detected they will appear as Alerts within your Microsoft Security dashboard enriched with additional information and allow you to handle the incident as you would any other alert initiated by Defender:
We don’t advise testing indicators are working using live, malicious sites. Which is why we provide a domain specifically for this purpose and we distribute an indicator for a site on this domain in order to allow testing.
The hostname is: blockme.539block.me The domain is entirely safe to connect to, it exists solely for testing purposes. If your Defender indicators feed is working as intended then visiting the following URL should result in a page notifying that the content has been blocked. It should also trigger a notification within your Microsoft Security dashboard:
How and when indicators are pushed down to endpoints is outside of Lab539’s control. Whilst this is usually a reasonably quick process this can vary depending on various factors.
Removing Indicators
If you wish to remove an indicator this can be done manually from the Microsoft Security portal although, if there are indicators that you wish to permit, we advise creating an "Allow" rule rather than simply deleting the indicator to ensure that subsequent updates to the indicators do not re-create the deleted indicator (allows always take precedence over block rules).
There is no functionality within the Lab539 AiTM-Feed portal to delete indicators once they are created, but our indicators are set to expire 48 hours hours after creation. Disabling the indicators feed within the portal by toggling the switch to off will result in no further updates, and after 48 hours all indicators will have expired and no longer exist in your environment.
Microsoft Bugs and Limitations
Indicator Expiration
There is/was a bug in the Microsoft Security portal which confuses the UTC/GMT/(and possibly other) timezones. As a result, during British summer time indicators with a lifetime of under 1 hour appear expired in the Microsoft Defender portal. This is not the case, if an indicator has expired then it will no longer exist in the portal.
Indicator Volume
Microsoft allows each tenant to configure up to 15,000 indicators. This is a total volume across the tenant rather than an per-indicator-source volume. This means that the Lab539 indicator feed is sharing that 15,000 indicators limit with any other indicators already configured within your environment. We have taken measures to ensure that this quantity is controlled (we don't seen any value in pushing out indicators that are no longer valid), but if your environment already makes use of custom indicators then you may not be able to consume our full feed or may not be able to consume updates as they arrive (we have spoken to Microsoft on this topic... no, we don't think this limit will increase any time soon!)
To provide some additional context, at the time of writing we frequently see in excess of 10,000 AiTM frontends per day (and obviously we want to ensure you have more than a days worth of indicators!). We do some clever things to compress this down to a minimum and are really happy with our approach. But we can't ignore the fact that there are inherent limitations imposed by Microsoft.
One thing that we do is to eliminate AiTM infrastructure fronted by Cloudflare from our indicator feed when Cloudflare have a detection for it (in fact we have some probing specifically designed to trigger their detections). The reason we do this is because Cloudflare present a block screen to users informing them that the site they are attempting to visit is malicious - much in the same way that Defender would for something in our feed. So whilst you won't get an alert in your defender dashboard, your user will be prevented from accessing the website and it frees up space in the feed to share other indicators that don't have a block elsewhere