If you manage Microsoft 365 for customers, ConnectWise Cloud Backup (the service formerly known as SkyKick) has probably dominated your last ten days. Scheduled backups stopped, two companion services went dark, and a supply-chain attack turned a trusted backup app into a path into customer tenants. ConnectWise now aims to let partners restore data from existing archives on October 26. That is useful news, but it answers only one of the three questions admins actually have: can I get my data back, is my tenant clean, and when do my backups run again?
This guide covers all three. It explains what ConnectWise has promised, what remains offline, what the "no indication of compromise" statement really covers, and the exact Microsoft 365 checks I recommend running in every tenant, including tenants that stopped using SkyKick years ago.
⚡ Quick Summary
- Target: phased partner onboarding and restore-from-archive access starting Monday, October 26, 2026, subject to successful testing and security validation.
- Still offline: scheduled Cloud Backup jobs, SaaS Security monitoring and Cloud Management user/license management. Full re-enrollment comes later, in phases.
- Archives: ConnectWise says existing backup archives are encrypted, isolated and show no indication of compromise. It also says it cannot see whether your Microsoft 365 tenant was breached.
- Your job: review every tenant where the affected apps were ever consented, search by application ID, preserve logs, and hunt for persistence before re-enabling anything.
ConnectWise's two-phase restore plan
ConnectWise's October 23 update split recovery into two stages, and the difference matters for how you plan customer communication.
| Phase | What partners get | What it does not mean |
|---|---|---|
| 1. Restore access Target: Oct 26 | A process to restore data from existing Cloud Backup archives, after testing and validation succeed. | Scheduled backups are not running again, and no tenant is declared clean. |
| 2. Full re-enrollment Later, in phases | Step-by-step instructions, video tutorials and webinars to set the service up again and verify it. | No date has been published for it. |
The company's October 24 Trust Center advisory describes the Monday date as a target for beginning phased onboarding, "subject to successful completion of the required checks." Every date ConnectWise has issued so far has been conditional, so plan for slippage rather than assuming Monday is guaranteed.
What is still offline
Three services are affected, not one. SaaS Security and Cloud Management were suspended as a precaution because they integrate with Cloud Backup.
| Service | Unavailable during suspension |
|---|---|
| Cloud Backup (formerly SkyKick) | Scheduled backup jobs, archive access, restores |
| SaaS Security | Monitoring and alerting |
| Cloud Management | User and license management |
ConnectWise has described restore access as the first capability to return and has not given dates for SaaS Security alerting or Cloud Management licensing. MSPs that need user or license changes in the meantime should work through ConnectWise Partner Care.
Incident timeline
- Oct 10–14: Failed password-spray activity against a small set of organizations, per Microsoft's reporting.
- Oct 15: Huntress observes the compromised Cloud Backup identity signing in to customer Microsoft 365 tenants.
- Oct 16: ConnectWise publishes its first advisory about unauthorized access in the Cloud Backup environment.
- Oct 17: ConnectWise suspends Cloud Backup, revokes certificates behind the affected app connections, and disables seven application identities listed on its Trust Center.
- Oct 18: SaaS Security and Cloud Management are taken offline as a precaution.
- Oct 19–20: ConnectWise completes an account and credential reset in the affected Cloud Backup environment.
- Oct 21: Microsoft Threat Intelligence attributes the compromise to Storm-0940, a China state-aligned actor, and says the actor used the open-source ARTEX agentic AI framework. ConnectWise reports it has begun controlled, phased restoration.
- Oct 22: ConnectWise starts publishing updates twice daily.
- Oct 23–24: Restore access is forecast, then narrowed to a Monday, Oct 26 target.
What "no indication of compromise" covers
ConnectWise has repeated that existing backup archives are encrypted, isolated and preserved. Read that sentence literally: it describes stored archives, not your live Microsoft 365 tenants.
ConnectWise has been explicit about this limit. Cloud Backup is designed so that the vendor has no visibility into downstream partner and customer environments, so it cannot independently determine whether any individual tenant was breached. Think of it as the vault versus the building: the vault may be intact, but you still need to find out what happened inside each building while someone held a working key.
How the attack worked
Cloud Backup is a multi-tenant app. Customers grant it permission to operate in their tenants, usually with application permissions that need no user sign-in. That is exactly why MFA and most Conditional Access policies never get a chance to stop it. Microsoft assessed that the actor likely abused permissions previously granted by customers.
What defenders have reported
- Microsoft: attributes the compromise to Storm-0940 using ARTEX, and reports sign-in attempts against more than 2,250 tenants, with Microsoft Graph reconnaissance and attempts to add credentials to service principals for persistence. In several cases the time from initial targeting to privileged access was under three hours.
- Huntress: saw the Cloud Backup identity sign in to 162 Microsoft 365 tenants between October 15 and 16. In one tenant, a ConnectWise Cloud Management app for Teams added itself to the Global Administrator role and then ran a script that added new client secrets to other applications.
- The noisy part failed: the October 10–14 password spraying generated well over 100,000 failed logons, but Microsoft reported no successful authentication in that phase. The quiet app-identity abuse that followed is the part that mattered.
These counts differ because each organization measured something different: attempts, successful sign-ins, or tenants it could see. Treat them as scale indicators, not as competing facts, and remember that Microsoft cautions an affected app or even a successful authentication does not by itself prove data was accessed or exfiltrated.
Former customers are still in scope
This is the scenario most likely to catch admins out. Reporting indicates that some affected tenants no longer had an active backup subscription. What they still had was the consent they once gave to the app. If your organization dropped SkyKick two years ago and never removed the enterprise application, the service principal and its permissions may still exist in your tenant.
Microsoft's guidance is to review every tenant where the affected applications are installed or authorized now or in the past, and to search by application ID, not by display name. Display names such as "SkyKick Backup" and "ConnectWise Cloud Backup" can vary, and names are easy to spoof.
Tenant check: step by step
This sequence follows Microsoft's mitigation guidance and ConnectWise's partner instructions. Run it in your own MSP tenant and in every customer tenant.
- Keep the affected connections disabled until ConnectWise publishes instructions for your service.
- Do not delete the enterprise apps first. Preserve configuration and evidence before making changes you cannot undo.
- Search by application ID in each tenant and record the local service principal Object ID.
- Preserve logs: Entra sign-in and audit logs, Microsoft Purview Audit, SIEM data and any Graph telemetry. Do not delay containment waiting for exports.
- Review from at least October 15, and back to October 1 where retention allows. Examine successful and failed service-principal sign-ins separately, and do not limit the review to published IP addresses.
- Hunt for persistence: credentials added to apps or service principals, new apps or owners, app-role assignments, consent grants, privileged role changes, and changes to Conditional Access or authentication methods.
- Check mailbox and file activity: unusual access, forwarding, inbox or transport rules, and delegated permissions.
- Pass the guidance on to customer tenant admins if you sell through a reseller, distributor or marketplace.
1. Find the service principals by application ID
ConnectWise lists seven disabled application identities on its Trust Center, while Microsoft's hunting guidance references four application IDs. Use both lists. The IDs below were published in press coverage of the advisory; confirm them against the Trust Center before relying on them.
Connect-MgGraph -Scopes "Application.Read.All","Directory.Read.All","RoleManagement.Read.Directory"
$appIds = @(
"506e08f9-6e9a-4da4-942b-a099a03644ae", # ConnectWise Cloud Backup
"2399d300-6fca-4e6a-a686-399fefe75b83", # Cloud Management
"24205314-2b89-4e07-a2a4-579e898a5640", # Cloud Management - MS Teams
"412dcf96-176d-4b3a-a1b0-4981ad66971e" # Cloud Management - Partner Center
)
foreach ($id in $appIds) {
Get-MgServicePrincipal -Filter "appId eq '$id'" |
Select-Object DisplayName, AppId, Id, AccountEnabled, CreatedDateTime
}2. Look for credentials added to apps
Attackers who keep access after the original app is fixed often do it by adding a client secret or certificate. This lists apps with credentials that started on or after October 1.
$since = Get-Date "2026-10-01"
Get-MgApplication -All -Property Id,DisplayName,AppId,PasswordCredentials,KeyCredentials |
Where-Object {
($_.PasswordCredentials.StartDateTime -ge $since) -or
($_.KeyCredentials.StartDateTime -ge $since)
} |
Select-Object DisplayName, AppId, Id3. Check whether any service principal holds a directory role
Huntress reported an app granting itself Global Administrator, so this check deserves priority.
Get-MgDirectoryRole -All | ForEach-Object {
$role = $_
Get-MgDirectoryRoleMember -DirectoryRoleId $role.Id -All |
Where-Object { $_.AdditionalProperties.'@odata.type' -eq '#microsoft.graph.servicePrincipal' } |
ForEach-Object {
[pscustomobject]@{
Role = $role.DisplayName
App = $_.AdditionalProperties.displayName
AppId = $_.AdditionalProperties.appId
}
}
}Expect to see some legitimate results, such as your security tools. What you are hunting for is any app you cannot explain.
4. Hunt in your SIEM with KQL (Log Analytics / Sentinel)
Adjust table names to match your connectors, and verify the operation names against what your tenant actually logs.
// Service-principal sign-ins from the affected apps
AADServicePrincipalSignInLogs
| where TimeGenerated > datetime(2026-10-01)
| where AppId in ("506e08f9-6e9a-4da4-942b-a099a03644ae",
"2399d300-6fca-4e6a-a686-399fefe75b83",
"24205314-2b89-4e07-a2a4-579e898a5640",
"412dcf96-176d-4b3a-a1b0-4981ad66971e")
| project TimeGenerated, AppId, ServicePrincipalName, IPAddress, ResultType, ResourceDisplayName
| order by TimeGenerated asc
// Persistence-style changes
AuditLogs
| where TimeGenerated > datetime(2026-10-01)
| where OperationName has_any ("Add service principal credentials",
"Add member to role",
"Add app role assignment to service principal",
"Consent to application")
| project TimeGenerated, OperationName, InitiatedBy, TargetResourcesWhen should you re-enable the apps?
My recommendation is to treat re-enablement as a change that must earn its approval, not an automatic step after Monday. Before reconnecting any ConnectWise app in a tenant:
- ConnectWise has issued formal re-enrollment instructions for your specific service.
- You have completed the checks above and resolved or explained every finding.
- Any unexplained credentials or role assignments have been removed through a controlled, documented change.
- Monitoring is in place for new credential additions on the app and for the app's privileged role membership.
Using restore access in the meantime is a separate decision. Restoring data from an archive reads from ConnectWise's isolated storage, but follow the vendor's process exactly and keep notes on what you restored and when, in case you need to prove integrity later.
Hardening against the next one
The lesson goes well beyond SkyKick. Any third-party app with tenant-wide Microsoft Graph permissions carries enormous trust, and if its credentials are stolen the attacker inherits that consent in every tenant that granted it. A few controls reduce that exposure:
- Audit app consent regularly. Review enterprise applications and their permissions, and remove integrations nobody uses. See Microsoft's guidance on managing application permissions.
- Apply least privilege to multi-tenant app permissions. A backup tool rarely needs more than it was designed to read.
- Protect workload identities. Service principals bypass MFA, so look at Microsoft Entra Workload ID for risk detection and Conditional Access on app identities where your licensing allows.
- Alert on credential additions to high-privilege apps and on service principals joining directory roles.
- Keep an independent recovery path. One backup vendor should not be the only thing standing between a customer and data loss.
If you are building out your Microsoft 365 and Entra ID skills, browse more practical guides on VMoreCloud. You can also see the backup and disaster recovery articles for related recovery planning.
Frequently asked questions
Will ConnectWise Cloud Backup restore access really start on October 26?
It is a target, not a commitment. ConnectWise says phased partner onboarding begins Monday, October 26 only if testing and security validation succeed. Watch the Trust Center for confirmation.
Does restore access mean my scheduled backups are running again?
No. Restore access lets partners recover data from existing archives. Scheduled backups return only after full re-enrollment, which ConnectWise says will happen in phases with its own instructions.
Is my Microsoft 365 tenant compromised?
ConnectWise cannot tell you, because it has no visibility into downstream tenants. You need to review your own sign-in, audit and application logs using the steps above.
I stopped using SkyKick years ago. Do I still need to check?
Yes. If the enterprise application and its consent were never removed, the app may still exist in your tenant with its permissions. Search by application ID.
Should I delete the ConnectWise enterprise apps now?
Not before you preserve evidence. Microsoft advises capturing configuration and logs first, because deleting the app can remove information you need for the investigation.
Who is behind the attack?
Microsoft attributes the compromise to Storm-0940, a China state-aligned actor, and says it used the ARTEX framework. That attribution comes from Microsoft's threat intelligence, and the Chinese government has denied involvement in such activity in the past.
Sources and further reading
- WindowsForum: ConnectWise Cloud Backup Restore Target, October 26 Phased Recovery and Microsoft 365 Tenant Checks
- Microsoft Security Blog: Storm-0940 uses ARTEX agentic AI in the ConnectWise supply chain compromise
- BleepingComputer: Hackers breach Microsoft 365 tenants via ConnectWise supply chain attack
- SecurityWeek: ConnectWise suspends cloud services in response to cyberattack
- The Hacker News: ConnectWise resets credentials as Cloud Backup restoration continues
- Cybersecurity Dive: ConnectWise suspends Cloud Backup after Microsoft 365 attack
- ConnectWise Trust Center and Partner Care: the authoritative source for application IDs, status and restoration instructions.
This article is based on public vendor and press disclosures available on October 25, 2026, and will be updated as ConnectWise confirms restoration milestones. It is general guidance, not a substitute for your own incident response process or legal advice.
