ConnectWise Cloud Backup: App Credential Abused in M365

What to do

In every tenant, disable (do not delete) the ConnectWise Cloud Backup and ConnectWise/SkyKick Cloud Management enterprise apps by setting 'Enabled for users to sign-in?' to No.
Remove any directory role a ConnectWise or SkyKick service principal holds that you did not grant, especially Global Administrator and Exchange Administrator.
Review client secrets and certificates on every enterprise app and app registration for anything added since Oct 13, 2026 that you did not create, and remove it.
Check mailboxes for new forwarding, inbox rules and delegated access, and review Conditional Access exclusions and federation trusts.
Export sign-in and audit logs now, especially on Entra ID Free with 7-day retention, and enable Microsoft Graph activity logs going forward.
Keep the apps disabled until ConnectWise issues formal reconnection instructions for your service.

How to check if you are affected or compromised

In Entra sign-in logs, open the Service principal sign-ins tab, filter on app ID 506e08f9-6e9a-4da4-942b-a099a03644ae, and look for 144.172.64.128 or any non-Microsoft IP.
In Entra audit logs, search for 'Add member to role', 'Update application' and 'Add service principal credentials' initiated by ConnectWise or SkyKick apps.
Search for user agents Python-urllib/3.12, python-requests/2.31 and kiota-dotnet tied to these apps between Oct 13 and Oct 16, 2026.
Look for sign-in attempts from 144.172.64.99, 144.172.64.60 and 144.172.94.243, which Huntress tied to password spraying.

What happened#

An attacker got hold of an application credential for ConnectWise Cloud Backup, the Microsoft 365 backup service formerly called SkyKick, and used it to sign in to customer tenants as the backup app. According to the ConnectWise Trust Center advisory, the company discovered the issue on October 14, 2026. On October 17 at 07:00 UTC it disabled seven application identities and revoked the certificates behind them. It also suspended Cloud Backup, SaaS Security and Cloud Management. ConnectWise says it completed a full reset of accounts and credentials in the affected environment on October 19, and phased restoration began on October 21.

The OAuth client-credentials flow involves no user, so MFA never came into play. Huntress reported token-issuing sign-ins from 144.172.64[.]128 on October 15 and confirmed unauthorized sign-ins in 162 tenants by 19:00 UTC on October 16. A later update counted almost 1,000 Entra tenants with sign-ins from that address, over 300 of them successful. In about 50 tenants it monitors, Huntress saw ConnectWise Cloud Management service principals grant themselves directory roles, mostly Exchange Administrator. In one tenant, the "Cloud Management - MS Teams" app made itself Global Administrator and added client secrets, set to expire in 2028, to two other apps. One of them was Huntress's own application. Huntress says it then removed that credential.

In an October 21 update, ConnectWise said that the evidence, including threat intelligence shared by Microsoft, points to a China state-aligned group. According to ConnectWise, the group used an openly available agentic AI framework to automate the operation. How the credential was stolen was not disclosed as of October 21, 2026.

Who is affected#

Any Microsoft 365 tenant that consented to ConnectWise Cloud Backup (app ID 506e08f9-6e9a-4da4-942b-a099a03644ae) or the related Cloud Management apps is at risk. In older tenants these may appear as "SkyKick Cloud Manager". The backup app's existing consent covers reading and writing mail, OneDrive and SharePoint files, and Teams chats. BleepingComputer reports that Microsoft Threat Intelligence called it an "active supply-chain attack" that likely abused existing permissions, including Directory.ReadWrite.All. Many tenants are run by MSPs, so a single partner may have dozens of exposed customers.

Do you really need to act?#

Yes, if those apps exist in your tenant, even if you no longer use the backup service. ConnectWise says backup archives "remain encrypted, isolated, and preserved, with no indication of compromise." It also says it cannot see into customer tenants, so it cannot tell you whether yours was touched. Containment on the vendor side stops new sign-ins with the old credential. It does not undo role assignments, secrets or inbox rules that were already added. ConnectWise also warns that previously issued tokens may stay usable until they expire.

The impact varied. Todyl found only sign-ins in the tenants it reviewed: no new accounts, roles or secrets. Huntress saw persistence set up in some tenants within minutes. Reads made through the backup app are hard to tell apart from normal backup traffic, and Graph directory reads leave no audit record. Absence of evidence is weak comfort here.

What to do now#

Disable the apps in every tenant you manage. In Entra, open Enterprise applications, then Properties, and set "Enabled for users to sign-in?" to No, or run Update-MgServicePrincipal -ServicePrincipalId <id> -AccountEnabled:$false. Disable rather than delete, so consent and evidence survive.
Find every ConnectWise or SkyKick service principal, for example with Get-MgServicePrincipal -Filter "appId eq '506e08f9-6e9a-4da4-942b-a099a03644ae'", plus the Cloud Management app IDs Huntress lists.
Remove directory roles you did not grant, then audit client secrets and certificates on all apps for additions since October 13.
Check Exchange for forwarding, inbox rules (Get-InboxRule -Mailbox <user>) and delegated access, and review Conditional Access exclusions and federation trusts.
Export logs before retention expires, and keep the apps disabled until ConnectWise issues reconnection instructions for your service.

How to tell if you were hit#

The default user sign-ins view will not show this activity. Open the Service principal sign-ins tab and filter on the Cloud Backup app ID. Flag 144.172.64.128, any non-Microsoft address, and the user agents Python-urllib/3.12, python-requests/2.31 and kiota-dotnet. In audit logs, search for "Add member to role", "Update application" and "Add service principal credentials" initiated by these apps. Huntress also lists 144.172.64.99, 144.172.64.60 and 144.172.94.243 for password spraying. Any hit means you should treat mail, files and Teams data in that tenant as possibly exposed.

Timeline#

Oct 13, 2026 — Huntress sees password spraying against law-firm tenants from the attacker's address range (Oct 13–14).
Oct 14, 2026 — ConnectWise discovers the problem and starts incident response.
Oct 15, 2026 — Service principals self-assign directory roles from 01:58 UTC, and token sign-ins from 144.172.64.128 sweep tenants in GUID order.
Oct 16, 2026 — ConnectWise posts its advisory, and Huntress and Todyl publish findings.
Oct 17, 2026 — ConnectWise disables seven app identities and suspends Cloud Backup, SaaS Security and Cloud Management (Cybersecurity Dive).
Oct 19, 2026 — Full credential reset completed in the Cloud Backup environment.
Oct 21, 2026 — Phased restoration begins, and ConnectWise attributes the attack to a China state-aligned group.

Sources

Original sources first: vendor and project advisories, CVE and government records, the discoverers’ write-ups. Every claim above links to one of these. See how the Security Desk works.

Original and primary sources

Coverage and analysis

BleepingComputer — Hackers breach Microsoft 365 tenants via ConnectWise supply-chain attack bleepingcomputer.com
Cybersecurity Dive — ConnectWise suspends Cloud Backup service as hacker targets Microsoft 365 users cybersecuritydive.com