One Stolen Credential, 27 Organizations: Inside the Entra ID Attack That's Spreading Through MSPs

Table of Contents

• Who's confirming this, and what they found
• Terms worth getting straight first
• What the attacker actually did, step by step
• Why this spread to 27 organizations instead of one
• The detail that should worry you more than the headline number
• What's still unknown
• Why this matters if you're working with Azure identity
• What we're not claiming

Most breach stories this year have had a familiar shape: phishing email, stolen password, maybe MFA fatigue, attacker gets in. This one is different, and worth understanding specifically because it doesn't fit that pattern at all. A security firm reported this week that a single actor is signing into Microsoft Entra ID not as a person, but as applications — using stolen credentials that were never meant to involve a human login screen, MFA prompt, or password reset flow in the first place. The campaign has reached 27 organizations so far, largely by walking through the managed service providers that serve them.

Who's confirming this, and what they found

The research comes from Todyl, a security firm, which published its findings on November 3, 2026. Cybersecurity Dive's coverage the next day, November 4, adds corroboration from a second firm, Huntress, whose principal security operations analyst Jon Semon is quoted directly, and whose researchers traced the activity to a hosting IP based in Poland. Both write-ups describe the same core numbers: the actor tried roughly 45 application registrations across about 18 organizations, successfully authenticated to more than 33 of them, and from there reached 27 organizations total — the gap between "organizations targeted" and "organizations reached" accounted for by the fact that some of the compromised applications belonged to managed service providers whose access extends into their clients' environments.

Neither source names the attacker. Todyl explicitly assessed the activity as unrelated to a separate, previously reported campaign involving the ConnectWise platform and a group tracked as Storm-0940. No Microsoft statement appears in either piece reviewed for this post, and Todyl itself is careful to note that no Microsoft vulnerability is involved — this isn't a flaw in Entra ID's code, it's the abuse of valid, stolen credentials.

Terms worth getting straight first

Entra ID is Microsoft's cloud identity service — the system that decides who and what is allowed to sign in to Microsoft 365, Azure resources, and connected applications. It used to be called Azure Active Directory.

App registration is how a piece of software, rather than a person, gets an identity inside Entra ID. When one system needs to talk to another automatically — a script pulling data from Microsoft Graph, a CI/CD pipeline deploying to Azure — it authenticates using an app registration's credentials instead of someone typing a password.

Client secret is one way an app registration proves it is who it claims to be — essentially a password for software rather than a person. Whoever holds a valid client secret can authenticate as that application, with whatever permissions that application has been granted.

GDAP (Granular Delegated Admin Privileges) is the mechanism Microsoft gives managed service providers to manage their clients' Microsoft 365 and Azure environments without needing separate logins for every client tenant. It's built for legitimate efficiency — one MSP technician managing dozens of customers — but it also means a single compromised MSP credential can, by design, reach into every client tenant that MSP administers.

What the attacker actually did, step by step

Starting November 1, 2026, according to Todyl's research, the actor began using stolen client secrets to sign in as application registrations rather than as people. Once authenticated, the pattern was methodical: first requesting tokens for Azure Resource Manager and Key Vault, then branching out to Microsoft Graph, Storage, and Cognitive Services tokens. From there, the actor ran Graph API searches across roughly 25 tenants, downloaded 81 files, and accessed somewhere around 2,279 to 2,300 mailbox items, depending on which outlet's rounding you use. In at least one documented instance, the actor also used an Azure DevOps federated workload identity and replayed session tokens belonging to two actual DevOps users.

The pace of the activity is itself a signal: Cybersecurity Dive reports that roughly 95% of the sign-ins were scripted rather than manual, arriving in bursts — 24 sign-ins within 10 seconds, followed by fixed 11-second retry loops. That's not a person clicking through logins; it's automation working through a pre-assembled list of stolen credentials at machine speed, which is also why Cybersecurity Dive describes the operation as behaving "like a self-propagating worm" even though researchers were careful to clarify it isn't being treated as a traditional supply-chain attack in the formal sense.

Why this spread to 27 organizations instead of one

This is the part of the story that's genuinely instructive beyond this one incident. The jump from "18 organizations targeted" to "27 organizations reached" happened specifically because some of the compromised application registrations belonged to managed service providers, and MSPs' GDAP and multi-tenant relationships are built to let one provider's credentials reach across every client they manage. That's not a flaw in GDAP itself — it's the feature working exactly as designed, just now in the hands of someone who stole the credential it was protecting. A single compromised MSP application effectively multiplies an attacker's reach by however many downstream clients that MSP serves, which is precisely why MSP credential security has become its own distinct risk category rather than something that can be folded into general "endpoint security" advice.

The detail that should worry you more than the headline number

Here's the part worth sitting with longer than the "27 organizations" headline: application and service-principal authentication doesn't trigger an MFA prompt at all. A person signing in gets challenged for a second factor; a script authenticating with a valid client secret does not, because there's no human on the other end for MFA to interrupt. That means every organization that has invested heavily in strong MFA for its human users can still be fully exposed through this exact pathway, because MFA was never designed to apply here in the first place. Todyl's own summary of the situation is blunt: if the credential is valid, the application is in — full stop, regardless of how strong the surrounding human-facing security posture is.

What's still unknown

Both sources are explicit about the limits of what's confirmed. How the attacker originally obtained the stolen client secrets is not known — Todyl states this directly rather than speculating. The attacker hasn't been named or formally attributed to a known group, beyond Todyl's assessment that it's a different operation from the Storm-0940 ConnectWise campaign. Huntress's tracing of the activity to a Poland-based hosting IP is a lead, not a confirmed origin for the actor themselves — hosting infrastructure and an attacker's actual location or identity are two different things. And per Todyl's own characterization in the most recent write-up available, the campaign is still active, meaning the final count of affected organizations may not be 27 by the time this is read.

Why this matters if you're working with Azure identity

If you're learning or working with Azure, the practical lesson here isn't "turn on MFA harder" — it's that application identities need their own dedicated security discipline, separate from how you think about human user accounts. Client secrets need rotation schedules, just like passwords used to before password managers made that less of a manual chore. Service principal permissions need to follow least-privilege the same way human role assignments do, so that a single compromised application credential doesn't carry Key Vault, Storage, and Graph access all at once. And if you administer client environments as an MSP or work with one that does, GDAP relationships deserve the kind of access review and monitoring that a direct admin login would get, not less. Identity and access management is one of the core modules in Innovative Academy's Azure Training in Bangalore, specifically covering app registrations, service principals, and role-based access control — plus the monitoring habits that would actually surface a pattern like 95% scripted sign-ins arriving in 10-second bursts, instead of that anomaly going unnoticed until an outside research team stumbled onto it independently. Contact for course details: 8447712333.

What we're not claiming

Entra ID itself does not have a confirmed security vulnerability here — both sources reviewed are explicit that no Microsoft flaw is involved, and the attack works entirely through stolen, valid credentials rather than any weakness in Microsoft's platform. Who's behind the campaign is a separate open question: no attacker name or nation-state attribution is established in the reporting checked for this piece, and the Poland-hosted IP Huntress traced is infrastructure, not a confirmed identity. The 27-organization figure, and the 45-registration and 33-authentication figures behind it, come from Todyl's own research as relayed through two outlets that corroborate each other closely — but Todyl itself describes its own count as a floor, meaning the real number could be higher by the time any final accounting is done. Treat the specific figures as a snapshot of an investigation still in progress, not a closed case.