Microsoft Azure Security Alert: Hackers Target Organizations Using Stolen Login Credentials

November 6, 2026

In a rapidly escalating cybersecurity incident that has sent shockwaves through the managed service provider (MSP) community and cloud security professionals worldwide, an unidentified threat actor is systematically abusing stolen Microsoft Entra ID application credentials and Azure DevOps identities to infiltrate Microsoft 365 and Azure environments. The campaign, tracked by security firm Todyl as “Key Eater,” has already reached at least 27 organisations since November 1, 2026, with the true scope likely larger. Critically, no Microsoft vulnerability is involved. The attackers are simply presenting valid credentials that organisations themselves failed to protect.

This latest wave of identity-based attacks underscores a broader and increasingly dangerous shift in the threat landscape: the targeting of non-human identities—service principals, application secrets, federated workload identities, and developer session tokens—rather than traditional user accounts. These identities often bypass multi-factor authentication (MFA) and user-focused Conditional Access policies entirely, giving attackers trusted access that looks legitimate to Microsoft’s systems.

The Campaign Unfolds: From Stolen Secrets to Downstream Breach

According to Todyl’s investigation, updated as of November 4, 2026, a single operator has been authenticating into MSP Microsoft 365 and Azure environments by impersonating the MSPs’ own applications. The actor targeted approximately 45 app registrations across roughly 18 organisations and successfully authenticated into more than 33 of them. From those footholds, the attacker pivoted into 27 organisations, including downstream clients of the compromised MSPs. Victims span critical sectors including government, energy, food and agriculture, transportation, construction and engineering, legal, education, and nonprofits.

The numbers available so far represent only organisations that send telemetry to Todyl. The actual impact is almost certainly higher. Investigators observed the actor conducting searches across about 25 tenants, downloading 81 files, and accessing approximately 2,279 mailbox items. Bulk file downloads occurred at a machine-like pace of roughly one file per second, with a clear focus on credential- and configuration-related material: password lists, private keys, VPN profiles, MFA and remote monitoring and management (RMM) API keys, backup-storage credentials, and firewall configurations.

The activity began on November 1 at 08:45 UTC with the first successful use of a stolen app credential. By November 3, the actor had escalated to sweeping 15 client tenants in rapid 10-second loops using multi-tenant and Granular Delegated Admin Privileges (GDAP) applications. After detections began firing, the operator adapted—switching to spoofed browser user agents and attempting to replay users’ refresh tokens. Those token-replay attempts were blocked by Conditional Access policies, demonstrating that well-configured identity controls can still interrupt the attack chain.

Todyl assesses the operation as the work of a single human operator working from a virtual private server and a pre-assembled stockpile of stolen secrets, rather than a self-propagating worm. Approximately 95 per cent of sign-ins used scripted clients. Bursts of up to 24 sign-ins in 10 seconds and fixed retry loops of about 11 seconds were observed. Multi-hour idle periods and tactical shifts after detection further support the presence of a human operator steering automated tooling. Confidence that the tooling is AI-assisted remains low; no clear evidence of an autonomous agent directing the activity has been identified.

How the Attack Works: Exploiting the Trust Placed in Applications

The technical elegance—and danger—of this campaign lies in its abuse of application identities. When an attacker authenticates as a service principal using a valid client secret, certificate, or federated credential, Microsoft treats the request as coming from a trusted application. No interactive user session exists, so MFA prompts do not fire and Conditional Access policies scoped to users do not apply. On-premises firewalls never see the traffic because the authentication goes directly to Microsoft’s identity endpoints.

The observed attack sequence is consistent and revealing:

1. Authenticate as an application using a stolen secret (or, in some cases, an Azure DevOps federated workload identity or a replayed user session token).
2. Immediately request tokens for Azure Resource Manager and Azure Key Vault.
3. Use Key Vault access and other permissions to harvest additional credentials.
4. Expand into previously unused applications within the same tenant within minutes.
5. Perform Microsoft Graph searches (including single-wildcard searches) and bulk-download files from SharePoint.
6. Leverage MSP multi-tenant applications, Partner Centre tokens, and GDAP relationships to reach downstream customer tenants.

Several of the initial “seed” secrets had previously been used only from staff devices and office networks. Some arrived as current-and-expired pairs. These characteristics suggest the credentials originated from a file store, configuration repository, or live backend rather than simple public code-repository scraping, although Todyl has not ruled out automated collection from exposed secrets. The precise initial source remains under investigation.

One particularly concerning observation involves AI services. At two MSPs, the actor obtained four AI-service tokens (three Cognitive Services and one Azure Machine Learning). AI configuration files were also among the downloaded material. This pattern is consistent with LLM-jacking—the theft and resale or abuse of enterprise AI access—though issuance of a token does not prove subsequent use.

Broader Context: Identity Is the New Perimeter

The Key Eater campaign does not exist in isolation. Throughout 2026, Microsoft and independent researchers have documented a sustained rise in attacks against cloud identities. Password spraying against Azure CLI using the legacy Resource Owner Password Credentials (ROPC) flow, token theft and session replay campaigns affecting dozens of organisations, passkey-themed social engineering leading to identity and cloud compromise, and sophisticated operations such as Storm-2949 and Storm-3168 (JADEPUFFER) all illustrate the same underlying reality: once an attacker possesses valid credentials—whether user or application—the traditional perimeter offers little resistance.

Microsoft’s own threat intelligence has repeatedly emphasised that identity compromise remains the leading initial access vector observed by its incident responders. Valid-account intrusions frequently lead to further credential theft, creating cascading compromise. Non-human identities have become especially attractive because they often carry broad permissions, long-lived secrets, and weaker monitoring compared with interactive user accounts.

MSPs sit at a particularly dangerous intersection. A single compromised multi-tenant application or poorly scoped GDAP relationship can expose dozens or hundreds of downstream customers. In the Key Eater activity, one compromised MSP app was observed sweeping 15 client tenants in rapid succession. The files harvested—VPN configurations, RMM keys, backup credentials—extend the potential blast radius far beyond Microsoft 365 into on-premises and hybrid environments that security teams monitoring only cloud logs cannot see.

Indicators of Compromise and Detection Guidance

Todyl has published high-confidence indicators, most notably the IP address 199.19.77.84, which accounted for all confirmed malicious app sign-ins, downloads, and token replays observed in their telemetry. Related addresses in the 199.19.77.0/24 range and 65.87.223.26 have been associated with password-spray activity. Organizations are advised to block these addresses via Conditional Access policies rather than relying solely on network firewalls, because the authentication traffic never reaches the customer’s network edge.

Key behavioural detections recommended by investigators include:

• AADSTS7000215 (invalid client secret) or AADSTS7000222 (expired secret) followed within minutes by a successful sign-in for the same application from the same IP.
• A single external IP authenticating as service principals across multiple unrelated organisations within a short time window.
• Azure Resource Manager token requests immediately followed by Key Vault token requests, then authentication by previously unused applications.
• High-speed, app-only SharePoint downloads focused on credential-related filenames.
• Fixed-interval retry loops against disabled or rotated credentials.
• Refresh-token replay attempts from hosting-provider IP addresses using scripted clients.

Organisations should examine both AADServicePrincipalSignInLogs and AADNonInteractiveUserSignInLogs, as well as Azure activity logs, Key Vault audit logs, Storage diagnostics, Azure DevOps audit logs, and Microsoft 365 unified audit logs.

Recommended Defensive Actions

Immediate response for potentially affected organisations includes:

• Inventorying every application registration, service principal, client secret, certificate, and federated credential.
• Removing all secrets, certificates, and federated credentials from any application showing suspicious activity, then rotating any secrets the application could have accessed (especially those in Key Vault).
• Reviewing and tightening GDAP relationships and Partner Centre access for MSPs.
• Implementing Conditional Access policies that apply to workload identities and block known malicious infrastructure.
• Preferring managed identities and workload identity federation over long-lived client secrets wherever possible.
• Ensuring that secrets are never stored in documentation, runbooks, PSA/RMM tools, or code repositories.
• Enabling and monitoring Key Vault audit logging and setting alerts on unusual secret access.

Longer-term hardening requires treating non-human identities with the same rigour traditionally applied to privileged user accounts: least privilege, short credential lifetimes, continuous monitoring, and regular access reviews.

Implications for the Industry

The Key Eater campaign is a stark reminder that the cloud’s greatest strength—its seamless integration of identity, applications, and services—is also its greatest vulnerability when credential hygiene fails. As organisations accelerate adoption of AI services, multi-tenant SaaS platforms, and MSP-managed environments, the attack surface of non-human identities continues to expand.

Security teams can no longer treat application secrets as secondary concerns. A single overlooked client secret in a forgotten app registration, a long-lived certificate, or a developer session token left in a configuration file can open the door to an entire ecosystem of downstream customers. The speed at which the Key Eater operator moved from initial access to multi-tenant compromise—minutes rather than days—leaves little room for slow, manual response.

Microsoft has not publicly attributed the campaign and has stated that no platform vulnerability is involved. The responsibility for prevention and detection therefore rests primarily with the organisations that create, store, and grant permissions to these application identities. Until credential management for non-human identities reaches parity with user identity security, campaigns of this type will continue to succeed.

As of November 6, 2026, the activity remains ongoing. Organisations that rely on Microsoft Entra ID, Azure, or MSPs should assume they may already be in the attacker’s stockpile of targets and act accordingly: audit, rotate, monitor, and restrict. In the identity-centric threat landscape of 2026, valid credentials—whether belonging to a person or an application—are the most valuable currency an attacker can hold.