ConnectWise has confirmed unauthorized access to Microsoft Entra application identities tied to ConnectWise Cloud Backup, formerly SkyKick, and has disabled seven related application identities. Huntress observed those vendor identities signing in to Microsoft 365 tenants from an attacker's IP address on October 15, 2026, and in at least two tenants an affected application granted itself Global Administrator. Microsoft attributes the attack to Storm-0940, a China state-aligned group that used ARTEX, an open-source AI agent framework, to automate it. On October 28, ConnectWise began restoring Microsoft 365 backups and restores through a new, security-hardened application, ConnectWise Cloud Backup for M365, and published reconnection steps: reset your password, set up MFA, and re-authorize each tenant with the new application. Do not re-enable the old, disabled applications, and confirm new backups actually complete after you reconnect.
If Spot On Tech manages your Microsoft 365, you are covered. We do not use ConnectWise Cloud Backup or Cloud Management for the businesses we support, and we checked every tenant we manage for the seven affected application IDs. The rest of this guide explains what happened and what every other Microsoft 365 business should check.
Current as of ConnectWise's October 30, 2026 update at 21:00 UTC Huntress's October 19 update, and Microsoft's October 21 report. Sources: the ConnectWise Trust Center and the Huntress investigation, and Microsoft Threat Intelligence. Follow those sources for further developments and restoration guidance.
Key takeaways
- Reconnect only through the new application. ConnectWise restored backups on October 28 through ConnectWise Cloud Backup for M365. Leave the old applications disabled, and confirm new backups complete.
- Review the affected application family. Check ConnectWise Cloud Management connections as well as Cloud Backup, including older installations listed as SkyKick Cloud Manager.
- Include services installed by a previous IT provider. A canceled contract should trigger an access review.
- Employee password resets do not remove an application's separate access. The response needs to address the identity being used.
- Check for additional access. Disabling the original integration does not remove credentials, roles, or permissions added elsewhere.
- Keep recovery in the plan. Track the last usable recovery point and make sure the business has a plan for a prolonged backup interruption.
Timeline of the ConnectWise SkyKick incident
| Date (2026) | What happened |
|---|---|
| October 10 to 14 | A password spray against 327 accounts at eight organizations, which Microsoft later traces to the same attacker, peaks at about 2,900 failed sign-ins a minute on October 11. No sign-in succeeds. |
| October 13 | Huntress observes a password spray from the same IP address against four law firm tenants. |
| October 14 | ConnectWise says it identified the issue. |
| October 15 | Huntress observes ConnectWise service principals assigning themselves directory roles, sign-ins from the attacker's IP address across nearly 1,000 tenants, and an affected application granting itself Global Administrator. |
| October 16 | ConnectWise publishes its advisory with an IP address and user agents to check. |
| October 17 | ConnectWise disables seven application identities, revokes affected certificates, suspends Cloud Backup, and engages a third-party incident response firm. |
| October 18 | ConnectWise confirms SaaS Security and Cloud Management are offline as precautions, then adds two more attacker IP addresses to its indicators. |
| October 19 | ConnectWise completes an account and credential reset in the affected environment. Huntress confirms a second tenant with post-compromise activity and reports a separate, ongoing password spray. |
| October 21 | ConnectWise begins a phased restoration that it expects to take several days, with reconnection instructions to follow for each service. Later that day it says a China state-aligned group appears to be responsible, and Microsoft publishes its report naming the group Storm-0940 and describing its use of ARTEX AI agents. |
| October 24 | ConnectWise says security validation will continue through the weekend and targets phased partner onboarding for Monday, October 26. It says existing backup archives show no indication of compromise. |
| October 26 | ConnectWise says it is still preparing for phased onboarding. Partners will first regain access to existing backups, then re-enroll in phases with step-by-step instructions. No reconnection instructions or root cause have been published. |
| October 27 | ConnectWise says it has finished preparing for phased partner restoration and is waiting on a required third-party validation. Existing backup archives remain encrypted, isolated, and preserved with no indication of compromise. No reconnection instructions or root cause have been published. |
| October 28 | ConnectWise begins phased restoration through a new application, ConnectWise Cloud Backup for M365. Partners reset their password, set up MFA, and re-authorize each tenant. Backups and restores come first; the customer portal, monitoring, reporting, and notifications follow in later phases. Previously disabled applications stay disabled. No root cause has been published. |
| October 29 | Restoration continues. Some partners see a server error when resetting their password and are told to retry or contact ConnectWise support. |
| October 30 | ConnectWise completes phases 1 and 2 (backups, restores, the customer portal, and monitoring) and starts phase 3 (backup health reporting, export jobs, and billing). Notifications return last. Existing backup archives remain encrypted and preserved with no indication of compromise. No root cause has been published. |
What ConnectWise has confirmed
ConnectWise's advisory says it disabled seven application identities, revoked affected certificates, and on October 19 completed an account and credential reset in the affected Cloud Backup environment. On October 21 it began restoring services in controlled phases and said the process will take several days. The start of restoration does not mean every capability is available, and ConnectWise publishes step-by-step reconnection instructions for each service. On October 18 at 18:45 UTC, it added two more IP addresses to the indicators customers should search for. On October 28 at 16:00 UTC, ConnectWise began phased restoration. The first phase brings back Microsoft 365 backups and restores through a new, security-hardened application, ConnectWise Cloud Backup for M365. Later phases restore the end-customer portal and monitoring dashboards, then Backup Health reporting, export, and billing, and finally notifications. ConnectWise says existing backup archives remained encrypted, isolated, and preserved with no indication of compromise. The October 28 update does not cover Cloud Management or SaaS Security, and no root cause has been published.
In its October 21 update at 22:00 UTC, ConnectWise said that "it appears that a China state-aligned group was responsible." How the attackers first obtained access is still under investigation.
Who was behind the ConnectWise breach?
Microsoft Threat Intelligence attributes the attack to Storm-0940, a China state-aligned group active since 2021 that steals data from organizations across many industries (Microsoft's October 21 report). The group has a history of password spraying and of adding credentials to existing applications for lasting Microsoft 365 access.
What stands out is how it worked. Storm-0940 used ARTEX, an open-source penetration testing framework that runs AI agents through an attack from reconnaissance to data theft with little human input. Microsoft says the agents sped up scanning, password spraying, and the abuse of trusted applications. Using four ConnectWise application credentials, the group attempted sign-ins to more than 2,250 Microsoft 365 tenants, with more than 200 sign-ins in under four minutes. Most attempts failed, but in several cases it reached privileged access in less than three hours.
Inside affected tenants, Microsoft saw the attacker change application credentials to keep access, change groups and privileged roles, and bulk-read secrets from Azure Key Vault. It also notes that finding an affected application or a successful sign-in does not by itself show that data was taken. Our post on Storm-0940 and AI-driven attacks explains what this means beyond ConnectWise.
The company reports preserved, encrypted backup archives with no evidence of access. ConnectWise says its findings so far do not establish whether individual customer Microsoft 365 environments were affected, and the root cause remains under investigation.
How do you reconnect ConnectWise Cloud Backup?
According to the ConnectWise Trust Center, partners resume Microsoft 365 backups this way:
- Reset your ConnectWise Cloud Backup password and finish MFA setup if it is not already on.
- Re-authorize each Microsoft 365 tenant with the new application, ConnectWise Cloud Backup for M365, using the method you use today: self-authentication, delegated authentication, or Partner Center.
- Do not re-enable the previously disabled applications unless ConnectWise specifically tells you to.
- Once backups are available for a tenant, confirm that new snapshots complete. ConnectWise says re-authorization alone does not confirm that backups have resumed.
- Keep investigating each tenant with ConnectWise's technical investigation and remediation guide. Re-authorization does not replace that review.
Before you grant consent, check which permissions the new application requests and make sure the right person in your organization approves it. Granting a backup application access is a security decision, not just a setup step.
What Huntress has observed in customer environments
In its October 17 update at 5:15 p.m. Eastern, Huntress reported sign-in activity from the associated IP address across nearly 1,000 Entra tenants, with more than 300 successful sign-ins. Those figures describe authentication activity, not a count of organizations with confirmed data theft.
In one partner tenant, Huntress observed the Cloud Management application for Microsoft Teams grant itself Global Administrator and add credentials to two other applications, including that tenant's Huntress application. Across roughly 50 tenants it monitors, Huntress also saw ConnectWise service principals assign themselves directory roles, mostly Exchange Administrator. Each of these creates a route back into the environment through separate identities.
In its October 19 update, Huntress said it had reviewed sign-in logs across more than 10,000 tenants with ConnectWise applications and confirmed a second tenant with post-compromise activity. In both tenants, the activity happened within minutes of 03:45 UTC on October 15: the application granted itself Global Administrator, then planted new secrets on a small number of other applications that appeared to be chosen at random. Huntress found no evidence of mailbox or file changes in those two tenants, but notes that Microsoft Graph directory reads leave no audit record. The last confirmed successful application sign-in it saw was at 08:44 UTC on October 15. After that, only failed attempts.
Huntress also observed activity recorded from private Azure IPv6 space. An investigation limited to one public IP can therefore miss relevant events. Review the identity, action, timing, and outcome together; an address or familiar application name cannot establish whether access was authorized.
Why a cloud backup connection deserves attention
Your backup provider needs access to your data to protect it. That also makes its connection to your business something worth protecting. A Microsoft 365 backup tool may need to read mailboxes, files, or other resources automatically, which can involve permissions granted to an application rather than a person. The exact reach depends on the permissions and restrictions configured in your environment.
Microsoft explains that application-only access lets software act using its own identity without a user signing in. A backup service is one example of a tool that may need this access across multiple users.
This matters because the familiar response to a stolen employee password does not cover every cloud incident. Changing a user's password does not change a vendor application's own credential. Multi-factor authentication remains essential for people, but an application using its own identity requires controls appropriate to that identity.
Your cybersecurity plan should therefore account for both people and connected services: what they can reach, who approved the access, how activity is monitored, and how access can be stopped.
What your business should check now
1. Establish whether the service is connected
Ask your IT team or provider to review Microsoft Entra enterprise applications using the vendor's list of seven disabled application identities. Match the application ID as well as the publisher; older installations may still show SkyKick Cloud Manager names.
| Application | Application client ID |
|---|---|
| ConnectWise Cloud Backup | 506e08f9-6e9a-4da4-942b-a099a03644ae |
| ConnectWise Cloud Management | 2399d300-6fca-4e6a-a686-399fefe75b83 |
| Cloud Management - MS Teams | 24205314-2b89-4e07-a2a4-579e898a5640 |
| Cloud Management - Exchange Online | b78f6a77-d4e5-46fb-87e5-d1648bd02519 |
| Cloud Management - MS Graph | 0de14c77-b9b0-4137-9360-34878a929827 |
| Cloud Management - Partner Center | 412dcf96-176d-4b3a-a1b0-4981ad66971e |
| Cloud Management - SharePoint Online | b2b55f5b-7758-4719-8d8f-88ae172e6bdb |
Include every Microsoft 365 tenant your business owns. Also check services introduced by former providers, past migration projects, trials, acquisitions, and offices that once managed their own technology. An old connection can be easy to overlook when everyone is working from the current vendor list.
2. Review and contain the relevant application's access
Verify that the affected connections are disabled in your own tenant and keep them disabled. ConnectWise is restoring service through a new application, so the old ones should not be re-enabled unless ConnectWise specifically instructs you to. Restoration is happening in phases, so one service coming back does not mean every connection is ready. Preserve the configuration and evidence; disabling an application is preferable to deleting it as the first response.
Microsoft documents how to disable an enterprise application's sign-in through its Properties page. This prevents new tokens from being issued for that application in your tenant. Have the response team also assess existing access tokens and resource permissions; changing one setting is not proof that all access has ended.
Record the change, the person responsible, and the conditions for restoring access. Treat application containment and backup continuity as parallel responsibilities, with a named owner for each.
3. Review application activity as well as user activity
Looking only for unusual employee logins can miss activity performed by an application. Microsoft's service principal sign-in logs record authentication by applications and services using their own credentials.
Ask the investigation team to preserve relevant sign-in and audit records and examine which resources were accessed. ConnectWise recommends reviewing activity from October 13, 2026 onward and extending back to October 1 where records are available. Microsoft gives similar guidance: review from at least October 15, extend service principal sign-in review back to October 1, and search by application ID rather than display name. Record the time zone used. Available evidence depends on your logging configuration and retention. A sign-in record can show authentication without proving which files were read, so the review may also need Microsoft 365 workload audit data.
The published indicators include:
| Published value | What it is |
|---|---|
144.172.64.128 |
IP address used for the password spray and application sign-ins |
144.172.64.99 |
IP address added by ConnectWise on October 18 |
144.172.64.60 |
IP address added by ConnectWise on October 18 |
144.172.94.243 |
Ongoing password spray against user accounts (Huntress, October 19) |
curl/7.88.1 |
User agent seen in the password spray (Huntress) |
Python-urllib/3.12 |
User agent seen in credential changes (Huntress) |
python-requests/2.31 |
User agent listed in the ConnectWise advisory |
If you searched your logs before October 19, search again for the newer addresses. According to Huntress, 144.172.64.128 is the only address that produced application sign-ins across the tenants it reviewed, while 144.172.94.243 is running a broad password spray against user accounts. Check user sign-ins as well as application sign-ins for every address on the list. Use these as investigation leads alongside application identity, timing, permissions, and resource activity. ConnectWise notes that scripting clients such as python-requests and curl can be legitimate, and that kiota-dotnet and private Azure IPv6 addresses are associated with expected vendor activity. ConnectWise also publishes a reference list of its own public IP addresses to help separate expected vendor traffic from suspicious activity. A match is not proof of compromise, and a clean result is not proof of safety. Include events from other source addresses and follow changes made to other identities.
4. Check for added credentials and privileged access
Have your response team inspect application registrations and enterprise applications for unexpected client secrets, certificates, and federated credentials added since October 13. Include management and security integrations. Compare each change with approved records, preserve the evidence, and remove confirmed unauthorized access through an authorized responder. If you use Azure Key Vault, review its logs for bulk secret reads by these applications and rotate any secrets they could reach; Microsoft saw the attacker read Key Vault secrets in affected tenants.
Look in the Entra audit logs for applications that added themselves to directory roles, such as Global Administrator or Exchange Administrator, or modified other applications. Also review application owners, consent grants, Conditional Access exclusions for these applications, and other security policy changes. For a structured investigation, use Microsoft's compromised application investigation playbook. Replacing a legitimate credential should never be treated as proof that every credential attached to that application is legitimate.
5. Review mailbox rules and other vendor permissions
Check for unexpected external forwarding, hidden inbox rules, transport rules, and new mailbox delegation. These can redirect messages or retain access after the original entry point is closed. Correlate findings with mailbox, SharePoint, OneDrive, and Teams activity where logs are available.
Use the review to identify other applications with broad access. For each connection, establish its purpose, business owner, approved permissions, and whether the service is still used. Microsoft provides instructions for reviewing and revoking enterprise application permissions.
This is particularly useful after changing IT providers. Access granted for a migration or support project should be reviewed when the work ends. Our MSP handoff checklist covers the broader transfer of accounts, tools, documentation, and responsibilities.
6. Plan for the recovery gap and verify protection after restoration
Record your last successful recovery point and identify important work created since then. Arrange suitable interim protection where possible. Make sure leadership understands how the interruption changes the amount of work the business could lose and its ability to recover during another incident.
Before reconnecting a contained service, confirm that the relevant remediation is complete and your response team approves restoring access. Then verify successful backup jobs and test a restore. A dashboard showing a connected account does not demonstrate that important data can be recovered.
Keep two questions separate: can the business recover its data, and could someone have accessed that data without authorization? A restore can help with loss or deletion. It cannot undo disclosure. Our business cloud backup guide explains the recovery side in more detail.
What business owners should expect from their IT provider
You should be able to get a clear account of the situation without interpreting sign-in logs yourself. Ask for a short written update covering:
- Whether the relevant integration exists in your environment.
- What access it holds and what containment has been applied.
- What evidence has been reviewed and what remains under investigation.
- Whether backup protection is interrupted and how that gap is being managed.
- Who owns the next steps and when you will receive another update.
Those answers make it possible to manage the business impact. They also prevent an incident from falling between the company that sells the backup service, the team that manages Microsoft 365, and the people responsible for security.
How Spot On Tech helps manage this risk
Our Single Point Of Tech™ approach to managed IT support brings day-to-day support, cloud accounts, vendors, and security coordination under one accountable team. When a vendor issue appears, the business needs someone who can connect the announcement to the systems it actually uses. For this incident, that meant confirming that none of the tenants we manage were exposed.
For businesses reviewing their exposure, the relevant services include:
- Cybersecurity services: Review cloud account protection, application permissions, vendor access, monitoring, and the response to suspicious activity.
- Cloud storage and data backup: Review protected workloads, backup access, retention, recovery expectations, and restore testing.
- Technology risk assessments: Identify overlooked integrations, unclear responsibilities, and gaps that need a prioritized fix.
- Compass™ internal IT consulting: Help internal teams establish vendor reviews, access procedures, documentation, and clear ownership of incident response.
For businesses across New York and New Jersey, that means a practical place to start: establish what is connected, decide what needs attention, and make sure the work has an owner.
Talk with Spot On Tech about reviewing your Microsoft 365 vendor access and backup protection.
Frequently asked questions
What happened in the ConnectWise SkyKick breach?
Attackers gained unauthorized access to Microsoft Entra application identities tied to ConnectWise Cloud Backup, formerly SkyKick. Huntress observed those identities signing in to Microsoft 365 tenants on October 15, 2026, and in at least two tenants an affected application granted itself Global Administrator. ConnectWise disabled seven application identities and suspended Cloud Backup on October 17, reset credentials in the affected environment on October 19, and began a phased restoration on October 21.
Who was behind the ConnectWise SkyKick breach?
Microsoft attributes it to Storm-0940, a China state-aligned group active since 2021, which used ARTEX AI agents to automate the attack. ConnectWise said on October 21, 2026 that a China state-aligned group appeared to be responsible. How the attackers first obtained the credentials is still under investigation.
What is Storm-0940?
Storm-0940 is Microsoft's name for a China state-aligned hacking group active since at least 2021. It is known for password spraying and for abusing trusted applications to keep access to Microsoft 365, and it used the ARTEX AI agent framework in the ConnectWise attack.
When will ConnectWise Cloud Backup be restored?
ConnectWise began restoring Microsoft 365 backups and restores on October 28, 2026, through a new application, ConnectWise Cloud Backup for M365. Partners must reset their password, set up MFA, and re-authorize each tenant with the new application. By October 30, backups, restores, the customer portal, and monitoring were back. Reporting, exports, and billing were in progress, with notifications last.
How do I reconnect ConnectWise Cloud Backup after the SkyKick breach?
Reset your ConnectWise Cloud Backup password, set up MFA, and re-authorize each Microsoft 365 tenant with the new ConnectWise Cloud Backup for M365 application. Then confirm that new backup snapshots complete for each tenant.
Should I re-enable the old ConnectWise applications?
No. ConnectWise says not to re-enable the previously disabled applications unless it specifically instructs you to. Service is restored through the new application instead.
Are Spot On Tech clients affected?
No. We do not use ConnectWise Cloud Backup or Cloud Management for the businesses we support, and we checked every tenant we manage for the seven affected application IDs.
Should we check even if we no longer use SkyKick?
Yes. Ask your administrator to verify whether any related enterprise applications or permissions remain from earlier services. Ending a commercial relationship and removing technical access are separate tasks.
Does changing employee passwords remove a cloud application's access?
An application using its own credential has a separate identity. The response must address that application's access and permissions. Employee password changes may still be needed if the investigation also finds affected user accounts.
Does disabling the ConnectWise applications finish the response?
No. Investigate credentials, roles, permissions, and mailbox settings changed during the incident. Separate access added to another identity requires its own remediation.
How should we manage the backup interruption?
Document the last successful recovery point, identify work outside that protection, and agree on interim measures. After approved service restoration, verify successful jobs and test recovery.
Can Spot On Tech work with our existing internal IT team?
Yes. We provide managed and co-managed support, and Compass can help your team improve processes, documentation, vendor ownership, and operational readiness.
