ConnectWise says it "recently identified unauthorized access to application identities within the ConnectWise Cloud Backup environment", the product formerly sold as SkyKick. Huntress has confirmed unauthorised sign-ins in 173 partner and customer Microsoft 365 tenants, up from an earlier count of more than a hundred.

No software flaw has been named. What the attacker has is the identity of an application that managed service providers installed, and consented, in every tenant they look after.

The containment is the outage

ConnectWise's advisory is unusually direct about the trade it is making: "As a protective measure for our Cloud Backup partners and their clients, we are shutting off Cloud Backup application access. This will interrupt backup services for customers until further notice."

That is the whole problem with a consented application. The permission that lets the backup service read a tenant's mail, files and Teams data is the same permission the attacker is using, and it is granted to the application rather than to a person. There is no way to revoke it from the attacker and keep it for the backups, because it is one grant.

So the vendor's only fast lever turns the product off. ConnectWise says the archive itself is not affected and "will be accessible once services are restored", and that it has "no indicators to date that Cloud Backup partner backup data has been compromised".

What the attacker actually did

Huntress's timeline is the clearest account available. Tokens were obtained from 144.172.64.128 on 15 October, between 06:13 and 08:34 UTC. The actor then moved through tenants in sorted identifier order, a few seconds apart — which is not somebody exploring, it is a script working down a list it already had.

The same address had password-sprayed four law firm tenants on 13 and 14 October, with no successful sign-ins in Huntress's telemetry.

The tooling is worth noticing too. ConnectWise lists the observed user agents as Python-urllib/3.12 and python-requests/2.31. Nothing about this was sophisticated. The sophistication was in what the credential was attached to.

How to check, in ConnectWise's own words

The advisory gives a hunting procedure, and one step in it is the kind of detail that decides whether a search finds anything:

In the Microsoft Entra admin centre, go to Monitoring and then Sign-in logs, select the Service principal sign-ins tab, and filter by application ID 506e08f9-6e9a-4da4-942b-a099a03644ae. ConnectWise notes that "The default User sign-ins tab will not display the required information". An administrator who checks the tab Entra opens on will see nothing and conclude they are fine.

Then look at the IP address column. The application's normal egress is Azure private IPv6, so anything outside expected Microsoft and Azure ranges is worth pursuing, and 144.172.64.128 in particular.

ConnectWise adds the caveat that matters: "The presence of these indicators warrants further investigation but does not, by itself, confirm that your environment has been compromised."

The shape of this keeps recurring

This is the third story here in a fortnight where the thing compromised was an identity rather than a program. GhostAction pushed workflows into 30,000 repositories using credentials that were already stolen, an npm publishing flow checked a package name instead of the identity behind it, and attackers swapped two unsigned files on a vendor's update server for five minutes at a time.

None of those needed a vulnerability either. The common factor is a trust relationship that was established once, granted broadly, and never scoped to anything smaller.

What to do

  • Run the sign-in log check above in every tenant you manage, on the service principal tab, before deciding whether you are affected.
  • If you are an MSP, treat every tenant where the application was consented as in scope, not only the ones with a hit. The grant is per tenant and the actor worked from a list.
  • Decide deliberately about disabling the service principal yourself. It stops the attacker and it also stops backups, and that is a business decision rather than a security one.
  • Review what the application could reach. A Microsoft 365 backup application typically holds permissions over mail, SharePoint and Teams content, which is the scope of the potential exposure whatever is eventually confirmed.
  • Check for permission changes and new grants, not just sign-ins. An actor inside an application identity can add to it.
  • Report suspicious activity to ConnectWise and check the Trust Center rather than waiting for a summary, because this is still moving.

What is not established

  • Whether any data was taken. ConnectWise says it has no indicators that partner backup data was compromised; third parties have described potential exfiltration from mail, SharePoint and Teams, and nobody has confirmed it.
  • How the application identity was compromised in the first place. The advisory does not say.
  • The total number of affected tenants. 173 is what one vendor has confirmed in its own telemetry, not a population count.
  • Who is responsible. No attribution has been offered.
  • When Cloud Backup service will be restored.
  • Whether the password spraying on 13 and 14 October is the same operator. The shared source address is suggestive and is not proof.