Stolen Entra App Secrets: What MSPs and Microsoft 365 Customers Should Check

Since November 1, 2026, security teams have been tracking a campaign in which attackers sign into victims' own Microsoft Entra ID and Microsoft 365 app registrations, also called service principals, using stolen app secrets that are still valid. In some cases the material comes from Azure DevOps federated or session credentials. This is not a flaw in a Microsoft product. It is abuse of credentials that already exist in the tenant.

App-only sign-ins do not prompt for multi-factor authentication, and Conditional Access rules written for people often do not apply to these workload identities. After a successful sign-in, researchers report the actors moving through Azure Resource Manager into Key Vault, requesting Microsoft Graph and Storage tokens, searching tenants, downloading credential and configuration files, and, where MSP multi-tenant, Partner Center or GDAP-style access is available, reaching downstream customer tenants.

The short version: hunt your Entra service-principal and non-interactive sign-in logs for the IP and user agents below. If you see a hit, disable the app, remove its secrets and certificates, revoke sessions, and rotate anything that app could read. Todyl assesses this campaign as unrelated to the October ConnectWise Cloud Backup (SkyKick) / Storm-0940 incident we covered earlier.

What is going on

According to Todyl, Huntress, N-able, Field Effect and Cybersecurity Dive, the attackers are authenticating as the customer's own registered apps rather than as users. Because the sign-in is app-only, there is no MFA challenge for a person to approve, and many user-scoped Conditional Access policies never fire.

Once authenticated, the reported path is consistent across the reports: Azure Resource Manager access, Key Vault reads, Graph and Storage token requests, Graph searches, downloads of files that hold credentials or configuration, and use of MSP multi-tenant or Partner Center / GDAP-style relationships to reach customer environments.

Who is at risk

Any organization with Microsoft Entra app registrations that still use client secrets, and any MSP that holds multi-tenant apps or GDAP relationships into customer tenants. Todyl's numbers are a floor based only on tenants that send logs to them:

• About 45 app registrations at about 18 organizations were targeted, and more than 33 authenticated successfully.
• Activity reached 27 organizations, including MSPs and downstream clients in government, energy, food and agriculture, transportation, construction and engineering, legal, education and nonprofits.
• Searches ran across about 25 tenants; 81 files were downloaded; about 2,279 mailbox items were accessed.
• The latest observed attempt Todyl reports was on November 3, 2026 at 21:31 UTC and was blocked. Updates through November 3 and 4 describe the activity as ongoing.

Indicators to hunt

• Primary IP (high confidence): 199.19.77.84 (AS203662). Todyl ties confirmed app sign-ins, downloads and token replays to this address.
• Related / lower confidence: 199.19.77.18 and 65.87.223.26.
• Distinct user agents: task177-f2267/1.0 and sait-tenant-deep/37346.
• Hunt signal: AADSTS7000215 or AADSTS7000222 failures followed by a successful sign-in for the same app from the same IP.

Do not treat normal Microsoft service addresses as indicators. Addresses such as 20.20.34.96, 20.20.34.160 and 20.231.130.224 are Microsoft service IPs and should not be blocked based on this campaign.

What to do this week

1. Hunt the logs. Review Entra service-principal and non-interactive sign-in logs for 199.19.77.84 and the user agents above. Treat AADSTS7000215 or 7000222 failures followed by success for the same app from the same IP as urgent.
2. Block the high-confidence IP. Add 199.19.77.84/32 as a Conditional Access named location. Apply workload-identity policies where you are licensed, and a user-scoped block for replayed sessions.
3. On any hit, cut access and rotate. Disable the app and remove all secrets, certificates and federated credentials. Revoke user sessions and Azure DevOps PATs and SSH keys. Rotate everything the app could have read, including Key Vault secrets and documents that hold VPN, RMM, backup or firewall credentials.
4. MSPs: check Partner Center and GDAP. Review Partner Center, GDAP relationships and multi-tenant apps, and notify any customers that may have been reached.
5. Longer term hygiene. Inventory and remove unused apps. Prefer managed identities or federation over client secrets. Keep secrets out of runbooks, PSA and RMM notes. Restrict Key Vault and Storage by network where you can.

Questions to ask your IT provider or MSP

1. Have our Entra service-principal and non-interactive sign-in logs been checked for 199.19.77.84 and the user agents above since November 1?
2. Are any of our app registrations still using long-lived client secrets, and have unused apps been removed?
3. If we are an MSP client, have Partner Center, GDAP and multi-tenant apps been reviewed, and will we be notified if our tenant was in scope?
4. Is 199.19.77.84 blocked in Conditional Access, including for workload identities where licensed?