Named Location Feeds
The named location feeds we provide are "backend" AiTM infrastructure which is performing the authentication component of an AiTM attack. i.e. it is the IP addresses that you will see logging into your Microsoft environment if a user is successfully targeted.
This will often not correspond to the IP address of frontend infrastructure (e.g. the phishing website that a victim may have visited). Blocking access to this backend infrastructure will not prevent it from authenticating to your environment, but blocking access from it will. This is why we provide our data in a manner compatible with Microsoft's Conditional Access Policies (CAP). It enables you to use CAPs to prevent AiTM infrastructure from authenticating to your environment.
The Lab539 service does not configure any conditional access policies for you. But it provides access to named locations that you can use in your conditional access policies and it keeps those named locations up to date for you.
Deployment Options
When it comes to incorporating our named location feeds into your conditional access policies you have a few options, so you should select the one that is right for you and your environment:
Lab539 Hosted
This is without doubt the easiest option. We take care of all of the hosting and logic and in real time push updated data into your named locations for you.
Deployment is a trivial point and click exercise and can be completed in a minute or two without you needing to deploy any new infrastructure.
However, this approach will not be suitable for you if you are unable to grant our AiTM Feed service the necessary permissions within your environment.
Lab539 Hosted Deployment Guide
Self Hosted Client
We provide an ARM template, which can be deployed as a Microsoft Azure Logic App within your own environment. This logic app takes advantage of the API in order to periodically update your named locations for you without the requirement for you to grant any access to Lab539 to your environment.
This will require you to first create an app registration within your environment and then to deploy the logic app.
Whilst more involved than the Lab539 Hosted approach, this is not a complex exercise and our guide will take you through the process.
Lab539 will have no ability to alter, modify or debug your deployment. Enabling error reporting will provide us some limited visibility. Whilst willing to support where we can, you will need to take ownership for maintaining this deployment type.
Self Built Client
If you have in house development capabilities you may wish to create your own client which interfaces with our API in order to obtain named location data.
This approach provides you with complete flexibility over how the feed functions within your environment which is particularly useful if you wish to peform custom workflows or additional processing of named location datta.
If taking this approach you should be aware that there are some inconsistencies, quirks and limitations to how the Microsoft Graph API works that you will need to accomodate. We have already handled these in the Lab539 and Self Hosted deployments. You may notice that our data does not always align with Microsofts schema definition, and that we often create single-entry named locations prior to populating them with data - this is to overcome some of these issues.