ConnectWise Cloud Backup incident: review the Microsoft 365 tenant before reconnecting

This is for the IT administrator or managed service provider responsible for Microsoft 365 at a small organization. If you have used ConnectWise Cloud Backup, formerly SkyKick, the immediate job is to establish what happened inside your tenant: your organization’s Microsoft 365 environment.

As of its October 24, 2026, 14:00 Coordinated Universal Time update, ConnectWise says it is testing restoration and targeting phased partner onboarding beginning Monday, October 26. That timing is conditional on successful checks. The company says affected connections should remain disabled until it provides instructions for the particular service. It reports no indication that existing encrypted, isolated backup archives were compromised. That statement concerns the archives; it does not clear customer tenants. ConnectWise’s advisory makes the continuing need for tenant review explicit.

For a small business, those are separate questions with separate owners. Is the backup provider returning? Has someone reviewed our environment? Can we actually restore a file today? Ask all three before closing an incident ticket.

The trusted application was the access path

Todyl’s investigation describes unauthorized sign-ins on October 15 using the Cloud Backup application’s credential. The attacker authenticated as software, rather than as a person. Previously granted application permissions provided access to Microsoft 365 resources. In the tenants Todyl monitors, it found no new accounts, permissions, or persistence. Its October 23 update, though, cites Microsoft research that elsewhere the actor changed application credentials, assigned privileged roles, changed groups, and read Azure Key Vault secrets. Todyl now advises every affected organization to hunt for persistence and to treat its data as potentially exposed. Todyl’s investigation distinguishes successful authentication from confirmed data copying.

A useful way to explain this at the help desk is that the organization had already given a backup application permission to work unattended. The attacker used that existing relationship. A user changing their password does not necessarily address access held by an application.

This was not a small, opportunistic break-in. ConnectWise’s October 21 update attributes the activity to a China state-aligned group, citing Microsoft. According to Todyl’s summary of Microsoft’s research, Microsoft tracks the actor as Storm-0940, which attempted sign-ins against more than 2,250 tenants using several ConnectWise application credentials. Huntress confirmed unauthorized sign-ins in 162 tenants it monitors.

Todyl also explains why multi-factor authentication, which asks a person for an additional proof during login, did not apply to this application-only flow. This is a reason to examine software identities alongside human accounts, not a reason to abandon multi-factor authentication.

Containment needs a second pass

Huntress found two tenants where a ConnectWise application (in one case, Cloud Management for MS Teams) granted itself Global Administrator. In one of them, the attacker also added new client secrets to other management applications. Its October 19 update says it found no mailbox or file manipulation, or user or policy changes, in those two investigations. It also cautions that some directory reads leave no audit record. Those findings describe the environments Huntress examined, not every customer. Huntress’s investigation is particularly useful for understanding persistent access.

Huntress recommends disabling affected applications rather than deleting them, and reviewing credentials across all Microsoft 365 applications. It also suggests checking for secrets or certificates added to any application since October 13. Turning off the original connection does not remove secrets planted elsewhere.

The scope is wider than backup, too. On October 17 ConnectWise disabled seven of its application identities and suspended its SaaS Security and Cloud Management services as well.

Think of the review as a set of questions you must answer with records. Which application authenticated? Which permissions did it have? Did anything create another way in? Which evidence is missing? A clean endpoint scan cannot answer those cloud questions on its own.

What to do about it

Start by assigning one person responsibility for the tenant review and a second person responsibility for recovery availability. In a small team those may be the same human, but keep the two work items explicit. Otherwise, an update about the provider coming back can accidentally become the organization’s all-clear.

Use ConnectWise’s technical investigation and remediation guide as the procedural reference. Preserve the findings and decisions in your incident record. Record which tenant was checked, by whom, when, and with which evidence. A provider managing several customers should keep a separate result for each customer.

Before removing suspicious material, document it. Save relevant sign-in and audit evidence, application identifiers, credential metadata, and the permissions present during the exposure. Handle exports as sensitive information and restrict access to the response team. Ask qualified responders to direct collection if you are unsure how a change will affect evidence.

Review inherited integrations as well as services you currently pay for. Search for every ConnectWise application identifier the advisory publishes, not just Cloud Backup and not just a familiar display name. Ask the previous provider what it installed and what it removed during offboarding. Treat an unanswered question as an open investigation item, rather than filling the gap with an assumption.

If you identify an unauthorized credential or role change, broaden the response beyond the original backup application. Determine what that identity could reach and involve your incident-response provider. Make remediation decisions from the actual permissions and evidence. Do not mass-delete applications simply to make a dashboard look clean.

For recovery planning, write down the most recent backup you have verified, the period potentially missing, and the current restore route. Tell the business owner what those limits mean in ordinary terms. For example, can payroll recover yesterday’s spreadsheet if someone overwrites it today? Record the answer and the next verification time.

When formal reconnection instructions arrive, schedule a controlled return. Verify new backups complete and perform a small, authorized restoration test. Keep the security investigation open until its own questions are answered; a successful backup job is evidence of recovery functionality, not proof about prior access.

What remains uncertain

There is no final victim count yet, a complete inventory of stolen information, or an established explanation for how the vendor credential was obtained. The cited investigations have different observation scopes. The practical conclusion is narrower: check your environment, preserve what you can establish, and distinguish unknown data exposure from proven absence of exposure.

Before publication, recheck the live vendor advisory. October 26 is a restoration target in the October 24 update, not a completed milestone.

Sources

• ConnectWise — Trust Center advisories, Cloud Backup updates, originally October 16, 2026; updated October 24, 2026.
• Todyl — Investigation: Unauthorized Access Through the ConnectWise Cloud Backup Microsoft 365 App, published October 16, 2026; updated October 23, 2026 with Microsoft’s October 21 research.
• Huntress — ConnectWise (SkyKick) Vendor Credentials Abused in M365 Attacks, updates October 17–19, 2026.
• ConnectWise — Cloud Backup technical investigation and remediation guide, linked from the October 24, 2026 advisory. No publication date was established for the PDF itself.