Microsoft Entra ID App Secrets Used to Access MSP Customer Tenants: Detection and Response Guide

What happened​

Todyl says it is investigating an actor that signs in to Microsoft Entra ID as application service principals using valid, pre-existing credentials. Its November 3 write-up puts the start at November 1. The attackers have targeted approximately 45 app registrations across about 18 organizations, and they authenticated successfully to more than 33 of them. Through those apps, the actor reached 27 organizations. They included the MSPs' downstream clients in government, energy, agriculture, transportation, construction and engineering, legal, education and nonprofits.

The other figures come from Todyl's reporting as relayed by Cybersecurity Dive:

• Searches ran across about 25 tenants.
• 81 files were downloaded.
• About 2,300 mailbox items were accessed (Todyl's precise figure is 2,279).

Todyl calls these numbers a floor, because they only cover organizations that send it logs. They are a snapshot of one investigation, not a census of victims.

Todyl says the activity is ongoing. Its latest logged attempt, at 21:31 UTC on November 3, was a token replay that Conditional Access blocked.

Why a service principal login is such a good disguise​

A service principal is an application's identity. Todyl's summary is blunt: with these sign-ins there is no MFA prompt, user-scoped Conditional Access doesn't apply, and firewall rules never see the traffic. "If the credential is valid, the app is in."

Cybersecurity Dive quotes Huntress analyst Jon Semon saying the attacker already held valid secrets for Entra application registrations. These are the identities software uses to sign in to Microsoft services with no person present.

MSP structure makes this worse. MSP multi-tenant and GDAP relationships turn one provider's app into a route to its customers. Todyl reports one multi-tenant app sweeping 15 client tenants in loops of about 10 seconds.

The playbook Todyl observed​

Todyl describes a consistent sequence, with the caveat that parts of it are inferred from timing:

1. Sign in as the app. The actor used client secrets. It also used an Azure DevOps federated workload identity and replayed user sessions in Azure DevOps.
2. Harvest more secrets. For almost every credential it asked for an Azure Resource Manager token, then a Key Vault token. Graph, Storage and Cognitive Services tokens often followed within seconds. Apps that had never been used before then began authenticating. Todyl says the timing suggests Key Vault reads were a source, but it needs Key Vault audit logs to confirm that.
3. Search and collect. It ran wildcard Microsoft Graph searches, then bulk-downloaded SharePoint files at about one per second. It focused on file names related to credentials and configuration.
4. Reach downstream. It used MSP multi-tenant and GDAP apps, plus Partner Center tokens, to reach client tenants.
5. Adapt. After detections fired on November 3, it switched from curl and Python to spoofed browser user agents. It then tried replaying users' refresh tokens, and Conditional Access blocked all of those.

Todyl says it has not seen persistence, meaning no new consents, credentials, roles or users. That is an observation from its own telemetry. It doesn't prove persistence is absent in other victims.

The stolen files are the real prize. Todyl lists password lists, private keys, VPN profiles, MFA and RMM API keys, backup credentials, firewall and RDP configs, and service-account maps. Those can be used against systems Microsoft 365 logs can't see.

Worm, AI agent or human? What's established​

Cybersecurity Dive says the operation behaves in many ways like a self-propagating worm. Todyl is more careful: nothing jumps between MSPs on its own. Its evidence points to a single operator on one VPS, working through a stockpile of secrets assembled before November 1. Multi-hour idle gaps and the browser-signature switch suggest a person steering the tooling.

About 95% of sign-ins used scripted clients. There were bursts of 24 sign-ins in 10 seconds and fixed retry loops of about 11 seconds. Todyl says this speed fits AI-assisted tooling, but it holds that at low confidence. It has not tied the activity to a specific agentic workflow, and its telemetry doesn't show an AI model directing it.

On attribution, Todyl and Cybersecurity Dive both say the activity is unattributed. Todyl assesses it as unrelated to the October 2026 ConnectWise Cloud Backup (formerly SkyKick) compromise it links to Storm-0940, noting different infrastructure and no meaningful overlap in victim tenants. Todyl also tracks a trojanized Claude Code extension in the Cursor marketplace as a plausible credential source. It has not tied any victim to that incident.

Microsoft's related findings​

On November 5, Microsoft Threat Intelligence published its own account. It says that as early as October 28, 2026, it began observing successful service principal sign-ins from 199.19.77[.]84 involving multiple application IDs. It also reports cases where a vendor-owned multitenant application credential was compromised and used to reach several downstream tenants. Microsoft's post separately describes threat actors using an agentic offensive framework called ARTEX to hunt for exposed secrets in public GitHub repositories. In at least one case, an agent went from scanning GitHub to exfiltrating Azure Key Vault data in five minutes.

Microsoft also lists a second sign-in address, 199.19.77.18, which it calls a Tor exit node that may carry unrelated malicious traffic. It describes adaptive Azure Resource Manager behavior too. Failed API calls were retried within seconds to a minute or so with a corrected API version or method, and those retries then returned HTTP 200.

Be careful how far to stretch this. Microsoft says a similar campaign involving the same IPs was reported by Todyl. Todyl's confirmed MSP incident is narrower, though, and the sources do not prove a single operator behind every incident described.

What to do now​

All of this comes from Todyl's and Microsoft's published guidance.

Hunt

• Search Entra service principal and non-interactive sign-in logs for 199.19.77.84. Todyl's query is:

union AADServicePrincipalSignInLogs, AADNonInteractiveUserSignInLogs
| where IPAddress == "199.19.77.84"
| project TimeGenerated, AppId, ServicePrincipalName, UserPrincipalName,
          ClientCredentialType, ResultType, ResourceDisplayName

• Microsoft's guidance adds 199.19.77.18 to that search, and says to include failed attempts.
• Treat AADSTS7000215 (invalid secret) and AADSTS7000222 (expired secret) as signs that someone holds a credential for your app. A failure followed by a success is urgent.
• Hunt for behavior, not just the IP. Examples are one address authenticating to three or more service principals with mixed success, or one app requesting ARM, Key Vault, Storage and Graph tokens in a short window.
• Todyl also warns that failed sign-ins from hosting providers that never succeed are worth reviewing. Detection logic keyed only on successes will miss them.
• Review Azure Activity, Key Vault and Storage diagnostics, Entra audit, Azure DevOps audit and Microsoft 365 unified audit logs. In Azure DevOps, look at PAT creation and first use, federated service connections and pipeline edits. Enable auditing if it is off. Search back as far as retention allows.

Contain

• Block 199.19.77.84/32 through a named location. Use a Conditional Access policy targeting workload identities and assigned directly to service principals. Add a user-scoped block policy to cover replayed sessions. Block the exact IP, not the whole ASN. Todyl says other addresses in that range show unrelated activity.
• Know the limits. Workload identity policies need Workload ID Premium. They cover only single-tenant apps registered in your tenant, not managed identities, multitenant apps or third-party SaaS.
• On an affected app, remove all secrets, certificates and federated credentials, including any you didn't add. Disable the service principal if needed. Tokens already issued stay valid until they expire.
• Revoke affected users' Entra sessions, Azure DevOps PATs and SSH keys.
• Rotate everything in any Key Vault the app could read, plus credentials in any documents it accessed.
• Todyl also reports that the actor kept retrying credentials against disabled and rotated apps. That means rotation alone is not the end of the work.

MSPs

• Review Partner Center access, GDAP relationships and customer tenants, and notify affected customers per your agreements.
• Never store customer app secrets in runbooks, PSA/RMM notes or client documentation.

Longer-term hardening​

• Retire client secrets. Todyl's order of preference is managed identities, then workload identity federation, then vault-held certificates. Use app management policies to cap secret lifetimes.
• Restrict Key Vault and Storage to selected networks or private endpoints, so a valid token from an unknown address can't reach the data.
• Tighten Azure DevOps. That means limiting PAT scope and lifetime, narrowly scoping service connections, requiring production approvals and streaming audit logs to a SIEM.
• Scan code for exposed secrets, as Microsoft advises. Treat any publicly exposed credential as compromised even if the original file was deleted, and rotate it.
• Todyl also advises that AI-resource owners inventory AI keys, prefer Entra authentication over keys, and set quotas and token-usage alerts. It saw four AI-service tokens issued at two MSPs. A token being issued doesn't prove it was used.

Bottom line​

This is not an Entra breach. It is a reminder that app identities are the soft underbelly of cloud security, because they skip MFA by design. If you run an MSP, one leaked secret can mean many customers' data. Most of the public detail so far comes from Todyl, a security vendor with its own telemetry, and Microsoft's blog corroborates the IP and the technique. The investigation is active, so check for updated indicators before relying on a single address.