ConnectWise Cloud Backup Credential Compromise: 173 M365 Tenants Breached — Detection and Remediation Guide | Security Arsenal

Security researchers are tracking an active campaign in which unknown threat actors have abused a compromised Microsoft 365 credential belonging to ConnectWise Cloud Backup (formerly SkyKick) — a cloud-based backup and recovery platform built for managed service providers — to gain unauthorized access to at least 173 customer M365 tenants.

This is a classic third-party service principal compromise with supply-chain blast radius. Backup platforms like ConnectWise Cloud Backup are routinely granted broad, persistent access into customer tenants — often Global Admin-adjacent delegated permissions or powerful Graph API application consents — precisely because they need to read and restore mailboxes, OneDrive, SharePoint, and Teams data. When the credential protecting that access is stolen, every tenant that onboarded the service inherits the breach.

If your organization uses ConnectWise Cloud Backup, or if you are an MSP whose customers do, treat this as an active incident: assume the service identity has been abused, hunt for post-compromise activity in your tenant, and rotate/re-scope the trust relationship immediately. The sections below give you concrete detection content and a hardening script to do exactly that.

Technical Analysis

What Was Compromised

Product: ConnectWise Cloud Backup (formerly SkyKick), a SaaS backup and recovery service for Microsoft 365 marketed to and through MSPs.
Compromised asset: A Microsoft 365 credential associated with the ConnectWise Cloud Backup service — effectively the identity the platform uses to authenticate into customer tenants.
Impact: Unauthorized access to 173 downstream M365 customer tenants.
Attribution: Unknown threat actor; campaign is active at time of reporting.

How the Attack Works (Defender's View)

While the full intrusion chain has not been publicly detailed, campaigns of this type follow a well-understood pattern mapped to MITRE ATT&CK:

Valid Accounts — Cloud (T1078.004): The actor authenticates to victim tenants using the stolen ConnectWise service credential. Because this identity is supposed to log in, authentication alone rarely trips alarms — which is exactly why these compromises dwell.
Use of a trusted third-party relationship (T1199 — Trusted Relationship): The backup service's consent grants (frequently Mail.Read, Sites.FullControl.All, Directory.Read.All, or full Exchange/SharePoint application permissions) become the actor's access. No malware, no phishing, no exploit in the tenant is required.
Post-access objectives: Historically, actors holding this level of M365 access pursue mailbox data collection (T1114.002 — Email Collection), inbox rule manipulation for persistence and BEC staging (T1098.002 — Additional Email Delegate Permissions), new OAuth consent grants to actor-controlled apps for redundant persistence (T1550.001 / T1528), and discovery of users, groups, and licensing to identify high-value mailboxes.

Key Detection Surfaces

Because no CVE is involved — this is identity abuse, not software exploitation — detection must be behavioral and identity-centric:

Sign-in telemetry: ConnectWise service authentications originating from IP addresses, ASNs, or geographies outside the vendor's documented infrastructure; interactive logons against an identity that should only ever be non-interactive/service-to-service; impossible-travel and token-theft indicators.
Audit log (Unified Audit Log / AuditLogSignIns): Add service principal, Consent to application, Add app role assignment, New-InboxRule/Set-InboxRule, Add-MailboxPermission, and bulk MailItemsAccessed (or SearchQueryInitiatedExchange) events attributed to the backup service identity or occurring shortly after its anomalous sign-ins.
Exchange workload: Abnormal volumes of mailbox reads against executives/finance mailboxes via application-context access.

Exploitation Status

Confirmed active exploitation in the wild — 173 tenants confirmed accessed.
No CVE is associated with this campaign (credential compromise, not a vulnerability). No CISA KEV entry applies.
Threat actor motivation appears consistent with data theft / pre-BEC staging; organizations should also assess downstream ransomware-affiliate interest given the MSP channel exposure.

Detection & Response

Sigma Rules

The first rule targets interactive or anomalous sign-ins to third-party backup service accounts — a high-fidelity signal when tuned against the vendor's known IP ranges. The second catches persistence and collection behaviors (inbox rules, mailbox permissions, consent grants) performed by or immediately following the backup service identity. Both assume you are shipping Entra ID sign-in and audit logs into a SIEM (e.g., via the Azure log source categories below, adaptable to your pipeline).

YAML

---
title: Interactive or Anomalous Sign-In to Third-Party M365 Backup Service Account
id: 3f8c2a91-7d44-4b5e-9a21-6c1e8f4a2b07
status: experimental
description: Detects interactive authentication or sign-ins from unusual locations/infrastructure targeting service accounts associated with third-party M365 backup platforms (e.g., ConnectWise Cloud Backup / SkyKick). Such accounts should authenticate non-interactively from vendor IP space; interactive logons or foreign ASNs indicate credential theft, as seen in the 2026 ConnectWise Cloud Backup campaign affecting 173 tenants.
references:
  - https://thehackernews.com/2026/10/hackers-use-compromised-connectwise.html
  - https://attack.mitre.org/techniques/T1078/004/
  - https://attack.mitre.org/techniques/T1199/
author: Security Arsenal
date: 2026/10/15
tags:
  - attack.initial_access
  - attack.t1078.004
  - attack.t1199
logsource:
  product: azure
  category: signinlogs
detection:
  selection_account:
    UserPrincipalName|contains:
      - 'skykick'
      - 'connectwise'
      - 'cloudbackup'
      - 'backup'
  selection_interactive:
    IsInteractive: true
  condition: selection_account and selection_interactive
falsepositives:
  - Vendor support personnel performing legitimate interactive troubleshooting — verify with ConnectWise before dismissing
  - Recently re-onboarded tenants where setup requires interactive consent
level: high
---
title: M365 Mailbox Persistence or Consent Grant Following Third-Party Service Activity
id: 9e1b6d42-3a78-4f0c-b5d8-2f7a9c3e5d10
status: experimental
description: Detects inbox rule creation, mailbox permission delegation, or OAuth application consent events attributed to backup service identities or initiated within a short window of third-party service sign-ins — post-compromise behaviors consistent with the ConnectWise Cloud Backup credential abuse campaign (data collection, BEC staging, redundant persistence).
references:
  - https://thehackernews.com/2026/10/hackers-use-compromised-connectwise.html
  - https://attack.mitre.org/techniques/T1098/002/
  - https://attack.mitre.org/techniques/T1114/002/
  - https://attack.mitre.org/techniques/T1550/001/
author: Security Arsenal
date: 2026/10/15
tags:
  - attack.persistence
  - attack.collection
  - attack.t1098.002
  - attack.t1114.002
logsource:
  product: azure
  category: auditlogs
detection:
  selection_operations:
    OperationName:
      - 'New-InboxRule'
      - 'Set-InboxRule'
      - 'Add-MailboxPermission'
      - 'Add-RecipientPermission'
      - 'Consent to application'
      - 'Add service principal'
      - 'Add app role assignment to service principal'
      - 'Add delegated permission grant'
  filter_legit_admin:
    UserId|endswith: '@yourdomain.onmicrosoft.com'
  condition: selection_operations and not filter_legit_admin
falsepositives:
  - Legitimate helpdesk mailbox delegation and admin consent workflows — scope the filter to your actual admin UPN suffixes and change windows
level: high

Tuning note: Before deploying Rule 1, export the current IP ranges ConnectWise documents for its backup infrastructure and add a ClientIPUsed|cidr exclusion list. An un-tuned version of this rule will page your SOC every time the vendor adds a PoP. Rule 2's filter_legit_admin is a placeholder — replace the UPN suffix with your tenant's real admin naming convention, or better, maintain a watchlist of sanctioned admin objects and filter on that.

KQL Hunt — Microsoft Sentinel / Defender

This two-stage hunt first surfaces anomalous sign-ins to third-party backup identities (interactive logons, new IP/ASN/geo, token anomalies), then pivots into post-authentication audit activity within a 60-minute window of any suspicious sign-in.

KQL — Microsoft Sentinel / Defender

// Stage 1: Anomalous sign-ins to third-party M365 backup service identities
// Tune KnownBackupIPs to ConnectWise Cloud Backup's documented egress ranges for your region
let KnownBackupIPs = dynamic(["203.0.113.0/24", "198.51.100.0/24"]); // PLACEHOLDER - replace with vendor-published ranges
let SuspiciousSignins =
SigninLogs
| where TimeGenerated > ago(14d)
| where UserPrincipalName has_any ("skykick", "connectwise", "cloudbackup", "backup")
   or AppDisplayName has_any ("SkyKick", "ConnectWise", "Cloud Backup")
| extend IsInteractive = tostring(AuthenticationDetails) has "Interactive"
      or tostring(AuthenticationDetails) has "Password"
| extend NewIP = ipv4_is_private(IPAddress) == false
         and not(ipv4_is_in_any_range(IPAddress, KnownBackupIPs))
| where IsInteractive or NewIP or RiskLevelDuringSignIn in ("high", "medium")
| project SigninTime=TimeGenerated, UserPrincipalName, AppDisplayName, IPAddress,
          Location, IsInteractive, ResultType, RiskLevelDuringSignIn, CorrelationId;
SuspiciousSignins;
// Stage 2: Post-authentication activity within 60 minutes of a suspicious sign-in
SuspiciousSignins
| extend WindowStart = SigninTime, WindowEnd = SigninTime + 60m
| join kind=inner (
    AuditLogs
    | where TimeGenerated > ago(14d)
    | where OperationName has_any (
        "Consent to application",
        "Add service principal",
        "Add app role assignment to service principal",
        "Add delegated permission grant",
        "Update application",
        "Add service principal credentials")
    | extend TargetName = tostring(TargetResources[0].displayName)
  ) on $left.UserPrincipalName == $right.InitiatedBy.user.userPrincipalName
| where TimeGenerated between (WindowStart .. WindowEnd)
| project SigninTime, IPAddress, Location, TimeGenerated, OperationName, TargetName, Result
| order by SigninTime desc;
// Stage 3 (run separately in Defender XDR): inbox rule creation by non-admin identities
CloudAppEvents
| where TimeGenerated > ago(14d)
| where ActionType in ("New-InboxRule", "Set-InboxRule", "Add-MailboxPermission")
| where not(AccountDisplayName has_any ("admin", "helpdesk")) // tune to your admin naming standard
| project TimeGenerated, AccountDisplayName, ActionType, RawEventData, IPAddress
| order by TimeGenerated desc

Velociraptor VQL — Endpoint Artifact

The M365 tenant is the primary crime scene here, but if the actor pivoted to endpoints (downloaded PST exports, staged exfiltration archives, or dropped tooling after using backup access to identify high-value users), this hunt sweeps Windows endpoints for large archive staging and recent mass-download artifacts in user temp/downloads paths.

VQL — Velociraptor

-- Hunt for large archive staging and bulk data export artifacts consistent
-- with post-M365-compromise collection (PST exports, zipped mailbox dumps)
LET archive_globs = {
  SELECT FullPath FROM parse_array(data=[
    'C:/Users/*/Downloads/*.pst',
    'C:/Users/*/Downloads/*.zip',
    'C:/Users/*/AppData/Local/Temp/*.7z',
    'C:/Users/*/AppData/Local/Temp/*.rar',
    'C:/ProgramData/*.zip',
    'C:/ProgramData/*.pst'
  ])
}

SELECT FullPath, Mtime, Size, Size / 1048576 AS SizeMB
FROM foreach(row=archive_globs,
  query={
    SELECT FullPath, Mtime, Size
    FROM glob(globs=FullPath)
    WHERE Mtime > ago('14d')
      AND Size > 52428800   -- > 50 MB: bulk export characteristic
  })
ORDER BY Mtime DESC

Remediation & Verification Script (PowerShell)

Run this against each affected tenant with an account holding at least Cloud Application Administrator and Exchange Administrator rights. It inventories the ConnectWise/SkyKick service principal, enumerates every permission grant and credential attached to it, flags recently created inbox rules and suspicious mailbox delegations, and produces a report you can hand to ConnectWise and your IR retainer. Review the output before removing anything — some grants are required for the backup service to function and should be re-issued cleanly by the vendor rather than deleted blind.

PowerShell

#Requires -Modules Microsoft.Graph.Applications, Microsoft.Graph.Identity.SignIns, ExchangeOnlineManagement
# ConnectWise Cloud Backup tenant audit — run per affected tenant
# Connect first: Connect-MgGraph -Scopes "Application.Read.All","AuditLog.Read.All","Directory.Read.All"
#                Connect-ExchangeOnline

$report = @()
$vendorKeywords = @('skykick','connectwise','cloud backup','cloudbackup')

# 1. Locate vendor service principals and enumerate their app role assignments + credentials
$sps = Get-MgServicePrincipal -All | Where-Object {
    $n = $_.DisplayName.ToLower()
    $vendorKeywords | Where-Object { $n -like "*$_*" }
}
foreach ($sp in $sps) {
    $grants = Get-MgServicePrincipalAppRoleAssignment -ServicePrincipalId $sp.Id -All
    foreach ($g in $grants) {
        $res = Get-MgServicePrincipal -ServicePrincipalId $g.ResourceId
        $report += [pscustomobject]@{
            Type='AppRoleGrant'; SP=$sp.DisplayName; Resource=$res.DisplayName
            Permission=$g.AppRoleId; Created=$g.CreatedDateTime
        }
    }
    $sp.PasswordCredentials | ForEach-Object {
        $report += [pscustomobject]@{Type='SPCredential'; SP=$sp.DisplayName
            Resource='Password'; Permission=$_.KeyId; Created=$_.StartDateTime}
    }
    $sp.KeyCredentials | ForEach-Object {
        $report += [pscustomobject]@{Type='SPCredential'; SP=$sp.DisplayName
            Resource='Certificate'; Permission=$_.KeyId; Created=$_.StartDateTime}
    }
}

# 2. OAuth delegated permission grants (consent) tied to vendor apps
$oauth = Get-MgOauth2PermissionGrant -All | Where-Object {
    $_.ClientId -in $sps.Id
}
$oauth | ForEach-Object {
    $report += [pscustomobject]@{Type='DelegatedGrant'; SP=$_.ClientId
        Resource=$_.ResourceId; Permission=$_.Scope; Created=$null}
}

# 3. Suspicious inbox rules created in the last 30 days (forward/redirect/delete markers)
$cutoff = (Get-Date).AddDays(-30)
Get-EXOMailbox -ResultSize Unlimited -RecipientTypeDetails UserMailbox,SharedMailbox | ForEach-Object {
    $mbx = $_.PrimarySmtpAddress
    Get-InboxRule -Mailbox $mbx -ErrorAction SilentlyContinue | Where-Object {
        ($_.ForwardTo -or $_.RedirectTo -or $_.DeleteMessage) -and $_.WhenCreated -gt $cutoff
    } | ForEach-Object {
        $report += [pscustomobject]@{Type='InboxRule'; SP=$mbx
            Resource=$_.Name; Permission=("Fwd:{0} Redir:{1} Del:{2}" -f $_.ForwardTo,$_.RedirectTo,$_.DeleteMessage)
            Created=$_.WhenCreated}
    }
}

$report | Export-Csv -Path ".\ConnectWise_Tenant_Audit_$(Get-Date -Format yyyyMMdd).csv" -NoTypeInformation
$report | Format-Table -AutoSize
Write-Host "`nReview the CSV. Coordinate credential rotation and grant re-issuance with ConnectWise support BEFORE removing required permissions." -ForegroundColor Yellow

Remediation

There is no patch — this is an identity compromise. Remediation is about breaking the actor's access, re-establishing a clean trust relationship, and scoping third-party access to the minimum viable. Execute in this order:

Engage ConnectWise immediately. Contact ConnectWise support/security, reference the Cloud Backup (SkyKick) credential incident, and confirm whether your tenant is among the 173 affected. Follow the vendor's official guidance at https://www.connectwise.com and their Trust Center for incident-specific instructions and re-onboarding procedures. Do not assume silence means safety — ask directly.
Rotate and re-issue the service identity's credentials. In coordination with ConnectWise, remove all existing password and certificate credentials from the backup service principal in your tenant and allow the vendor to re-provision clean ones. Any credential the actor touched is burned.
Audit and revoke suspicious consent. Using the script above plus Entra ID → Enterprise Applications → Permissions, review every application and delegated grant associated with the vendor app. Revoke any grant you did not knowingly approve, especially Mail.ReadWrite, offline_access on unfamiliar apps, and grants created during the exposure window.
Hunt for persistence and staging. Run the KQL and inbox-rule checks above across at least 14–30 days of logs (extend to 90 if retention allows). Look specifically for: inbox rules with forward/redirect/delete actions, new mailbox delegates, Add service principal credentials events, and anomalous MailItemsAccessed volume. If your license includes it, review Audit (Premium) retention for the full exposure period.
Enforce Conditional Access on third-party identities. Third-party service accounts frequently bypass MFA/CA by design. Where the vendor supports it, require certificate-based auth, named-location restrictions to vendor IP space, and block interactive sign-in for the service identity outright. An identity that never needs a browser should never be able to use one.
Apply least privilege to the re-provisioned service. When ConnectWise re-onboards you, scrutinize the requested scopes. Backup read/restore does not inherently require Directory.ReadWrite.All or tenant-wide Exchange impersonation. If the consent screen asks for more than the product documentation justifies, push back in writing.
Reset exposed user credentials and enforce phishing-resistant MFA. If mailbox contents were accessed, assume harvested credentials and session material. Force password resets for users whose mailboxes show access evidence, revoke refresh tokens (Revoke-MgUserSignInSession), and verify FIDO2/passkey or number-matching MFA enrollment.
Breach-notification assessment. If mailbox data containing regulated information (PHI, PCI, PII) was accessed, engage counsel now — HIPAA, state breach statutes, and contractual notification clocks may already be running. Preserve Unified Audit Log exports before retention windows close.
Update your third-party risk register. Add this incident to your vendor risk file, and extend the lesson: enumerate every third-party app with tenant-wide consent (backups, email hygiene, CRM sync, e-discovery) and apply steps 5–6 to all of them. Your blast radius from the next MSP compromise is decided by what you consent to today.

The Bottom Line

This campaign is a reminder that in M365, the perimeter is consent. A single stolen credential at a trusted MSP vendor handed an actor legitimate, low-noise access to 173 tenants — no exploit required. The defenders who catch this class of attack are the ones who baseline what their third-party service identities should look like (non-interactive, fixed IP space, predictable API patterns) and alarm on the deviation. Do that baselining this week, run the hunts above, and treat every tenant-wide consent grant in your environment as a loaded weapon that needs a guard.

Related Resources

Security Arsenal Managed SOC Services AlertMonitor Platform Book a SOC Assessment soc-mdr Intel Hub

ConnectWise Cloud Backup Credential Compromise: 173 M365 Tenants Breached — Detection and Remediation Guide