Key Eater: An Audit Playbook for Entra ID App Credentials After 27 Organisations Were Reached

Todyl’s team reported on 3 November 2026 that an unattributed actor is signing in to Microsoft Entra ID and Azure DevOps as applications. It uses stolen client secrets that were still valid. Todyl’s update headline calls the activity Key Eater. It has reached 27 organisations, including MSP downstream clients, since 1 November 2026.

Todyl says no Microsoft vulnerability is involved. If the credential is valid, the app is in, with no MFA prompt and no user scoped Conditional Access. That makes this a credential hygiene job: find every app secret you own, learn where it lives and make it worthless to a thief.

What Did Todyl Observe in the Key Eater Activity?

The actor signed in as service principals with client secrets, used an Azure DevOps federated workload identity and replayed two users’ Azure DevOps session tokens. For each credential it ran a fixed token sequence: Azure Resource Manager first, then Key Vault, often followed within seconds by Storage, Microsoft Graph and Cognitive Services. Where it could, it also asked for a Partner Center token.

Inside tenants it ran single wildcard Graph searches, 29 in total across about 25 tenants, then downloaded SharePoint files at about one file per second. Todyl says the names it chased were credential and configuration related: password lists, private keys, VPN profiles, MFA and remote management API keys, backup storage credentials and firewall configurations. Todyl has not observed persistence, and describes the pattern as collection, not dwell.

The path into client tenants ran through MSP multi-tenant and delegated admin apps. Todyl says one compromised MSP app can expose every client that MSP manages.

Which Of Your Own App Credentials Would Work For This Actor?

Any client secret, certificate or federated credential on an app that can reach Azure Resource Manager, Key Vault, Storage, Graph or Partner Center. Todyl notes that several seed secrets had only been used from staff devices and office networks, and some arrived as current and expired pairs. It reads that as pointing to a file store or live backend, not secrets crawled from the internet, and says it does not yet know how the credentials were obtained.

Our service principal glossary entry and the entry on non-human identities explain why these accounts sit outside user focused controls. ATT&CK maps the use of such credentials to valid accounts; Todyl lists seven techniques for this activity, among them T1078.004, T1550.001, T1555.006 and T1199.

How Do You Audit App Credentials, Step by Step?

Todyl’s own list blocks the operator address first and hunts second. We put the hunt first, because rotating a secret before you know which app was used destroys that evidence. The order and the inventory step are ours; the other steps come from Todyl.

What Should the Hunt Look For in Sign-In Logs?

Todyl’s first hunt in those two tables is a failed sign-in. The error is AADSTS7000215 (invalid secret) or AADSTS7000222 (expired secret), followed by a success for the same app from the same address. It calls that urgent.

Other patterns: one address authenticating as service principals across unrelated organisations within 24 hours. Another is one app fanning out across Resource Manager, Key Vault, Storage and Graph, then unused apps authenticating within minutes.

It also lists app only SharePoint downloads at about one file per second from non Microsoft addresses. Fixed retry loops of about 11 seconds and bursts of up to 24 sign-ins in 10 seconds are further signs. Failed sign-ins from hosting providers that never succeed also count, so do not key detections only on success.

Todyl also points to sign-ins to the Azure CLI public client with the password grant from hosting providers. It adds that refresh token replay from scripted clients was blocked by Conditional Access on 3 November.

union AADServicePrincipalSignInLogs, AADNonInteractiveUserSignInLogs
| where ResultType in ("7000215", "7000222")
| project TimeGenerated, AppId, ServicePrincipalName, IPAddress, ResultType

This starter query is ours, not Todyl’s. Pair it with a second pass for successes from the same address.

How Do You Contain an App That Matches?

When you remove the app’s credentials, watch for ones you did not add. Disabling the service principal does not end tokens already issued; they stay valid until they expire.

Search Azure activity, Key Vault and Storage diagnostics, Entra audit, Azure DevOps audit and Microsoft 365 unified audit logs for the operator address, including secret reads and file downloads. Todyl says Key Vault audit logs are needed to confirm whether vault reads supplied new credentials.

Why Does Todyl Mention AI Services?

Todyl says four AI service tokens were issued at two MSPs: three for Cognitive Services and one for Azure ML. It also saw unauthorised use of AI models, including Anthropic Claude models, at affected organisations. It says a token being issued does not prove use, and that the pattern fits LLM-jacking. Confidence that the spike is related is moderate and confidence in the mechanism is low.

Inventory your AI resources and keys, prefer Entra ID authentication over keys, rotate keys in any reachable vault and set quotas and usage alerts. Our explainer on LLMjacking covers how stolen cloud access turns into billing fraud.

What Does Hardening Look Like After the Audit?

Todyl recommends retiring client secrets in favour of managed identities, then workload identity federation, then certificates held in a vault. Entra app management policies can block new secrets and cap credential lifetimes. Restrict Key Vault and Storage to selected networks or private endpoints, and keep secrets out of code, wikis, tickets, PSA and RMM notes.

Apply least privilege to app ownership and app admin roles, and alert on new secrets, certificates or federated credentials. For MSPs, move to least privilege, time bound GDAP and never store customer app secrets in runbooks.

What Is Still Unknown?

Todyl does not know how the credentials were first obtained, who is behind the activity or whether any vendor or AI platform is compromised. It says it sees no sign of a vendor platform compromise, and assesses the activity as unrelated to an October compromise of a vendor’s cloud backup app. It also says more victims are likely outside its view.

We will update this playbook if Todyl names a credential source or attribution. Until then, the audit above works whichever way the secrets leaked.