Stolen Entra ID app credentials and Azure DevOps identities used to breach 27 organizations
Attackers used stolen Microsoft Entra ID app credentials and Azure DevOps identities to reach at least 27 organizations via MSPs, with no Microsoft flaw
- Published
- Updated
- Ecosystem
- CloudEnterprise softwareCI/CD
- Fixed in
- No patch. Not a software vulnerability; remediation is credential rotation, session revocation and blocking 199.19.77.84
- Exploitation
- Yes, Todyl reports an ongoing campaign since November 1, 2026 using valid stolen credentials, with files downloaded and mailbox items accessed
What happened
Attackers are using stolen Microsoft Entra ID application credentials and Azure DevOps identities to access Microsoft 365 and Azure environments, reaching at least 27 organizations, according to Cybersecurity News and GBHackers. Both outlets rely on an investigation by Todyl, whose MXDR team tracks the campaign, which GBHackers says is referred to as Key Eater. It targets managed service providers (MSPs) and their customers and has been running since November 1, 2026. No primary advisory from Todyl, Microsoft or a CERT was provided, so the details below come from the two news reports.
Key facts reported:
- The operator targeted about 45 app registrations across roughly 18 organizations, and more than 33 authenticated successfully. Downstream access widened the victim count to 27. Victims span government, energy, agriculture, transportation, legal, education and nonprofit sectors. Cybersecurity News also lists construction, while GBHackers lists engineering. The figures cover only environments visible to Todyl, so the real reach may be larger.
- Investigators recorded searches across about 25 tenants, downloads of 81 files and access to about 2,279 mailbox items.
- No Microsoft vulnerability was involved. The attacker used valid credentials to act as trusted applications. Todyl also saw abuse of an Azure DevOps federated workload identity and replay of user session tokens.
- The typical token sequence is Azure Resource Manager, then Key Vault, then Microsoft Graph and Storage. GBHackers adds Cognitive Services tokens. Previously unused applications then began authenticating within minutes.
- The operator ran 29 wildcard Microsoft Graph searches, then downloaded SharePoint files at roughly one per second. Collected material included password lists, private keys, VPN profiles, backup credentials and remote access settings. GBHackers also lists MFA and remote monitoring API keys, firewall configurations and service-account maps.
- One multi-tenant MSP application swept 15 customer tenants in loops of about 10 seconds.
- Scripted clients made up 95% of sign-ins. Todyl describes automation controlled by one operator from a VPS, not a confirmed worm. AI involvement is a low-confidence possibility.
- After detections on November 3, the attacker swapped curl and Python signatures for spoofed browser user agents and replayed several users’ refresh tokens. GBHackers reports Conditional Access blocked every observed replay that day. Cybersecurity News reports the latest attempt, at 21:31 UTC on November 3, was blocked.
- Four AI-service tokens were issued across two MSPs. This fits possible LLMjacking, but token issuance alone does not prove resource consumption.
Not confirmed: how the original credentials were stolen, who the operator is, and whether additional victims exist outside monitored environments. Todyl found no evidence that a vendor platform was compromised, even though credentials of trusted security integrations were abused, and GBHackers reports no signs of persistence.
Am I affected?
You may be affected if any of these apply:
- You have Entra ID app registrations or service principals with secrets or federated credentials that could have leaked, especially ones with access to Microsoft Graph, Key Vault, Storage or SharePoint.
- You are an MSP with multi-tenant applications or delegated access to customer tenants.
- You use Azure DevOps federated workload identities, or users’ Azure DevOps session tokens could have been exposed.
Check for indicators:
- Source IP 199.19.77.84, confirmed as the operator address, in service-principal and non-interactive user sign-in logs. Failed attempts matter as well as successful ones.
- User agents task177-f2267/1.0 and sait-tenant-deep/37346 (from GBHackers).
- Previously unused applications that begin authenticating shortly after an Azure Resource Manager then Key Vault token request.
- Bursts of Graph wildcard searches followed by rapid SharePoint downloads.
App-only authentication runs without a user signing in, so existing permissions can allow access without an MFA prompt, and user-focused Conditional Access policies do not govern it, per Cybersecurity News.
What to do now
- Search service-principal sign-in logs and non-interactive user logs for 199.19.77.84, including failed attempts, and for the user agents listed above.
- Block the exact address 199.19.77.84. Todyl advises against blocking its whole hosting network, where unrelated activity exists.
- Disable affected applications where needed and remove compromised credentials from app registrations.
- Revoke user sessions, including refresh tokens, for users tied to suspicious activity.
- Rotate secrets in accessible vaults, documents and downstream systems, including exposed application credentials, VPN profiles, private keys, backup credentials and remote access or API keys.
- Review Key Vault audit logs to confirm whether harvested secrets were the source of access by newly active applications.
- Add controls for app-only authentication. Workload-specific Conditional Access has licensing and coverage limits, so user policies alone are insufficient.
- MSPs: review delegated customer access and multi-tenant applications, preserve audit logs, and notify affected clients.