What Happened in the Key Eater Campaign
An attacker is signing into Microsoft 365 and Azure as trusted apps, not as people. Since November 1, 2026, the Key Eater campaign has hit 27 organizations by using stolen Microsoft Entra ID app credentials, mostly through managed service providers and their customers (GBHackers, citing Todyl).
Below, we break down this Entra ID app credential attack, how to protect your Microsoft 365 tenant, and how to check whether your application registrations are exposed. No Microsoft vulnerability was exploited. The attacker simply used valid client secrets.
Investigators counted about 45 targeted app registrations, 81 downloaded files and roughly 2,279 mailbox items accessed. The stolen material included password lists, private keys, VPN profiles and backup credentials, which can fuel attacks well beyond Microsoft 365.
Figures as reported by GBHackers, citing Todyl.
How the Entra ID App Credential Attack Works
Every app in Microsoft Entra ID has two parts. The application registration is the parent application object, stored in the applications object of its home tenant. Each tenant that uses the app gets a service principal, the local representation of the app, listed under Enterprise applications.
→
Service principal (per tenant)
→
Secret or certificate
→
Access token for the app
Apps prove who they are with service principal credentials. A client secret is a shared secret string, stored in the app’s passwordCredentials property and shown once as secretText. A certificate uses an asymmetric key pair: the public key sits in the keyCredentials collection, and the private key stays with the app.
App developers usually call the authentication endpoint through the MSAL library, using the application (client) ID plus a secret or certificate. In return, they get an access token issued for the service principal. That signed token is a JSON Web Token whose identity claim is the app itself, not a user account.
That is why this attack works. With a stolen secret, Key Eater requested Azure Resource Manager and Key Vault tokens, then Microsoft Graph API, Storage and Cognitive Services tokens within seconds. It ran wildcard Microsoft Graph searches across about 25 tenants and pulled SharePoint files at about one per second.
Multi-tenant application registrations made it worse. One MSP integration swept 15 customer tenants in roughly 10-second loops. Previously unused apps also started signing in within minutes, which suggests secrets harvested from Key Vault were unlocking more access. Attackers also abused an Azure DevOps federated workload identity.
Why App Credentials Are a Blind Spot
Most security programs protect people: MFA, user risk policies and Conditional Access. Workload identities, meaning service principals and managed identities, skip all of that. A secret cannot answer an MFA prompt, so a stolen one works from anywhere until it expires.
Long-lived credentials make the window huge. The Microsoft Entra admin center lets you set client secrets to expire after up to 24 months, and credentials added through Graph SDK for PowerShell or the API can last far longer, even an eight-year lifetime, unless a policy stops it.
These application authentication risks pile up quietly:
Unused credentials and stale apps that nobody owns but that still hold application permissions.
Tenant-wide access from admin consent to permissions like mail access or broad file access.
Third-party applications and OAuth-enabled apps from vendors and MSPs that reach into your tenant.
App hijacking, where an attacker with the Application Administrator role or Cloud App Administrator role adds a new secret to an existing app.
Todyl’s own guidance is blunt: user-focused Conditional Access does not replace controls for app-only sign-ins. That gap is the identity risk Key Eater exploited.
How to Check If Your Tenant Is Exposed
Start with an inventory, then look at sign-ins. These checks take an afternoon and show you where you stand.
List every app with credentials. In the Microsoft Entra admin center, open App registrations > All applications. Note each app’s secrets, certificates and upcoming expiry dates. Filter out Microsoft services applications so you can focus on your own and third-party apps.
Find long-lived and unused credentials. Use Graph Explorer or Graph SDK for PowerShell to pull passwordCredentials and keyCredentials for each app. Flag anything over 365 days and any service principal credential usage that has gone quiet.
Review service principal sign-ins. Check both successful and failed sign-ins, as Todyl advises. Look for scripted clients, unfamiliar IPs and apps that suddenly wake up.
Review permission grants. Look for application permissions that give tenant-wide access, especially mail access and broad file access, and confirm who approved the admin consent.
Check multi-tenant apps. List multi-tenant application registrations and any third-party applications from MSPs. Confirm verified publisher information and whether each one still needs access.
Check your Identity Secure Score recommendations. They flag some credential issues, but treat them as a manual and reactive recommendation, not a full review.
If you find a compromised app, preserve the audit log trail first. Then turn off the app and rotate its credentials and any downstream secrets it could reach.
Want an expert to run these checks across your tenant?
We can review your app registrations, service principals, permission grants and third-party MSP apps, and tell you where you’re exposed.
How to Lock Down App Registrations
The fix is to make secrets rare, short-lived and watched. Microsoft gives you the tools; most tenants simply have not turned them on.
Turn on application management policies
Application management policies let you control which credentials apps can use. Open Entra ID > Enterprise apps > Application policies in the Microsoft Entra admin center, or use the app management policy APIs (Microsoft Learn).
| Restriction | What it does |
| passwordAddition | Blocks new client secrets entirely |
| customPasswordAddition | Blocks user-typed secrets, which are weaker than system-generated ones |
| passwordLifetime / symmetricKeyLifetime | Sets a max lifetime (“Restrict max password lifetime”) |
| symmetricKeyAddition | Lets you restrict symmetric keys, which act like passwords |
| asymmetricKeyLifetime | Caps certificate lifetimes |
| trustedCertificateAuthority | Allows only certificates from your trusted certificate authority list |
On a phone, scroll the table sideways to see both columns.
The tenant default policy is a tenant-wide configuration that applies to all applications. Custom policies apply to select applications and take precedence over the default. A sensible start is to restrict max password lifetime to 365 days or less.
Plan rollouts carefully. Restrictions apply to new service principals and new credentials based on a creation date, and they do not block tokens for existing apps. Before blocking secrets, confirm each app has valid alternative authentication methods, or you risk a service disruption.
For true application exceptions, use a caller-based exemption. You tag excluded callers, such as an automated process, with custom security attributes. Managing them needs the Attribute Definition Administrator and Attribute Assignment Administrator roles, while the attribute assignment reader role can view them.
Replace secrets with better credentials
Use managed identities for Azure workloads. There is no secret to steal.
Use federated credentials for GitHub, Azure DevOps and other pipelines. Key Eater abused one, so scope them tightly.
Where a secret is unavoidable, use short-lived client secrets and rotate them through an automated process, stored in Key Vault.
Turn on secret scanning in your code repositories so leaked secrets get caught fast.
Add guardrails around apps
Conditional Access policies for workload identities can limit where service principals sign in from.
App instance property lock stops other tenants from changing credentials on your multi-tenant apps.
Prefer single-tenant apps where possible, and block multitenant applications and block consumer account applications if your app policies support it.
Microsoft Defender for Cloud Apps with App Governance capabilities can flag OAuth-enabled apps behaving oddly.
Protect the Global Administrator role, Security Administrator role and app admin roles with Privileged Identity Management, and give app owners a least-privileged custom role instead.
Run access reviews on stale apps and permission grants every quarter.
This is Zero Trust applied to workloads: verify every app, limit what it can reach, and assume a secret can leak.
Get a Tenant Security Review From WME
Key Eater is still active, and the original source of the stolen secrets is unknown. If your tenant has old secrets, unreviewed MSP apps or no Conditional Access for workload identities, you may be exposed today.
Windows Management Experts can review your app registrations, service principals and app policies, then help you close the gaps without breaking the apps your business relies on. Contact WME to book a Microsoft 365 tenant security review.
Make secrets rare, short-lived and watched.
We’ll review your app registrations, service principals and app policies, and close the gaps without breaking the apps your business relies on.
