Entra ID Password Spraying using APIM as IP-Rotating Mechanism

Attackers don’t just hack in, they often just log in. And sometimes they just try to log in an automated approach. This is where password spraying comes in.

Check my website https://www.patrick-binder.de/

Disclaimer and Scope

This article covers how Azure API Management can be used as distributed reverse proxies for authentication traffic, specifically as an IP-rotating tool for password spraying EntraID credentials.

This article explains how cloud integration services like Azure APIM can be exploited as distributed reverse proxies for authentication traffic.

I have created apimspray, as an alternative to the now-defunct Fireprox, serves as a straightforward Entra ID password spraying tool that utilizes Azure API Management objects for IP rotation.

Before sharing this information, I worked with the Microsoft Security Response Center to confirm the boundaries for disclosure. Microsoft verified that the technique uses intended features of the platform and does not expose any product vulnerability.

The cloud gateway pattern, from FireProx to apimspray on Azure

The idea of using IP rotating proxies via cloud API gateways is not new. For years, the offensive security community relied on this pattern to distribute traffic and avoid simple IP based controls. Tools like Fireprox, demonstrated how effective this approach could be by abusing AWS API Gateway to generate large numbers of short lived endpoints, each presenting a different source IP. For a long time, this worked exceptionally well. That well that many bruteforce and password spraying tools like o365spray implemented a specific proxy parameter for Fireprox.

As this method is no longer effective, it raises the question of other options. Several approaches exist to achieve distributed egress in the cloud. Logic Apps, Azure Kubernetes, Service, Azure virtual machines with diverse outbound IPs, Azure Front Door, Traffic Manager, Azure Functions, Automation Accounts, and similar services.

→ → All provide mechanisms to spread requests across multiple addresses. There is a tool called OmniProx which allows you to deploy such HTTP proxy mechanism via Azure, Cloudflare, GCP or Alibaba.

The underlying idea remains the same if we use this during credential based attacks. Each authentication attempt is routed through a different source IP, reducing per IP noise, lowering the likelihood of blocks, and decreasing the volume of alerts triggered by reputation or rate based defenses.

The Toolkit in Action

Apimspray uses Azure API Management (APIM) gateways as a distributed egress layer. Each authentication attempt is routed through a different APIM gateway endpoint, resulting in rotating Microsoft-owned source IP addresses.

Step1 Preparation

Clone the Repository to your localhost or Azure Cloud Shell: crtvrffnrt/apimspray: Azure apim mini proxy

This script requires an active Azure Subscription with resource creation permission. The associated costs are minimal even during intensive usage, expenses typically remain under $1.

As preparation, we need a users.txt containing UPNs. And a password list. For enumerating usernames, there are different tools out there which can help you. There are also different portals out there which can help you to identify valid UPNs Apollo.io, Hunter.io or LinkedIn.

Step 2: Infrastructure Deployment

To get our IP-Rotating mechanism working we will now deploy several Azure APIM objects.

The apimspraycreate.py script leverages your own Azure subscription to deploy ephemeral resources. If you want to spray aggressively from all possible regions use such a command

python3 apimspraycreate.py - count 100 - outfile urls.txt

This will deploy 100 APIM URLS (good number for real assessments) across all possible regions. The URLs will be written into urls.txt which we need in next step.

Note: If you successfully spray an account the likelihood is high to trigger an “Unfamiliar Sign-In Properties” alert. But there is also a more sneeky approach!

To make spraying more discreet, specify locations within the region where the user is most likely working.

python3 apimspraycreate.py --location germanywestcentral,westeurope --count 33 --outfile urls.txt 

This approach reduces the number of egress IP variations but also lowers the chance of triggering an EntraID Identity Protection alert if successful. Even if an “Unfamiliar Sign-In Properties” alert occurs, we have better chances that the SOC analyst will not identify it as a True-Positive.

The script creates the defined number of Azure API Management instances and configures each of them as a minimal reverse proxy for Entra ID authentication traffic.

https://login.microsoft.com/common/oauth2/token

For every APIM object, a dedicated API is deployed that exposes a single POST endpoint at /oauth. This endpoint is not an authentication service by itself. Instead, it acts purely as a forwarding layer.

Internally, apimspraycreate.py uses the Azure management APIs to provision an APIM service, define an API operation, and attach a backend policy. This policy transparently forwards incoming POST requests to the Microsoft Entra ID OAuth2 token endpoint at:

https://login.microsoft.com/common/oauth2/token

Step 3: ExecutionNow we are ready to rumble. Let’s fire up apimspray.py

Now we are ready to rumble. Let’s fire up apimspray.py

This is the core engine. It orchestrates the authentication traffic through the deployed gateways. Execute a spray with medium pacing like this:

python3 apimspray.py - urls urls.txt - mode spray - users users.txt - passwords passwords.txt - pace medium

This spraying attempt identified two valid credentials: one for a disabled account and one for an enabled account. The Sign-in events for this activity appear as follows.

Each Username:Password pair was sent through a unique APIM URL, so Entra ID saw each login as coming from a different Microsoft IP address.

At this point you might ask yourself how this can improve my Security Posture! My recommendation to you: Export a full list of valid UPN`s from EntraID and create a list of 9 likely valid passwords from these categories

• Generic passwords from the old times
• Most likely password based on company name, hometown or address of your headquarters
• Your own real password as positive test (optional)
• Current and historical used generic initial passwords

This is a example list for Contoso

Contoso!2025 // Company Name
Contoso@2025 // Company Name
Contoso2025! // Company Name
Welcome@Contoso2025 // generic Init-Passwords
Welcome@Contoso // generic Init-Passwords
Paris2025! // Headquarters City
Paris@2025 // Headquarters City
ChampsElysees48 // Headquarters Street
ChampsElysees2025! // Headquarters Street

If credentials match, log in. To see what you are encountering!

The purpose of this exercise is to observe the functionality of EntraID, Defender XDR, and your Tenant at all from an adversarial perspective.

Next review which alerts were triggered across Entra ID Identity Protection, Defender XDR and Sentinel.

Review if Conditional Access Policies worked as intended, ensuring MFA, risk-based blocks, and sign-in restrictions were applied consistently.

If you have a SOC in place, do me a favor and give them a signal to let them know what your are going to do.

Smart Lockout

Microsoft Entra Smart Lockout exists to slow down or even interrupt password guessing attempts while preserving user experience. In other words, it tries to block the attacker without locking out the user.

Smart Lockout is not a naive counter. It is an adaptive system that considers signals such as sign in location familiarity and observed malicious activity. Microsoft documentation describes a default lockout threshold of 10 failed attempts in Azure Public clouds, with an initial lockout duration of one minute that increases on subsequent attempts.

The documentation was crucial for setting apimspray´s parameters, based on the assumption that most companies use default values. If a tenant adjusts these defaults, such as setting the threshold from 10 to 9 and lockout from 60 to 70 seconds, apimspray becomes less effective. Slightly increasing restrictions without impacting user experience improve security, as it decreases the effectiveness of such attack tools.

Bruteforcing a single account is effectively limited by Smart Lockout, which blocks further attempts without hindering legitimate user sign-ins from familiar locations.

However, attackers bypass this by spraying a single password across many accounts, keeping each individual account’s failed attempts below the lockout threshold. Additionally, when attack traffic is distributed among numerous IP addresses, IP-based throttling loses effectiveness and weakening detections based solely on the activity of a single IP.

It is important to keep Smart Lockout in mind during authorized penetration testing activities. If you attempt a single password across all users, no accounts will be locked. However, if you run this script multiple times using many different passwords, you may trigger account lockouts at some point. This increases the likelihood that users themselves will be unable to log in interactively for some time.

If your target environment uses Modern Workplace with Intune-managed devices and users sign-in through Edge SSO, interactive sign-in to Entra ID is typically not required during a common workday. In most cases, triggering Smart Lockout shouldn’t disrupt user activity since lockout resets after 60 seconds. For effective ethical password spraying, limit your password list to fewer than 20 strings for a single run to minimize impact.

Detection

Detection engineering methods for such spraying attacks can be complex. If an attacker uses a single password like “CompanyName2025!” across hundreds or thousands of UPNs and only targets it once per user, it becomes difficult to develop accurate detections with a good Signal-to-Noise ratio.

Attempts to develop a reliable KQL query for identifying successful password spraying attacks revealed significant obstacles. A primary issue is the high level of noise in the results; attackers are constantly spraying passwords across all tenants, resulting in numerous legitimate successful login attempts being logged alongside malicious ones. This makes it difficult to distinguish between genuine user activity and successful attacks.

If you have Entra ID P2, Identity Protection provides risk signals such as password spray detections and suspicious sign ins.

While testing apimspray, several Entra ID Identity Protection alerts were triggered such as Atypical Travel, Unfamiliar sign-in properties, and even one Attack Disruption event that automatically disabled a successfully sprayed user.

But would these alerts still be triggered if the user did not have any license, had never logged into EntraID before, or was just recently created???

What I’m trying to consider is that EntraID Identity Protection requires context, historical telemetry, and actual user activity to establish what is “normal” for a user in order to determine if something is suspicious.

The most effective detections are those that automatically trigger containment actions, and the best containments are those that don’t disrupt business operations when activated.

In my opinion, Microsoft’s Defender Attack Disruption is one of the standout features within the Defender Suite. I’ve witnessed many incidents where Defender responded appropriately. I can’t recall any explicit false positives where Attack Disruption acted incorrectly.

Microsoft has achieved an impressive balance between acting when necessary and maintaining business continuity.

Because of its nature, we can’t depend solely on Microsoft’s built-in features when it comes to password spraying using a IP-Rotating mechanism like we did it with apimspray.

From a threat modeling perspective, this uncertainty is a structural advantage for attackers. We must therefore assume that this situation will not fundamentally change in near future. As long as password based authentication exists, password spraying will remain a viable, low cost, and scalable attack technique for initial access.

Password spraying is not a theoretical risk or a legacy problem. It is a persistent and serious threat to every Entra ID tenant. The realistic defensive goal is not perfect prevention or flawless detection, but reducing the number of exploitable identities, minimizing the blast radius of compromised credentials, and ensuring that downstream controls reliably break the attacker’s kill chain once a password is successfully guessed.

The Microsoft IP fallacy in practice (Must Read for all SOC-Analysts)

When defenders refer to something as “coming from Microsoft”, they typically mean either the sign-in log shows an IP owned by Microsoft or the ISP field lists the cloud provider directly. Teams often assume such traffic is harmless, but this is a flawed view that oversimplifies network traffic as just “our users” versus “others.”

In reality, if IP-Rotating proxies like Bright Data were used, Entra ID would block authentication attempts by default, and these proxies usually have poor reputations, especially low-cost or free ones.

For sure this can happen to an Azure APIM IP as well. But in my tests all Ips I got from Microsoft had a good reputation.

ipscan.info IP Reputation intelligence aka neon intel

I checked for example the IP 40.119.174.131 with ipscan.info, which reviews IP reputation across platforms like VirusTotal, AbuseIPDB, Kaspersky, Alienvault OTX, OPSWAT and others. None of them flagged any Microsoft-provided IPs as suspicious.

A clean APIM IP offers a positive initial IP reputation from the perspective of an attacker.

It is important for defenders to recognize that if an IP address belongs to Microsoft, it should not be automatically considered as secure. Attackers have the capability to use Azure virtual machines for their outgoing activities. Therefore, extra caution is advised when investigating EntraID Identity Protection alerts referencing Microsoft-owned addresses. A single tenant may observe sign-in events originating from Microsoft egress IPs for several reasons, including:

1. Azure Virtual Desktop and Cloud-PCs.

2. Third-party integrations hosted on Azure.

3. Customer-deployed automation, such as Logic-Apps, Azure DevOps CI/CD Pipelines and many more.

Many successful sign-in attempts originate from Microsoft’s IP range, making it difficult for defenders to differ between legitimate activity from malicious actions. You can check if a IP is related to Microsoft at https://www.azurespeed.com/

The issue is that you can’t identify the specific service linked to the IP.

This diversity illustrates why a “Microsoft IP” should not be inherently trusted. Any defensive strategy that relies solely on blocklists becomes fragile, as blocking the entire Azure backbone would disrupt legitimate access patterns. Threat actors are aware of this and may select infrastructure commonly associated with atypical travel or unfamiliar signin property alerts.

Defenders once used IP reputation to block malicious networks and flag suspicious activity, but this was more effective when attacks came from easily identified sources. Now, as cloud platforms are widely used, both harmful and legitimate traffic often share the same IP ranges and data centers. For organizations with Microsoft 365 and Azure, Microsoft datacenter IPs frequently appear in login data, so their presence alone doesn’t guarantee legitimacy.

Remediation and attack surface reduction

Effective threat modeling involves adopting the perspective of potential attackers. Most adversaries prioritize efficiency and seek methods that require minimal effort, often exploiting weak or inconsistent security measures through techniques that can be easily automated and scaled.

Password spraying continues to be a common attack method and is not expected to be fully eliminated in the coming years. Although Microsoft is working to counter this trend, for example, by deprecating Auth SMTP or promoting passwordless authentication, passwordbased authentication will persist in some form across various Tenants. As such, attackers are likely to continue targeting it, given that it remains one of the more vulnerable components in the security chain.

Remediation therefore starts with reducing this attack surface as much as possible. First of all back to the basics:

Microsoft strongly recommends that all accounts use multi-factor authentication. In practice, this must not be treated as a static configuration goal, but as a continuously enforced security control. Organizations must regularly validate that every identity has MFA correctly registered and that no accounts silently fall out of compliance due to onboarding gaps, lifecycle issues, or legacy exceptions.

While newly created tenants ship with MFA enabled by default, this baseline alone is not sufficient. Over time, tenant configurations evolve through exclusions, Conditional Access exceptions, service accounts, migrations, and inherited technical debt. Without continuous review, these changes can unintentionally reintroduce credential-only authentication paths that attackers actively seek to exploit.

Under an Assume Breach and Zero Trust mindset, defenses should not rely solely on downstream controls. Successful password spraying must be treated as a realistic event, even in mature environments. The focus should be on minimizing the number of exploitable identities, eliminating MFA gaps, tightening Conditional Access exclusions, and continuously validating that no authentication path exists where weak credentials alone are sufficient.

So what can we do to minimize the risk of password spraying attacks?

There is a wide range of things you can do for hardening around this. Let me give you some no-brainers to make EntraID more resilient to credential based attacks like this.

1. Reduce attack surface

Enumerate all user accounts in Entra ID. Make sure you don’t have Accounts in EntraId without a MFA Method registered.

Authentication Methods → User registriation Details → Check empty lines in Colum “Methods Registered”

2. Exclude all accounts from Cloud-Sync which are not needed in EntraID

In hybrid environments, it is essential to carefully control the synchronization scope. Syncing entire Organizational Units (OUs) for convenience introduces unnecessary risk. To reduce the attack surface, utilize directory synchronization filtering to ensure that only accounts necessary for business operations are synchronized. Especially OnPrem Service Principals with elevated permissions should not synced towards EntraID.

nagios@company.local
Lansweeper@company.local
veeam@company.local
SQL@company.local
Backup@company.local
ldap@company.local

3. Reduce Password Guessability

Password spraying attacks succeed because users often select predictable passwords.

You can avoid this issue by not enforcing password expiration in EntraID. Forcing users to change passwords every 90 days or annually often leads to predictable choices like “Summer2024!”. Even Microsoft recommends to not let passwords expire.

You can change the settings in Org Settings with M365 Adminportal

There is another important consideration to note. When attempting to change a password in EntraID to a highly guessable one like “Summer2024!”, Microsoft prevents this action with the error: “Choose a password that is harder to guess”

However, if the password change originates from On-Premises and is then synchronized to EntraID, this restriction does not apply. Consequently, cloud-only tenants demonstrate greater resilience against password spraying attacks compared to hybrid environments.

One powerful technical mechanism to make your tenant less vulnerable to password spraying attacks is by adding Custom banned password list to EntraID. Use strings which a attacker would likely use to build his password.txt file. Like, Company-Name, Headquarters City and Street name or old generic initial passwords.

Next change the lockout threshold for Smart Lockout to a number between 5 and 9 and increase lockout duration to make it longer than the default of 60 seconds:

4. Conditional Access Hardening Recommendations

Conditional Access Policies remain one of the most effective control planes for disrupting password spraying and APIM-based credential attacks. The following recommendations focus specifically on closing the gaps attackers exploit after obtaining valid credentials.

Restrict MFA registration to trusted locations. The registration of new MFA methods should be allowed only from corporate office networks or explicitly trusted locations. This prevents attackers who successfully guess a password from immediately enrolling their own MFA factors. For front line workers or remote onboarding scenarios, Temporary Access Pass should be used as the only exception mechanism, time bound and closely monitored.

A separate Conditional Access Policy should control MFA registration, restricting it by user risk level. Block MFA method registration for users at low, medium, and high risk.

Conditional Access acts as a post-compromise control as well to disrupt attackers after password validation. Since some credentials may be compromised, defenses against password spraying should anticipate this risk. Microsoft Cloud Security Stack provides additional tools, features and possibilities to enhance security against credential-based attacks. Effective cyber-resilience starts with simple, consistent basic configurations. Continuously improve your security posture by regularly reviewing Conditional Access, Identity Protection, and potential attack paths.

Keep your BASICS strong! Stay Secure.