A Stolen Backup App Credential Opened 173 Microsoft 365 Tenants, and MFA Never Asked

Most identity defenses are built around a person: a password, a second factor, a device check, a risky sign-in score. The incident that MSPs spent the weekend cleaning up had no person in it. An attacker held the credential of a trusted backup application, signed in as that application across customer tenants one after another, and inherited every permission those tenants had granted it. Nobody was phished, no prompt appeared, and the default sign-in log most administrators check showed nothing.

One Credential, Every Tenant That Consented

ConnectWise Cloud Backup is a Microsoft 365 and Google Workspace backup service sold through managed service providers. To do its job it holds broad, standing access to mailboxes, OneDrive, SharePoint, Teams and directory data in every tenant where it is installed. The Hacker News reported on October 17 that Huntress had confirmed unauthorized sign-ins in 173 partner and customer tenants, and that Microsoft described an active supply chain attack on the app. ConnectWise closed Cloud Backup application access until further notice and said it had found no evidence that partner backup data was compromised.

The running Huntress analysis by Jonathan Semon lays out how quickly the access spread. Huntress counted 162 tenants with confirmed unauthorized sign-ins as of 19:00 UTC on October 16, and its later updates reported almost 1,000 Entra tenants with sign-in activity from the attacker's address, more than 300 of them successful. The credential was a client assertion that lives in the vendor's own tenant, which is why it worked against every customer that had consented to the app. Semon's summary of the risk is blunt: "A credential on a security tool's application gives the holder whatever that tool is permitted to do."

The pattern looked automated. Sign-ins from 144.172.64[.]128, a hosting provider address, moved through tenants in sorted GUID order a few seconds apart. Todyl, which detected the same activity independently, saw one sign-in per tenant between 07:11 and 08:47 UTC on October 15, in strictly ascending tenant order. In its investigation write-up, Todyl's Nicholas Koken concludes that every tenant with the app enabled should be treated as compromised, and notes that the legitimate backup service normally authenticates from Microsoft-internal IPv6 addresses rather than the public internet.

Why None of the Usual Controls Fired

The attacker authenticated with the OAuth 2.0 client credentials flow. That flow involves no user, so there is no MFA challenge to fail, and Todyl recorded Conditional Access as not applied on every sign-in. Conditional Access cannot be applied to third-party multi-tenant apps at all, Todyl says, which leaves least-privilege consent and the removal of unused apps as the main controls. Koken also warns that "revoking user sessions does not end this access," because there is no user session to revoke.

One tenant shows how far the access could go. Huntress found that ConnectWise Cloud Management for Microsoft Teams, a separate app from the same vendor, added itself to the Global Administrator role and then added client secrets to two other applications: an MSP management app and Huntress's own security platform app. Those secrets were set to expire in 2028. Huntress says the whole sequence took about five minutes, and that service principals for ConnectWise Cloud Management apps had assigned themselves directory roles, mostly Exchange Administrator, in roughly 50 tenants.

Visibility is the second problem. Entra shows these events on the service principal sign-ins tab, not the user sign-ins view most teams open first. Huntress notes that Entra audit logs record role and application changes but not source IPs for app-only actions, and that Microsoft Graph directory reads leave no audit record. Todyl could not separate the attacker's reads from the backup service's own, because both used the same app identity and per-request source IPs appear only in Microsoft Graph activity logs, which were not collected. It called the lack of confirmed exfiltration "partly a visibility limit rather than a clean result."

AppOmni's Bill Legue, in an October 19 analysis, reduces the incident to five conditions: a multi-tenant credential valid everywhere it was consented, broad standing permissions, sign-ins that skip user MFA, an app able to grant itself Global Administrator, and detection that depends on logs many tenants never collect. None of those is specific to ConnectWise. Every tenant running third-party backup, security or management tools carries some version of all five.

What to Do This Week

Huntress, Todyl and AppOmni converge on the same short list, and most of it applies well beyond this one vendor.

• Disable, do not delete. Set the ConnectWise and SkyKick enterprise apps to block sign-in, which stops new tokens while keeping consent so they can be re-enabled later. Keep them disabled until ConnectWise confirms every credential has been reset, and remember issued tokens last up to 90 minutes.
• Hunt in the right log. Filter service principal sign-ins by app ID for non-Microsoft addresses such as 144.172.64[.]128, and search audit logs for apps adding themselves to directory roles or adding credentials to other apps since October 13.
• Audit every secret on every app. Review client secrets and certificates on enterprise apps and app registrations, especially security and management tools, and remove anything nobody can account for.
• Turn on Microsoft Graph activity logs. They are not retroactive and require Entra ID P1 or P2, but without them legitimate and malicious use of the same app identity cannot be told apart.
• Inventory third-party consent. List every multi-tenant app, its vendor and its scopes, flag broad grants such as Directory.ReadWrite.All and Mail.ReadWrite, and remove apps no longer in use.
• Constrain app credentials. Huntress recommends application management policies that restrict client secrets and cap their lifetimes, plus tight limits on who holds Application Administrator and Cloud Application Administrator.

The lesson is not that backup apps are dangerous. It is that a tenant's most trusted applications hold access no person in the organization would ever be granted standing, and they authenticate where MFA cannot reach. Until those identities are inventoried, logged and constrained like administrators, the next stolen vendor credential will sweep through tenants just as quietly.