DEV Community

Cover image for ConnectWise SkyKick Breach: How a Backup App Got Into Microsoft 365 Tenants, and How to Audit Your Own Apps
Ahsan Nadeem
Ahsan Nadeem

Posted on Originally published at znovastudio.com

ConnectWise SkyKick Breach: How a Backup App Got Into Microsoft 365 Tenants, and How to Audit Your Own Apps

#microsoft #azure #security #sysadmin

On 15 October 2026, a backup app that hundreds of businesses trusted with their email signed in to their Microsoft 365 tenants from a rented server. Nobody typed a password or answered an MFA prompt. In the ConnectWise SkyKick breach, attackers held the app's own credential, and that was enough.

ConnectWise Cloud Backup, formerly SkyKick, is usually bought by your managed service provider (MSP), not by you. Below: the timeline, a two-minute check, and a step-by-step audit of your third-party apps that stays useful long after this incident. If you'd rather not do it alone, our managed IT support team can run it with you.

What happened in the ConnectWise SkyKick breach? Timeline, 10 to 25 October

In mid-October 2026, an attacker used a stolen credential belonging to the ConnectWise Cloud Backup app (formerly SkyKick) to sign in to customers' Microsoft 365 tenants, with no password or MFA involved. Huntress confirmed 162 tenants and saw activity in almost 1,000. ConnectWise suspended the service, and Microsoft attributes the attack to the China state-aligned group Storm-0940.

Sources agree on the shape of the attack, not every number. Times are UTC.

Date (2026) What happened
10 to 14 Oct Password spraying against 327 accounts at eight organisations: Microsoft counted more than 151,000 failed sign-ins.
15 Oct, from 01:58 ConnectWise Cloud Management apps give themselves admin roles, mostly Exchange Administrator, in about 50 tenants Huntress monitors.
15 Oct, 03:44 In one tenant, the Teams management app adds itself to Global Administrator, then plants secrets valid until 2028 on two other apps.
15 Oct, 06:13 to 08:44 The Cloud Backup app signs in from 144.172.64.128 and collects Microsoft Graph tokens, tenant after tenant (08:44 is Huntress's last confirmed successful sign-in).
16 Oct Huntress goes public and confirms unauthorised sign-ins in 162 tenants; ConnectWise posts its first advisory.
17 Oct ConnectWise shuts off Cloud Backup access, disables seven app identities and revokes certificates. Huntress sees activity in almost 1,000 tenants, over 300 successful.
18 to 19 Oct SaaS Security and Cloud Management go offline too. ConnectWise completes a full credential reset.
21 Oct Microsoft attributes the attack to Storm-0940, a China state-aligned group using ARTEX, an open-source penetration testing framework driven by AI models, and says it tried more than 2,250 tenants.
25 Oct ConnectWise targets phased restoration from Monday 26 October, backup restores first.

Where the counts differ: Huntress confirmed 162 tenants; The Hacker News later reported 173. "Almost 1,000" is tenants with any activity from the attacker's address, and Microsoft's 2,250 is tenants the group tried. Microsoft says the group was already using ARTEX as early as September 2026.

ConnectWise says backup archives stayed encrypted and isolated, but it can't see inside customer tenants, so it can't tell you whether yours was accessed. You or your IT provider can, in about two minutes.

Was my tenant affected by the ConnectWise breach? A two-minute check

You're in scope if any of these is true:

  • You use ConnectWise Cloud Backup or SkyKick for Microsoft 365, directly or through your MSP. If you're not sure, ask your MSP today: it's a yes or no question.
  • You used it in the past. Sophos found the attacker's sweep hit tenants with no active backup subscription. Uninstalling the product doesn't remove the app's access from your tenant.
  • The app is still listed in your tenant. In the Microsoft Entra admin centre, go to Entra ID, then Enterprise apps, then All applications, and search by the application IDs below, as Microsoft advises (names vary; older tenants may show "SkyKick Cloud Manager").
App (as named by Huntress) Application ID
ConnectWise Cloud Backup (SkyKick) 506e08f9-6e9a-4da4-942b-a099a03644ae
ConnectWise Cloud Management 2399d300-6fca-4e6a-a686-399fefe75b83
Cloud Management, MS Teams 24205314-2b89-4e07-a2a4-579e898a5640
Cloud Management, Exchange Online b78f6a77-d4e5-46fb-87e5-d1648bd02519
Cloud Management, MS Graph 0de14c77-b9b0-4137-9360-34878a929827
Cloud Management, Partner Center 412dcf96-176d-4b3a-a1b0-4981ad66971e
Cloud Management, SharePoint Online b2b55f5b-7758-4719-8d8f-88ae172e6bdb

If one appears, go straight to "what to do now" below. If none does, this incident probably didn't reach you, but do the audit anyway: every app you've ever approved carries the same weakness.

Why a backup app could walk into hundreds of tenants

When you connect a cloud backup tool, an admin clicks "Accept" on a consent screen. That creates a service principal in your tenant: a local identity for the vendor's app, holding the permissions you approved. A backup tool needs every mailbox, file and Teams chat, so it asks for a lot.

The app then signs in on its own, with a secret or certificate kept in the vendor's systems: no password to phish, no MFA prompt. Huntress noted the stolen credential lives in ConnectWise's own tenant, so no customer could have leaked it.

A multi-tenant app's secret isn't a key to one door; it's a key to every door that ever said yes. In Huntress's words, the credential "works against every tenant the app is consented in". Sophos watched the attacker work through that list in about 96 minutes.

These sign-ins never appear under user sign-ins, only under service principal sign-ins, a log tab many small business admins have never opened.

If the ConnectWise apps are in your tenant: what to do now

ConnectWise, Microsoft and Huntress broadly agree. In order:

  1. Disable the apps, don't delete them. Open each app, choose Properties, set Enabled for users to sign-in? to No and save. Microsoft says this stops all tokens being issued for the app in your tenant. Deleting destroys evidence and the consent you'll need to restore backups.
  2. Export your logs before they expire. On Entra ID Free, sign-in and audit logs last seven days, so 15 October has already gone from Entra. P1 or P2 keeps 30 days. Directory changes also sit in the Microsoft Purview audit log for 180 days by default.
  3. Check service principal sign-ins under Entra ID, Monitoring & health, Sign-in logs, Service principal sign-ins. Filter by the IDs above, back to 1 October if you can (Microsoft's advice). Look for 144.172.64.128, .60 and .99, 144.172.94.243, and any address outside Microsoft and Azure. A clean result doesn't prove nothing happened.
  4. Search the audit log from 13 October for "Add member to role", "Add service principal credentials" and "Update application". An app adding itself to a role, or a secret to another app, is this attack's pattern.
  5. Remove apps from admin roles they shouldn't hold, especially Global Administrator and Exchange Administrator.
  6. Check mailbox forwarding rules and Conditional Access changes, as ConnectWise's checklist asks.
  7. Keep the apps disabled until ConnectWise says otherwise. Tokens already issued can stay valid until they expire.

Save what you find before changing it, and report it to ConnectWise through its Trust Center page.

How to audit enterprise apps in Entra ID (Microsoft 365), step by step

This takes an IT person an hour or two at a typical small business. Most steps need the Cloud Application Administrator role.

Step 1: List every app that isn't Microsoft's

Go to Entra ID, Enterprise apps, All applications, with the application type filter on Enterprise Applications. Every row is an app someone let in at some point.

In PowerShell (Microsoft Graph module), run Connect-MgGraph -Scopes "Application.Read.All", then Get-MgServicePrincipal -All -Property DisplayName,AppId,AppOwnerOrganizationId | Where-Object { $_.AppOwnerOrganizationId -notin @('f8cdef31-a31e-4b4a-93e4-5f571e91255a','72f988bf-86f1-41af-91ab-2d7cd011db47') } | Select-Object DisplayName,AppId,AppOwnerOrganizationId. Those two IDs are Microsoft's own tenants, so what remains is yours and everyone else's.

Note who uses each app and who approved it. Anything nobody recognises is your first finding.

Step 2: Read the permissions, application permissions first

Open each app and select Permissions; the Admin consent tab shows tenant-wide grants. Delegated permissions act as a signed-in user, but application permissions work with no user at all, across the whole tenant, so start there.

Permission What it lets an app do with no user present
Mail.ReadWrite Create, read, change and delete email in every mailbox
Mail.Send Send email as any user
full_access_as_app Full access to all mailboxes through Exchange Web Services
Files.ReadWrite.All Read, change and delete every file in every SharePoint site
Directory.ReadWrite.All Read and write users, groups and other directory data
Application.ReadWrite.All Manage other apps, including adding credentials to them
AppRoleAssignment.ReadWrite.All Grant itself or other apps more permissions
RoleManagement.ReadWrite.Directory Add members to admin roles, including Global Administrator

The last three let an app escalate: Microsoft warns they "allow an application to grant additional privileges to itself, other applications, or any user." BleepingComputer reported that Microsoft assessed the ConnectWise attacker likely abused existing permissions, including Directory.ReadWrite.All.

A backup tool may need mail and file access; it rarely needs to hand out admin roles.

One legacy trap: apps granted Directory.ReadWrite.All before 3 December 2020 also got the Directory Writers role, which revoking the permission doesn't remove.

Step 3: Check which apps hold admin roles

Under Entra ID, Roles & admins, open Global Administrator, Privileged Role Administrator, Privileged Authentication Administrator, Exchange Administrator and Application Administrator. Apps can be members too. Each one needs a reason you can state in a sentence.

Step 4: Look at service principal sign-ins

On the Service principal sign-ins tab, rows are grouped by app, status, IP address and resource, so a new IP appears as a new row. Huntress noted the ConnectWise app normally signed in from Azure address space, which is why a commercial hosting address stood out.

Step 5: Hunt for new secrets and certificates

A secret added to an app you trust is an easy way back in. Run Get-MgServicePrincipal -All -Property DisplayName,PasswordCredentials,KeyCredentials | Where-Object { (@($_.PasswordCredentials) + @($_.KeyCredentials)).StartDateTime -gt (Get-Date).AddDays(-30) } | Select-Object DisplayName to list apps that gained a credential in the last 30 days. For your own apps, also check App registrations, Certificates & secrets.

Once recorded as evidence, an unexplained secret can be removed (reconnect with the Application.ReadWrite.All scope first) with Remove-MgServicePrincipalPassword -ServicePrincipalId <object id> -KeyId <key id>.

Step 6: Remove what you don't use

Disable unneeded apps, wait a week for complaints, then delete them. Microsoft notes that revoking permissions doesn't stop someone consenting again, so lock consent down next.

Lock it down so the next breach is smaller

You can't stop a vendor losing its credential. You can limit what it's worth in your tenant.

  • Restrict user consent. Under Enterprise apps, Consent and permissions, User consent settings, turn it off, or allow it only for verified publishers and low-impact permissions, as Microsoft recommends.
  • Turn on the admin consent workflow. Under Admin consent settings, set "Users can request admin consent to apps they are unable to consent to" to Yes and pick reviewers. Staff ask, an admin decides, and it's on record.
  • Block new app secrets. Under Enterprise apps, Application policies, switch on Block password addition. Existing secrets keep working; new ones can't be added quietly. Test first, as some vendor tools add secrets during setup.
  • Scope mailbox apps with Exchange Online's RBAC for Applications, and remove the tenant-wide grant in Entra, or the scope does nothing.
  • Use Conditional Access for workload identities if licensed, and know its limit. It needs Workload Identities Premium and blocks apps outside known IP ranges or at detected risk, but only for single-tenant apps registered in your own tenant. Third-party multi-tenant apps like ConnectWise's aren't covered, so it wouldn't have stopped this attack.
  • Keep logs longer than seven days: route Entra logs to storage or a SIEM.
  • Ask vendors three questions: which permissions do you need and why, do you hold admin roles in our tenant, and how do you protect the credential that signs in to every customer?

This is the same lesson as npm supply chain attacks and this month's LiteLLM supply chain attack: you inherit the security of everything you plug in. For the email side of your defences, see our guide to DMARC for small business.

What isn't known yet: how the key was stolen, and how much was taken

As of 26 October 2026, how the credential was stolen is unconfirmed; ConnectWise says the exposure mechanism "remains under investigation" and is working with outside specialists. The true number of affected tenants isn't known either.

Huntress found no mailbox or file tampering in the two tenants it examined in depth, but directory reads leave no audit trail. Microsoft saw follow-on activity in several environments, including attempts to change privileges and bulk reads of Azure Key Vault secrets.

Both can be true: most tenants saw a token grab, a few saw much more. For the wider picture, see our roundup of cyber attacks in October 2026.

Frequently asked questions

Was backup data stolen in the ConnectWise SkyKick breach?

ConnectWise says its backup archives stayed encrypted and isolated, with no indication of compromise. The bigger question is your live Microsoft 365 data, which the attacker reached as the backup app, and only your tenant's logs can answer it.

Does MFA protect against OAuth app attacks?

Not against this kind. An app signing in with its own secret or certificate never meets an MFA prompt, which is why BleepingComputer, reporting Todyl's findings, said MFA was ineffective here. The protections are fewer, narrower app permissions, watching service principal sign-ins, and blocking new app secrets.

Should I delete the SkyKick app from my tenant?

Not as a first step. ConnectWise, Microsoft and Huntress all say to disable it and preserve evidence first, because deleting removes the consent and hampers investigation. Once your logs are saved, Sophos advises removing consent for the apps ConnectWise disabled, which suits a former customer.

The bottom line

The ConnectWise SkyKick breach didn't need a single stolen password, because apps don't use them. Every third-party app in your tenant holds a key, and the vendor keeps a copy. You can't control that copy, but you can control which doors it opens.

Start today with Step 1 above and send the list to your MSP. Want a second pair of eyes? Book a free consultation and we'll go through your tenant's enterprise apps with you: what to keep, restrict or remove.

Sources

Originally published on znovastudio.com.

Top comments (0)