Stolen App Credentials, Real Access: An Actor Is Signing Into Entra ID and Azure DevOps as Your Workloads

This is an ongoing incident and Todyl’s MXDR team will be updating as new information becomes available.

Todyl is investigating an actor that signs in to Microsoft Entra ID as application service principals using valid, pre-existing credentials. This has involved the use of client secrets and, in at least one case, a workload identity federated credential. This is an active incident that began on November 1, 2026 and spans multiple unrelated organizations, including MSPs and the customer tenants they manage. Because these are app 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.

What we’re observing

• One source address. All confirmed malicious activity comes from 199[.]19[.]77[.]84 (AS203662, 3K33 sp. z o.o., Poland-geolocated hosting), first seen Nov 1 and last seen Nov 3 (UTC).
• Same playbook per app. For almost every credential, the actor hits Azure Resource Manager first, then Key Vault, Storage, Microsoft Graph and, where available, Partner Center. A failed client-secret attempt and a successful one often appear for the same app seconds to minutes apart.
• Broad reach from one address. In one tenant, nearly every legitimate address touched a single service principal; the actor’s address touched every tenant it held credentials for, and was the only source with failures.
• Azure DevOps. A federated credential tied to Azure DevOps was used from the actor’s address starting Nov 1, 14:39 UTC, and two users’ Azure DevOps sessions were replayed on Nov 2. Reported PAT use is being examined.
• Collection, not dwell. File downloads from Microsoft 365, with interest in keys, API credentials and client documentation. No persistence observed; time in each tenant is short. Scripted clients and custom user agents that change per task.
• MSP-to-customer reach. In at least one case, access to an MSP was followed within seconds by access to several downstream customer tenants via delegated admin.

NOTE: Todyl is currently investigating the root cause around this investigationnand will provide more details once confirmed.

Don’t block the whole ASN. Other addresses in this provider’s space are doing unrelated things (scanning, a file-sync relay, Azure CLI password attempts) and are not attributed to this actor. Block the exact IP only; we’ll publish further indicators only once confirmed. How the credentials were obtained, and who is behind this, is not yet known.

Why it matters

• Secrets unlock more secrets. The path from ARM to Key Vault and Storage means one compromised app can expose the keys and connection strings for many other systems.
• MSP and supply-chain blast radius. Partner Center, delegated admin and Azure DevOps service connections turn one app into access to customer tenants, source code and production deployments.
• False assurance. Firewall blocks and user-focused Conditional Access don’t stop this. Treat confirmed access as a potential data-exposure event and involve legal and privacy stakeholders early.

What to do now

1. Block in Conditional Access

Create a named location for 199.19.77.84/32 and block it in a policy targeting workload identities, assigned directly to service principals (group assignment isn’t enforced for them). Add it to a user-scoped block policy to cover replayed sessions and turn on Conditional Access policy validation in Azure DevOps. Note the limits: workload identity policies require the standalone Workload ID Premium license and cover only single-tenant apps registered in your tenant, not managed identities, multitenant apps or third-party SaaS.

2. Hunt

Check Entra Service principal and non-interactive sign-in logs for the IP, or run:

union AADServicePrincipalSignInLogs, AADNonInteractiveUserSignInLogs

| where IPAddress == "199.19.77.84"

| project TimeGenerated, AppId, ServicePrincipalName, UserPrincipalName,

         ClientCredentialType, ResultType, ResourceDisplayName

• Failures count. AADSTS7000215 (invalid secret) or AADSTS7000222 (expired secret) means someone holds a credential for your app and observing a failure followed by a success is urgent.
• Azure DevOps. Filter Organization settings → Auditing (or AzureDevOpsAuditing) by IpAddress. Review PAT creation and first use, federated service connections, pipeline runs and edits, and unfamiliar user agents. If auditing is off, enable it.
• Behavior, not just IP. Alert on one address authenticating to three or more service principals in a tenant with mixed success, or one app fanning out across ARM, Key Vault, Storage and Graph in a short window.
• Look back further. Earliest sightings sit at the edge of current query windows; search as far back as retention allows.

3. Recommended response(s)

1. Contain. Remove all secrets, certificates and federated credentials on the affected app, watch for ones you didn’t add, and disable the service principal if needed. Issued tokens otherwise stay valid until expiry. For affected users, revoke Entra sessions, Azure DevOps PATs and SSH keys.
2. Scope. Review the app’s API permissions, directory and Azure RBAC roles, Key Vault access, Partner Center access and Azure DevOps service connections.
3. Audit. Search Azure activity, Key Vault and Storage diagnostics, Entra audit, Azure DevOps audit and M365 unified audit logs for the IP, including secret reads, blob and file downloads, and changes to apps, permissions or pipelines.
4. Rotate downstream. Rotate everything in any Key Vault the app could read and any credentials in accessed documents, then find where the original credential was stored and who had it.
5. MSPs. Check Partner Center, GDAP relationships and customer tenants, and notify affected customers per your agreements.

Harden against the whole class of attack

Regardless of how these credentials were obtained, client secrets, PATs, and session cookies commonly leak from developer and admin workstations (infostealers), scripts and .env files, repositories and CI/CD variables, and runbooks or client documentation. Federation removes the stored secret but moves trust to the system issuing tokens. In this case that’s Azure DevOps, so protect that system just as carefully.

• Retire client secrets. Prefer managed identities, then workload identity federation, then vault-held certificates. Use Entra app management policies to block new secrets and cap credential lifetimes.
• Put data behind the network. Restrict Key Vault and Storage to selected networks or private endpoints so a valid token from an unknown address can’t reach the data; use Key Vault RBAC and enable diagnostic logging.
• Harden Azure DevOps. Restrict PAT creation and scope, enforce short lifetimes, limit who can create and use service connections, scope them narrowly, require approvals for production, and stream auditing to your SIEM.
• Shrink the surface. Inventory apps and service principals, remove unused ones and stale credentials, enforce least privilege, limit app ownership and app-admin roles, and alert on new secrets, certificates or federated credentials.
• Protect the endpoints that hold the keys. Defend developer and admin machines against infostealers, keep secrets out of code, wikis and tickets, shorten privileged session lifetimes, and use token protection where supported. Turn on risk detection for workload identities if licensed.
• MSPs. Audit partner-tenant apps (especially those with Partner Center access), move to least-privilege time-bound GDAP, and never store customer app secrets in runbooks, PSA/RMM notes or client documentation.

MITRE ATT&CK: T1078.004 Cloud Accounts, T1550.001 Application Access Token, T1550.004 Web Session Cookie, T1580 Cloud Infrastructure Discovery, T1555.006 Cloud Secrets Management Stores, T1530 Data from Cloud Storage, T1199 Trusted Relationship.

Help us track it

If you’ve seen 199[.]19[.]77[.]84 or this behavior, please share first and last timestamps (UTC) including Azure DevOps audit entries and first PAT use, as well as any service principal sign-ins or SharePoint downloads from other AS203662 addresses. We’ll continue to update this post as the investigation develops.

References: Microsoft Learn documentation on Conditional Access and continuous access evaluation for workload identities, Workload ID licensing, Entra error codes, and Azure DevOps auditing; RIPE/RIPEstat registration and routing data.