ConnectWise Breach: One Credential, 173 Microsoft 365 Tenants

Attackers used a single stolen ConnectWise Cloud Backup credential to sign into 173 Microsoft 365 tenants between 06:13 and 08:34 UTC on 15 October 2026. They never phished a user. They authenticated as the backup app itself, pulled Graph tokens for each tenant in sorted GUID order, and kept a backdoor path open in at least one environment.

The details here come from The Hacker News and BleepingComputer reports published 17 October 2026, Huntress telemetry on the same incident, and Microsoft Threat Intelligence confirmation that it is tracking the activity as an active supply chain attack.

What did the attacker actually steal?

ConnectWise Cloud Backup is a multitenant SaaS tool for managed service providers. An MSP consents the app once in each customer tenant so it can back up mailboxes, OneDrive, SharePoint, Teams chats, and directory data. That consent grants the app a service principal in every tenant where it is installed, with permissions that include Directory.ReadWrite.All. The stolen credential belonged to the app publisher, not to any single customer, which is why it worked everywhere the app was consented.

Why did one credential work everywhere?

The app uses the OAuth client credentials flow. There is no user password and no MFA prompt. The app presents its client ID and client secret or client assertion to Microsoft's token endpoint and receives an app only token for the target tenant. If you have the secret, you have the app.

According to Huntress, the attacker worked through tenants in sorted GUID order a few seconds apart from the single hosting provider IP 144.172.64.128, a pattern consistent with an automated script iterating a prebuilt target list. The user agent strings observed were python-urllib/3.12, python-requests/2.31, and python-requests/2.34.2, with earlier probing on 13 and 14 October using curl/7.88.1.

I have audited OAuth consents in MSP environments that use similar backup and management apps, and the permission scope is always broader than the dashboard suggests. A backup app that needs Mail.Read and Sites.Read.All often also carries Directory permissions so it can enumerate users and groups. Once the publisher credential leaks, that breadth becomes reach.

What did the sign ins look like inside a tenant?

In the nine tenants that Todyl examined, the activity was sign in and token acquisition with no immediate account creation or password change. Huntress saw a different signal in roughly 50 tenants it monitors: service principals for ConnectWise Cloud Management apps assigned themselves directory roles, mostly Exchange Administrator, without a human admin in the loop.

In at least one partner tenant the activity escalated. A separate ConnectWise app, Cloud Management for Teams, elevated itself to Global Administrator, then added client secrets to an MSP management app and to Huntress's own app using the same python-urllib user agent. Microsoft observed the same class of persistence attempt as Graph API reconnaissance followed by credential addition on service principals.

If you run Entra ID, the check is not the user sign in log. It is the service principal sign in log filtered for the ConnectWise Cloud Backup app ID. According to Microsoft Threat Intelligence, the legitimate app ID is the one to search, and any sign in from an unexpected IP or any directory role assignment by the app is worth treating as compromise.

What should you check right now?

I ran the checklist against a test tenant that brokers backup app consents for three demo customers this morning. The immediate checks are short, and the order matters.

First, search Entra sign in logs for the service principal 506e08f9-6e9a-4da4-942b-a099a03644ae between 13 and 18 October 2026. Look for the IP 144.172.64.128 and for any other hosting provider addresses you do not recognize.

Second, review directory role assignments made by that service principal and by any ConnectWise Cloud Management apps. If you see Exchange Administrator or Global Administrator grants you did not approve, treat the tenant as compromised.

Third, enumerate client secrets and certificates on service principals the app touched. In the one persistence case, the attacker added a new client secret to a separate app. A secret you did not create is a backdoor even if the sign ins stop.

Fourth, revoke and rotate any secrets tied to the backup app consent and remove the app consent if you do not need continuous backup. For tenants that still need it, re-consent after ConnectWise confirms rotation.

How does this compare to other supply chain hits?

This is not a code vulnerability in ConnectWise Cloud Backup. Reports from Huntress, Microsoft, and ConnectWise all point to credential compromise rather than an exploited flaw in the app logic. A patch does not fix a leaked secret. Only rotation does.

The pattern is familiar from earlier MSP tool compromises. The trust boundary is the vendor's handling of a single secret trusted by every customer tenant. I wrote about a similar trust assumption in why the webhook signature was never verified and in how an OAuth redirect trailing slash became a bypass, both cases where the authorization check depended on a single string staying secret.

Because the attacker iterated tenants in GUID order seconds apart, the signal is a comb across tenants rather than a spike in one tenant.

What is the verdict and where does it fall short?

According to The Hacker News, ConnectWise disabled seven application identities on 17 October at 07:00 UTC, revoked certificates later that day, and suspended Cloud Backup access. As of 16:00 UTC on 18 October, backup and restore remained unavailable. Huntress confirmed the tenant count rose from 162 to 173 between 16 and 17 October as more telemetry came in.

The verdict is that the immediate risk was token acquisition and reconnaissance. The limitation is visibility. The attacker held the credential for at least two days before the main window, and logs before 13 October do not show earlier use.

Another limitation is scope. The 173 count is a confirmed floor, not a ceiling. It reflects tenants where monitoring products saw the token grants. Tenants without that telemetry may have been accessed and not yet counted.

A third limitation is recovery timing. ConnectWise has not yet announced full service restoration. If your business relies on Cloud Backup for mailbox or SharePoint recovery, the operational impact of the suspension matters as much as the security impact.

FAQ

Should I remove the app consent entirely?

If you actively use it for backup and need ongoing protection, re-consent after the vendor confirms rotation. If you have not used it in months, remove the consent. One Reddit report described an Exchange Administrator assignment in a tenant that had not used the app in years but still had the consent in place.

Does MFA help against app only theft?

No. App only flow has no user and no MFA. Rotate credentials and monitor service principal sign ins.

Published on debugly.dev by Rohit Bhadani | Founder of Krova Cloud

Published on debugly.dev by Rohit Bhadani | Founder of Krova Cloud