ConnectWise Cloud Backup Attack on Microsoft 365: Entra Checks to Run

In mid October 2026 an attacker took control of ConnectWise Cloud Backup application identities (formerly SkyKick) and used the permissions customers had already granted them to sign in to Microsoft 365 tenants. Anyone who ever connected Cloud Backup or Cloud Management should keep those apps disabled, export Entra logs, and review service principal sign-ins, credentials, roles and consent grants.

No user password was phished. The attacker signed in as the vendor's app, which is why this matters beyond ConnectWise customers: every backup, management or monitoring tool an MSP connects to a tenant holds the same kind of standing, app-only access. This post covers the verified timeline, how those permissions become a supply chain path, the Entra checks Microsoft documents, and what would have helped.

What happened

Dates come from the vendor and responder posts named in each row.

Two details differ between sources. Microsoft dates the spraying from 10 October across eight organisations; Huntress saw it on 13 and 14 October across four law firms, and each sees different telemetry. ConnectWise dates discovery to 14 October; Microsoft says public reports surfaced on 15 October. Neither changes what defenders should check.

Who did it

Microsoft's 21 October report assesses that Storm-0940, which it calls a "China-state aligned actor" active since 2021, was responsible. Microsoft says the group used ARTEX, an openly available multi-agent penetration testing framework, to automate the operation, and that it attempted sign-ins to more than 2,250 tenants at up to 2,900 attempts per minute. ConnectWise's 21 October update repeats the attribution.

How the attacker got the vendor credential is still open: ConnectWise says it is under investigation, and Microsoft defers to ConnectWise on initial access.

How many tenants

These numbers measure different things, so do not add them up, and a successful sign-in is not data theft. Huntress notes Graph directory reads leave no audit record, so impact cannot be fully ruled out. ConnectWise says it has no evidence its encrypted backup archives were accessed.

What Microsoft and ConnectWise said

Microsoft Threat Intelligence first described this as an active supply chain attack in a post on X, reported by BleepingComputer, and said the attacker "likely abused permissions previously granted by customers to the application" (as quoted by The Record). BleepingComputer reports that the X post named Directory.ReadWrite.All among them. Microsoft's longer 21 October report does not list permission names; it refers to highly privileged roles and app roles. Treat the specific permission as reported, not confirmed in Microsoft's own blog.

ConnectWise's advisory says the shared Cloud Backup credentials are no longer valid, but warns that "previously issued access tokens may remain usable until they expire." It also says it cannot tell from its own systems whether a given partner or customer tenant was affected. That is the key point for administrators: the vendor cannot do this review for you.

How MSP tool permissions become a supply chain path

Microsoft's MITRE mapping in its report describes the technique in one line: compromising a multi-tenant OAuth application to reach downstream customer environments. Here is how that works in plain terms, without attack detail.

1. The vendor registers one app in its own tenant. ConnectWise's apps are published from a single tenant, which Todyl identifies as "ConnectWise S-K LLC" (tenant ID 3f9cd7a0-127a-4ed4-bf06-2f830d5616b7).
2. Each customer consents once. When an admin connects the backup service, Entra creates a service principal for that app in the customer's tenant and records the permissions granted. Backup needs broad read access to mail, OneDrive, SharePoint and Teams. Management tools need write access to settings and directory objects.
3. The app authenticates as itself. Backup jobs run without a user. Microsoft's documentation calls these service principal sign-ins: the app presents its own certificate or secret in the OAuth client credentials flow. No user means no MFA prompt, and Todyl saw Conditional Access recorded as "notApplied."
4. The credential lives with the vendor. Huntress explains that the app's client assertion credential sits in the vendor's tenant. Whoever holds it can request tokens for every tenant where the app is consented.
5. Standing permissions do the rest. If an app can write to the directory, it can grant itself a role or add a secret to another app. Huntress observed exactly that pattern in two tenants. Each new secret is a way back in that survives the vendor rotating its own credential.

Remote monitoring and management (RMM) agents, professional services automation tools, Microsoft 365 management consoles and security tools follow a similar model: install once, grant broad rights, run unattended across many customers. That is what makes an MSP efficient, and why one vendor credential can open many doors. Huntress warned that a foothold in one customer environment could reach others. We covered the provider side of third party risk in the IDCF cloud ransomware post; this incident is the identity side of the same problem.

A common confusion: Microsoft's granular delegated admin privileges (GDAP) govern the admin roles a partner's people get in a customer tenant, which Microsoft describes as "least-privileged access" that is granular and time-bound. GDAP does not govern the permissions a third party app holds through consent, so it does not cover this path.

Who is affected

Huntress said the second wave focused on policy, national security, trade and critical mineral organisations; Microsoft lists wider sectors, from aerospace and defence to legal and think tanks.

The application IDs ConnectWise asks partners to disable and verify are below. Match on the ID, not the display name; ConnectWise and BleepingComputer note older tenants may show the apps as "SkyKick Cloud Manager."

ConnectWise lists three attacker IPs: 144.172.64[.]128, 144.172.64[.]99 and 144.172.64[.]60. Huntress adds 144.172.94[.]243 for the password spray. Microsoft explicitly says not to limit your review to published IPs, and ConnectWise says an IP match alone does not confirm compromise.

What to do now: Entra checks step by step

These steps follow ConnectWise's technical workflow, Microsoft's 21 October guidance and Microsoft Learn documentation. You need at least Reports Reader to read sign-in logs and Cloud Application Administrator or Application Administrator to review and change apps. Do them in order; preserving evidence comes first.

1. Preserve logs before you change anything

Todyl warns that Entra ID Free keeps logs for only 7 days, so 15 October activity may already be gone. Export what you have now from Entra ID > Monitoring & health > Sign-in logs and Audit logs, or stream them to a Log Analytics workspace. Microsoft's report asks you to start from 15 October, or 1 October where records exist.

2. Find every ConnectWise and SkyKick service principal

In the Entra admin center, go to Entra ID > Enterprise apps > All applications, set the application type filter to all applications, and search each app ID. Todyl recommends exporting each app's granted permissions before you touch it. With Microsoft Graph PowerShell:

Connect-MgGraph -Scopes "Application.Read.All","Directory.Read.All"

$ids = @(
  "506e08f9-6e9a-4da4-942b-a099a03644ae","2399d300-6fca-4e6a-a686-399fefe75b83",
  "24205314-2b89-4e07-a2a4-579e898a5640","b78f6a77-d4e5-46fb-87e5-d1648bd02519",
  "0de14c77-b9b0-4137-9360-34878a929827","412dcf96-176d-4b3a-a1b0-4981ad66971e",
  "b2b55f5b-7758-4719-8d8f-88ae172e6bdb","c921256f-04a7-44e8-9b2a-69c33929ba19"
)
foreach ($id in $ids) {
  Get-MgServicePrincipal -Filter "appId eq '$id'" |
    Select-Object DisplayName, AppId, Id, AccountEnabled, AppOwnerOrganizationId
}

# Anything else published from the ConnectWise S-K LLC tenant (per Todyl)
Get-MgServicePrincipal -All |
  Where-Object { $_.AppOwnerOrganizationId -eq "3f9cd7a0-127a-4ed4-bf06-2f830d5616b7" } |
  Select-Object DisplayName, AppId, AccountEnabled

3. Disable, do not delete

Microsoft, ConnectWise, Huntress and Todyl all say the same thing: disable the apps and leave them disabled until ConnectWise sends formal reconnection instructions. Microsoft's report specifically warns against deleting enterprise applications as a first response. Deleting removes the consent record you need for the investigation and forces a fresh consent later.

In the portal, open the app, select Properties, set Enabled for users to sign-in? to No, and save. Microsoft Learn says this sets the service principal's accountEnabled property to false and "prevents all tokens from being issued." The Graph PowerShell form is:

Connect-MgGraph -Scopes "Application.ReadWrite.All"
$sp = Get-MgServicePrincipal -Filter "appId eq '506e08f9-6e9a-4da4-942b-a099a03644ae'"
Update-MgServicePrincipal -ServicePrincipalId $sp.Id -AccountEnabled:$false

Disabling stops new tokens, not tokens already issued. Todyl says existing tokens stay valid for up to 90 minutes, and revoking user sessions does nothing here because no user is involved.

4. Review service principal sign-ins

This is the check ConnectWise asked for first. Go to Entra ID > Monitoring & health > Sign-in logs and open the Service principal sign-ins tab. Huntress stresses that the user sign-in tabs will not show this activity. Filter by application ID, then look at the IP address, resource and status of each row. Microsoft's documentation notes that rows are aggregated when the service principal, status, IP and resource match, so expand each row to see every timestamp.

Microsoft says to review successful and failed sign-ins separately and investigate any unfamiliar source; Huntress notes the vendor's own traffic comes from Microsoft and Azure ranges. In Log Analytics or Microsoft Sentinel:

AADServicePrincipalSignInLogs
| where TimeGenerated > datetime(2026-10-01)
| where AppId in ("506e08f9-6e9a-4da4-942b-a099a03644ae",
                  "2399d300-6fca-4e6a-a686-399fefe75b83",
                  "24205314-2b89-4e07-a2a4-579e898a5640",
                  "b78f6a77-d4e5-46fb-87e5-d1648bd02519",
                  "0de14c77-b9b0-4137-9360-34878a929827",
                  "412dcf96-176d-4b3a-a1b0-4981ad66971e",
                  "b2b55f5b-7758-4719-8d8f-88ae172e6bdb")
| project TimeGenerated, ServicePrincipalName, AppId, IPAddress,
          ResourceDisplayName, ResultType, ServicePrincipalCredentialKeyId
| order by TimeGenerated asc

Microsoft's report also names Defender XDR tables: OAuthAppInfo for which apps are present and what they hold, and EntraIdSpnSignInEvents with GraphAPIAuditEvents for sign-ins and the Graph activity that followed.

5. Review app permissions

For each ConnectWise app, open Permissions and check the Admin consent tab, which shows tenant-wide grants. Microsoft Learn lists the Graph PowerShell calls to read both kinds of grant:

$sp = Get-MgServicePrincipal -Filter "appId eq '506e08f9-6e9a-4da4-942b-a099a03644ae'"

# Application permissions (app roles) the service principal holds
Get-MgServicePrincipalAppRoleAssignment -ServicePrincipalId $sp.Id -All |
  Select-Object ResourceDisplayName, AppRoleId, CreatedDateTime

# Delegated permission grants (consent grants)
Get-MgOauth2PermissionGrant -All |
  Where-Object { $_.ClientId -eq $sp.Id } |
  Select-Object ConsentType, Scope, PrincipalId

Microsoft's app consent playbook lists the highest impact permissions, including Application.ReadWrite.All, Directory.ReadWrite.All, RoleManagement.ReadWrite.Directory and any app-only permission that allows writes. A ConsentType of AllPrincipals covers everyone in the tenant. Record what you find before revoking anything.

6. Review consent grants and role changes in the audit log

Go to Entra ID > Monitoring & health > Audit logs and filter from 13 October onward. Huntress names three activities that matter most: Add member to role, Update application and Add service principal credentials. Microsoft's playbook adds Consent to application. Look at the initiating actor: a service principal adding itself to a role, or modifying a different app, is the pattern both Huntress and Microsoft describe.

AuditLogs
| where TimeGenerated > datetime(2026-10-13)
| where OperationName in ("Add member to role", "Update application",
                          "Add service principal credentials",
                          "Consent to application",
                          "Add app role assignment to service principal")
| extend InitiatorApp = tostring(InitiatedBy.app.displayName),
         InitiatorAppId = tostring(InitiatedBy.app.appId)
| where isnotempty(InitiatorApp)
| project TimeGenerated, OperationName, InitiatorApp, InitiatorAppId,
          TargetResources, Result

7. Check every app's secrets and certificates, not just ConnectWise's

Huntress found secrets added to an MSP management app and to Huntress's own app in one tenant, set to expire in 2028. Disabling the ConnectWise apps does not remove credentials planted on other apps. Review Certificates & secrets on all app registrations and the credentials on all service principals, and remove any added since 13 October that you cannot account for. Include federated credentials, per ConnectWise.

8. Check roles, Conditional Access and Exchange

ConnectWise's guide asks you to review privileged role assignments and new owners, recent Conditional Access changes including exclusions and named locations, and Exchange items such as inbox rules, forwarding, transport rules and mailbox delegation. Remove any directory role a ConnectWise or SkyKick app holds that you did not grant on purpose, especially Global Administrator.

9. Report and record

Record findings per tenant and report suspicious activity to SecurityPartnerSupport@ConnectWise.com, without passwords, keys or tokens. Pass the guidance to whoever administers each customer tenant.

What would have helped

Nothing below would have stopped a vendor's credential from being stolen. These are the practices that shrink what a stolen vendor credential can reach and shorten how long it goes unnoticed.

Practices any team can use

• Keep an inventory of third party apps and what they hold. Run the permission export in step 5 for every multi-tenant app quarterly, and remove what nobody uses.
• Grant the least an app needs. Microsoft's report asks for least privilege on multi-tenant application permissions and consent grants. A backup tool needs read access to data. It rarely needs to write to the directory or manage roles. Push vendors to document why each write permission exists.
• Alert on app-only privilege changes. Microsoft recommends monitoring credential additions, privilege assignments and unusual app-only activity. The audit query in step 6, run as a scheduled alert, flags exactly the event Huntress saw: a service principal adding itself to Global Administrator.
• Use Privileged Identity Management for roles. BleepingComputer cites an MSP on Reddit whose PIM alert on 15 October caught a SkyKick app, unused for years, assigning itself Exchange Administrator.
• Retain logs long enough. Seven days is not enough for a story that took a week to surface. Stream sign-in, audit and Microsoft Graph activity logs to a workspace; Todyl notes Graph activity logs need Entra ID P1 or P2 and are not retroactive.
• Restrict who can manage app credentials. Huntress suggests limiting Application Administrator and Cloud Application Administrator role holders and using application management policies to restrict client secrets and cap credential lifetimes.
• Know the limits of Conditional Access. Huntress suggests Conditional Access for workload identities, but Microsoft Learn says those policies apply only to single tenant service principals registered in your tenant; "third-party SaaS applications, including multitenant apps, are not covered." They also need Workload Identities Premium licenses. Use them for your own apps and do not assume they protect vendor apps.

For a general response template when a supplier you depend on is compromised, see our compromised dependency playbook. Attackers automating with AI agents, as Microsoft describes here, is also a theme of our post on AI-found vulnerabilities.

Where Safeguard fits

The boundary first: Safeguard does not monitor Entra ID, does not read service principal sign-ins, and would not have detected this attack or the stolen vendor credential. The steps above happen in Microsoft's tools.

Where Safeguard helps is the software you build and ship, a second supply chain next to your identity one:

• Know what is in your code and images. safeguard scan --dir ., --image <name> or --sbom <file> builds an inventory and matches it against vulnerability databases, with results as JSON under ./output. The platform shows which projects contain a given component and version, the software equivalent of step 2 above.
• Gate changes with policy. Policies and gates evaluated in the platform let you block or require approval for risky components, rather than relying on standing trust.
• Keep a human on every action. The Safeguard CLI's assistant can edit code and run commands, but asks first in its default modes (/permissions offers Ask, Accept edits, Plan, Auto and Strict). The desktop and phone apps can send work to a computer running the CLI and approve each command. That is the opposite of the always-on, app-only access at the centre of this incident.
• Fix with review. Reachability analysis helps you rank what matters, and autonomous remediation can open fix pull requests, off by default, so a person reviews each change.

Zero-Day Discovery and Gold

Zero-Day Discovery looks for previously unknown flaws before a CVE exists, in an agentic mode and a deterministic scanner mode. Findings are issued as SGZ advisories before they reach public CVE databases. It covers seven package ecosystems.

Gold Open Source (gold.safeguard.sh) is free and needs no login. It offers searchable CVE intelligence with CVSS, EPSS, KEV status, affected and fixed versions and a recommended safe version, plus a free read API and a CI gate GitHub Action. Gold Registry (registry.safeguard.sh, paid) provides hardened drop-in components and container images held to zero exploitable critical or high CVEs, SLSA L3 or above, Sigstore-signed, with evidence pages. An artifact loses its badge if it regresses.

Neither applies directly here: this was a stolen application credential, not a vulnerable package, and there is no CVE or SGZ advisory for it. The shared habit is pulling components from a curated, signed source and rebuilding quickly, so a compromised supplier means swapping a known good part rather than starting from nothing.

Common mistakes

• Looking only at user sign-ins. This activity appears only on the Service principal sign-ins tab. The user tabs will look clean.
• Deleting the app. Microsoft, ConnectWise, Huntress and Todyl all say disable instead. Deletion destroys consent records and complicates restoration.
• Revoking user sessions and calling it done. No user was involved. Disabling the service principal is what blocks new tokens, and issued tokens can still live for a short time after that.
• Stopping at the ConnectWise apps. Planted secrets on other apps survive the vendor's credential reset. Step 7 is the step that removes them.
• Assuming the IP list is complete. Microsoft says not to limit review to published IPs. Look for any non-Microsoft source.
• Waiting for the vendor to say you are clear. ConnectWise says it cannot see into partner or customer tenants. The review is yours.

FAQ

What was the ConnectWise supply chain attack?

An attacker gained control of ConnectWise Cloud Backup and Cloud Management application identities and used permissions customers had already granted to sign in to Microsoft 365 tenants. Microsoft calls it a supply chain compromise and attributes it to Storm-0940.

Was my backup data stolen?

ConnectWise says its encrypted backup archives show no sign of compromise and it has no evidence they were accessed. Data inside your Microsoft 365 tenant is a separate question, which only your own log review can answer.

Why didn't MFA stop it?

The attacker authenticated as the application using the OAuth client credentials flow. No user signed in, so there was no MFA prompt, and Todyl saw Conditional Access recorded as not applied.

How did the attacker get the ConnectWise credential?

Nobody has said publicly. ConnectWise says the mechanism remains under investigation, and Microsoft defers to ConnectWise on initial access.

Does GDAP protect against this?

GDAP limits the admin roles a partner's staff get in your tenant. It does not limit the permissions a third party app holds through consent, which is the path used here.

Can Conditional Access for workload identities block vendor apps?

Per Microsoft Learn, no. Those policies apply only to single tenant service principals registered in your own tenant. Multi-tenant and third party SaaS apps are not covered.

Does Safeguard detect compromised OAuth apps?

No. Safeguard does not monitor Entra ID or OAuth apps. It inventories and scans the software you build and ship and keeps a person approving each change its assistant makes.

Fix it without waiting for upstream

In incidents like this one, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would have helped

None of these demos show this incident, Entra ID or a ConnectWise app. Each shows a real flow built on what this incident argues for: access granted on purpose, scoped to the task, with a person in the loop.

The first demo connects Claude to the Safeguard MCP server with OAuth and lets you choose which tools Claude can use. It is consent done the way this incident suggests: you pick exactly what an integration can do, rather than accepting a broad grant you will forget about.

Click through it at your own pace, or open it full screen.

The second demo sets up the Safeguard runner on your own machine, approves it with its device code, then scans from the terminal. Compare that with a vendor app whose credential lives in someone else's tenant: here the machine that does the work is yours, and you approve it explicitly before it runs anything.

Click through it at your own pace, or open it full screen.

The third demo is a real Android session: work is sent to a computer running the CLI and the command is approved on the phone with Allow once, Allow for turn or Deny. In this incident, an app granted itself Global Administrator with nobody asked. In this flow, nothing runs until a named person taps Allow.

Click through it at your own pace, or open it full screen.

To try it on your own repositories, download Safeguard and follow the CLI docs. For the wider month's picture, see October 2026 security incidents and what would have helped.

Quick check

Sources

• Microsoft Security blog: AI-driven, large-scale nation-state campaign using ARTEX enables supply chain compromise (21 Oct 2026)
• ConnectWise Trust Center: Cloud Backup (formerly known as SkyKick) Service Interruption advisory
• Huntress: Vendor credential enables unauthorized access
• Todyl: Investigation of unauthorized access through the ConnectWise Cloud Backup Microsoft 365 app
• BleepingComputer: Hackers breach Microsoft 365 tenants via ConnectWise supply chain attack
• The Record: ConnectWise suspends Cloud Backup service after supply chain attack
• Microsoft Learn: Sign-in logs in Microsoft Entra ID
• Microsoft Learn: Service principal sign-in logs
• Microsoft Learn: Review permissions granted to enterprise applications
• Microsoft Learn: Disable user sign-in for an application
• Microsoft Learn: App consent grant investigation playbook
• Microsoft Learn: Conditional Access for workload identities
• Microsoft Learn: Granular delegated admin privileges (GDAP) introduction
• Microsoft Threat Intelligence post on X (did not load for us; cited through BleepingComputer and The Record)

Last reviewed: 22 October 2026. This is a developing story; check the linked advisories for the latest status.