How a Trusted Backup App Opened a Route Into Customer Clouds

A company can protect its employees’ passwords and still leave another kind of identity exposed: the software allowed to work on their behalf. In the ConnectWise incident, attackers used compromised application credentials to reach customers’ Microsoft cloud environments without an interactive user sign-in, according to Microsoft’s investigation.

That distinction explains why a breach at a backup provider can become a problem inside another company’s cloud. The attacker is not necessarily persuading each employee to open a malicious link. It can be using access that an administrator previously granted to a legitimate service.

Microsoft’s October 21 report attributes the campaign to Storm-0940, a China-state-aligned actor, and says it used an AI-agent framework called ARTEX to accelerate its operations. The report describes successful authentication and further activity in multiple customer environments. It does not establish that every targeted organization was breached or that every successful sign-in led to stolen data.

A Backup Service Has Its Own Identity

An automated backup cannot wait for someone to sign in every time it needs to copy a mailbox. It needs an identity and permission to do its job while people are elsewhere.

Microsoft’s application-only access documentation describes this arrangement: an application acts as itself, with permissions authorized by an administrator. A backup service may need access to resources belonging to several users. That is different from an app acting within the rights of a particular signed-in person.

The permissions are the important part. An application does not automatically have unlimited access to everything. Its assigned rights determine what it can reach and do. But a highly privileged integration can make one stolen application identity valuable across multiple customer environments.

Microsoft says the attacker gained control of identities associated with ConnectWise cloud applications, then used those applications’ existing trusted access to authenticate downstream. In some environments, it went on to inspect resources, change application credentials and make changes involving identities and privileged roles.

A “tenant” in this account is an organization’s Microsoft cloud environment. An application trusted by many tenants can carry a supplier relationship across many separate organizational boundaries. That is the supply-chain problem here: the route into a customer can begin with software the customer deliberately connected.

A Failed Password Attack Was Not the End

Microsoft also describes a separate password-spraying effort from October 10 through 14. Password spraying means trying candidate passwords across accounts, rather than relying on one stolen application credential.

That activity produced more than 151,000 failed logon events against 327 accounts at eight organizations. Microsoft says it observed no successful authentication, token issuance or subsequent cloud-directory changes in that effort.

Those numbers do not demonstrate a spectacularly successful password attack. They document an unsuccessful one in the observed telemetry.

The application route was different. After the ConnectWise compromise, Microsoft says the actor attempted to sign in to more than 2,250 tenants using its automated framework. In multiple customer environments, authentication and further activity did occur. Treating the failed password campaign and the compromised-app activity as one undifferentiated tally would hide the mechanism that mattered.

The AI contribution also needs the right scale. Microsoft describes agents accelerating reconnaissance and abuse of already compromised application access. It reports some attacks in the broader campaign reaching privileged cloud access in less than three hours. That is an observation from its investigation, not a controlled measurement of how much faster AI was than a human team.

AI helped operate the machinery. It did not invent the permission model or turn every attempt into a successful intrusion.

Four Different Claims Hide Inside “Affected”

The same incident can generate four very different statements: a customer had the application installed; the attacker targeted that customer; an application identity successfully authenticated; the attacker accessed or removed customer data.

Each step requires its own evidence. Having a potentially affected integration is a reason to investigate, not a count of confirmed data theft. A successful sign-in shows that the identity was accepted, but not everything it did afterward.

Microsoft explicitly cautions that the presence of an affected application, or even successful attacker authentication, does not necessarily show that customer data was accessed or exfiltrated. Its report also says the activity did not result from a compromise of, or vulnerability in, Microsoft’s own corporate systems, products or services.

That does not make the incident harmless. Microsoft observed follow-on activity in multiple environments. It means a headline claiming that 2,250 organizations had their data stolen would say substantially more than the evidence supports.

Preserved Backups Can Still Be Unavailable

ConnectWise’s incident updates describe another consequence: interrupting a trusted service can also interrupt the business process that depends on it.

The company says existing backup archives remain encrypted, isolated and preserved, with no indication of compromise. Those are its reported findings about the stored archives, not a declaration that every customer’s Microsoft environment is clear.

At the same time, the incident has disrupted Cloud Backup and connected services. The company began phased restoration work on October 21, but that did not mean all customer capabilities were available again.

In its October 23 update at 01:11 UTC, ConnectWise said it anticipated completing testing and security validation by the end of the weekend. Subject to successful validation, it expected to enable access for restoring existing backups early the following week, with full service re-enrollment afterward. These were anticipated milestones, not confirmed restoration dates. Its instruction remained to keep affected application connections disabled until service-specific directions arrived.

The practical distinction is sharp: a backup may still exist without being immediately available when someone needs to restore it.

Closing the Original Connection May Not Close Every Route

Microsoft warns that unauthorized credentials or privilege changes made inside a customer environment can remain after the original compromised application is dealt with. Removing the first route does not, by itself, establish that no additional route was created.

Its guidance therefore separates containing the affected integration from examining what happened afterward. That includes application sign-ins and subsequent directory, permission and resource activity. The vendor’s current investigation instructions, rather than a general headline, are the appropriate operational reference for an affected administrator.

The distinction resembles another gap in security: finding a software flaw is not the same as getting the patch into production. Likewise, recording an AI agent’s activity is not the same as having an effective monitor. In each case, a protective step can be real without completing the whole chain.

The ConnectWise incident exposes a boundary that a password-centered picture of cloud security misses. A company’s cloud is also shaped by the software identities it has authorized. When a supplier’s application becomes an attacker’s credential, the decisive question is no longer just who signed in. It is what that application was already allowed to do.