A Compromised ConnectWise Cloud Backup Credential Let Attackers Sign In to Microsoft 365 Tenants as the Backup App

ConnectWise announced at 05:01 UTC on Saturday, October 17 that it was shutting off application access to Cloud Backup, formerly SkyKick Backup, after attackers used the application’s own credential to sign in to customers’ Microsoft 365 tenants as the backup app. Microsoft Threat Intelligence says it is tracking “an active supply chain attack.” Huntress had confirmed unauthorized sign-ins in 162 tenants as of 19:00 UTC on Friday, October 16, and The Hacker News reports its count as 173. Neither number is a ceiling: the credential works in every tenant that approved the app, and Huntress says the actor “is not limited to the tenants we have confirmed so far.”

ConnectWise says it has “no evidence that these encrypted backup archives have been accessed.” It also says it “cannot determine through our investigation alone whether a particular customer’s Microsoft 365 environment experienced unauthorized activity,” which leaves that question to each customer’s own logs. “Scheduled Cloud Backup jobs are not running during the interruption,” the company says, and it has no restoration time to give. This is a developing story, and the figures here are as of 19:20 UTC on October 17, when we last re-read the sources.

If your tenant ever approved a SkyKick or ConnectWise Cloud Backup or Cloud Management app, the advice from the sources splits into two parts. Microsoft and ConnectWise tell customers to review the app’s service principal sign-ins and any credential, permission or consent changes. Huntress and Todyl add that the apps should be disabled until ConnectWise confirms its credentials have been reset, and Huntress says not to delete them. The details, and the points where the accounts disagree, follow.

What the sources say happened

Four first-hand accounts exist, and each sees only part of the incident: ConnectWise’s advisory, which carries three dated updates; Huntress and Todyl, two security firms that watch Microsoft 365 tenants for their customers; and a post by Microsoft Threat Intelligence on X. BleepingComputer’s report ties them together.

The mechanism is ordinary OAuth. Cloud Backup is a multi-tenant application: Microsoft says “customers grant consent for the application to operate in their tenants,” and Todyl explains that an administrator grants it application permissions, which let it read data without a signed-in user. To get a token for a tenant, the app presents its own credential. Microsoft’s documentation says this client credentials flow lets a service use “its own credentials, instead of impersonating a user, to authenticate,” and that the resource enforces the app’s authorization “since there is no user involved in the authentication.” Whoever holds that credential can ask for tokens in every tenant that approved the app. Todyl lists the consent it saw as read and write access to mail and attachments, OneDrive and SharePoint files and Teams chats, including the ability to restore data. Huntress says the credential type in the sign-in logs “was a client assertion, which means the credential lives in the vendor’s own tenant,” and adds: “Nothing a customer did in their environment could have produced it.”

Microsoft assesses that the actor “likely abused permissions previously granted by customers to the application, including highly elevated permissions like Directory.ReadWrite.All.” Microsoft’s Graph reference lists that permission, along with Application.ReadWrite.All, as a higher-privileged application permission for the addPassword call on a service principal, which is the kind of step Microsoft describes next: “Microsoft Graph API reconnaissance and attempts to add additional credentials on the related service principal in target tenants to maintain direct access as a backdoor.”

The times below are UTC and come from the source named in each row.

Why the usual defenses did not apply

Several of the controls administrators reach for first do not touch this kind of sign-in. Todyl’s explanation is that no user interaction was required, “so user-focused controls such as MFA and conditional access for users did not apply,” and that revoking user sessions “does not end this access.” Todyl’s indicator table records the Conditional Access status as notApplied, and Microsoft’s documentation says why a customer cannot fix that: its Conditional Access policies for workload identities cover single-tenant service principals registered in your tenant, and “Microsoft and third-party SaaS applications, including multitenant apps, are not covered by these policies.” Todyl’s conclusion is that “least-privilege consent and removing unused apps are the main controls.” Stale approvals count. Todyl saw tokens issued in tenants that had no active backup subscription, and BleepingComputer relays a Reddit user’s report of a role-assignment alert from an app they had not used in years.

Disabling the app is the right first move, but it has limits. Microsoft’s error reference lists the failure a disabled app gets as AADSTS7000112, “The application is disabled,” and Todyl says disabling “stops new tokens from being issued” in that tenant. Tokens already issued are another matter. Todyl says they “stay valid for up to 90 minutes,” which fits the “random value ranging between 60-90 minutes” that Microsoft documents as the default. Todyl’s own indicator table, though, marks the sign-ins as continuous access evaluation (CAE) tokens, which Microsoft says can be extended to “24-28 hours” when a client and a resource both support CAE, and Microsoft’s page on CAE for workload identities says: “Third-party SaaS and multitenant apps are out of scope.” So 90 minutes is the likely case, not a guarantee. A disabled app also does not undo what an attacker already added. Huntress warns: “Disabling M365 apps, including the abused ConnectWise apps will not remove credentials that were already added.” The technique it names is MITRE ATT&CK T1098.001, additional cloud credentials.

Visibility is the other gap. Huntress says Microsoft’s audit log records role assignments and application changes along with the acting application, “but for app-only actions it carries no source IP,” and that “Directory reads through Microsoft Graph leave no audit trail.” Todyl’s tenants were not collecting Microsoft Graph activity logs, so in tenants with an active backup subscription it could not separate the actor’s mailbox and file reads from the real backup service’s, which use the same application identity. “The absence of confirmed exfiltration is partly a visibility limit rather than a clean result,” Todyl writes. Microsoft’s documentation says Graph activity logs need an Entra ID P1 or P2 license and a diagnostic setting that sends them to a destination, and its retention table gives tenants on the Free license seven days of sign-in logs against 30 for P1 and P2. Todyl’s advice is: “Export logs now if you’re on Entra ID Free (7-day retention).” By our arithmetic, a Free tenant’s October 15 sign-ins age out around October 22.

Where the accounts do not line up

• What happened after sign-in. Todyl says it “found no directory changes tied to the activity” in the tenants it reviewed. Microsoft describes reconnaissance and attempts to add credentials on the related service principal. Huntress saw persistence in one tenant, through a different ConnectWise app. These are different apps in different tenants, so they are not necessarily in conflict, but no source says the same thing happened everywhere.
• Whether the early activity is the same operator. Huntress’s Global Administrator change and credential additions came about two and a half hours before the first Cloud Backup sign-in from 144.172.64[.]128. Huntress writes: “We have no source address for the earlier activity, so we have not tied the two phases to the same operator.” BleepingComputer says all three firms tracked the activity to the same address. That holds for the Cloud Backup sign-ins; Huntress does not claim it for the earlier changes.
• What kind of credential. Both firms report the credential type as a client assertion (clientAssertion in Todyl’s table, which shows the key ID and thumbprint fields empty). Todyl’s text calls it a client secret and Huntress’s first key takeaway calls it an API secret, while ConnectWise says it revoked certificates. Microsoft’s Graph beta documentation lists clientSecret, clientAssertion and certificate as separate values of that field, so the public accounts use one word for what may be more than one thing. Only ConnectWise can replace the credential either way.
• Which apps are involved. ConnectWise’s advisory names only Cloud Backup, and its 17:00 UTC update says “we have no indication that any other ConnectWise product, service, or offering is impacted.” Huntress has high confidence that the Cloud Management apps for Exchange Online, Teams and SharePoint Online were also abused. The advisory never uses the words Cloud Management, so we cannot tell whether the certificate revocation covers those apps. The Hacker News lists all seven application IDs as “the application IDs the threat actor has abused as part of the activity”; Huntress puts four of them in its confirmed group and gives the other three as IDs to look for.
• How many tenants. Huntress’s page says 162 as of 19:00 UTC on October 16; The Hacker News says 173. Each count covers only the tenants that firm monitors.
• What ConnectWise says it knew, and when. ConnectWise says it “identified the issue on October 14, 2026.” Its first advisory is dated October 16 at 17:47 UTC, and the shut-off announcement came at 05:01 UTC on October 17, which by our arithmetic is 1 day, 20 hours and 27 minutes after the end of the 06:13 to 08:34 UTC window in which Huntress logged the Cloud Backup sign-ins. ConnectWise says it “emailed and called partners directly and posted updates on LinkedIn and Reddit” but gives no times, and it does not say whether the October 14 detection and the October 15 sign-ins are the same activity. Todyl noted that the first advisory “does not mention Microsoft 365, the application, or its credential”; the 05:01 UTC update added “application identities.”

What administrators are being told to check

1. Disable the apps, do not delete them. In the Entra admin center, open the enterprise application, choose Properties and set “Enabled for users to sign-in?” to No; Microsoft documents that path for at least a Cloud Application Administrator. Huntress says: “Do not delete the application.” Deleting it “removes the consent,” and disabling pauses backups.
2. Read the right log. Sign-ins by an app appear on the Service principal sign-ins tab, not the default User sign-ins tab. Filter by the Cloud Backup application ID and look for any address outside Microsoft and Azure ranges; ConnectWise says the app’s normal egress is Azure private IPv6. Search for 144.172.64[.]128 and the user agents Python-urllib/3.12, python-requests/2.31 and python-requests/2.34.2, which Microsoft lists. Huntress also saw curl/7.88.1 in the October 13 and 14 spraying. ConnectWise says indicators alone do not confirm compromise, and Huntress says: “A clean result does not rule out access.”
3. Review credentials. Huntress asks administrators to check the secrets and certificates on every enterprise application and app registration for additions since October 13 that they did not make, especially management and security tools, and to remove anything unexpected.
4. Review roles and audit logs. Check whether any ConnectWise or SkyKick app holds a directory role such as Global Administrator or Privileged Authentication Administrator, and look in the audit log for those apps adding themselves to roles or modifying other apps. Huntress says the ConnectWise apps it reviewed use a .NET user agent (kiota-dotnet) while the application changes it saw in one tenant came from a Python one.
5. Keep the evidence. Todyl suggests hunting from October 1 or as far back as retention allows, and turning on Microsoft Graph activity logs, which it notes are not retroactive.
6. Use Defender if you have it. Microsoft says Defender detects post-exploitation activity through any “Suspicious sign-in” alert, “Graph API activity from a Microsoft threat intelligence IP address” and “Verified Threat Actor IP.”
7. Do not turn anything back on yet. Huntress says: “Do not re-enable any ConnectWise applications until ConnectWise confirms all credentials have been reset.” ConnectWise’s 17:00 UTC update says the shared Cloud Backup credentials “are no longer valid and cannot be used,” but it does not say a replacement has been issued, and the service is still off.

The application IDs below appear in Huntress’s post and BleepingComputer’s report. The third column follows Huntress’s own wording.

Huntress adds that older tenants may list the Cloud Management apps as “SkyKick Cloud Manager.”

What is still unknown

• How the credential was taken. ConnectWise says: “Whether a product vulnerability contributed has not been established. The original credential-exposure mechanism remains under investigation.” BleepingComputer likewise says the method the attacker used to obtain vendor credentials is unclear. We found no CVE: a keyword search of the National Vulnerability Database for SkyKick and for ConnectWise Cloud Backup returned nothing on October 17.
• Who is behind it. No source attributes the activity. The only attacker infrastructure published is one address. ARIN lists its covering block, 144.172.64.0/18 (net name PONYNET-12), as an allocation to FranTech Solutions, and RIPEstat shows the /24 containing it announced by AS14956, RouterHosting LLC, the network Todyl reported. Todyl’s table has Entra placing the address in Cheyenne, Wyoming and its own enrichment placing it in Sydney, so location says little. A rented server in a hosting range is not attribution.
• What was read or copied. In the one tenant audit log it reviewed in detail, Huntress says, “the actor shows no mail or file access,” and it adds that this does not mean no data was taken. Todyl tells affected organizations to treat their data as potentially exposed.
• When backups return. ConnectWise says “New or changed data may therefore fall outside existing backup recovery points” while the service is off, and that it does not yet have a restoration time.

Backup and remote-support software has now been the subject of three of our stories in nine days. Ahsay and Huntress disagreed over whether AhsayCBS 10.3.4 fixes two exploited flaws in our October 9 report, and BeyondTrust disclosed an exploited Remote Support zero-day in our October 16 report. Those involved flaws in software customers run. This one involves a credential the vendor holds, and no source links the three.

Sources and method

We read ConnectWise’s advisory twice on October 17 (the second time at about 19:20 UTC, when the latest update was still the one dated 17:00 UTC), Huntress’s post and Todyl’s post in full, BleepingComputer and The Hacker News. Microsoft has not published a blog or advisory page that we could find, so its statements come from its post on X, which we read through a public JSON mirror of the post. We could not open the Reddit thread BleepingComputer cites, so that detail is second-hand. The Huntress page we read still said 162 tenants, so the 173 figure rests on The Hacker News. For documentation we read Microsoft Learn pages on the Conditional Access scope for workload identities, CAE for workload identities, access token lifetimes, log retention, Graph activity logs and error codes, plus the Graph reference for the signIn resource and the service principal addPassword permissions. The registry facts come from ARIN’s RDAP service and RIPEstat. We did not test anything in a Microsoft Entra tenant. Times are UTC, weekdays and the 1 day, 20 hours and 27 minutes figure are our arithmetic from the timestamps given, and we left out Huntress’s tentative observation about victim names, which it offers only as a hint for prioritizing reviews.