Ravindra BagaleCourses & study guides Track your progress

Daily Cyber Incidents · 18 October 2026

ConnectWise Cloud Backup (SkyKick) breach: one stolen vendor app secret, hundreds of Microsoft 365 tenants

By , Cyber Security trainer LinkedIn Published: Last updated:

On 15 October 2026, someone signed in to customer Microsoft 365 tenants as the ConnectWise Cloud Backup app itself (earlier called SkyKick), using the app's own secret credential. Huntress saw sign-in activity in almost 1,000 tenants, and more than 300 sign-ins succeeded. No person was signing in, so MFA never came into the picture. How the attacker got the vendor's credential is not public yet.

Quick facts

  1. What: a stolen vendor app secret used to get Microsoft Graph tokens in many customer tenants.
  2. When: sign-ins on 15 October 2026; ConnectWise advisory on 16 October, updated 18 October.
  3. Scale: Huntress confirmed unauthorised sign-ins in 173 tenants it protects; later, more than 300 successful sign-ins out of almost 1,000 tenants.
  4. Response: ConnectWise disabled seven app identities on 17 October and suspended the backup service.
  5. Backups: ConnectWise says it has no evidence the stored backup archives were accessed.
  6. Still unknown: how the credential was stolen, and how much data was read.

The full story (English, मराठी, हिंदी)

Pick your language. The story, the defence steps and the checklist are the same in all three.

ConnectWise Cloud Backup (SkyKick): the full story

1. What happened

ConnectWise Cloud Backup (earlier called SkyKick) is a backup service that managed service providers (MSPs) use to back up their clients' Microsoft 365 mail, OneDrive, SharePoint and Teams data. To do that job, every client gives the backup app broad read and write permission in its Microsoft 365 tenant.

  • On 15 October 2026, someone signed in to customer tenants as the backup app itself, using the app's own secret credential, and received Microsoft Graph access tokens.
  • Huntress confirmed unauthorised sign-ins in 173 tenants it protects. Its later update said almost 1,000 Microsoft tenants saw sign-in activity from the attacker's server, and more than 300 of those sign-ins succeeded.
  • Microsoft Threat Intelligence called it an active supply-chain attack. It said the attacker likely abused permissions customers had already given the app, including the very powerful Directory.ReadWrite.All.
  • ConnectWise published an advisory on 16 October, disabled seven of its app identities on 17 October and suspended the backup service. It said it has no evidence the stored backup archives were accessed.
  • The reports do not yet say how the attacker got the vendor's credential, and how much data was read is still unclear. Educational framing only.

2. How the hack happened (public reporting only – high-level)

  1. When a company connects the backup app, Microsoft Entra ID creates an app identity (service principal) for it inside that company's tenant, with the permissions the admin approved once.
  2. The app proves who it is with a secret or certificate kept in the vendor's own environment. The same credential works in every tenant where the app is installed, so one stolen credential opens many companies at once.
  3. A script signed in as the app to tenant after tenant, a few seconds apart. This is an app-only sign-in: no user and no phone, so MFA never comes into the picture.
  4. The tokens carried the app's existing rights – read and write mail, files, Teams chats and directory data. Microsoft also saw Graph reconnaissance and attempts to add extra credentials as a backdoor.
  5. In about 50 tenants, ConnectWise Cloud Management apps gave themselves admin roles, mostly Exchange Administrator. In one tenant, a Cloud Management app made itself Global Administrator and added new secrets to two other trusted apps – an MSP management tool and Huntress's own security app. A secret added like this keeps working even after the vendor app is switched off. Huntress has not yet confirmed whether this earlier activity was the same operator.
  6. It was hard to see: these sign-ins show only on the separate Service principal sign-ins tab, not the default user sign-ins tab, and directory reads through Microsoft Graph leave no audit trail.

3. How to stop it / defend (lesson 30.2: IAM done right)

  1. Least privilege applies to apps and vendors too. Before you approve a third-party app, read the permissions it asks for. Ask the vendor why it needs directory write rights or admin roles.
  2. Remove apps you no longer use. ConnectWise asked partners to check even tenants with dormant SkyKick connections. An old, forgotten app with big permissions is an open door.
  3. MFA does not protect app identities. Protect them with the controls built for them: Conditional Access for workload identities (allow sign-in only from the vendor's expected locations), app management policies that block or shorten client secrets, and very few people holding the Application Administrator roles.
  4. The same idea in AWS: give a vendor an IAM role with an External ID and a narrow policy, never long-lived access keys. Watch CloudTrail for a vendor role that creates access keys or attaches policies to itself, and use IAM Access Analyzer to list everything shared outside your account.
  5. Alert on these events: an app adding itself to a directory role, an app changing other apps, or new credentials appearing on an app (SOC and SIEM, Chapter 31).
  6. During an incident: disable the vendor app (don't delete it), save the sign-in and audit logs early because they are kept only for a limited time, and remember that tokens already issued stay valid until they expire. Revoking user sessions does not stop app access.

4. How to take care so it won't happen again (checklist)

  • If you use ConnectWise Cloud Backup or Cloud Management (or older SkyKick apps), follow the ConnectWise advisory: keep the listed apps disabled until ConnectWise gives restore steps, and check service principal sign-ins from 13 October 2026 onwards.
  • Review the secrets and certificates on all your apps and remove any you did not create.
  • Remove any directory role you never meant to give an app.
  • Keep a list of every third-party app in your tenant or AWS account, its owner, its permissions and when it was last used.
  • Turn on alerts for app role changes and new app credentials.
  • Plan for a backup vendor outage: know how you would restore if the backup service is suddenly suspended.

Why MFA did not help

Think of two kinds of sign-in:

Sign-in typeWho signs inHow it proves itselfDoes MFA apply?
User sign-inA person (e.g. an employee)Password + phone prompt or OTPYes
App-only sign-inAn app (service principal)A client secret or certificateNo

The backup app used app-only sign-in, the same way the real backup service does. Anyone holding that secret looks like the app. That is why the defence is about app permissions, app secrets and app sign-in logs, not MFA.

The AWS angle: how to give a vendor access safely

The same risk exists in AWS when you let an outside company (a backup, monitoring or cost tool) into your account. Do it like this:

  1. Create an IAM role for the vendor. Never create an IAM user with long-lived access keys for them.
  2. In the role's trust policy, allow only the vendor's AWS account, and require an External ID that the vendor gives you.
  3. Attach a narrow policy: only the actions and resources the tool really needs.
  4. Watch CloudTrail for that role doing things it should never do, such as CreateAccessKey, AttachRolePolicy, PutRolePolicy or UpdateAssumeRolePolicy.
  5. Use IAM Access Analyzer to list every role and resource shared outside your account, and remove what you don't recognise.
  6. When you stop using the vendor, delete the role. A forgotten role is like a dormant SkyKick connection.

Example trust policy (the account ID and External ID are placeholders):

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": { "AWS": "arn:aws:iam::111122223333:root" },
    "Action": "sts:AssumeRole",
    "Condition": { "StringEquals": { "sts:ExternalId": "vendor-given-external-id" } }
  }]
}

Learn this properly in lesson 30.2 IAM Done Right.

Summary

QuestionAnswer
What was stolen?The backup app's own secret credential
How was it used?App-only sign-ins to many Microsoft 365 tenants
Why no MFA?No person signs in, so MFA does not apply
Main defenceLeast privilege for apps, few app secrets, alerts on app changes
During an incidentDisable the app (don't delete), save logs, check all app secrets
AWS versionIAM role + External ID, CloudTrail alerts, IAM Access Analyzer
Still unknownHow the credential was stolen, how much data was read

Quick quiz: check what you learned

  1. How did the attacker sign in to the tenants?

    1. As the backup app, using its secret
    2. As an admin, using a phished password
    3. As a guest, using a shared Teams link
    4. As a user, using a stolen phone OTP
    Show answer

    A. It was an app-only sign-in with the vendor app's own credential.

  2. Why did MFA not stop these sign-ins?

    1. No person signs in, so no MFA prompt
    2. The attacker had stolen every phone
    3. Microsoft had switched MFA off that day
    4. MFA only works for Google accounts
    Show answer

    A. App identities prove themselves with a secret or certificate, not MFA.

  3. During an incident, what should you do with the vendor app?

    1. Disable it, keep it, and save the logs
    2. Delete it at once and clear all logs
    3. Leave it on and reset user passwords
    4. Give it more roles to finish backups
    Show answer

    A. Disable (don't delete) and preserve sign-in and audit logs early.

  4. In AWS, what is the safer way to give a vendor access?

    1. IAM role with External ID, narrow policy
    2. Root user password sent over email
    3. Long-lived access keys for an admin user
    4. A public S3 bucket shared with the vendor
    Show answer

    A. A role with an External ID and least privilege, never long-lived keys.

Sources

  1. Huntress, Jonathan Semon: "ConnectWise (SkyKick) Vendor Credentials Abused in M365 Attacks", 16 October 2026 (updated 17 October 2026)
  2. BleepingComputer, Ionut Ilascu: "Hackers breach Microsoft 365 tenants via ConnectWise supply-chain attack", 17 October 2026
  3. The Hacker News, Ravie Lakshmanan: "Hackers Use Compromised ConnectWise Credential to Sign In to 173 Microsoft 365 Tenants", 17 October 2026 (quoting Microsoft Threat Intelligence and Todyl)
  4. ConnectWise Trust Center advisory: "Cloud Backup (formerly known as SkyKick) Service Interruption", first published 16 October 2026, updated 18 October 2026

This page is a defensive, educational summary of public reporting. It does not include attack tools, IP addresses or app IDs.

Learn it properly

These pages go deeper: