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).
Configuring a user 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 authorise this service to operate as:
User Permissions
The user you select for this service does not need to be the user which you are logged into the portal as. It does not even need to be a user in the same tenant as the user logged in.
The account being authorised should have the permission to read and write indicators. The Security Administrator role has this permission. The service, however, only requires the following permission:
Ti.ReadWrite
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.
These permissions will be presented on the consent screen when you select your user:
Assuming the user you have selected has permission to do so, clicking accept will enable the service for the selected user. Success will result in the username being displayed with a green tick as shown below:
Configuring a user does not result in any indicators being written. These are only written once the desired feed is toggled to “on” using the toggle switch.
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 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.
There is no functionality within the portal to delete indicators once they are created, but our indicators are set to expire 2 hours after creation. Disabling the indicators feed within the portal by toggling the switch to off will result in no further updates, and after 2 hours all indicators will be removed.
Microsoft Bugs and Limitations
Indicator Expiration
There is a bug in the Microsoft Security portal which confuses the UTC and GMT timezones. As a result, during British summer time indicators with a lifetime of under 1 hour appear expired the moment they are created. Whilst we would like to write indicators with a time-to-live of minutes rather than hours we currently write indicators with a time-to-live of 2 hours in order to avoid confusion when indicators are initially written. This bug does still result in indicators appearing as Expired during the last hour of their lifetime.
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, but there may be complications if your environment already makes heavy use of custom indicators.
To provide some additional context, at the time of writing, in just the last 7 days we have observed over 34,000 unique AiTM frontends. We do some work to reduce that down to just over 12,000 and have some additional techniques that we plan to implement in order to further reduce this without reducing the level of protection we provide. But the crux of it is that the scale of the AiTM challenge is a little more than Microsoft Defender is currently able to handle without compensating controls. Not a reason not to counter the AiTM challenge, but definitely something that makes our work harder.