The sign-in looked like Tuesday. A Microsoft 365 audit row for ConnectWise Cloud Backup, the MSP product formerly called SkyKick, showed a successful login into a customer tenant. Backup software is supposed to live there. Researchers then reported that the same compromised vendor credential had signed into 173 Microsoft 365 tenants. Treat that as a master key walking through your cybersecurity perimeter with a valid ticket.

ConnectWise Cloud Backup sells cloud restore to managed service providers. The pitch is resilience: mailboxes and files you can get back after a bad week. To do that job, the product has to sit inside customer directories with enough privilege to read, copy, and write the estate you care about. Somebody got the vendor’s Microsoft 365 credential and used it the way the integration is designed to be used. Unknown actors did not need a clever exploit chain. They needed a login customers had already blessed, then they reused it at scale.

The Session Looked Like a Scheduled Job

You already trained analysts to panic at impossible travel and password spray. This campaign will not wave those flags. A backup vendor signing into Microsoft 365 is expected traffic in shops that outsourced restore years ago. Mailbox reads, item enumeration, and app activity can hide under the same labels your SOC uses for “the restore tool is running.” If your hunting still starts with brute-force noise against the firewall, you’ll file the whole thing under operations and go back to the ticket queue.

That is the ugly geometry of MSP cyber security. Your tenant trusts a company the board never interviewed. The MSP trusts a backup SaaS platform. The platform holds an identity with a long reach. One stolen secret turns that chain into a hallway. 173 tenants is not a spray-and-pray statistic. It is evidence the same key fit a lot of doors because the architecture invited a shared trust model and then hoped the vendor would guard the key better than you guard Global Admin.

ConnectWise’s direct customers are MSPs, and MSP customers are everyone else: law firms, clinics, manufacturers, school districts, shops that outsourced Microsoft 365 because they could not hire a full-time admin. Those shops did not think they were sharing a password with 172 strangers. They clicked consent for a vendor app. From an attacker’s chair, consent and a shared secret are the same object. The restore account held the keys, and the keys opened more than backups.

Your Cybersecurity Stack Never Got a Vote

Defense in depth still belongs in the program. It does not get a vote when the packet is an authenticated Graph call from a partner application you allowlisted during onboarding. Your edge firewall never saw a fight. Threat-protection products that score malware attachments and fake login pages had nothing sticky to detonate. Threat detection that waits for a failed logon storm will sleep through a success. This is identity abuse dressed as a partner integration, and partner integrations are where a lot of teams go quiet on purpose so the business can keep running.

Security hardening conversations this week will want a CVE and a patch window. You will not get one from this incident. Incident response for a vendor credential starts with a different question than a workstation implant: what could that identity do, in which tenants, for how long, and what did it create that still holds a refresh token? If your playbook opens with imaging a laptop, you’re already late. The evidence lives in Entra sign-in logs, directory audit events, mailbox rules, OAuth grants, and the vendor’s own control plane. Cheap Microsoft 365 SKUs throw some of that history away. Confirm you still have it before you promise leadership a timeline.

This is a bad look for backup platforms that market themselves as the last clean copy after ransomware, then hold directory-wide reach with a secret that can be copied. Buying another dashboard will not invent the inventory you skipped. Plenty of those 173 directories already had tools. The gap is cultural. Non-human identities get treated like plumbing. Plumbing does not get Conditional Access, named locations, phishing-resistant MFA, or an owner who is paged when the certificate ages out. Human users get the policy. The backup app gets a hall pass because restore failed once in 2019 and nobody wanted that call again.

Pull the Vendor Keys Before You Write the Report

Start tonight in the directory, not on the vendor’s status page. In every Microsoft 365 tenant you own or manage, list enterprise applications and service principals tied to backup, restore, and “cloud backup” products, including names that still say SkyKick in the guts. Record the permissions in writing. Broad Exchange roles or Global Admin on a backup app is a standing incident, even if the secret has been quiet this month. Revoke active sessions for that identity, rotate client secrets and certificates, and force a fresh consent you can explain to an auditor without hand-waving.

Hunt while you rotate. Look for inbox rules you did not write, forwarding you did not approve, application consents from this quarter that have no ticket, added mailbox permissions, and sign-ins from places backup jobs do not live. If the vendor can impersonate users, treat every mailbox the app could reach as in-scope until you prove otherwise. Tell the MSP to produce a tenant list, a permission matrix, and a timestamped account of their own credential rotation. If they cannot name the 173, assume you might be number 174 and keep hunting. Do the same for every other restore, archiving, and “we sit in your tenant” add-on. This class of failure is not unique to one logo.

Then change how the next vendor lands. Backup and monitoring products should get the least directory role that still restores data, Conditional Access that pins them to known infrastructure, and alerts on interactive sign-in when the design is supposed to be unattended. Put vendor apps on the same review cadence as domain admins. Defense in depth, in this case, means the restore tool cannot also reset Conditional Access, add owners, or mint new applications. If a product cannot operate inside that box, it is too privileged for your tenant. Ongoing work is dull, and it is the job: quarterly access reviews for every non-human identity, a kill switch you have tested by disabling the enterprise app without waiting for a blog post, and a written map of which credential is “handling Microsoft 365 for you.” That map is the perimeter you actually have.

You’ll be tempted to wait for ConnectWise to finish the narrative. Finish yours first. The actors already had a working login. Working logins do not wait for your change window.

Sources

• Hackers Use Compromised ConnectWise Credential to Sign In to 173 Microsoft 365 Tenants