When Your Backup Vendor's Keys Get Stolen: The Microsoft 365 Supply-Chain Attack Every Small Business Should Understand

A backup tool needs access to the data it protects. That access can include mailboxes, OneDrive, SharePoint, Teams and directory information. On October 15, 2026, attackers used a compromised ConnectWise Cloud Backup credential to sign in to customer Microsoft 365 environments, turning a vendor’s stolen key into a potential risk for every tenant where the application was installed.
This was not a ransomware incident. It was an identity and supply-chain incident: attackers used a trusted application’s existing access, and in some cases attempted to create additional ways to stay in a tenant. Small businesses should understand what happened, what protections did, and did not, apply, and what to ask their IT provider to check.
What happened, in plain English
ConnectWise Cloud Backup, formerly SkyKick, uses an application identity to connect to customer Microsoft 365 tenants. The application has permissions needed to back up and restore customer data. According to Huntress’s incident analysis, attackers obtained a vendor API credential, a client assertion held in the vendor’s own environment, and used it to authenticate as the application.
On October 15, the application signed in to customer tenants from the hosting-provider IP address 144.172.64.128 and received Microsoft Graph access tokens. Those tokens carried the application’s existing permissions. The sign-ins were not ordinary employee logins: they were made by software using an application identity.
Huntress confirmed unauthorized sign-ins in 162 tenants as of October 16. It also identified activity from the attacker’s IP address in nearly 1,000 Entra tenants, with more than 300 successful sign-ins. A successful sign-in is a serious signal to investigate, but does not by itself prove that data was copied.
Investigators also found concerning follow-on activity in two tenants they examined. A ConnectWise Cloud Management application assigned itself Global Administrator and added new client secrets to other applications. Some of those credentials were set to remain valid until 2028. That matters because access planted in a separate application could outlast the original vendor credential.
ConnectWise disabled the affected application identities on October 17 and completed an account and credential reset in the affected Cloud Backup environment. As of its October 21 advisory, the related services remained suspended while security validation and restoration preparations continued. ConnectWise said existing backup archives remained encrypted, isolated and preserved, with no indication they had been compromised. That is separate from whether a customer’s live Microsoft 365 tenant experienced unauthorized access: each tenant still needs its own review. See the ConnectWise Trust Center for current status and guidance.

Why MFA did not stop this
MFA remains an important safeguard for people signing in to business accounts. But this attack used app-only authentication: an application proved its identity with a credential, then requested a token. No employee was signing in, so there was no user to challenge with an MFA prompt.
That distinction is easy to miss. A business can require MFA for every employee and still have third-party applications with their own credentials and permissions. Those workload identities need their own controls, monitoring and review. User-focused protections do not automatically protect every application connected to Microsoft 365.
What small business owners should do this week
You do not need to investigate Microsoft logs alone. Ask your IT provider to explain what they have checked and what they found. If your business or provider used ConnectWise Cloud Backup or SkyKick, ask them to follow current vendor guidance and review the affected tenant, not just the backup vendor’s environment.
Use these four steps to make the conversation concrete:
1. Identify: What applications have access?
Ask:
- Do we use, or have we previously used, ConnectWise Cloud Backup, SkyKick or related ConnectWise Cloud Management apps?
- What third-party enterprise applications are consented into our Microsoft 365 tenant?
- Which applications have administrator roles or broad permissions?
- Are any old or unused integrations still enabled?
For the Cloud Backup service, the application ID is 506e08f9-6e9a-4da4-942b-a099a03644ae. Ask your provider to check the tenant’s actual application identity and status, rather than relying only on a display name. Vendor-side action and the application’s status in your own tenant are not necessarily the same thing. If a relevant app needs to be disabled, follow vendor and security guidance; do not delete it as a first step, since that can remove configuration needed for investigation or restoration.
2. Quantify: What could each app access?
Ask your provider to translate application permissions into business terms. Could an app read email, files, Teams content or directory information? Could it also change data, assign roles or manage other applications?
The point is not to assume every connected app has unlimited access. It is to know what each app can do if its credential is misused, and whether those permissions are broader than the service needs.
3. Mitigate: What was checked and contained?
Ask your provider directly:
- Has the Cloud Backup or related application been disabled in our tenant where appropriate?
- Have credentials on all enterprise applications and app registrations been reviewed for anything added since October 13 that was not authorized?
- Have Entra service-principal sign-in logs been reviewed for the affected applications and the suspicious IP
144.172.64.128? - Were any applications assigned Global Administrator or other unexpected roles?
- Have application credentials, permissions, owners and consent grants been reviewed for suspicious changes?
- Are Global Administrator and application-credential management roles limited to the people who genuinely need them?
A service-principal sign-in is recorded in a different category from a typical employee sign-in. The review should include Entra’s Service principal sign-ins, not just the default user sign-in logs. A matching IP or a successful sign-in warrants investigation; neither alone proves data theft.

4. Monitor: How will the review continue?
Ask how your provider will monitor service-principal sign-ins, role assignments and application credential changes going forward. Confirm who receives alerts, who investigates them and how often the application inventory is reviewed. Where possible, limit who can add credentials to applications and avoid leaving unused or excessive permissions in place.
Treat “we found no evidence of theft” carefully. Some application activity, particularly Microsoft Graph directory reads, may not leave a corresponding audit trail. The absence of a visible record is not proof that no data was accessed. Your provider should document the log coverage, what was reviewed and what remains uncertain.
The bigger lesson: trusted access is still access
Backups, security platforms and IT management tools are valuable precisely because they can reach important systems. That makes them part of your business’s attack surface. A vendor you do not interact with directly can still have an application inside your Microsoft 365 tenant, and a problem in that vendor’s environment can become a risk to yours.
This does not mean businesses should avoid third-party services. It means vendor trust needs to be supported by practical controls: know what is connected, understand what it can access, limit unnecessary privileges, review credentials and monitor application activity. Those are ongoing responsibilities, not a one-time setup task.
For a practical starting point, use B&R’s Backup & Disaster Recovery Readiness Checklist to assess backup and recovery planning, and explore the B&R Computers resource hub for additional business-focused guidance.
If you need help understanding your Microsoft 365 integrations, assessing exposure or prioritizing next steps, request a Business Review or Strategy Session. A focused review can help clarify what has access to your data, and what to address first.