The Backup App That Didn't Need a Password

On October 15, 2026, a Python script logged into hundreds of companies' Microsoft 365 environments. Nobody typed a password and nobody approved an MFA prompt. In one of those companies, the script made itself Global Administrator in about five minutes.

The script logged in as a backup app that those companies had trusted for years.

TL;DR

• What happened: Attackers abused a stolen credential belonging to ConnectWise Cloud Backup (formerly SkyKick Cloud Backup), a Microsoft 365 backup service sold widely through MSPs. They used it to sign into customer Microsoft 365 tenants as the app itself.
• How big: Huntress confirmed unauthorized sign-ins in 162 tenants by October 16, and reports put it at 173 on October 17. By Huntress's update that evening, nearly 1,000 tenants showed sign-ins from the attacker's IP address, with more than 300 successful.
• Why MFA didn't help: The attacker signed in as an application, not a person. App sign-ins never trigger MFA, and the app already held broad permissions that customers had granted.
• What to do now: Disable (don't delete) every ConnectWise and SkyKick app in your Entra ID tenant. Remove any directory roles you didn't grant, and look for client secrets or certificates added to any app since October 13.

What happened in the ConnectWise Cloud Backup breach?

An attacker obtained a credential that let them authenticate to Microsoft 365 as ConnectWise's own Cloud Backup application, then used it to get into customer tenants. Huntress describes the credential as a client assertion stored in ConnectWise's own tenant. The security firm Todyl describes it as a client secret. Either way, Huntress was blunt about blame: "Nothing a customer did in their environment could have produced it."

The rough timeline, from Huntress and BleepingComputer reporting:

• October 13–14: A password spray hit four law-firm tenants from IP 144.172.64[.]128. Huntress saw no successful user logins.
• October 15, from 01:58 UTC: In about 50 Huntress-monitored tenants, ConnectWise "Cloud Management" apps assigned themselves directory roles, mostly Exchange Administrator. In one tenant, the MS Teams app made itself Global Administrator, and a Python script planted new client secrets, set to expire in 2028, on an MSP management app and on Huntress's own security app.
• October 17: ConnectWise disabled seven application identities and took Cloud Backup offline. As of October 18, backups and restores are unavailable.

ConnectWise says it has "no indicators to date that Cloud Backup partner backup data has been compromised." Huntress hasn't confirmed data theft either, but it warns that directory reads through Microsoft Graph leave no audit trail. A clean log doesn't prove nothing was read.

Why didn't MFA stop the attack?

MFA protects people, and the attacker never logged in as a person. When you connect a backup tool to Microsoft 365, you give it its own identity, called a service principal. That identity gets standing permission to read mailboxes, OneDrive, SharePoint and Teams so it can back them up. It logs in with a key, not a password, and nobody gets a phone prompt.

Think of it like a building's cleaning crew. You'd never let a stranger walk in without a badge, but the cleaners have a master key and come in at 3 a.m. by design. If someone copies that key at the cleaning company's head office, your alarm system has no idea anything is wrong.

Microsoft assessed that the attacker likely abused permissions the app already held, including Directory.ReadWrite.All. That one permission is how an app could make itself an administrator.

Am I affected by the ConnectWise SkyKick compromise?

You're potentially affected if your Microsoft 365 tenant ever consented to ConnectWise Cloud Backup, SkyKick Cloud Backup, or any ConnectWise Cloud Management app, even years ago. One admin on Reddit got a Microsoft PIM alert on October 15 that a SkyKick service principal had assigned itself Exchange Administrator. They hadn't used the product in years.

Here's how to check:

1. In Microsoft Entra admin center → Enterprise applications, search for "ConnectWise" and "SkyKick." Older tenants may list them as "SkyKick Cloud Manager."
2. Go to Monitoring → Sign-in logs → Service principal sign-ins and filter on the Cloud Backup application ID 506e08f9-6e9a-4da4-942b-a099a03644ae. Look for source IPs outside Microsoft and Azure ranges, especially 144.172.64[.]128.
3. Huntress recommends auditing service principal sign-ins from about 01:00 UTC October 15 to 02:00 UTC October 16. Some access came from private Azure IPv6 space, not just the known IP.
4. Check the Entra audit logs for ConnectWise or SkyKick apps assigning roles or modifying other apps. Huntress's post lists all seven app IDs to search for.

How do I fix it and lock it down?

Disable every ConnectWise and SkyKick app in your tenant now, even if you see nothing unusual, and then hunt for anything the attacker may have left behind. Huntress's guidance boils down to this:

• Disable, don't delete. Deleting an app removes its consent, which makes restoring the service harder. Disabling it stops new tokens. Todyl warns that tokens already issued stay valid until they expire, and revoking user sessions does nothing to app access.
• Strip unexpected roles, especially Exchange Administrator and Global Administrator.
• Hunt for planted keys. Review client secrets and certificates on all app registrations, especially management and security tools, for anything added since October 13. Those 2028-expiry secrets are the backdoor that survives after ConnectWise is switched off.
• Don't re-enable anything until ConnectWise confirms all credentials have been reset.
• Shrink the blast radius for next time. Cap or restrict client secrets with application management policies, and limit who holds Application Administrator.

Why are MSP vendor tools such a big target?

One vendor credential sits upstream of hundreds of client environments, so attackers get hundreds of breaches for the price of one. Every integration, whether backup, RMM, PSA or security tooling, is a non-human identity with standing access. It often holds more privilege than any employee, and nobody reviews it after the day it was set up.

The same pattern exists inside most client networks. On-prem Active Directory is full of quiet vendor identities too: a backup service account in Domain Admins, an RMM account whose password hasn't changed since 2019, the sync account with rights to pull every password hash. Those are the cleaning crew's master keys, just in a different building.

Where KinoSec fits

First, a straight answer: KinoSec does not audit your Entra ID app registrations or OAuth consents. For this incident, follow the Huntress and ConnectWise guidance above, today.

What KinoSec does is find the same kind of trust problem in the places it tests: your clients' external networks, web apps and Active Directory. An autonomous KinoSec pentest works the way an attacker would:

• External surface: It maps what each client exposes to the internet, including the kind of login portals someone was password-spraying on October 13 and 14.
• Active Directory: It hunts for over-privileged service accounts, kerberoastable vendor accounts, credentials left in shares and scripts, and paths that turn one foothold into domain admin.
• Chaining: It shows how a single leaked key turns into "attacker owns everything." Then it writes a plain-language report with remediation, which you deliver under your own brand.

For MSPs and MSSPs, that means continuous testing across every client, not a once-a-year snapshot. You can show each client exactly which keys to their building exist before someone copies them.

Frequently Asked Questions

What is the ConnectWise Cloud Backup breach?

The ConnectWise Cloud Backup breach is an October 2026 supply chain attack. Attackers abused a stolen credential for ConnectWise's Cloud Backup app, formerly SkyKick Cloud Backup, to sign into customers' Microsoft 365 tenants as the app. Huntress confirmed unauthorized sign-ins in 162 tenants by October 16, 2026, and later saw more than 300 successful sign-ins from the attacker's IP. ConnectWise disabled seven app identities and suspended the service on October 17.

Why didn't multi-factor authentication stop the ConnectWise attack?

MFA didn't stop it because the attacker authenticated as an application (a service principal), not as a user. Application sign-ins use keys or certificates and never prompt for MFA. The backup app already held broad Microsoft 365 permissions, including likely Directory.ReadWrite.All, so the attacker inherited that access.

How do I check if my Microsoft 365 tenant was compromised through ConnectWise or SkyKick?

In Microsoft Entra, open Service principal sign-ins and filter on the Cloud Backup app ID 506e08f9-6e9a-4da4-942b-a099a03644ae. Look for sign-ins from outside Microsoft and Azure ranges, especially 144.172.64[.]128, between October 13 and 16, 2026. Then check the audit logs for ConnectWise or SkyKick apps assigning directory roles or adding secrets to other apps. Huntress advises disabling, not deleting, those apps either way.

Was Cloud Backup data stolen?

ConnectWise says it has no indicators that Cloud Backup partner backup data was compromised, and that archives remain encrypted and isolated. Huntress has not confirmed data theft, but notes that directory reads through Microsoft Graph leave no audit trail. So a lack of evidence is not proof that no data was accessed.