TL;DR: Unosecur's analysis of the ConnectWise Cloud Backup breach shows how a stolen application credential enabled token abuse, self-assigned roles and planted secrets inside customer tenants, while vendor remediation left behind access paths the vendor could not remove. The core failure is assuming a supplier can clean up identity changes it never owns.
Editorial analysis by NHI Mgmt Group, based on content published by Unosecur: “ConnectWise Cloud Backup Breach: Storm-0940’s AI-Driven Attack Left Keys That Outlive the Vendor’s Fix”.
Key questions
Q: What signs suggest a third-party application has been compromised in a tenant?
A: Signs include unexpected consent grants, new service principals, altered API permissions, unusual mailbox or directory access, and tokens issued from unfamiliar IP addresses or client IDs.
Q: Why do stolen application credentials remain dangerous after the vendor disables its app?
A: Stolen application credentials can still be used to mint new access tokens, call APIs, or impersonate the application from outside the vendor’s control.
Q: How should teams govern third-party applications that can change tenant identities?
A: Teams should govern third-party applications with explicit ownership, least-privilege API scopes, approval workflows, and periodic review of consent and role grants.
Practitioner guidance
- Map every consented app to a named owner Create and maintain an inventory of every application identity, the permissions it can exercise and the business owner who can justify those permissions.
- Review service-principal role grants after every incident window Pull directory role history for all applications, then look for self-assigned privileges, sibling principal grants and unexpected elevation to Global Administrator, Privileged Role Administrator or Exchange Administrator.
- Search for new secrets and certificates on tenant-owned apps List every credential added to applications during the compromise window, confirm who approved each change and remove any secret or certificate that cannot be tied to an approved workflow.
Bottom line: A compromised third-party app can leave behind durable access even after the vendor disables its own identities.
What's in the full article
Unosecur's full analysis covers the operational detail this post intentionally leaves for the source:
- Tenant-by-tenant remediation sequence for disabling the affected application identities without destroying evidence
- Log collection and scoping steps for Microsoft Graph activity, service principal sign-ins and directory role history
- Recovery guidance for backup re-enrollment and partner-side tenant restoration after the incident
- Console and workflow detail for tracing secrets, certificates and privilege changes across affected identities
👉 Read Unosecur's analysis of the ConnectWise Cloud Backup breach and tenant persistence →
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
Third-party applications must be governed as tenant-local identities, not as disposable integrations. This breach shows what happens when a supplier identity can create durable access inside customer-owned apps and directory roles. The remediation boundary stops at the vendor's own objects, but the persistence boundary sits in the tenant. Practitioners should treat any consented app with write privileges as part of the identity estate, with an owner, scope and offboarding path.
A question worth separating out:
Q: How do app-only tokens differ from user sessions in incident response?
A: App-only tokens authenticate the application itself, while user sessions represent a named human identity with interactive sign-in state and browser or device context. In incident response, app-only tokens usually point to machine-to-machine access, service principal abuse, or secret compromise, whereas user sessions require checking account takeover, MFA status, and conditional access history.
👉 Read our full editorial: Stolen vendor app secrets outlive remediation in tenant breaches