Seven App Identities, 173 Tenants: Hunting the ConnectWise Cloud Backup Sign-Ins in Your Own Logs

The only record that an intruder signed in as your backup provider sits in a tab of the Entra portal most tenants have never opened. It is called Service principal sign-ins, and it is a different tab from the one your SIEM connector almost certainly reads.

Open it and filter on application ID 506e08f9-6e9a-4da4-942b-a099a03644ae. That is ConnectWise Cloud Backup, formerly SkyKick Backup. Between October 13 and October 16, someone holding the vendor's credential used it to request Microsoft Graph tokens in hundreds of customer tenants.

ConnectWise disabled seven application identities at 07:00 UTC on October 17 and suspended Cloud Backup, SaaS Security and Cloud Management. At 01:28 UTC today all three remain down, with no restoration time published. The vendor closed its own side. Anything the intruder changed inside your tenant is still sitting there.

Whether this one is yours

Four answers, depending on where you sit.

You consented to ConnectWise Cloud Backup or SkyKick Backup in your Microsoft 365 tenant, directly or through a managed service provider. This is yours and it is today's work. Treat every mailbox, SharePoint site and Teams chat the backup service could read as readable by someone else during the window.

You buy other ConnectWise products but believe you never installed the backup app. Check anyway. Consent for these apps is frequently granted through a partner relationship, by someone who left years ago, in a tenant nobody audits. Huntress found the service principal missing in plenty of probed tenants, which is the only reason those token requests failed.

You run Microsoft 365 with no ConnectWise relationship of any kind. This specific incident passes you by. The query below still earns an hour of your week, because the question it answers - which third-party service principals hold tenant-wide consent in my directory, and what signed in as them last month - has the same answer whoever the vendor turns out to be next time.

You do not run Microsoft 365. Stop here. Nothing below applies to you.

What the intruder actually held

The compromised credential is a client assertion, which means it lives in ConnectWise's tenant rather than yours. You cannot rotate it. You cannot see it. You never could. Your tenant granted consent once, and from that moment the vendor's certificate was a valid way to obtain tokens scoped to your data.

Todyl, which detected the same activity independently, published what that consent grants: read and write access to mail and attachments, including full mailbox access through Exchange Web Services; read and write access to OneDrive and SharePoint files; read and write access to Teams chats; and the ability to restore data back into the tenant. Microsoft added that the attacker likely used permissions already granted, naming Directory.ReadWrite.All among them.

A backup product needs most of that to do its job. That is the uncomfortable arithmetic of this category. The scope you approve for a backup vendor is close to the scope you would approve for an attacker, and the only thing separating the two is control of one certificate in a tenant you do not administer.

Fifteen hours on October 15

Huntress security researcher Jonathan Semon reconstructed the sequence from partner telemetry. It reads like someone working through a list.

• October 13-14 - password spray against four law firm tenants from 144.172.64.128, using curl/7.88.1 to script OAuth2 token requests. Two accounts smart-locked. No user sign-in succeeded.
• October 15, from 01:58 UTC - in roughly 50 monitored tenants, ConnectWise Cloud Management service principals assigned themselves directory roles, mostly Exchange Administrator. User agent kiota-dotnet.
• 03:44 and 03:48 UTC - in one tenant, the Cloud Management Teams app added itself to Global Administrator. Then, under Python-urllib/3.12, it made nine changes to two unrelated applications, adding client secrets to both. Six succeeded. The new secrets expire in 2028.
• 06:13 to 08:34 UTC - Graph tokens obtained in 17 of the first 290 or so tenants tried, processed in sorted GUID order, seconds apart.
• 09:25 to 12:35 UTC - a sweep requesting Graph tokens for the backup app across a further 16 tenants.
• 13:54 to 14:20 UTC - a slower, apparently hand-driven pass over the same tenants, this time against Exchange Online, SharePoint Online, Teams, Azure Resource Manager, Entra and the Office 365 Management APIs.

The 03:44 entry is the one that should change your remediation plan. A vendor app granted itself Global Administrator and then used that authority to plant long-lived secrets on two applications that have nothing to do with ConnectWise. One of them was Huntress's own agent app. Disabling the backup app does nothing about either secret.

ConnectWise says it identified the problem on October 14 through its own security monitoring. Its first public status entry went up at 17:48 UTC on October 16, after Todyl had already published and while Huntress was still counting tenants. For two days the people with the logs that mattered were customers who had been told nothing. If you build a third-party incident runbook out of this story, start it at the point where a researcher tells you, because that is when you will actually hear.

By the evening of October 16 Huntress had confirmed unauthorized sign-ins in 162 tenants. By the following day the count stood at 173. The wider tally is worse: sign-in attempts from that single address appear in close to 1,000 Entra tenants, and more than 300 of them succeeded.

The hunt your logs can still answer

Run this before you read any further vendor updates. It needs the Microsoft.Graph module and an account with Global Reader or better.

# ConnectWise / SkyKick application identities disabled by the vendor 2026-10-17 07:00 UTC
$cwApps = @(
  '506e08f9-6e9a-4da4-942b-a099a03644ae',  # Cloud Backup (SkyKick)
  '2399d300-6fca-4e6a-a686-399fefe75b83',  # Cloud Management
  '24205314-2b89-4e07-a2a4-579e898a5640',  # Cloud Management - MS Teams
  'b78f6a77-d4e5-46fb-87e5-d1648bd02519',  # Cloud Management - Exchange Online
  '0de14c77-b9b0-4137-9360-34878a929827',  # Cloud Management - MS Graph
  '412dcf96-176d-4b3a-a1b0-4981ad66971e',  # Cloud Management - Partner Center
  'b2b55f5b-7758-4719-8d8f-88ae172e6bdb'   # Cloud Management - SharePoint Online
)

Connect-MgGraph -Scopes 'Application.Read.All','RoleManagement.Read.Directory','AuditLog.Read.All'

# 1. Which of the seven exist here, and are any still enabled for sign-in?
foreach ($id in $cwApps) {
  Get-MgServicePrincipal -Filter "appId eq '$id'" -Property Id,AppId,DisplayName,AccountEnabled |
    Select-Object DisplayName, AppId, AccountEnabled
}

# 2. Directory roles held by ANY service principal. A vendor app in a role is the finding.
Get-MgDirectoryRole -All | ForEach-Object {
  $role = $_.DisplayName
  Get-MgDirectoryRoleMember -DirectoryRoleId $_.Id -All |
    Where-Object { $_.AdditionalProperties['@odata.type'] -eq '#microsoft.graph.servicePrincipal' } |
    ForEach-Object { [pscustomobject]@{ Role = $role; Principal = $_.AdditionalProperties['displayName'] } }
}

# 3. Every credential on every app and service principal added since the spray began.
$since = Get-Date '2026-10-13T00:00:00Z'
Get-MgServicePrincipal -All -Property Id,DisplayName,AppId,PasswordCredentials,KeyCredentials |
  ForEach-Object {
    $sp = $_
    @($sp.PasswordCredentials) + @($sp.KeyCredentials) |
      Where-Object { $_ -and $_.StartDateTime -ge $since } |
      ForEach-Object {
        [pscustomobject]@{ App = $sp.DisplayName; Added = $_.StartDateTime; Expires = $_.EndDateTime }
      }
  }

Step three is the one to read closely. Any secret or certificate added to a management or security application since October 13 that you cannot tie to a change ticket should be removed, and the application it sits on should be treated as compromised until you prove otherwise.

Then take the same question to the sign-in logs

In Entra, go to Monitoring and health, then Sign-in logs, then the Service principal sign-ins tab. The default User sign-ins tab will not show any of this. Filter by each application ID above and look at the source addresses. Normal traffic for these apps arrives from Azure private IPv6 space. Anything from 144.172.64.128, 144.172.64.99 or 144.172.64.60 is the intruder. Those three addresses sit in AS14956.

The three audit operations worth a saved search

Entra's audit log, under the same Monitoring and health blade, is where the role grants and the planted secrets are recorded. Three operation names carry this incident: Add member to role, Update application and Add service principal credentials. Read the initiating actor, the target and the user agent together. No single field identifies the activity on its own, and the combination of a service principal as the initiator and Python-urllib/3.12 or python-requests/2.31 as the agent is what separates it from normal vendor traffic. A service principal that adds itself to a directory role is abnormal in almost any tenant, whoever owns the app, so that search is worth keeping after this incident closes.

If you hold Entra ID P1 or P2, turn on Microsoft Graph activity logs now. They record the per-request source address that sign-in logs alone will not give you. They are also not retroactive, so switching them on today answers the next question rather than this one. On Entra ID Free, sign-in data ages out after seven days. Export it before Thursday.

What the vendor's shutdown did not reach

ConnectWise's own status page is unusually clear about the limits of its action. Revoking the certificates stopped new authentication. Previously issued access tokens stay usable until they expire. Disabling the connections reverses nothing that already happened inside a customer tenant.

Three consequences follow for you.

Directory roles the apps granted themselves survive the shutdown. Exchange Administrator on a disabled service principal is still Exchange Administrator the moment anything re-enables it. Remove the role assignments by hand.

Client secrets planted on other applications survive it completely, and they are valid until 2028. They are the persistence that outlives this news cycle.

Reads through Microsoft Graph leave no audit record. Huntress reviewed one affected tenant and found no mail or file access logged at all. A clean unified audit log here is an absence of evidence and nothing stronger, so scope your data-exposure assessment from what the consent allowed rather than from what the logs show.

When you disable the apps, use the enterprise application sign-in toggle rather than deleting the service principal. Deleting removes the consent grant, and restoring service later would require a fresh admin consent you may not want to give under time pressure.

Disable the apps, then go looking for the secrets they added

Today's sequence, in order: disable all seven application identities in every tenant you administer, strip any directory role a ConnectWise or SkyKick principal holds, and then run step three of the script above across your whole application estate rather than only against the vendor's apps. The credential the intruder planted on an unrelated management app is the part that will still be live in eighteen months. Keep the apps disabled until ConnectWise publishes restoration instructions, and expect scheduled backups to stay stopped until it does.

The wider control is consent, not patching. There is no CVE here and no update to install. Every multi-tenant application in your directory holding tenant-wide permissions is a credential you do not control, in a tenant you cannot audit, scoped to data you are accountable for. We review those grants as part of an identity assessment, and the review usually finds two or three apps nobody can name, still consented, still enabled.