Technical Overview
At a glance
- Blocks AiTM authentication attempts at the Entra ID layer before accounts are compromised
- Uses existing Named Locations and Conditional Access policies - no agents, no appliances, no new infrastructure
- Feed data lives in your tenant - you retain full control and there is no operational dependency on Lab539
- Continuously updated as new AiTM infrastructure is identified - typically within minutes
- Zero telemetry collected from subscribers - we never see your authentication logs or user data
- Proactive hunting - our proactive approach means that we routinely blocks AiTM infrastructure before incidents occur and before IOCs appears in post-incident reporting
From detection to prevention
Most threat intelligence feeds work the same way: an incident occurs, indicators are extracted, and those indicators are distributed so that future incidents involving the same infrastructure can be detected faster. This model has driven the industry for years, and the metric everyone chases is time to detect - how quickly can you spot that something has gone wrong?
But detection still means something went wrong.
AiTM (Adversary-in-the-Middle) attacks exploit this gap. An attacker proxies a legitimate login page, captures the user's session token in real time, and replays it - bypassing MFA entirely. By the time a traditional threat intel feed includes the proxy infrastructure IP, the account has already been compromised and the attacker has already authenticated.
The Lab539 AiTM Feed takes a fundamentally different approach: prevent the authentication from succeeding in the first place.
How it works
The feed integrates directly into Microsoft Entra ID using functionality that already exists in every Microsoft tenant: Named Locations and Conditional Access policies.
There is no agent to deploy, no appliance to install, and no third-party authentication proxy sitting in front of Entra. The feed populates Named Locations - lists of IP addresses and CIDR ranges - with known AiTM proxy infrastructure. A Conditional Access policy then references those Named Locations to block authentication attempts originating from them.
This operates at the identity layer, not the endpoint layer. It does not block users from accessing resources - it prevents adversary-controlled infrastructure from completing authentication flows against Entra ID. Legitimate users authenticating from legitimate locations are unaffected.
The authentication flow with the feed in place
User → AiTM Proxy → Entra ID
↓
Conditional Access evaluates
source IP against Named Locations
↓
IP is in Lab539 blocklist → Authentication denied
(attacker never receives session token)
Without the feed, the authentication succeeds, the attacker captures the session token, and the compromise has already occurred before any alert is raised.
Integration
The solution deploys as an Azure App Registration within the end tenant and writes directly into Entra ID Named Locations and Microsoft Defender Indicators. It operates entirely within the customer's existing Microsoft environment - there is no additional platform to integrate, no data to parse, and no custom ingestion to build.
If you are already consuming Entra ID sign-in logs and Defender telemetry from the tenant - which most SOC operations will be - the feed's actions will be visible in your existing workflows immediately.
How this differs from traditional threat intelligence
Traditional threat intelligence feeds are enormously valuable for investigation, attribution, and situational awareness. The Lab539 AiTM Feed is designed to complement that work by adding a layer that operates earlier in the attack chain.
Most threat intel - whether from commercial feeds, open-source indicators, or intelligence gathered during incident response and ransomware negotiations - is derived from observed attacks. An incident occurs, indicators are extracted, and those indicators are shared so that future incidents involving the same infrastructure can be identified. This is powerful, but it is inherently retrospective: the intelligence exists because someone was already compromised.
The Lab539 feed works differently. We identify AiTM proxy infrastructure independently, before it is used to compromise accounts in your environment. The feed data is pushed into your Named Locations continuously - typically within minutes of detection, not in daily or hourly batches. This means the Conditional Access policy is already blocking that infrastructure when the attack arrives.
For SOC teams and MSSPs, this changes the operational model. The impact is not faster detection - it is fewer incidents to detect. An authentication blocked by Conditional Access does not result in a compromised account, does not trigger an investigation, and does not require remediation. The metric shifts from "time to detect" to "incidents prevented."
What alerts will this mitigate?
This is a common and reasonable question, but it is important to understand why the answer is more nuanced than it might first appear.
When an AiTM attack succeeds - that is, when the attacker captures a valid session token - Microsoft may raise alerts such as:
- Impossible travel activity
- Unfamiliar sign-in properties
- Anomalous token or token issuer anomaly
- Atypical travel
- MFA fraud alert
The challenge is that these alerts are not raised reliably, and in many cases the compromise occurs without triggering any of them, after all a legitimate authentication flow is being followed. Therefore, if/when they are raised, they are raised after the attacker has already obtained a valid session.
What happens next is often more visible than the compromise itself. Many AiTM platforms automate their post-compromise actions - using the Microsoft Graph API, an attacker can programmatically create inbox forwarding rules, send phishing emails from the compromised mailbox, register OAuth applications, or exfiltrate data within seconds of obtaining the session token. The alerts that SOC teams most commonly respond to are often these downstream actions: suspicious inbox rule creation, mass email sending, unusual OAuth consent grants, new MFA methods registered, data access anomalies and many others.
By that point, the attacker has already achieved their objective. Detecting the activity in minutes is genuinely impressive, but if the post-compromise actions are automated and completed in seconds, even a fast detection is a reactive response to damage that has already been done.
There is also a practical delay in visibility. Microsoft Entra sign-in logs typically take around 15 minutes to become available for analysis. This means that even if a SOC team is actively monitoring authentication events, there is a built-in lag before a compromise is visible - by which point automated post-compromise actions have long since completed.
This is why prevention at the authentication layer is so important. If the Conditional Access policy blocks the authentication attempt from the AiTM proxy, none of the above occurs - no compromise, no automated post-compromise actions, no alert to triage, no incident to investigate, and no 15 minute lag to deal with.
You're probably already measuring time-to-detect. Incorporating AiTM Feed gives you the opportunity to track an "attacks prevented" metric.
How we collect our intelligence
The Lab539 AiTM Feed is not a resold or repackaged version of someone else's data. We operate our own detection and tracking infrastructure, purpose-built for identifying AiTM proxy platforms and the networks they rely on.
Our approach involves a combination of techniques tailored to how different adversaries operate - there is no single method that works across the board, and the specifics of our collection are not something we disclose publicly. What we can say is that we identify infrastructure independently, through our own research and detection capabilities, rather than deriving indicators from victim telemetry or incident response data.
This approach is proven. When Microsoft published their research on Void Blizzard (LAUNDRY BEAR) - a Russia-affiliated threat actor using Evilginx-based AiTM phishing to target NATO member states, government, and defence organisations - the infrastructure they reported was already in our feed weeks before the targeting even occurred. Our subscribers were already protected.
A significant part of our work goes beyond raw detection. There are practical limits on how much data can be pushed into a Microsoft tenant's Named Locations, so we invest heavily in curation - ensuring the right data makes it into your environment, prioritising active and high-confidence infrastructure, and maintaining the ability to surge coverage when threat activity increases. The feed is not just a raw data dump; it is an actively managed intelligence product.
Defender Indicators feed
In addition to the Named Location feeds, we also provide a feed of indicators for Microsoft Defender. This covers the frontend phishing infrastructure - the domains and URLs that users are directed to as part of AiTM campaigns. It interfaces seamlessly with Microsoft Defender, propagating, blocking and alerting when a user accesses known AiTM infrastructure.
It is worth being direct about the nature of this feed. Frontend phishing infrastructure is inherently short-lived and expendable. Adversaries rotate domains frequently, increasingly host on legitimate infrastructure, and can stand up new campaigns in minutes. The security industry has been playing whack-a-mole with phishing domains for decades, and this feed does not change that fundamental dynamic.
That said, the Defender Indicators feed has real value. It can disrupt active campaigns, provide an additional signal for SOC teams investigating suspicious activity, and contribute to defence in depth. It is a useful complement to the Named Location feeds - but it is the proxy infrastructure blocking that provides the more durable and reliable layer of protection, because the backend proxy infrastructure is harder for adversaries to replace than a disposable phishing domain. Also, Microsoft simply don't provide capacity for us to drop all frontend infrastructure we identify into this feed, so we tend to be quite selective, ensuring the most impactful infrastructure is prioritised.
Why our solution is not the same as Microsoft's built-in protections
Microsoft does have its own IP reputation and risk-based capabilities within Entra ID Protection. These work from Microsoft's global telemetry - in practice, this means Microsoft learns about malicious infrastructure by observing it being used against their users. The intelligence is built from knowledge of victims.
The Lab539 feed identifies AiTM infrastructure independently, without relying on it first being used to compromise, or even target, accounts. This is a fundamentally different approach, and it is why the feed catches infrastructure that Microsoft's built-in protections do not.
Microsoft's protections are also broad and generic by design - they cover a wide range of threat types across a massive user base. They are not purpose-built for detecting the residential proxy networks and dedicated infrastructure that modern AiTM platforms use. The continued rise in successful AiTM attacks is itself an indication that these built-in protections are not sufficient on their own. The Lab539 feed is specifically and solely focused on identifying and tracking AiTM infrastructure - this is all we do, and we do it continuously.
The reality is that the overlap between our feed and Microsoft's data is tiny. It's extremely rare for AiTM infrastructure that we uncover to be already blocked by Microsoft (or any other security provider for that matter).
Deployment
How easy is this to deploy?
The core point is that Named Locations and Conditional Access policies already exist in your Microsoft environment. There is no new technology to deploy. The feed simply populates data into a mechanism your tenant already supports.
The two things that need to happen are:
- Named Locations are created and kept updated with current AiTM proxy infrastructure data (we handle that for you).
- A Conditional Access policy is configured to act on those Named Locations (you do that piece).
That is it. The Conditional Access policy is a straightforward configuration within Entra ID - block or restrict authentication attempts from the Named Locations that the feed manages.
Deployment options
Lab539-managed (recommended) - We manage the Named Locations in your tenant directly. You grant limited permissions via an app registration (which we provide), and our infrastructure keeps the Named Locations updated automatically. You retain full control: you can inspect, modify, disable, or delete the Named Locations at any time. You create and own the Conditional Access policy.
Self-hosted - For organisations that prefer to keep everything in-house, we provide an Azure Logic App template that synchronises the feed data into your Named Locations on your own infrastructure. This works in a very similar fashion to the managed approach, but you create and manage the app registration yourself.
In both cases, we handle the work of fitting the right volume of data into your environment and maintaining the ability to surge coverage when threat activity increases.
What about false positives?
There are two things to consider here.
First, the Conditional Access policy can be deployed in report-only mode. In this mode, Entra logs what the policy would have done without actually blocking anything. This lets you validate the feed against real authentication traffic with zero risk before switching to enforcement.
Second, it is worth reframing what "false positive" means in this context. The feed is not blocking users - it is blocking authentication attempts from specific IP addresses. A false positive would mean a legitimate user is authenticating from an IP address that is also being used as AiTM proxy infrastructure. This is unusual, but if it does occur, the recommended approach is to create your own Named Location as an allow list and incorporate it into the Conditional Access policy. This way, any specific IPs you trust are always permitted, and the feed continues to update independently without conflict (allow lists always take precedence over block lists).
Additionally, the feed is not a single monolithic blocklist. We offer a selection of feeds - our core AiTM feeds, as well as more thematic feeds - and you can enable or disable whichever ones are relevant to your environment. It is not an all-or-nothing situation. You can also use them across as many or as few policies as you like.
You are always in full control of the Conditional Access policy and the Named Locations.
- What if your service goes down?
The feed data lives in your Microsoft tenant as Named Locations. If Lab539's infrastructure were to experience downtime, your Conditional Access policies continue to operate exactly as they were. The Named Locations remain in place with all existing data - the only impact would be that new updates are paused until service resumes.
This is an important distinction from solutions that route authentication traffic through a third-party service, where an outage could disrupt your users. The Lab539 feed has no such dependency - it writes data into your environment and your environment enforces it.
Is this relevant if we have MFA?
Not all MFA methods are resistant to AiTM attacks and AiTM takes advantage of this in order to bypass those MFA controls.
AiTM phishing works by proxying the entire authentication flow in real time - the user enters their credentials, completes the MFA challenge, and the attacker captures the resulting session token. The MFA step completes successfully from everyone's perspective; it just happens to be relayed through the attacker's infrastructure.
The MFA methods most commonly deployed in Microsoft environments are all susceptible to this. Push notifications through Microsoft Authenticator, one-time codes, and SMS verification are all susceptible - the user approves the prompt or enters the code, and the attacker's proxy captures the session that follows. Number matching in Authenticator adds very little friction for the attacker, and does not prevent token capture, because the user is still completing the challenge.
Phishing-resistant methods such as FIDO2 security keys and passkeys do protect against this attack. They bind the authentication to the legitimate domain, so the proxied session cannot complete. However, in practice, many organisations that have deployed passkeys or security keys still have other authentication methods enabled as fallbacks - for onboarding, for lost devices, for legacy applications, or simply because the rollout is not yet complete. Attackers can often downgrade the authentication to a less secure method that remains available on the account.
Until an organisation has fully migrated to phishing-resistant authentication and disabled all fallback methods for every account, AiTM attacks remain a viable threat. For most organisations, that migration is a long-term project. The Lab539 AiTM Feed provides protection now, regardless of which MFA methods are in use.
Even where phishing resistant MFA is in use, session theft can still occur by other means (malware, malicious browser extensions etc.). Continuous Access Evaluation (CAE), which is enabled by default for most Microsoft 365 tenants, provides a means to reject sessions in near real time if they are replayed from IP addresses in the feeds we provide. It is not the primary purpose of the feed, and its effectiveness depends on CAE being active and the resource being CAE-capable, but it does provide an additional layer of defence that is worth being aware of.
Subscriber telemetry and data privacy
We collect no telemetry from subscribers. We have no visibility into your authentication logs, your users, or your environment. If a Conditional Access policy blocks an authentication attempt based on our feed data, we do not know about it unless you choose to tell us.
This is particularly important for MSSPs. Your customers' data stays entirely within their Microsoft tenants. The feed writes data in; it does not read anything back. There is no reporting channel, no analytics pipeline, and no data leaving the tenant as a result of using the feed.
Summary
The Lab539 AiTM Feed uses existing Entra ID capabilities to prevent account compromise rather than detect it after the fact. It deploys without agents or appliances, operates independently of Microsoft's built-in detection, updates continuously as new infrastructure is identified, and leaves you in full control of enforcement.
For MSSPs managing multiple customer tenants, this means fewer compromise incidents to investigate and a measurable reduction in reactive workload - not because alerts are being suppressed, but because the attacks are being stopped before they succeed.