Stolen app credentials target Entra ID and Azure DevOps

Todyl’s MXDR team is reporting an active campaign in which an attacker signs in to Microsoft Entra ID and Azure DevOps as legitimate applications using stolen credentials that remain valid. Since November 1, the actor has targeted about 45 app registrations at roughly 18 organisations, with more than 33 authenticating successfully. Access has reached 27 organisations so far, including downstream customers of MSPs.

This matters because the attack may not trigger an MFA request or the usual signs of employee account compromise. A valid app credential allows a service to authenticate as designed, while Conditional Access policies scoped only to users may not apply.

The priority action: review service-principal and Azure DevOps sign-ins from 199[.]19[.]77[.]84, but do not limit the hunt to one indicator. Look for an app reaching Azure Resource Manager, Key Vault, Storage and Microsoft Graph in a short period, unexpected downloads, and a failed credential attempt followed by a successful sign-in for the same application.

What is known about the campaign

According to Todyl’s November 3 update, one operator is using a previously stolen stockpile of app secrets. Of about 45 app registrations targeted at roughly 18 organisations, more than 33 authenticated successfully. Through MSP relationships and delegated administration, the attacker reached 27 organisations across government, energy, food and agriculture, transportation, construction and engineering, legal services, education and nonprofits.

Within Todyl’s visibility, the operator ran searches across about 25 tenants, downloaded 81 files and accessed roughly 2,279 mailbox items. These figures are a lower bound because they cover only environments that send logs to the company.

There is no reported vulnerability in Microsoft Entra ID. The attack abuses valid credentials, excessive permissions and trusted relationships. Investigators have not confirmed how the original stockpile was stolen or who is behind the campaign.

Why it looks like a worm but is not one

The activity moves quickly. In one case, the attacker used the app credentials from a downloaded connector archive about 2.5 minutes later. Scripts generated bursts of up to 24 sign-ins in ten seconds, and one multitenant app swept 15 customer tenants in short loops.

Todyl nevertheless assesses that this is not self-propagating code. Idle periods, user-agent changes after detections fired and repeated retries point to a human steering automation. Agentic tooling or AI assistance is possible at low confidence; telemetry does not show a particular model directing the operation.

That distinction matters. Organisations should not publish an unsupported claim about an “AI worm.” They should respond to the confirmed behaviours: theft of workload-identity credentials, automated resource discovery and rapid movement across supplier-customer trust relationships.

How legitimate identities become the attack path

A service principal represents an application in a tenant. It can authenticate with a client secret, certificate or federated workload identity credential. Once authentication succeeds, it receives a token and performs operations within its assigned permissions — commonly without an interactive user or MFA.

In this campaign, the attacker reached Azure Resource Manager, Key Vault, Storage, Microsoft Graph and, where available, Partner Center. A federated identity linked to Azure DevOps was also used, and two Azure DevOps user sessions were replayed.

One stolen app secret can expose additional secrets in Key Vault, customer documentation, source code and deployment connections. At an MSP, delegated administration and GDAP relationships amplify the impact: one identity may provide a path into many customer tenants.

Today’s response plan

1. Preserve logs before they disappear

Export service-principal sign-ins, non-interactive user sign-ins, Entra audit, Microsoft 365, Azure Activity, Key Vault, Storage and Azure DevOps audit records. Retention may be short, while these records are necessary to assess access and reporting obligations.

2. Hunt for the confirmed indicator and behaviours

Check 199[.]19[.]77[.]84, but do not block the entire ASN. Todyl explicitly warns that other addresses in that network show unrelated activity. Also look for one source authenticating to many service principals, mixed failures and successes, and one app rapidly reaching ARM, Key Vault, Storage and Graph.

AADSTS7000215 can indicate an invalid client-secret attempt, while AADSTS7000222 indicates an expired credential. A failed attempt followed by a successful sign-in for the same App ID from the same source requires urgent investigation.

3. Contain access and invalidate credentials

For an affected application, remove secrets, certificates and federated credentials that cannot be explicitly approved. Disable the service principal when necessary. Revoke affected user sessions, Azure DevOps PATs and SSH keys. Remember that issued tokens may remain valid until expiry.

4. Establish the data scope

Review directory and Azure RBAC roles, API permissions, Key Vault access, Partner Center, repositories and service connections. Identify downloaded files, mailbox searches, secret reads and pipeline activity. If an app could read a vault or credential document, rotate the downstream credentials as well.

5. MSPs must examine customer tenants

Do not stop at the MSP’s own tenant. Review GDAP relationships, multitenant apps and actions in customer environments. Trigger contractual and regulatory notification processes where access is confirmed or data exposure cannot be ruled out.

Reducing the entire class of risk

Prefer managed identities, then workload identity federation, followed by certificates held in a secure vault. Long-lived client secrets should be an exception. Federation removes a stored secret but transfers trust to the token issuer, so Azure DevOps needs protection of equal strength.

Reduce app permissions, assign accountable owners, cap credential lifetimes and remove unused service principals. Restrict Key Vault and Storage through private endpoints or named networks so a valid token alone is insufficient from an arbitrary location.

Conditional Access for workload identities has licensing and scope limitations. It does not cover every managed identity, multitenant application or external SaaS. Defence cannot be reduced to one policy. It requires least privilege, logging, behavioural detection and control over systems where credentials may be stored.

Our Microsoft Entra ID penetration testing guide explains how to assess this attack surface more broadly.

Source facts and Breachroad conclusions

Todyl confirms the active campaign, observed numbers of apps and organisations, use of 199[.]19[.]77[.]84, access to Microsoft 365 and Azure resources, and specific detection and containment guidance. The source stresses that this is not a Microsoft vulnerability, the actor and initial source of secrets remain unknown, and AI involvement is a low-confidence hypothesis.

Prioritising log preservation, involving legal and privacy teams, reviewing MSP obligations and rehearsing business decisions are Breachroad recommendations. Organisations can prepare administrators, help desks and service owners through cybersecurity training. An IT security audit can assess app permissions and logging visibility.

FAQ: Entra ID and Azure DevOps campaign

Is this a Microsoft Entra ID vulnerability?

No. Available evidence shows the attacker using valid, previously stolen app credentials and sessions. The issue concerns credential control, permissions and monitoring.

Will MFA stop this attack?

User MFA is not invoked for an ordinary app-only sign-in. Organisations need workload-identity policies, network restrictions, least privilege and service-principal sign-in monitoring.

Is blocking one IP address enough?

No. It is a useful immediate containment step, but attacker infrastructure can change. Hunt for behaviour, rotate credentials and determine which resources the app could access.

Has the campaign been attributed?

No. Todyl describes the activity as unattributed and assesses it as separate from the October ConnectWise Cloud Backup incident attributed to Storm-0940.

Primary sources: Todyl — Stolen App Credentials, Real Access, Microsoft Learn — Conditional Access for workload identities, Microsoft Learn — Azure DevOps auditing.