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 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):
If you find that your tenantID is displayed instead then it is probable that the permissions took a little longer to propagate than hoped (which is not uncommon). If you’d prefer to see a friendly name then just go through the setup process again by clicking the “Replace/set account” icon to the right and it should rectify.
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 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.
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.