Threats like password spray or adversary-in-the-middle (AiTM) are routine and too easily overlooked in an endless stream of security alerts. But what if these routine threats are only a small part of a much deeper, more sophisticated attack?

Since June 2025, Microsoft Defender Experts has been closely monitoring a sophisticated and continuously evolving attack campaign targeting poorly managed Azure cloud environments. What sets these threats apart is their use of Azure’s elasticity and interconnected structure, which allows users and attackers alike to move more easily through multi-tenant environments and avoid basic detection. By specifically targeting student and Pay-As-You-Go accounts that are improperly secured and poorly monitored, adversaries can rapidly move across tenants, weaponize ephemeral resources, and manipulate quotas—constructing a resilient and dynamic ecosystem. Their methods blend so seamlessly with legitimate cloud activity that they frequently evade basic threat detection methods, taking full advantage of trusted cloud features to ensure persistence and scale.

The campaigns demonstrate how today’s adversaries can transform even a single compromised credential into a sprawling and complex attack across multiple tenants.

Attackers no longer simply establish static footholds; instead, every compromised account becomes a possible springboard, every tenant a new beachhead. Their arsenal is thoroughly cloud-native: rapidly deploying short-lived virtual machines, registering OAuth applications for ongoing access, manipulating service quotas to expand their attack infrastructure, and abusing machine learning workspaces for covert activity. The result is an attack ecosystem that’s agile, elusive, and built to endure in the fast-moving world of the cloud.

Why are these attacks worth watching?

These attacks represent a strategic evolution in threat actor behavior—blending into legitimate cloud activity, evading traditional detection, and exploiting the very features that drive business agility. The scale, adaptability, and persistence demonstrated in this campaign is a wake-up call: defenders must look beyond the surface, understand the full lifecycle of cloud-native attacks, and be prepared to counter adversaries who are already mastering the art of stealth and scale.

This blog doesn’t just recount what happened, it breaks down the anatomy of a cloud-scale attack. Whether you’re a security analyst, cloud architect, or threat hunter, the goal is to help you recognize the signs, understand the methods, and prepare your defenses. With the cloud, organizations benefit from scale, global access, and agility. But if not properly secured, those attributes also benefit threat actors.

Resource development: exploiting the weakest links

Microsoft Defender Experts has observed ongoing, large-scale campaigns on Azure environments. Student and Pay-As-You-Go (PAYG) accounts, were exploited due to poor security hygiene. These accounts often lacked essential protections: weak or default passwords, no multi-factor authentication (MFA), and no active security monitoring or Defender for Cloud subscription.

Initial access was achieved via adversary in the middle (AiTM) attacks or password sprays against Azure User Profile Application (UPA) accounts, commonly using infrastructure hosted by M247 Europe SRL & LTD (New York) and Latitude.

Weaponizing ephemeral infrastructure

Once access was established using a compromised account, the attacker created new Resource Groups and deployed short-lived Virtual Machines (VMs). These VMs ran for as little as 3–4 hours and up to 1–2 days before being deleted. This approach enabled rapid rotation of attack infrastructure, minimal forensic footprint, and evasion of long-term detection.

From these ephemeral VMs, large-scale password spray attacks were launched (predominantly utilizing user agents—BAV2ROPC, python-requests/2.32.3, python-requests/2.32.4) against thousands of accounts across multiple Azure tenants. Operating within Azure’s ecosystem helped the campaign stay below conventional alerting thresholds. Alerts that did occur were often dismissed as false positives or benign because they originated from legitimate Azure associated IP addresses.

Scaling through multi-hop and multitenant techniques

The sophistication of this campaign lies in their multi-hop and multitenant architecture:

• Multi-hop: Attacker used compromised Azure VMs to pivot and launch attacks on other accounts, masking their origin and complicating attribution.


• Multitenant: By controlling multiple Azure tenants, attackers distribute their operations, scale attacks, and maintain resilience against takedowns.

This cross-tenant movement within the Azure environment allows attackers to expand their footprint more easily, making detection more challenging.

Impact: spam, financial fraud, phishing, and sextortion campaigns

Following each successful password spray attack, the campaign expanded across compromised Azure tenants. Using access gained from earlier stages, the attacker repurposed virtual machines within these tenants to send large volumes of phishing and scam emails.

These phishing campaigns were carefully crafted to deceive users in compromised tenants, often leading to financial fraud involving URL shorteners like rebrand.ly, redirecting victims to fraudulent non-work related websites such as those with personal interest, entertainment, or leisure activity content.

On those fake sites, users were prompted to:

• Complete surveys or questionnaires


• Provide personal information


• Download malicious Android APKs such as FM WhatsApp or Yo WhatsApp

Note: The APK is a resigned WhatsApp clone trojan that exploits elevated WhatsApp permissions to harvest private data (contacts, files) while mimicking legitimate registration by communicating with official servers to evade detection. Its malicious actions are triggered via commands hosted in a compromised GitHub repo (xiaoqaingkeke/Stat), indicating a GitHub based C2.

In some cases, victims were lured to enter their mobile numbers for chat services or install additional video calling apps—further expanding the attacker’s reach and enabling data harvesting and even extortion.

 

Persistence and expansion

Privileged access and the infrastructure the attacker compromised, built, and used in this campaign are worthless if the attacker cannot maintain control. To maintain and strengthen their foothold, the adversary deployed multiple persistence mechanisms. Below is a summary of the persistence techniques used by the attacker, as observed by Microsoft Defender experts across compromised tenants during the investigation.

Abuse of OAuth applications

Once access to an Azure tenant was obtained, the campaign escalated by registering OAuth applications. Two distinct types of applications were observed:

• Azure CLI–themed apps (named like “Azure-CLI-2025-06-DD-HH-MM-SS” and “Azure CLI”) were registered with the compromised tenant as owner. The attacker added password credentials and created service principals for these apps to enable persistent backdoors (even attempted to re-enable a disabled subscription). In one instance, two custom Azure CLI apps were used to authenticate to Azure Databricks so access would survive account disables.


• The attacker registered a malicious custom application named MyNewApp, which was used to send large volumes of phishing emails and was successfully traced the campaign by analysing Microsoft Graph API calls, which revealed delivery and engagement patterns

Quota manipulation

To amplify the campaign’s infrastructure, the attacker exploited compromised credentials to submit service tickets requesting quota increases for Azure VM families:

• A request was made to raise the quota for the DaV4 VM family to 960 cores across multiple regions.


• A guest account, added during the attack, submitted a similar request for the EIADSv5 VM family.

These actions reflect a deliberate effort to scale up the virtual machine farm, enabling broader password spray operations and phishing campaigns.

Notably, the VM farm created by the compromised user was dismantled within three hours, while the farm initiated by the guest account remained active for a full day. This highlights the risk of guest access persistence, which often remains unless explicitly revoked.

 

Advanced abuse in Azure: ML workspaces, Key Vaults, and beyond

The recent campaign against a poorly managed, monitored, and configurated Azure environment was marked by a sophisticated, multi-stage attack that leveraged the elasticity and trusted features of cloud-native infrastructures for stealth and scale. The attacker’s operations were not limited to simple credential theft or cross-tenant movement—they demonstrated advanced abuse of Azure’s Machine Learning (ML) services, notebook proxies, Key Vaults, and blob storage to automate, persist, and exfiltrate at scale.

ML workspaces and notebook proxies: a stealthy execution layer

The attacker repeatedly created Machine Learning workspaces (Microsoft.MachineLearningServices/workspaces/write) and deployed notebook proxies (Microsoft.Notebooks/NotebookProxies/write) using both compromised user accounts and invited guest identities.

Attackers can abuse Azure ML to run cryptominers or malicious jobs disguised as training, poison or deploy compromised models, use workspaces/notebooks for persistent RCE, and exfiltrate data via linked storage. They scale with automated pipelines and quota requests, all while blending into normal AI workflows to evade detection.

Blob storage exploitation: payload staging and data exfiltration

Simultaneously, the attacker provisioned blob storage containers (Microsoft.Storage/storageAccounts/blobServices/containers/write) to stage payloads, host malicious scripts, and store sensitive datasets. The global accessibility and high availability of blob storage made it an ideal channel for covert data exfiltration and operational agility, minimizing the likelihood of detection.

Key Vault manipulation: securing persistence

The creation and modification of Key Vaults (Microsoft.KeyVault/vaults/write) suggests a deliberate effort to store secrets, credentials, and access tokens. That allowed the attacker to automate interactions with other Azure services and maintain long-term persistence. By embedding themselves into the fabric of cloud identity and access management, they ensured continued access even if initial entry points were remediated.

Damage statistics from the campaign controlled by single attacker machine

The impact? Staggering. In a matter of days, a single attacker machine was able to:

• Target nearly 1.9 million global users and compromise over 51,000 accounts.


• Infiltrate 35 Azure tenants and abuse 36 subscriptions.


• Spin up 154 virtual machines with 86 used specifically for password spray attacks.


• Raise over 800,000 Defender alerts, flooding security teams and masking true malicious activity.


• Send 2.6million spam emails.


• Abuse Azure’s machine learning services, register malicious OAuth apps, and manipulate quotas to scale up attacks—all while maintaining persistence and evading detection.

Recommendations

• Harden identity to prevent attackers from exploiting low-hanging student subscriptions.


• Enforce MFAand password protection as most of the users often don’t enroll in MFA. Investigate and auto remediate risky users/sign ins; enable token protection (where available) to reduce the blast radius of stolen cookies. Microsoft’s public AiTM guidance consolidates these defenses, and XDR’s AiTM disruption revokes cookies and disables users during active compromise. 


• Constrain abuse pathways in Azure.


• Apply least privilege RBAC, review guest invitations, and monitor for role promotions on a schedule and via near Realtime analytics, as outlined in Microsoft’s subscription compromise post. 


• Watch for subscription directory/transfer changes and couple with approval style processes; remember transfer can move management (and thus logs) while billing may not change by default. 


• Treat quota as a credit limit and instrument alerts for large, fast, or multiregion quota consumption to spot bursts (legitimate or not). Microsoft’s ML quota docs explain defaults, VM family splits (e.g., “Nseries” GPUs default to zero), and how to request increases. 

If you suspect your subscription is being misused 

1. Start an investigation using Microsoft’s playbooks (password spray) and the hunting queries below; prioritize containment of accounts with risky sign ins and recent ARM writes. 


2. If you’re a CSP partner, subscribe to Unauthorized Party Abuse (UPA) alerts and follow the documented response steps for compromised Azure subscriptions. These alerts help surface anomalous consumption and abuse earlier. 


3. Clean up tenants/subscriptions you don’t need and understand transfer/cancellation mechanics (“Protect tenants and subscriptions from abuse and fraud attacks”). This both reduces your attack surface and simplifies response. 


4. Report abuse (e.g., spam, DoS, brute force, malware) observed from Azure IPs or URLs via the MSRC reporting portal; this ensures the platform teams can act on infra being used against others.

A practical hunting mini playbook

1) Azure resource writes, role assignments, etc (last 24h) from high-risk sign-in accounts. 

 

let RiskySignin = SigninLogs

| where TimeGenerated > ago(24h)

| where RiskLevelAggregated == “high”

| project RiskTime = TimeGenerated, UserPrincipalName, IPAddress;

AzureActivity

| where TimeGenerated > ago(24h)

| where OperationNameValue has_any (

“Microsoft.MachineLearningServices/workspaces/write”,

“Microsoft.MachineLearningServices/workspaces/computes/write”,

“Microsoft.Compute/virtualMachines/extensions/write”,

“Microsoft.Authorization/roleAssignments/write”,

“Microsoft.Resources/subscriptions/resourceGroups/write”,

// Optional: include the VM create/update itself (not just extensions)

“Microsoft.Compute/virtualMachines/write”

)

or (ActivityStatusValue == “Success”

and OperationNameValue == “Microsoft.Subscription/aliases/write”)

| extend CallerIP = coalesce(CallerIpAddress, tostring(parse_json(Properties).callerIpAddress))

| join kind=inner (RiskySignin) on $left.Caller == $right.UserPrincipalName

| where TimeGenerated between (RiskTime .. RiskTime + 2h)

| summarize Ops = count(), DistinctOps = dcount(OperationNameValue)

by Caller, CallerIP, bin(TimeGenerated, 30m)

| order by Ops desc

 

2) Azure Activity (Sentinel): Support ticket creation before ML service deployment for Quota abuse 

//Below query shows the risky users writing support tickets which involve quota increase

let RiskySignin = SigninLogs

| where TimeGenerated > ago(24h)

| where RiskLevelAggregated == “high”

| project RiskTime = TimeGenerated, UserPrincipalName, IPAddress;

AzureActivity

| where TimeGenerated > ago(24h)

| where OperationNameValue has_any (“supportTickets/write”,”usages/write”)

| project QuotaTime = TimeGenerated, Caller, CallerIpAddress = tostring(parse_json(Properties).callerIpAddress)

| join kind=inner (RiskySignin) on $left.Caller == $right.UserPrincipalName

| where QuotaTime between (RiskTime .. RiskTime + 2h)

In conclusion

The cloud offers organizations many important benefits.  Unfortunately, threat actors are leveraging cloud attributes such as elasticity, scale, and interconnectedness to orchestrate persistent, multitenant attacks that evade traditional defenses. As demonstrated, even a single compromised account can rapidly escalate into a widespread attack, affecting thousands of users and tenants.

To counter those evolving threats, defenders must adopt proactive measures: enforce strong identity controls, monitor for suspicious activity, limit privileges, and regularly audit cloud resources. Ultimately, maintaining vigilance and adapting security practices to the dynamic nature of cloud environments, such as Azure, is essential to protect against increasingly stealthy and scalable adversaries and making your cloud more secure.

 

What’s next? 

Join us at Microsoft Ignite in San Francisco on November 17–21, or online, November 18–20, for deep dives and practical labs to help you maximize your Microsoft Defender investments and to get more from the Microsoft capabilities you already use. Security is a core focus at Ignite this year, with the Security Forum on November 17th, deep dive technical sessions, theater talks, and hands-on labs designed for security leaders and practitioners

Featured sessions

• BRK237: Identity Under Siege: Modern ITDR from Microsoft
  Join experts in Identity and Security to hear how Microsoft is streamlining collaboration across teams and helping customers better protect, detect, and respond to threats targeting your identity fabric.


• BRK240 – Endpoint security in the AI era: What’s new in Defender
  Discover how Microsoft Defender’s AI-powered endpoint security empowers you to do more, better, faster.


• BRK236 – Your SOC’s ally against cyber threats, Microsoft Defender Experts
  See how Defender Experts detect, halt, and manage threats for you, with real-world outcomes and demos.


• LAB541 – Defend against threats with Microsoft Defender
  Get hands-on with Defender for Office 365 and Defender for Endpoint, from onboarding devices to advanced attack mitigation.

Explore and filter the full security catalog by topic, format, and role: aka.ms/SessionCatalogSecurity.

Why attend?
Ignite is the place to learn about the latest Defender capabilities, including new agentic AI integrations and unified threat protection. We will also share future-facing innovations in Defender, as part of our ongoing commitment to autonomous defense.

Security Forum—Make day 0 count (November 17)
Kick off with an immersive, in person preday focused on strategic security discussions and real-world guidance from Microsoft leaders and industry experts. Select Security Forum during registration.

Register for Microsoft Ignite >