Sometime between October 13th and October 17th this year (2026), a malicious threat actor used stolen application credentials for ConnectWise Cloud Backup – a Microsoft 365 backup service, formerly known as SkyKick – to sign in to customers’ tenants.
ConnectWise has now disabled logins to the application, which will prevent any new sign-ins from the threat actor, however, it is important users understand that this should not be read as if the incident is over for businesses that had the affected service principals in their tenant.
In their advisory, ConnectWise also states: “Disabling the affected connections prevents new authentication through those connections; it does not reverse changes previously made inside a tenant.”
The second part of this sentence is what I will look at here.
Over the past month, our series on non-human identities has covered:
- Understanding Applications and Non-Human Identities in Microsoft Entra
- How Enterprise Applications Authenticate in Entra ID
- App Registration Permissions: Delegated vs Application
This incident highlights the importance of understanding all of these areas.
In this article, I’ll summarize what happened, why the danger is not over yet, and my thoughts on what this should mean for tenant security going forward.
What happened with the ConnectWise Cloud Backup hack
ConnectWise Cloud Backup is a product used by MSPs (managed service providers) to back up their customers’ Microsoft 365 data. To do this, ConnectWise has an App Registration in their own tenant, which is, when consented, used to create a service principal in the MSPs’ customers’ tenants. This service principal holds a broad set of application permissions, including – according to Microsoft – Directory.ReadWrite.All.
Multiple companies have given their insights into the timeline, and I’ll summarize the important parts here. For a more thorough walkthrough, I suggest reading the Huntress analysis of the attack.
October 14th, 2026: Compromised Application credentials are used to obtain Microsoft Graph tokens in some victims’ tenants.
October 15th, 2026 – From around 01:58: Service Principals for the ConnectWise Cloud Management apps assign themselves Entra ID Directory roles in some victims’ tenants. These were mostly Exchange Administrator, but Huntress discovered one instance where Global Administrator was assigned. This instance also saw modification of two other existing service principals, where client secrets were added for persistence.
October 15th, 2026 – From around 06:13: Compromised application starts signing-in to victims’ Microsoft 365 tenants. This happens from a specific IPv4 address: 144.172.64[.]128.
October 16th, 2026 – 17:47: ConnectWise releases its advisory, confirming that they are investigating.
October 17th, 2026 – Around 07:00: ConnectWise disables seven App Registrations in total, making the threat actors unable to obtain new tokens.
October 18th, 2026 – 18:45: ConnectWise informs about two additional IPv4 addresses used for malicious activity: 144.172.64[.]60 and 144.172.64[.]99.
Note: This timeline is based on multiple sources, all times are in UTC.
These are the seven identities ConnectWise disabled. In older tenants the Cloud Management apps may show up as "SkyKick Cloud Manager".
Huntress has stated that they have seen successful sign-in activity from the attacker’s IPv4 address in more than 300 of their customers’ tenants.
Why disabling of the compromised ConnectWise Cloud Management applications is not enough
The analyses released by different sources more or less all focus on how you can detect if you have been compromised. This is of course an important step, but they often fail to specify the complexity involved of remediating the issues if there are indications of successful sign-in from the threat actor.
That ConnectWise disabled the ability to log in as the applications – or if you did this manually in your own tenant before ConnectWise did it centrally – does not affect any potential actions taken by the threat actor while they were in your tenant.
So, what are the longer-term implications of breaches such as this one?
As stated, it is important to stop the incident, but the next step is to get a clear overview of all the actions taken by the threat actor while they had access. These could include, but are not limited to:
- Added credentials to other applications. A secret or certificate added to another app with either directory roles or Microsoft Graph permissions that can be used to establish persistence once the initial attack vector is mitigated.
- Creating new applications and consent grants. An attacker could, with sufficient permissions, create new app registrations and service principals.
- Mailbox changes. Forwarding roles, mailbox permission, etc. could have been modified.
- Assigned Entra ID directory roles. Users could have been created. Directory roles could have been assigned to new users or old existing users who could have had new authentication methods assigned.
- Configuration changes. All different kinds of configuration changes across SharePoint, Exchange, Defender, Entra ID, and even Intune could have been changed. Exclusions could have been made to Conditional Access Policies allowing deployment of scripts or applications to your endpoints.
If you see any indications of successful sign-ins to your tenant(s) from the compromised applications, you need to review all configuration changes done in the period, to ensure that these are not initiated by the attacker.
What is the purpose of the ConnectWise Cloud Backup attack
There are, at the time this article was published, no clear reports of the purpose of this attack. Was it shut down because the security community was vigilant and managed to thwart it, before the threat actors managed to weaponize their access? Did the threat actors only perform further actions in a small subset of victims? Or was it something else?
The fact that Huntress reported an instance of the threat actors actively trying to establish persistence by creating credentials for other service principals, is at least a clear indicator that they had further intentions with this attack.
Another factor to consider is that the compromised software is an MSP management tool. It is likely that MSPs could have been affected by this attack, and any potential persistence gained here could be leveraged in a second wave of attacks.
This is speculation, but everyone working within the security space knows that you need to be right every time, while the threat actors need to be right just once.
On this basis, CoreView Intelligence Labs recommends that if there are any indicators of a successful sign-in from the threat-actor, the incident should be treated as a configuration-change incident. This means clearly mapping and rolling back any non-confirmable changes performed between 1st October, 2026, and 17th October, 2026, 07:00.
Summary: The front door may be closed; but you are responsible for the back door
From a security perspective, as the vendor, ConnectWise has done what they can do to technically respond to the breach. They have revoked credentials and disabled their applications until their investigation is complete. This prevents the threat actor from continuing the attack. The front door is closed.
However, this still leaves every affected organization and MSP with questions:
- Do any of our tenants have any of the mentioned applications? It does not matter if you are an active customer or not.
- Did any of those service principals assign themselves directory roles?
- Did any other service principals have credentials added; that wasn’t part of standard operations?
- Were any other configurations changed; that wasn’t part of standard operations?
- What did any of those changes to configuration, users, or policies affect?
- Do we have the logs and capabilities to do this?
There are currently no reports of customers’ backups being affected by the breach, and likely most tenants will come back with clean checks. But for those who don’t, a lot of hours will need to be spent on answering the questions above and hopefully being successful in removing the threat actor from the tenants.
