Security Guides

#supply chain #Microsoft 365 #OAuth #AI security #MSP #incident response

ConnectWise Cloud Backup (formerly SkyKick) incident: AI-driven sign-in attempts against 2,250+ Microsoft 365 tenants, and what admins should check

Q: What happened at ConnectWise?

ConnectWise's advisory (first published October 16, 2026) says there was unauthorized access to application credentials associated with Cloud Backup, formerly SkyKick, its Microsoft 365 backup service for MSPs. It disabled seven application identities on October 17, suspended Cloud Backup, and as a precaution SaaS Security and Cloud Management, and reset all accounts and credentials in the affected Cloud Backup environment on October 19.

Q: Are my Microsoft 365 tenant and data affected?

ConnectWise says its findings do not establish whether individual partner or customer Microsoft 365 environments were affected, and that it has no indication its existing backup archives were compromised. Microsoft says an affected application or a successful sign-in does not necessarily mean data was accessed or copied. The practical answer is to check your own tenant for the identifiers and changes described below.

Q: What does '2,250 tenants' mean?

Microsoft says the group used the AI framework to attempt sign-ins to more than 2,250 tenants. That is a count of tenants targeted, not of tenants compromised. Microsoft says most of the targeting was unsuccessful, but that privileged cloud access was gained at many organizations without giving a count. A security firm separately confirmed unauthorized sign-ins in 162 tenants as of October 16 and later reported more than 300 successful sign-ins from the same source across a broader set. These figures measure different things and should not be added together.

Q: How did AI change this attack?

Microsoft describes the tool as an open-source system of cooperating AI agents that can carry out a security test from reconnaissance through data theft with little human involvement, using any AI model. Microsoft's assessment is that this let the group work across many tenants at machine speed, with some privileged access reached within three hours of first targeting. The weaknesses used were ordinary ones: sign-in credentials and application permissions.

Q: What should a Microsoft 365 admin check?

Search your tenant for the affected ConnectWise and SkyKick applications by application ID, not display name. Keep them disabled rather than deleting them, preserve logs, and review service principal sign-ins, new client secrets or certificates on any application, directory role assignments, consent grants, Conditional Access changes and mailbox rules, starting from about October 1 where records allow.

Q: Who attacked, and is the cause known?

ConnectWise says that, based on its evidence and threat intelligence shared by Microsoft, a China state-aligned group appears to have been responsible. Microsoft assesses the same. How the application credentials were first obtained has not been published, and Microsoft says the activity did not result from a compromise of or a vulnerability in its own systems, products or services.

ConnectWise disabled Cloud Backup (ex-SkyKick) after unauthorized access to app credentials. Microsoft says AI agents then tried 2,250+ tenants. What to check.

Published 2026-10-30 Updated 2026-10-30 Last verified 2026-10-30 13 min read

On this page

For: Microsoft 365 administrators, MSPs that used ConnectWise Cloud Backup, Cloud Management or SaaS Security (formerly SkyKick), and companies whose IT provider does. This article is based on ConnectWise's advisory and Microsoft's research post, and it does not cover attack techniques.

Bottom line

Check your tenant for the ConnectWise and SkyKick apps by ID, and keep them disabled

ConnectWise says someone gained unauthorized access to credentials used by its Microsoft 365 backup service. Those apps can hold broad permissions inside customer tenants, so the question for an admin is what those apps, and any other app they touched, can now do in your tenant.

Search for the affected applications by application ID, since older installs may still show SkyKick names
Disable, do not delete, and keep them disabled until ConnectWise says otherwise
Look for new credentials on any application, unexpected directory roles and consent changes
Do not treat a clean first look as proof: Microsoft says no results in the Graph activity logs should not be read as confirmation that no access occurred, and ConnectWise says completing its steps does not guarantee a tenant is unaffected
If you use an MSP, ask them in writing whether they used these apps in your tenant

Developing: this article will be updated as the organisation publishes more

As of October 30, 2026

Not yet known

How the application credentials were first obtained
Number of tenants actually compromised
Whether any customer data was accessed or copied
When Cloud Backup restoration will be complete

ConnectWise's advisory was last updated on October 29, 2026 (20:45 UTC). It says phased restoration of Microsoft 365 backups began on October 28 through a new application, "ConnectWise Cloud Backup for M365", and that partners must not re-enable previously disabled applications unless ConnectWise instructs them to.

What Microsoft 365 admins should check today

Find the applications by ID, in your own tenant and every customer tenant you manage

In Entra ID, open Enterprise applications and App registrations and search by application ID rather than name. ConnectWise's advisory lists the seven application identities it disabled (Cloud Backup, Cloud Management and five Cloud Management integrations), and says older installs can appear under SkyKick names. The Cloud Backup application ID published by ConnectWise is 506e08f9-6e9a-4da4-942b-a099a03644ae; take the full list from the advisory itself.

Include past installs. An app you removed from use years ago can still be present in the tenant.

Disable, do not delete, and keep the evidence

Both ConnectWise and Microsoft say to keep the affected connections disabled until ConnectWise issues restoration instructions, and Microsoft advises against deleting enterprise applications as a first step. Deleting removes consent and the audit trail you need to see what the app did. Save Entra sign-in and audit logs, Purview audit records and SIEM data before changing anything.

Review service principal sign-ins

Look at sign-ins by these applications, successful and failed separately, from at least October 15 and ideally back to October 1. Do not limit the review to the IP addresses ConnectWise published: Microsoft says not to, and ConnectWise's own guide says not to restrict the search to the published IP. The ConnectWise application's normal traffic comes from Azure ranges, so successful sign-ins from elsewhere deserve a closer look.

Check what changed inside the tenant

Disabling an app does not undo changes already made. Review, for the period above:

new client secrets or certificates on any application, especially management and security tools, that you did not add
new service principals, new owners, app-role and consent grants
directory role assignments, in particular any app that was given a privileged role
changes to groups and to Conditional Access policies or exclusions

Microsoft notes that such changes can act as a way back in after the original app is disabled.

Check mail and file activity

In the Purview audit log, look for new inbox rules, forwarding to outside addresses, rules that hide or delete messages, new Full Access or Send As permissions, and transport rule changes. Validate each against changes your team approved. Authentication by an app does not by itself show that data was copied, and logging that was not enabled earlier cannot be recovered now.

Escalate quickly, and ask your provider

If you find unexpected credentials, privileged assignments or suspicious successful activity, bring in your incident response provider. ConnectWise asks partners to report findings to its security partner support address given in the advisory, without including passwords, keys or tokens. If an MSP manages your tenant, ask which of these apps they used, when, and what they have checked.

What happened (per ConnectWise and Microsoft)

October 15, 2026
A security firm that investigated the incident saw the main burst of unauthorized sign-ins using the vendor's application credential (per that firm's report).
October 16
ConnectWise first published its advisory. The security firm reported unauthorized sign-ins in 162 tenants as of 19:00 UTC.
October 17
ConnectWise disabled seven application identities and suspended Cloud Backup by revoking the certificates its connections used. It also says it suspended SaaS Security and Cloud Management as a precaution (the advisory gives no time for that step), so scheduled backups are not running. The security firm later reported nearly 1,000 tenants with sign-in activity from the same source, more than 300 of them successful.
October 19
ConnectWise completed a full reset of all accounts and credentials in the affected Cloud Backup environment.
October 21
Microsoft published its research post. ConnectWise updated its advisory to say that, based on its evidence and Microsoft's threat intelligence, a China state-aligned group appears to have been responsible.
October 28
Phased restoration began for Microsoft 365 backups, through a new application that partners must re-authorize in each tenant.
October 29
Latest advisory update. Restoration continues; ConnectWise repeats that disabled applications must stay disabled unless it says otherwise.

2,250+

Tenants Microsoft says were targeted with sign-in attempts

162

Tenants with confirmed unauthorized sign-ins (security firm, Oct 16)

ConnectWise application identities disabled

<3 hours

From first targeting to privileged access in some cases (Microsoft)

What the two organisations have published

Service: Cloud Backup (formerly SkyKick), a Microsoft 365 backup service sold through MSPs. Cloud Management and SaaS Security were suspended as a precaution because they connect to it
Backup archives: ConnectWise: existing archives remain encrypted and isolated, with no indication of compromise
Customer tenants: ConnectWise: findings do not establish whether partner or customer Microsoft 365 environments were affected. Microsoft: an affected app or a successful sign-in does not necessarily mean data was accessed
Attribution: ConnectWise, citing Microsoft threat intelligence: a China state-aligned group appears responsible. Microsoft assesses the same
Microsoft systems: Microsoft says the activity did not result from a compromise of or vulnerability in its own systems, products or services
Other ConnectWise products: ConnectWise reports no indication that products beyond the three suspended services are affected

The AI angle, in plain terms

Microsoft says the group used ARTEX, an open-source tool made of several cooperating AI agents. It works with any AI model and can run a security test on its own, from mapping a target to reading data, with little human involvement. Microsoft notes that public reporting in October also linked the same tool to breaches at Korean financial institutions (see our article on those breaches), and that actors in several regions use it.

What Microsoft describes is the same set of weaknesses as before, used much faster. Microsoft says that after the vendor credential was misused, the tool was used to attempt sign-ins to more than 2,250 tenants and, where access was gained, to work through directory and application settings. Microsoft gives no per-minute rate for those attempts. Separately, it describes password guessing from October 10 to 14 against 327 accounts at eight organizations that produced more than 151,000 failed sign-ins, peaking at 2,900 failures per minute on October 11, with no successful sign-in in that activity. For defenders the practical effect is a shorter time between first contact and privileged access, so alerting on new credentials and role changes matters more than reviewing logs a week later. For a broader picture of AI-driven intrusion, see the Hugging Face intrusion article.

Vendor app credentials misused

↓→

Does the app still exist in your tenant, under any name?

→ Search by application ID, including old installs

Apps were given roles and new secrets (Microsoft, security firm)

↓→

Does any app have a credential or role you did not add?

→ Review credentials and directory roles on all apps

Access reached in under three hours (Microsoft)

↓→

Would you learn of a new credential today, not next week?

→ Alert on new secrets and role changes

What the published facts mean for an admin (a general mapping)

What is known and what is not

Status as of October 30, 2026. We will update the status column as ConnectWise and Microsoft publish more.

Item	What the organisations say	Status
Unauthorized access to Cloud Backup application credentials	ConnectWise advisory, first published October 16	Confirmed (ConnectWise)
Seven application identities disabled, certificates revoked	October 17	Confirmed (ConnectWise)
All accounts and credentials in the affected environment reset	October 19	Confirmed (ConnectWise)
Backup archives accessed	No indication of compromise	Not found (ConnectWise)
Customer Microsoft 365 tenants affected	Findings do not establish whether they were	Under investigation
Tenants targeted by AI-driven sign-in attempts	More than 2,250	Confirmed (Microsoft), attempts not compromises
Tenants with unauthorized sign-ins	162 as of October 16; more than 300 successful sign-ins from the same source later	Reported (security firm)
Privileged access gained	At many organizations, count not given; some within three hours	Confirmed (Microsoft)
Data copied from any tenant	Not stated; Microsoft cautions sign-in alone does not show it	Not disclosed
How the credentials were first obtained	Not stated	Under investigation
Responsible party	State-aligned group	Assessment (ConnectWise, Microsoft)
Restoration	Phased since October 28, new application, re-authorization needed	In progress

How to read the numbers: three counts, three meanings

2,250 is tenants targeted. 162 is tenants where unauthorized sign-ins were confirmed on one day. "More than 300" is successful sign-ins from the same source across a wider set. None of them is a count of data theft, and none is a total of victims.

Why one backup app can matter to many companies

A multi-tenant app works through a single set of credentials that every customer tenant has approved. Whoever holds those credentials can attempt to sign in as the app in all of those tenants at once. Backup tools often hold wide read permissions, which is what makes them useful and also why they deserve a careful permission review. This is the same shape as earlier incidents where a trusted vendor connection, rather than the customer's own staff, was the way in. See Data breaches and cyberattacks in 2026 for related cases.

For admins and MSPs: reviewing apps that hold broad access

This section is this site's own general recommendations, not ConnectWise's or Microsoft's. Some points, such as limiting Application Administrator rights, Conditional Access exclusions, workload identity protection and MFA, go beyond what the two organisations published. It is not an assessment of how the credentials were obtained, which has not been disclosed.

List every third-party app with directory or mail permissions, record who owns it and why it exists, and remove the ones nobody can explain
Limit who holds the Application Administrator role, because that role can add credentials to apps
Alert on new client secrets or certificates, and on any app assigned a directory role
Review Conditional Access exclusions that let an app bypass location-based blocks
Enforce multi-factor authentication for people, and use workload identity protections for apps, since app sign-ins do not use MFA
Know your last good backup point. With Cloud Backup suspended, check how long your protection gap is, and see backup and recovery essentials for a second copy you control

Sources (public record)

ConnectWise, "Cloud Backup (formerly SkyKick) Security Advisory, October 2026" (first published October 16, last updated October 29, 2026) — connectwise.com
Microsoft Threat Intelligence, "AI-driven, large-scale nation-state campaign using ARTEX enables supply chain compromise" (October 21, 2026) — microsoft.com
A security firm's investigation report on unauthorized sign-ins using the vendor credential (updated through October 27, 2026) — huntress.com

Update history

2026-10-30: First version, based on ConnectWise's advisory as updated on October 29 and Microsoft's October 21 research post. We will update this article when either publishes more.

Latest breaking reports

All breaking reports →

FAQ

QWhat happened at ConnectWise?

ConnectWise's advisory (first published October 16, 2026) says there was unauthorized access to application credentials associated with Cloud Backup, formerly SkyKick, its Microsoft 365 backup service for MSPs. It disabled seven application identities on October 17, suspended Cloud Backup, and as a precaution SaaS Security and Cloud Management, and reset all accounts and credentials in the affected Cloud Backup environment on October 19.

QAre my Microsoft 365 tenant and data affected?

ConnectWise says its findings do not establish whether individual partner or customer Microsoft 365 environments were affected, and that it has no indication its existing backup archives were compromised. Microsoft says an affected application or a successful sign-in does not necessarily mean data was accessed or copied. The practical answer is to check your own tenant for the identifiers and changes described below.

QWhat does '2,250 tenants' mean?

Microsoft says the group used the AI framework to attempt sign-ins to more than 2,250 tenants. That is a count of tenants targeted, not of tenants compromised. Microsoft says most of the targeting was unsuccessful, but that privileged cloud access was gained at many organizations without giving a count. A security firm separately confirmed unauthorized sign-ins in 162 tenants as of October 16 and later reported more than 300 successful sign-ins from the same source across a broader set. These figures measure different things and should not be added together.

QHow did AI change this attack?

Microsoft describes the tool as an open-source system of cooperating AI agents that can carry out a security test from reconnaissance through data theft with little human involvement, using any AI model. Microsoft's assessment is that this let the group work across many tenants at machine speed, with some privileged access reached within three hours of first targeting. The weaknesses used were ordinary ones: sign-in credentials and application permissions.

QWhat should a Microsoft 365 admin check?

Search your tenant for the affected ConnectWise and SkyKick applications by application ID, not display name. Keep them disabled rather than deleting them, preserve logs, and review service principal sign-ins, new client secrets or certificates on any application, directory role assignments, consent grants, Conditional Access changes and mailbox rules, starting from about October 1 where records allow.

QWho attacked, and is the cause known?

ConnectWise says that, based on its evidence and threat intelligence shared by Microsoft, a China state-aligned group appears to have been responsible. Microsoft assesses the same. How the application credentials were first obtained has not been published, and Microsoft says the activity did not result from a compromise of or a vulnerability in its own systems, products or services.