ConnectWise Cloud Backup credential used on 160+ M365 tenants

A stolen credential for the ConnectWise Cloud Backup (formerly SkyKick) multi-tenant app let an attacker sign in to customer Microsoft 365 tenants as the app itself. Huntress has confirmed unauthorized sign-ins in 162 tenants. No user account or MFA prompt was involved.

What happened

In an October 16 write-up, Huntress reported that an API secret belonging to ConnectWise Cloud Backup (application ID 506e08f9-6e9a-4da4-942b-a099a03644ae) was used from 144.172.64.128, a RouterHosting address. Huntress says nearly 1,000 Entra tenants saw sign-in activity from that IP, with more than 300 successful. Huntress's timeline:

  • October 13–14: password spraying against four law firm tenants from the same IP.
  • October 15: ConnectWise apps assigned themselves Exchange Administrator and other directory roles in about 50 tenants. In one tenant, the actor gave the ConnectWise Cloud Management - MS Teams app Global Administrator and added client secrets to two other apps, including the Huntress Security Platform app. A targeted wave of Graph token requests followed against 16 policy, national security, trade and critical minerals tenants.
  • October 17: ConnectWise disabled the affected apps.

The Hacker News reports ConnectWise detected the activity on October 14, disabled seven application identities on October 17 and suspended Cloud Backup, noting this blocks new authentication but does not undo changes already made inside tenants. BleepingComputer reports ConnectWise has no indication partner backup data was compromised and warned that previously issued access tokens may stay usable until they expire. Huntress has not confirmed data theft either, but notes that directory reads through Microsoft Graph leave no audit trail.

Why it matters

A backup service needs read access to mail, files, Teams and the directory, plus write access to restore. That makes it one of the most privileged non-human identities in a tenant, and its access is app-only, so user MFA never comes into play. One vendor credential became a key to every tenant that had consented to the app.

The persistence is standard cloud tradecraft: a service principal adding itself to a directory role, then adding secrets to other apps, some set to expire in 2028. Disabling the vendor app does not remove those. Huntress also warns that a foothold in one MSP tenant can become a path to its customers. It is the same failure mode as the Storm-3168 service principal intrusion: broad app permissions nobody reviews until the credential is gone.

A clean result does not rule out access. Please disable the application regardless. — Huntress

What to check in your environment

  • Disable, don't delete. Huntress's steps: in the Entra admin center, open Enterprise applications, search for 506e08f9-6e9a-4da4-942b-a099a03644ae, and under Properties set "Enabled for users to sign-in" to No. Deleting it removes the consent. Do the same for other "SkyKick" and "ConnectWise" apps.
  • Review service principal sign-ins. Under Monitoring > Sign-in logs, use the Service principal sign-ins tab and filter by the Cloud Backup app ID. Huntress says legitimate traffic shows an Azure private IPv6 address, so public IPs stand out. Search for 144.172.64.128 and the additional ConnectWise-supplied IPs 144.172.64.99 and 144.172.64.60.
  • Hunt the audit log. Look for "Add member to role", "Update application" and "Add service principal credentials" initiated by an application. Huntress flags Python user agents (Python-urllib/3.12, python-requests) as suspicious; the vendor's own automation shows kiota-dotnet.
  • Remove unexpected roles. If a ConnectWise or SkyKick app holds a directory role, especially Global Administrator or Privileged Authentication Administrator, remove any you did not grant once the app is disabled.
  • Audit credentials on every app. Check client secrets and certificates on all Enterprise applications and App registrations, especially management and security tools, and remove anything added since October 13 that you didn't create.
  • Revisit Conditional Access exclusions. If any policy exempts these apps from location-based blocks, review that exclusion.
  • Inventory other vendor apps. List third-party apps holding tenant-wide application permissions or directory roles, and give each an owner who would notice this behavior.

References

Original source: Huntress