Application identity abuse targets MSPs and customer environments

Threat summary

On November 3, 2026, researchers disclosed an ongoing intrusion campaign in which a threat actor used valid application credentials belonging to the victims' own applications to authenticate directly to Microsoft Entra ID and Azure DevOps environments.

The activity was first observed on November 1, 2026, and remained active as of November 3, with the latest observed attempt occurring at 21:31 UTC.

The activity is reported to primarily affect managed service providers (MSPs) and their customers, particularly those that rely on cloud apps, workload identities, and delegated administration across multiple tenants.

The threat actor signed in as trusted applications and replayed developer sessions, gaining whatever access those applications already held. How the adversary obtained these credentials remains under investigation. All confirmed malicious activity originated from a single IP address, 199.19.77[.]84, on a hosting provider geolocated to Poland.

Because applications sign in without a user, this activity sidesteps MFA and user-focused Conditional Access policies, and falls outside the view of on-premises firewalls. Conditional Access policies for applications offer partial protection, but they require an additional license and exclude the multi-tenant applications MSPs commonly rely on.

Once authenticated, the operator used application access to retrieve stored secrets and credentials. Previously unused applications often began authenticating within minutes, suggesting those secrets were used to expand access within affected environments. The adversary then searched and accessed mailboxes and file stores across multiple tenants, collecting files that contained credentials and configuration details for systems such as VPNs, remote monitoring and management (RMM) tools, backups, and firewalls.

The operator used MSP multi-tenant applications and Partner Center tokens to access customer environments. Researchers also observed attempts involving Granular Delegated Admin Privileges (GDAP) applications. Integration applications for security tools, including Todyl's own integration applications in two MSP tenants, were among the credentials abused, with no sign of a vendor platform compromise.

After detections fired on November 3, 2026, the adversary switched to spoofed browser signatures and later began replaying users' refresh tokens, while continuing to retry disabled and rotated applications in fixed 11-second loops. Conditional Access blocked every token replay observed that day.

Analysis

MSPs are the primary target of this campaign as the applications used to manage customer environments are designed to access multiple tenants, making them valuable to threat actors.

Application identities in particualr have become attractive targets because they often hold extensive permissions and operate with little day-to-day visibility. As organizations have strengthened protections around user accounts, threat actors have increasingly focused on applications, which commonly rely on long-lived credentials and maintain persistent access to cloud resources.

Additionally, the return on effort can be significantly greater than traditional account compromise. A compromised user account may provide access to a mailbox or a limited set of resources, while a compromised application can expose far more sensitive data. The operator's focus on credential stores and configuration files suggests the goal is to establish additional access beyond the initial cloud environment.

The biggest concern is the credentials, keys, and configuration data available through compromised applications. Access to RMM API keys, backup credentials, firewall configurations, and VPN settings can provide paths into systems beyond Microsoft cloud services. Access to Azure DevOps introduces additional risk because service connections and deployment pipelines often have direct access to production infrastructure and business-critical environments.

Risk increases in environments that rely on long-lived application secrets, store credentials in operational systems or shared documentation, and connect security, backup, monitoring, and administrative platforms through broadly permissioned applications. Organizations that rely primarily on user-focused identity controls may have limited visibility into this activity because many application identities operate outside protections designed for interactive sign-ins. The ultimate impact depends on what affected applications can access and whether exposed credentials remain valid.

Mitigations

Block the operator's address, 199.19.77[.]84, through a Conditional Access named location in a policy that targets workload identities assigned directly to service principals, and in a user-focused policy that covers replayed sessions.

Review service principal sign-in logs for that address and for failed secret attempts (error codes AADSTS7000215 and AADSTS7000222) followed by a success, along with applications that begin authenticating after long periods of inactivity.

Where exposure is identified, remove all secrets, certificates, and federated credentials on the affected application, check for any that were added without approval, and disable the service principal, since already-issued tokens remain valid until they expire and the operator retries rotated credentials.

Revoke affected user sessions, Azure DevOps personal access tokens (PATs) and Secure Shell (SSH) keys, then rotate every credential the application could reach, including VPN, RMM, backup, firewall and administrative credentials, and review Azure DevOps service connections and pipelines for unauthorized changes.

For longer-term protection, review application registrations and multi-tenant applications to identify which can reach multiple tenants, Key Vault, storage and administrative services, and remove unused applications and excess permissions.

Restrict Key Vault and Storage to selected networks or private endpoints, which protects data even from multi-tenant applications that workload identity Conditional Access policies leave uncovered.

Move credentials out of documentation, runbooks, ticketing systems and shared repositories into managed secret stores, and replace client secrets with managed identities or workload identity federation to reduce exposure to secret theft. Federation shifts trust to the system that issues tokens, in this case Azure DevOps, so protect that system with the same care.

Stay on top of emerging threats like this.

Sign up to receive a weekly roundup of our security intelligence feed. You'll be the first to know of emerging attack vectors, threats, and vulnerabilities. 

Sign up