ConnectWise Breach and Storm-0940: Microsoft 365 Tenant Takeover

Last updated: 26 October 2026. Sources are listed at the end.

In mid-October 2026, attackers stole a credential from ConnectWise Cloud Backup, the backup service formerly called SkyKick. They then signed in to customer tenants as the backup app itself. No user password or MFA prompt was involved. In a few tenants, this became a Microsoft 365 tenant takeover: a ConnectWise app gave itself Global Administrator and planted secrets on other apps.

On 21 October, Microsoft Threat Intelligence attributed the attack to Storm-0940, a China state-aligned group. Microsoft says the group attempted sign-ins to more than 2,250 tenants after the ConnectWise compromise. It also says the same actor used ARTEX, an open-source AI penetration-testing framework, to automate attacks on hundreds of organisations.

This guide is for MSPs and for any company that consented to a ConnectWise or SkyKick app. It covers what is confirmed, how to spot a Microsoft 365 tenant takeover, and how to clean up.

Free tool: Can criminals send email in your company’s name? Check SPF, DKIM and DMARC with our email security checker.

The short answer

• Search Entra ID for the seven ConnectWise app IDs listed below. If any exist, disable them, but do not delete them.
• Then check every app and service principal for secrets or certificates added since 13 October 2026. Remove any you did not create.
• Also look for apps holding directory roles, especially Global Administrator or Exchange Administrator.
• Export your Entra sign-in and audit logs today, because retention is short.
• Finally, do not reconnect Cloud Backup until ConnectWise gives formal restoration instructions.

What happened, in plain English

Cloud Backup is a multi-tenant app. When an MSP onboards a customer, an admin grants the app broad permissions in that customer’s tenant. The app then signs in with its own secret, not as a person. Therefore, anyone holding that secret can act as the app in every tenant that consented to it.

That is what happened here. Microsoft says this did not come from a flaw in Microsoft products. Instead, the attacker abused trust that customers had already granted. Microsoft told BleepingComputer that the attacker likely abused existing permissions such as Directory.ReadWrite.All. That permission is enough to change users, groups and roles.

ConnectWise has not said how the credential was stolen. According to The Hacker News, the company has not confirmed whether a product vulnerability played a part.

Timeline: confirmed vs reported

A note on the numbers. Some early roundups dated the stolen-credential sign-ins to 13 October and gave 162 to 173 tenants. However, Huntress puts the app sign-ins on 15 October, while 13–14 October was a password spray. We could only confirm the figure of 162 tenants, which comes from Huntress. Huntress later saw activity from the attacker’s IP in almost 1,000 tenants, with over 300 successful. Microsoft’s figure of more than 2,250 tenants counts attempted sign-ins, not successful takeovers. In fact, Microsoft says most of the targeting failed.

Where ARTEX fits

Microsoft describes ARTEX as an open-source, multi-agent framework written in Go that can use any AI model. Its agents can run reconnaissance through to data theft with little human input. Microsoft says Storm-0940 used it to automate attacks. In some cases, the group moved from targeting to privileged cloud access in under three hours.

So, should you worry about AI here? The practical lesson is speed rather than magic. The attacker still relied on a stolen credential, existing permissions and weak app hygiene. Those are the things you can fix, and they decide whether a Microsoft 365 tenant takeover succeeds.

ConnectWise CEO Manny Rivelo told Reuters that a China state-aligned group appears to be responsible. He also warned that ConnectWise’s containment does not remove access an attacker may already have inside a customer tenant.

Am I affected by this Microsoft 365 tenant takeover?

You are in scope if any of these apps exist in your tenant. Huntress and BleepingComputer list all seven; Microsoft’s hunting queries cover three of them.

Older tenants may show these as “SkyKick Cloud Manager”. For that reason, always search by application ID, not by name.

Check in the Entra admin center

1. Go to Entra ID > Enterprise apps > All applications.
2. Remove the default application type filter, then paste each application ID into the search box.
3. For any match, open Permissions to see admin-consented API permissions.
4. Next, open Roles and administrators in Entra ID and look for service principals among the role holders.

Check with Microsoft Graph PowerShell

The cmdlets below follow Microsoft Learn syntax. We parsed them with PowerShell 7.4 but could not run them against a live tenant. They only read data.

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

$cwAppIds = @(
  '506e08f9-6e9a-4da4-942b-a099a03644ae', # Cloud Backup (formerly 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
)

foreach ($id in $cwAppIds) {
  Get-MgServicePrincipal -Filter "appId eq '$id'" -Property Id,AppId,DisplayName,AccountEnabled |
    Select-Object DisplayName, AppId, Id, AccountEnabled
}

While you are there, list every third-party app in the tenant. Microsoft’s own apps will also appear, so review the list by owner.

$myTenant = (Get-MgContext).TenantId
Get-MgServicePrincipal -All -Property Id,AppId,DisplayName,AppOwnerOrganizationId,AccountEnabled |
  Where-Object { $_.AppOwnerOrganizationId -and $_.AppOwnerOrganizationId -ne $myTenant } |
  Sort-Object DisplayName |
  Format-Table DisplayName, AppId, AppOwnerOrganizationId, AccountEnabled

To see what a given app is allowed to do, check both delegated grants and application permissions:

$sp = Get-MgServicePrincipal -Filter "appId eq '506e08f9-6e9a-4da4-942b-a099a03644ae'"
Get-MgOauth2PermissionGrant -All -Filter "clientId eq '$($sp.Id)'" |
  Select-Object ConsentType, PrincipalId, Scope
Get-MgServicePrincipalAppRoleAssignment -ServicePrincipalId $sp.Id |
  Select-Object ResourceDisplayName, AppRoleId, CreatedDateTime

Was my tenant touched? Log checks

First, preserve evidence. Entra ID Free keeps sign-in and audit logs for only 7 days. P1 and P2 keep them for 30 days. As a result, Free tenants have already lost the 15 October records. P1 and P2 tenants should export now, before mid-November.

Service principal sign-ins

In the portal, go to Monitoring & health > Sign-in logs and open the Service principal sign-ins tab. The default tab shows only user sign-ins, so this step is easy to miss. Then filter by each application ID and look for IP addresses outside Microsoft ranges.

Microsoft suggests reviewing from at least 15 October and, where logs exist, from 1 October. This needs the beta module, Microsoft.Graph.Beta.Reports:

Get-MgBetaAuditLogSignIn -All -Filter "createdDateTime ge 2026-10-01T00:00:00Z and signInEventTypes/any(t: t eq 'servicePrincipal') and appId eq '506e08f9-6e9a-4da4-942b-a099a03644ae'" |
  Select-Object CreatedDateTime, AppDisplayName, IPAddress, @{n='ErrorCode';e={$_.Status.ErrorCode}} |
  Export-Csv .\cw-sp-signins.csv -NoTypeInformation

Repeat for each app ID. An ErrorCode of 0 means success. However, a clean result does not prove safety, so disable the app anyway.

Credentials planted on other apps

This is the most important check for a Microsoft 365 tenant takeover. In the case Huntress studied, the attacker added secrets to an MSP tool and to Huntress’s own app. Those secrets would keep working even after ConnectWise reset its credential. The script below lists every secret or certificate added since 13 October:

$since = [datetime]'2026-10-13T00:00:00Z'
Get-MgServicePrincipal -All -Property Id,AppId,DisplayName,PasswordCredentials,KeyCredentials |
  ForEach-Object {
    $obj = $_
    @($obj.PasswordCredentials) + @($obj.KeyCredentials) |
      Where-Object { $null -ne $_ -and $_.StartDateTime -ge $since } |
      ForEach-Object {
        [pscustomobject]@{
          Name  = $obj.DisplayName
          AppId = $obj.AppId
          KeyId = $_.KeyId
          Start = $_.StartDateTime
          End   = $_.EndDateTime
        }
      }
  } | Format-Table -AutoSize

Run the same logic with Get-MgApplication for your own app registrations.

Directory changes

Next, pull audit events about credentials, roles, consent and owners since 13 October:

Get-MgAuditLogDirectoryAudit -All -Filter "activityDateTime ge 2026-10-13T00:00:00Z" |
  Where-Object { $_.ActivityDisplayName -match 'credential|certificate|secret|role|consent|owner' } |
  Select-Object ActivityDateTime, ActivityDisplayName, Result,
    @{n='InitiatedByApp';e={$_.InitiatedBy.App.DisplayName}},
    @{n='InitiatedByUser';e={$_.InitiatedBy.User.UserPrincipalName}} |
  Export-Csv .\entra-audit-since-13oct.csv -NoTypeInformation

Pay close attention to rows where a ConnectWise or SkyKick app is the initiator.

Indicators published by named sources

Huntress and Microsoft both stress that none of these is unique to the actor. Treat them as leads, not proof.

Mailbox access

Microsoft says the actor read and exfiltrated email through Graph in some tenants. In contrast, Huntress found no mail or file access in the tenants it reviewed in detail. Note that Graph directory reads leave no audit record at all.

In Exchange Online PowerShell, search the unified audit log. The MailItemsAccessed event is on by default for E3 and E5 users. The free-text search on the app ID is only a rough first pass:

Connect-ExchangeOnline
Search-UnifiedAuditLog -StartDate "2026-10-13 00:00:00z" -EndDate "2026-10-26 23:59:59z" -Operations MailItemsAccessed -FreeText "506e08f9-6e9a-4da4-942b-a099a03644ae" -SessionCommand ReturnLargeSet -ResultSize 5000 |
  Export-Csv .\mailitemsaccessed-cw.csv -NoTypeInformation

Search-UnifiedAuditLog -StartDate "2026-10-13 00:00:00z" -EndDate "2026-10-26 23:59:59z" -Operations New-InboxRule,Set-InboxRule,UpdateInboxRules,Add-MailboxPermission,Set-Mailbox -ResultSize 5000 |
  Select-Object CreationDate, UserIds, Operations

Get-Mailbox -ResultSize Unlimited |
  Where-Object { $_.ForwardingSmtpAddress -or $_.ForwardingAddress } |
  Select-Object UserPrincipalName, ForwardingSmtpAddress, ForwardingAddress, DeliverToMailboxAndForward

The same searches are available in the Microsoft Purview portal under Audit.

How to contain and clean up

If you find signs of a Microsoft 365 tenant takeover, work in this order.

1. Preserve first. Export logs before you change anything, as Microsoft and ConnectWise both advise. Then contain quickly.
2. Disable, don’t delete. In the app’s Properties, set “Enabled for users to sign-in” to No. Deleting removes the consent and some evidence.
3. Remove planted credentials. Delete any secret or certificate you cannot explain, using the KeyId from the list above.
4. Strip unexpected roles. Remove directory roles held by ConnectWise or SkyKick apps that you did not grant on purpose.
5. Wait for the vendor. Keep the apps disabled until ConnectWise publishes restoration steps.

PowerShell versions of steps 2 and 3 (these make changes, so use them carefully):

Connect-MgGraph -Scopes "Application.ReadWrite.All"
Update-MgServicePrincipal -ServicePrincipalId $sp.Id -BodyParameter @{ accountEnabled = $false }
Remove-MgServicePrincipalPassword -ServicePrincipalId $sp.Id -BodyParameter @{ keyId = '<KeyId-from-the-list-above>' }

One caution: disabling an app stops new tokens, but tokens issued earlier stay valid until they expire. Also, revoking user sessions does nothing for app-only access.

Preventing the next Microsoft 365 tenant takeover

Conditional Access for workload identities sounds like the answer, yet it has a hard limit. Microsoft’s documentation says it covers only single-tenant apps registered in your own tenant. Third-party multi-tenant apps, such as ConnectWise’s, are not covered. It also needs Workload Identities Premium licences. Even so, use it for your own automation apps.

For vendor apps, the stronger controls are these:

• Review every admin consent at least twice a year, and remove apps you no longer use.
• In addition, limit who holds Application Administrator and Cloud Application Administrator roles.
• Use application management policies to restrict client secrets and cap their lifetime.
• Turn on Entra ID Protection alerts for risky service principals where your licence allows.
• Finally, ask each backup vendor what access it needs and how it will report a breach.

Backup tools need wide read access by design. That makes your backup vendor part of your attack surface, not just your recovery plan. A Microsoft 365 tenant takeover through a trusted vendor app bypasses the MFA you rely on for users.

India angle

We could not find a CERT-In advisory on this incident as of 26 October. Still, many Indian MSPs and companies use ConnectWise tools. If you confirm unauthorised access and your organisation falls under CERT-In’s April 2022 Directions, the 6-hour reporting rule applies. Separately, DPDP Rule 7 sets a 72-hour breach notice to the Data Protection Board. However, it applies only from May 2027, so it is not in force yet. Our free DPDP readiness check can help you prepare. For background on the wider month, see our Black October fact-check.

Quick checklist

• ☐ Searched Entra ID for all seven ConnectWise app IDs
• ☐ Exported Entra sign-in and audit logs
• ☐ Disabled (not deleted) any ConnectWise or SkyKick apps found
• ☐ Listed secrets and certificates added since 13 October on every app
• ☐ Removed unexplained credentials and app-held directory roles
• ☐ Reviewed service principal sign-ins from 1 October
• ☐ Checked MailItemsAccessed, inbox rules, forwarding and mailbox permissions
• ☐ Reviewed all third-party app consents
• ☐ Asked your backup vendor about permissions and breach notice
• ☐ Kept Cloud Backup disconnected until ConnectWise’s restoration guidance

A stolen vendor credential is a reminder that third-party access needs the same review as user accounts. Want an outside check of your Microsoft 365 apps, consents and admin roles? Our VAPT services include cloud configuration review. Teams preparing for ISO 27001 can also use our readiness assessment to build supplier risk reviews into their process.

Sources

• Microsoft Threat Intelligence: Storm-0940 uses ARTEX agentic AI and ConnectWise supply chain compromise
• Huntress: ConnectWise (SkyKick) vendor credential abused in M365 attacks
• BleepingComputer: Hackers breach Microsoft 365 tenants via ConnectWise supply chain attack
• The Hacker News: ConnectWise resets credentials as Cloud Backup restoration is prepared
• iTnews: Stolen ConnectWise SkyKick credential exposed Microsoft 365 tenants
• Microsoft Learn: Conditional Access for workload identities
• Microsoft Learn: Use MailItemsAccessed to investigate compromised accounts
• Microsoft Learn: Entra data retention

Need help finding and fixing exposed systems? Our VAPT services find unpatched and exposed systems before attackers do, and our free website safety check grades your site in seconds. Contact us for a quote.