The ConnectWise Backup Breach Needed No Customer Password
A backup app’s own credential, held in the vendor’s tenant, was used to get tokens in customer Microsoft 365 tenants. I ran the vendor through my own supplier check this morning. It passed, which shows what a supplier check can’t see.
The FAQ on my vendor checker answers a question most people would rather hear yes to: “Does a clean result mean it is safe to pay?” The answer is no. The checks cannot see the most common invoice fraud, where a real supplier’s mailbox is taken over and only the bank details on the invoice change.
In the guide that goes with it, I wrote that the attacker usually gets into that mailbox “with a password from an unrelated breach, or a phishing page that collected it weeks earlier.” That was true when I wrote it and it is still the common case. Last week showed a route that needed neither, and it came through a supplier.
What happened
ConnectWise Cloud Backup, which used to be called SkyKick, backs up Microsoft 365 and Google Workspace data for managed service providers and their clients. To do that, Huntress explains, the app is granted broad access to mailboxes, OneDrive, SharePoint, Teams and directory data in every tenant it is installed in.
On 15 October, according to Huntress’s write-up, the app’s identity signed in to customer tenants from a hosting-provider address between 06:13 and 08:34 UTC and received Microsoft Graph access tokens. Normal traffic from the app comes from Microsoft’s own cloud network. The sign-ins moved through tenants in sorted order a few seconds apart, which Huntress reads as a script working from a target list. By 19:00 UTC on 16 October Huntress had confirmed unauthorized sign-ins in 162 tenants. In a later update it reported sign-in activity from the same address in almost 1,000 Entra tenants, more than 300 of them successful.
Huntress is specific about the credential itself:
“The credential type was a client assertion, which means the credential lives in the vendor’s own tenant. Nothing a customer did in their environment could have produced it.”
No customer password was phished. There was no MFA prompt to get past either: in Huntress’s words, app-only sign-ins involve “no user, no device, and no MFA prompt.” The customer’s part in this was a decision made earlier: they, or their IT provider, consented to a backup app, and the app needed wide access to do its job.
It got worse in one tenant. Huntress saw a second ConnectWise app, the Cloud Management app for Microsoft Teams, add itself to the Global Administrator role at 03:44 UTC on 15 October and then put new client secrets on two other applications, one of them Huntress’s own. Those secrets were set to expire in 2028. Huntress’s 19 October update found a second tenant with the same pattern. It also says plainly that it has not tied that earlier activity to the same operator as the 06:13 sign-ins.
What the vendor says it cannot see
ConnectWise’s advisory on its Trust Center is unusually direct about the limits of its own response. It disabled seven application identities at 07:00 UTC on 17 October. Then come three sentences that matter to anyone who has approved a vendor app:
- Disabling the connections “does not reverse changes previously made inside a tenant.”
- “Previously issued access tokens may remain usable until they expire or are otherwise invalidated.”
- “Cloud Backup does not provide the downstream security visibility needed for us to determine independently whether a particular partner or customer tenant experienced unauthorized activity.”
Put those together and the vendor that held the key is telling each customer to go and look for themselves. Huntress adds the reason why looking may not settle it: directory reads through Microsoft Graph leave no audit trail, so for the tenant it examined most closely, “tokens issued, nothing visible taken” is the current state. That is not the same as nothing taken.
Get Josepollman’s stories in your inbox
Join Medium for free to get updates from this writer.
As of the advisory’s 21 October 00:30 UTC update, Cloud Backup, SaaS Security and Cloud Management are still suspended, and ConnectWise says it is still working out how the unauthorized access first occurred.
I ran the vendor through my own tool
VetThisVendor runs five checks on a supplier: VAT registration, IBAN checksum, sanctions screening, the company register and the sending email domain. I only entered the domain, so the other four checks show as not run.
connectwise.com passed. SPF present, DMARC at quarantine, mail servers present, domain registered more than ten years ago. The green box says forged mail claiming to come from it is likely to be rejected or quarantined, which is a fair reading of its records.
None of that is wrong, and none of it is relevant to what happened. Every check I built answers a question about identity: is this business real, is this registration real, can someone pretend to be them by email. Not one of them asks what a supplier can already do inside your systems. A supplier with a perfect domain, a clean register entry and a long history can still hold standing access to every mailbox you have, through an app you approved once and forgot about.
I knew that in the abstract. The FAQ answer is there because I knew it. What this case added was a concrete version where the supplier itself was never the fraudster, the supplier’s own email was never forged, and nothing the customer did produced the credential that was used.
Why someone who pays invoices should care
This is where it touches my own subject. ConnectWise’s remediation guide tells every affected tenant to search the audit log for inbox rule changes, mailbox permission changes and transport rules, and to investigate “unexpected external forwarding, rules that hide or delete messages, new Full Access or Send As rights.”
That list is the toolkit of bank-detail fraud. My guide describes the same moves from the other side: an attacker inside a mailbox reads the thread, waits for a real invoice, and sometimes sets a rule so the customer’s replies never reach the real person.
Huntress says that in the two tenants it reviewed it found no sign of mailbox or file manipulation. Neither source reports any invoice fraud from this incident. The point is what the access allows, not what anyone has shown was done with it. A backup app has to read and write mail to back it up and restore it. Whoever holds its credential holds that too.
What I would actually do with this
If you approve vendor apps in Microsoft 365, or your IT provider does it for you:
- Open Enterprise applications in the Entra admin center and look at what has been consented. Huntress asks for management and security tools to be reviewed first, and a backup app has broad access by design.
- For each of those, find the service principal sign-ins. Huntress points out that they are on a separate tab from user sign-ins, so the default view will not show them.
- Ask the vendor three questions: what credential the app uses and where it lives, how fast they can revoke it, and whether they can see activity in your tenant if it is misused. ConnectWise’s own answer to the last one was no.
- Know which controls help and which don’t. ConnectWise’s guide notes that Conditional Access for workload identities covers single-tenant service principals registered in your tenant, not third-party multitenant apps like this one. Huntress lists other Entra controls that limit the damage: application management policies that restrict client secrets and cap their lifetime, and fewer people holding the roles that can add credentials to apps.
And if you pay suppliers, the old rule survives this intact. A bank-detail change gets a phone call to a number you already had, whatever the email looks like and however it got there. No check of the vendor from the outside will tell you who is sitting in the mailbox.
I build tools that check suppliers before you pay them, at vetthisvendor.com. The check describes the supplier on the day you run it. It says nothing about the keys you have already handed them.
Sources: Huntress, “ConnectWise (SkyKick) Vendor Credentials Abused in M365 Attacks” (published 16 October 2026, updated to 19 October), and ConnectWise Trust Center advisory “Cloud Backup (formerly known as SkyKick) Service Interruption” (first published 16 October 2026, read at its 21 October 00:30 UTC update).
