Attackers Used ConnectWise Cloud Backup's App Identity to Sign Into Microsoft 365 Tenants

ConnectWise shut down its Cloud Backup service on 17 October 2026 after an attacker used the product's own application identity to sign into customer Microsoft 365 tenants and obtain Microsoft Graph tokens. No user password was involved, and no multi-factor prompt appeared. Huntress reported the activity first; SpecterOps and BleepingComputer published accounts of it on 17 October.

Related reading: Attackers Pushed a Backdoor Through AOMEI Backupper's Own Update Servers · Hacktron's HEIF Heist: An Unpatched Image Library Opened the Door to OpenAI's Monorepo.

The sign-ins ran from 06:13 to 08:34 UTC on 15 October, all from 144.172.64.128, an address at a hosting provider. They moved between tenants a few seconds apart, a pattern SpecterOps describes as consistent with a script working from a target list. On 13 and 14 October the same address had attempted scripted sign-ins with client application IDs belonging to other tools, using the user agent curl/7.88.1. Huntress and BleepingComputer both recorded that earlier probing. The Cloud Backup identity was not the first one tried. Two days of attempts against other applications make the successful window look like the end of a search rather than a lucky guess.

Huntress confirmed unauthorised sign-ins in at least 162 tenants by the time BleepingComputer published. SpecterOps uses the same figure. A later weekly roundup put the count at 173, which suggests it was still rising as the first reports went out. Treat either number as a floor.

The application did the work of a password

A service principal is how software signs in to Microsoft Entra ID. An administrator grants it permissions once, and from then on it presents a secret or a certificate. There is no human at the keyboard to challenge, so MFA has nothing to act on. That is not a flaw in MFA. It is a different authentication path, and it was the path used here.

Cloud Backup holds one of these identities in each customer tenant, with rights wide enough to do its job: read mailboxes, OneDrive and SharePoint files, and Teams chats, then copy them somewhere else. Todyl, whose analysis BleepingComputer cites, said the pre-consented app could read and write mail and attachments, files and chat messages. A stolen token inherited all of it.

The customer's side of that arrangement is a consent screen. An administrator approves the app once, and the credential that proves the app's identity stays with the vendor. The tenant gets a working backup service and gives up direct control of the key.

The permissions were broad by design. How much of that reach the attacker used is a separate question. Microsoft confirmed the malicious authentication attempts from that address on 15 October and described the incident as an active supply-chain attack. Its threat intelligence team assessed that the attacker likely abused existing permissions, including Directory.ReadWrite.All, and saw Graph API reconnaissance and attempts to add credentials.

What Huntress found inside the tenants

Huntress looked past the login records. It reported that ConnectWise Cloud Management service principals covering Exchange Online, Teams and Microsoft Graph assigned themselves directory roles in nearly 50 of the tenants it monitors. Most of those roles were Exchange Administrator.

In one tenant the attacker reached persistence in about five minutes. The Cloud Management – MS Teams app granted itself Global Administrator, then added credentials to an MSP management tool and to Huntress's own application. Adding a credential to an existing app gives an intruder a way back that survives a password reset, a session revocation or the expiry of the token that opened the door.

Todyl's sample looks different. It examined nine intrusions and found sign-in activity only, with no evidence that the actor created accounts, changed passwords, added permissions or established persistence through the backup app in those nine. Both accounts can hold. The severity varied by tenant, and so did what the intruder did once inside.

Seven identities, one switch

ConnectWise announced the service interruption at 05:01 UTC on 17 October. Its advisory said the company had identified “unauthorized access to application identities within the ConnectWise Cloud Backup environment” and had cut off application access for partners and clients. The Hacker News reported on 18 October that the suspension had taken the backup product out of service while the company investigated.

The same day it disabled seven application identities:

• Cloud Backup: 506e08f9-6e9a-4da4-942b-a099a03644ae
• 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

Those IDs are the practical part of the story for anyone reviewing logs. A service principal sign-in naming one of them, from an address the tenant does not recognise, is the event to search for. One identity on the list covers Partner Center, the portal Microsoft partners use to manage customer accounts, so the response reached past the backup product itself.

ConnectWise said it had “no indicators to date that Cloud Backup partner backup data has been compromised”. Existing archives are encrypted and isolated, it said, and would be reachable once the service was restored. An update at 01:00 UTC on 18 October said Cloud Backup was still down, scheduled backups were not running, and archives and restore capability were unavailable. SaaS Security and Cloud Management were offline as a precaution. ConnectWise added that the shutdown should not be read as evidence that a partner or customer environment had been compromised.

What revoking an app does not fix

Disabling an app identity stops new tokens from being issued. It does not cancel tokens already in someone's hands. ConnectWise said that previously issued access tokens may remain usable until they expire or are invalidated, and that credentials, permissions or access established through separate identities need their own review. Todyl made the same point: revoking user sessions does not end application-based access.

Microsoft's recommended checks include service principal sign-in logs filtered to the Cloud Backup app ID and to unexpected source addresses, then to application credential changes, OAuth grants and related Graph activity. That guidance points at a reporting gap: the familiar user sign-in view does not show this traffic, because no user signed in.

Huntress advises disabling the implicated ConnectWise apps and reviewing Cloud Management integrations. Tenants that have used the product since before the rebrand may still list it as “SkyKick Cloud Manager”, an old name in a consent screen that hides a current risk.

Managed service providers use Cloud Backup, formerly SkyKick Cloud Backup, to protect customers' mailboxes, OneDrive, SharePoint and Teams. That is the product working as intended, and it is why one intrusion reached so many organisations. One vendor identity, held in many tenants, gives whoever steals it a key that fits every door at once. An MSP does not need to be careless to be exposed; being a customer of the tool is enough.

The same logic applies to every integration an MSP installs. Backup, documentation, PSA and remote monitoring tools commonly ask for broad, long-lived access. Each one is a service principal with a credential somewhere. Few organisations can list them from memory, and fewer alert on their sign-ins.

Someone has to list the service principals in each tenant, name an owner for each, and put their sign-ins in front of a person who will notice an unusual address. An application identity is a privileged account, so it should be reviewed like one.

Caveats

The counts are not settled. Huntress confirmed at least 162 tenants; the 173 figure comes from one later roundup. Both are floors built from what the researchers could see, and neither is a final tally. The extent of any data theft is unknown.

No attacker has been publicly named. The initial access method is unknown, and ConnectWise has not said how the vendor credential was obtained. Speculation about either is guesswork at this stage.

ConnectWise's statement that it has no indicators of backup data compromise is the company's own, issued while its investigation continues. No outside party has confirmed it.

“unauthorized access to application identities within the ConnectWise Cloud Backup environment” — ConnectWise, trust advisory, 17 October 2026

What to watch

The restoration timeline is the first open item. ConnectWise has not given one, and until it does, partners are running without scheduled backups and without restore access. That is a business risk separate from the intrusion, and it grows with every day the service stays down.

The second is disclosure. Microsoft has confirmed the authentication attempts but not a tenant count of its own. ConnectWise has confirmed the disabled identities and not the path that led to them. Either company could fill in the sequence, and neither has.

The third is what partners find when they look. Tokens issued before the shutdown expire on their own schedule, and credentials added to other applications will not appear in a ConnectWise advisory. The organisations that answer this well will be the ones that already had an inventory of their service principals. The rest will be building one now.

Cover image: Microsoft data centre in Middenmeer, the Netherlands, by Hay Kranen, CC BY 4.0, via Wikimedia Commons. The photo shows Microsoft cloud infrastructure, not a ConnectWise facility.