ConnectWise Cloud Backup Supply-Chain Attack Hit Microsoft 365 Tenants Through a Vendor App Identity That MFA Never Sees

Attackers have used a vendor's application identities to get into Microsoft 365 tenants, and ConnectWise has taken its Cloud Backup service offline in response. According to BleepingComputer, the service, formerly SkyKick Cloud Backup, was shut down on 17 October after administrators noticed unauthorised access to client data. Huntress confirmed at least 162 compromised tenants in its own environment. The total victim count has not been published.

How the attackers got in

Cloud Backup works through Microsoft Entra ID. Customers grant it permissions, and it acts through a service principal, an application identity that holds those permissions in each tenant.

According to Todyl, the attacker authenticated directly to Microsoft 365 as the backup application, using its secret. Because this was done by script rather than a user sign-in, MFA never applied. The app already held broad rights in each tenant, so the attacker could reach mail, OneDrive and SharePoint files, and Teams chats.

How the attacker obtained the vendor's application credentials has not been disclosed.

What defenders have observed

• Huntress: across nearly 50 monitored tenants, ConnectWise Cloud Management service principals assigned themselves directory roles, mostly Exchange Administrator. In one tenant the attacker took about five minutes to establish persistence, including a Global Administrator grant and new credentials added to an MSP management tool.
• Microsoft: described an active supply-chain attack, with Microsoft Graph reconnaissance and attempts to add credentials after successful service principal sign-in. It assessed that the attacker likely abused existing permissions such as Directory.ReadWrite.All.
• Todyl: in nine tenants it analysed, it saw sign-in activity only, with no evidence of account creation, permission changes or persistence.

The picture varies by tenant, so assume nothing about yours until you have checked.

Indicators published so far

• Source IP: 144.172.64[.]128
• User agents: curl/7.88.1, python-urllib/3.12, python-requests/2.31, python-requests/2.34.2
• Cloud Backup app ID: 506e08f9-6e9a-4da4-942b-a099a03644ae (a legitimate app, abused)

Scripted sign-ins were linked to the attacker's IP from 13 to 14 October, and malicious activity was recorded on 15 October. ConnectWise disabled seven application identities on 17 October, and as of 18 October backups and restores remain unavailable. It says archives are encrypted and isolated, and that it has no indication partner backup data was compromised.

What to check now

1. Review service principal sign-ins in Entra filtered by the Cloud Backup app ID, looking for unexpected source addresses.
2. Disable the implicated ConnectWise applications. Huntress recommends this for all tenants that use them. Disabling stops new tokens, but existing tokens remain valid until they expire, and revoking user sessions does not end application-based access.
3. Audit secrets and certificates on every application added or changed since 13 October, and remove any you did not create.
4. Check directory role assignments. A service principal that assigns itself Exchange Administrator or Global Administrator is the clearest sign of abuse reported so far.
5. Inventory third-party OAuth grants. Remove apps you no longer use. One administrator reported an alert from a SkyKick service principal they had not used in years.

Where Obiguard fits: seeing non-human sign-ins

The lesson here is that the most trusted identities in a tenant are often the ones nobody watches. Obiguard SOC collects logs and host metrics through OpenTelemetry, makes them searchable in Live Logs by source and level, and fires alerts on rule matches and log volume. Each alert keeps an evidence timeline linked to the raw events behind it.

To be clear about scope: SOC works on the logs you send it. Getting Entra sign-in and audit logs into that pipeline is a configuration step on your side, and it does not replace Microsoft's own protections or revoke tokens for you. Once those logs are flowing, rules for a backup app signing in from a new address, or a service principal granting itself a directory role, turn this incident from something found days later into an alert with evidence attached.

For other recent vendor and appliance incidents, see our coverage of the BeyondTrust zero-day and the OpenCode key exposure.

The question to take away

Which third-party apps in your Microsoft 365 tenant can read mail and files without a person signing in, and would you notice if one signed in from an address you had never seen?

See how Obiguard SOC works or talk to us about monitoring the identities attackers prefer you ignore.